The Burning Questions

[Matthew Tuck]

Hans-Dieter Dreier wrote:

> 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.

I don't see a problem with this.

> 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).

I'm not sure that's the case.  The JVM would be the easiest to implement
since it's already been implemented.  But there are other reasons that
have been given of course.

For the purposes of bootstrapping a compiler, I don't see a problem
making it platform independent.
 
> > What will be the uncompiled source distribution format?
> C++ Source code for the kernel, plain ASCII for input to Ultra compiler

I was thinking more long term.  From what seems to be the consensus,
this would be the USSID.
 
> > What will be the compiled module distribution format?
> I wouldn't specify any at this moment.

Again, this would be like UPPID, except for only one module, and with no
entry point.

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

Well that's pretty obvious.  =)  What about long term?

>> Do we support static library binding, dynamic library binding, or
>> both?
> For a start: no libraries at all.

Sure, but again, long term ...

>> What optimisations can we do?
> For a start: none

Same.

>> 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

Are you talking short term again here?

> 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).

I was referring to code tree as in having the source on a server where
source can be checked in or out.

>> 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.

Well 12 months ago, there was just me.  Now there are about 10 people on
the list.  I expect exponential growth for a couple of years at least. 
It doesn't hurt to talk about it, so we'll be prepared when the time
comes.

> 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.

I think the important thing is to design the user interface cross
platform.  The Mozilla project (i.e Netscape Communicator Open Source)
are doing this at the moment.  The platform-dependent code is isolated
in a module that wraps around the widget code.  Win32 is certainly true,
but under Unix there is GTK, Qt, Lesstif, and even plain X.  I'm not
certainly one for supporting Qt as I believe their license is not in the
spirit of open source even if it is classified as such.

> 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

I think that you can't get the sort of functionality you want without a
web server.  I'm looking for a way to automate the message archive, at
the same time it could be threaded at least.

Getting a Web server would be important so we could run CVS to be able
to maintain versions of the source code.  It appears CVS is freely
useable.

-- 
     Matthew Tuck - Software Developer & All-Round Nice Guy
                              ***
       Check out the Ultra programming language project!
              http://www.box.net.au/~matty/ultra/