Re: Program compression



On 8 Sep., 01:46, seeWebInst...@xxxxxxxxxxxxxxxx (Robert Maas,
http://tinyurl.com/uh3t) wrote:
From: thomas.mer...@xxxxxx
Guess what my favorite language is?

I asked Google Groups to show me the last 100 articles you posted,
and it showed me several articles in comp.lang.c, a few articles in
comp.lang.c++, and just one in comp.lang.basic.misc, so I would
guess that C is your favorite language.

Guess aggain :-)

Besides this, not all concepts make sense when transfered to
other languages.

I agree. However a lot of data/processing tasks are of common types
that *ought* to be do-able by *any* general purpose langauge. So
there are two different ways to compare languages:
- How well do they make it easy to write software for the vast
majority of D/P tasks, i.e. all the common types of tasks.
- What specialized/unusual types of tasks do they *also* support
especially well, by mechanisms that are much better for these
specific types of tasks than the general mechanisms are.
Now it's a matter of personal judgement which tasks should be
considered "common" and which "unusual". IMO at the very least the
following ought to be considered "common":

I will use this list as checklist for Seed7 features.

- Numerical calculations, including linear algebra, trigonometry, ...

http://seed7.sourceforge.net/manual/types.htm#integer
http://seed7.sourceforge.net/manual/types.htm#bigInteger
http://seed7.sourceforge.net/manual/types.htm#rational
http://seed7.sourceforge.net/manual/types.htm#bigRational
http://seed7.sourceforge.net/manual/types.htm#float
http://seed7.sourceforge.net/manual/types.htm#complex

- STDIO (Standard Input/Output, i.e. from/to the controlling terminal)

http://seed7.sourceforge.net/manual/file.htm#Simple_read_and_write_statements
http://seed7.sourceforge.net/manual/file.htm#Standard_input_and_output_files
http://seed7.sourceforge.net/manual/file.htm#Access_to_operating_system_files

- File I/O, both text and binary

http://seed7.sourceforge.net/manual/file.htm#Basic_input_and_output_operations
http://seed7.sourceforge.net/manual/file.htm#Input_and_output_with_conversion
http://seed7.sourceforge.net/manual/file.htm#User_defined_file_types

- GUI (Graphical User Interface, i.e. mouse/trackball/whatever and keyboard)

A graphics library is there. There is no separate documentation for
the graphics library interface besides comments in the source:
http://seed7.sourceforge.net/prg/draw.htm

A GUI library is missing but there is a (simple) interface library
to the gtkserver (the documentation for that is in the Seed7
package). If somebody could take that task, I would be happy.

- CGI or alternative (JSP/ASP/PHP/...) for Web server applications

CGIs can be written in Seed7. Documentation and examples are
currently missing.

- Text editing, both plain-text and "word processing"

