The Burning Questions

[Hans-Dieter Dreier]

Somehow I missed your mail concerning  "The Burning Questions".
With regard to the goal of  "distribute early, distribute often" I
suggest that we start with the utmost minimum to output "hello world".
Sure this will only be a toy, but a working, extendable one.

Here's what I think about it:

* The Compiler

> What will be the target platforms:  JVM, Our own VM, Win32, Mac, Unix,
Output To C, Something else?

Our own VM - because it's by far easiest to implement and has none of
the limitations that output to existing platforms has. Make it OS
indepedend for a start (use only standard C libraries that exist
everywhere). I got Win32 on my machine, so I would like it to run there
(maybe in a DOS box).

> What will be the uncompiled source distribution format?

C++ Source code for the kernel, plain ASCII for input to Ultra compiler

> What will be the compiled module distribution format?

I wouldn't specify any at this moment.

> What tools shall we write?

For a start: Compiler running some very simple syntax, interpreting the
results

> Do we support static library binding, dynamic library binding, or
both?

For a start: no libraries at all.

> What optimisations can we do?

For a start: none

> What will be the general structure of the compiler?
> What compilation techniques shall we use?

Combination of state machine and table driven LR(1) bottom up parser,
with hooks for special treatment of tokens:
a) treatment when recognized
b) treatment when executed (= interface to runtime system)

I'll explain that in more detail in another thread.


> * The Language

> What facilties should be in the library?  Bear in mind that since we
are an
> open source project, we will let anybody include the code in their
compiler.
> Hence, one reason against large libraries (the need to write them) is
gone.

The absolute minimum.

> How much and what syntactic sugars should we use?

None

> Too many other things to list here ...

> * The Project

> What sort of mechanisms will be used with code trees, and how will
they be regulated?

Code trees will only be used internally for a start, since there isn't
any persistent storage for them in the beginning (just plain ASCII).

> Will there be any standard distribution?

Later

> Will there be voting on issues as to the direction of the project.  If
so, will they be binding on the standard distribution, and who can vote?

I'd say that there may be proposals and a list of subprojects (with a
description of mutual dependencies: what has to be done first). The
actual direction of the project will be influenced by the preferences
set by the implementers. There should be a (brief) discussion on the
contents of standard distributions, and if there a differences, everyone
can make their own. It would be nice if we maintained compatibility as
far as possible.
Voting by code is a good idea. This should minimize the town council
effect. I expect that general discussions like those that we are having
at the moment will eventually grow more concrete as we arrive at some
consensus.

> How will the project be structured?

Don't know. Am I right that there are about 4 *active* members at the
moment? Maybe this issue can wait till there are more.

> In what order should things be attempted?

For the quickest possible start:

1. Kernel
1.1 Compiler, VM, rudimentary memory management (without memory reclaim
at the start)
     to be written in C++
1.2 Syntaxes & runtime for a single-namespace assembler like language
1.3 Lambdas (function support)
1.4 Namespace support
1.5 Class support
...
2. Runtime system (in parallel to kernel)
3. Tools
3.1 Editor (as soon as plain text won't be sufficient any longer, and
expressiveness of language grows)
3.2 Debugger (as soon as complexity grows)

Some time soon there might be the need for a graphical environment. That
will be a challenge. Maybe for some time we can make do with a character
oriented simulation of a window system (looks ugly but can be made
highly portable). After that, IMHO there has to be a Win32 interface.
(Win32 IS the standard, after all, and I'm using it ;-). Those who
dislike Mircosoft will surely come up with a KDE interface (or X windows
or ... you name it) pretty soon.

> How do we attract more members?

I noticed Ultra by a posting in comp.lang.misc.

> How can we be more accessible to members?

I think it's sufficient how it is, for the time being. But besides the
mailing list there should be a discussion forum employing a tree
structure instead of the message archive. I found a nice solution for
this in http://www.HyperNews.org.  If that won't do (I think we need our
own web server for this), there is a list of similar producs:
http://www.HyperNews.org/get/www/collab/conferencing.html