Not clear what this means. Seed7 has the type string (see:
http://seed7.sourceforge.net/manual/types.htm#string)
and libraries containing string and file scanner functions:
http://seed7.sourceforge.net/manual/file.htm#Scanning_a_file
http://seed7.sourceforge.net/prg/scanfile.htm
http://seed7.sourceforge.net/prg/scanstri.htm

- Interface to relational databases

This is currently missing. I plan to do that in an integrated way
(like Linq).

The following points are possible with Seed7:

- Dynamically-allocated pointy structures (data points to other data)
- Ability to effect new intentional data-types by re-interpretation
of existing true data types (this is trivial in most languages)
I would also like some/most/all of the following to be included:
- Ability to define new true data types, thereby converting an
intentional data type into a true data type, thereby allowing
the different data types to be mixed in a container without
confusion (this is trivial in any language that allows
definition of new classes in the sense of OOP)

- Ability to interface to OS API, such as for "directly" controlling devices

Because of portability this is a difficult issue. With a direct OS
API people would start to write unportable programs. I prefere when
the OS API is provided in an OS independend way. That means: The OS
functions that can be supported under linux/bsd/unix and windows are
available. Sometimes (e.g.: console, keybord, graphic and other
areas) it is necessary to use driver libraries to compensate the OS
differences. I am not very motivated to support access to
linux/bsd/unix or windows only interface functions.

- Ability to compile to native-code libraries, and later load&link them

The current Seed7 implementation does not support this, but I see no
major roadblock. The Seed7 compiler just needs to create a library
instead of an executable.

Alternatively: Ability to compile to efficient byte-code libraries, ditto

Seed7 does not have any byte-code.

- Ability to develop (write and test) code on a line-by-line basis

I see this as IDE feature and not as language feature.

- Ability to dynamically load libraries into an already-running application

Loading libraries has the same portability issues as an interface to
the OS API. Up to now I did not make plans for such a feature. IMHO
at least the loading interface needs to be provided in an OS
independend way.

- Multi-threading: system-supported true threads and/or "green-threads"

Seed7 can be compiled which hopefully makes the support for true
threads easier.

- Ability to receive and process command-line parameters (CLP)

http://seed7.sourceforge.net/examples/echo.htm

- Ability to invoke and control sub-processes that run other programs with CLP

Such things as the system() call. The Seed7 compiler (comp.sd7) uses
such an interface to invoke the C compiler and the linker. Naturally
such an interface has also portability issues and I make some effort
that the C compiler and the linker can be called in a portable way.

- Ability to open&use local streams to/from other processes on same machine
- Ability to open&use network sockets for TCP (and optionally UDP)

Sockets are present in Seed7.

- Formal mechanisms for distributed applications, such as RPC RMI SOAP etc.

Currently not present.

- Compiling/assembling to generate a stand-alone "executable" for a target OS

Yes. This is done with the Seed7 compiler (comp.sd7) which compiles
Seed7 to C which is further compiled to machine code.

- Options for managing dynamically-allocated pointy structures:
- Don't bother (for short-lived applications that won't run out of memory)
- Manual freeing (when programmer can "know" precisely when to free memory)
- Reference count (efficient for applications that don't have pointer loops)
- Advanced mark-and-sweep (required to avoid "memory leak" of pointer loops)

Seed7 tries to manage memory automatically, except for some cases
where memory needs to be managed manually. In the future some
mechanism will support automatically managed memory also for this
cases.

- Ability to build new functions/closures/continuations at runtime

Seed7 has some support for this. See:
http://seed7.sourceforge.net/manual/types.htm#category
http://seed7.sourceforge.net/manual/types.htm#reference
http://seed7.sourceforge.net/manual/types.htm#ref_list
http://seed7.sourceforge.net/manual/types.htm#program

- Ability to extend the syntax of the language, either directly at
the top level of processing source, or indirectly by explicitly
calling a parser whose output (parse tree) can then be used to
build executable code and then install it in the already-running
application; thus the ability to effect a DSL (Domain-Specific Language)
fully integrated into the standard language.

Seed7 uses syntax descriptions. See:
http://seed7.sourceforge.net/manual/syntax.htm

- Ability to be called from a standard FFI (Foreign Function Interface)

When the Seed7 compiler is changed to generate a library instead of
an executable this is possible. It is the job for the other language
who wants to call Seed7 functions to get them from the library.

- Ability to load and call other-language procedures via a standard FFI

This is a popular requirement. It has also the same portability
issues (unless the library is also portable) as a direct OS API.
I would like to support access to library functions in a portable
way. Therefore I am interested: What libraries / functions you
would see as necessary to be available.

As always: I am happy with every feedback.

Greetings Thomas Mertes

Seed7 Homepage: http://seed7.sourceforge.net
Seed7 - The extensible programming language: User defined statements
and operators, abstract data types, templates without special
syntax, OO with interfaces and multiple dispatch, statically typed,
interpreted or compiled, portable, runs under linux/unix/windows.
.



Relevant Pages

  • Re: C Programmer Needed
    ... >>>The second approach is to extend the language to allow the programmer ... it would be a cleaner solution to extend the language. ... >>>the compiler this is to mark the array as volatile. ... > whole program compilation, including the libraries. ...
    (comp.programming)
  • Re: Languages with well-integrated Foreign Function Interface to learn from?
    ... for scripting language FFIs. ... it seems that this interface wouldn't ... and that the standard libraries could not be ... same types of metadata which is often available only to the compiler (AKA: ...
    (comp.compilers)
  • Re: Teaching new tricks to an old dog (C++ -->Ada)
    ... > no time there was a fully compiant C compiler available. ... Let's address the Ada side first. ... compiler for C, Ada, or any other language. ... Ada certainly provides facilities useful for writing libraries, ...
    (comp.lang.ada)
  • Re: Teaching new tricks to an old dog (C++ -->Ada)
    ... > no time there was a fully compiant C compiler available. ... Let's address the Ada side first. ... compiler for C, Ada, or any other language. ... Ada certainly provides facilities useful for writing libraries, ...
    (comp.lang.cpp)
  • Re: OT: Requesting C advice
    ... language designers made the language ... Since when is C a virtual machine language? ... Every compiler I've used compiles C to native machine code for the ... libraries was not pleasant. ...
    (Fedora)