The Burning Questions

[Otieno Ododa]

I apologize for not being very active. I am very interested in helping with the project, but among other things, I'm somewhat lost by some of the things being discussed (parse trees, syntactic sugars, static vs dynamic library bindings; I think I understand the last issue). As I figure out what's going on, I may be able to contribute more.

-----Original Message-----
From:	Tanton Gibbs [SMTP:thgibbs@Harding.edu]
Sent:	Sunday, November 15, 1998 11:15 PM
To:	ultra-devel@bay-city.net
Subject:	Re: The Burning Questions

>>There are going to be heaps of questions that need to be answered at
>some point, so I've tried to wrack my brain trying to think of them to
>get them out in the open.  Many are like religious issues, some are
>arbitrary and some probably have clear cut answers.  But which is which?
>Anyway, here goes:

>>* The Compiler
>>
>>What will be the target platforms:  JVM, Our own VM, Win32, Mac, Unix,
>Output To C, Something else?
    I'm afraid to say the JVM because of much of the legal battles/copyright
up in the air quality of Java not to mention that Java is still not the
fastest language to be executed, although it is gaining on compiled
programs.  I think we should output either to C or to Unix.  The reason not
Win32 is that because most people who do development and would need an
experimental compiler do so at a university that usually uses Unix or VMS.
Win32 is not used a lot for expiramental research on language/compiler
design
>>

[Otieno Ododa]  

I think output to C gives a measure of portability while making speed less of a problem. The resulting output could be tweaked by the programmer, if he/she knew C. Perhaps, also, we could consider output to C++ (perhaps that was implied in the original suggestion) ? I don't like Java for many reasons, none of them particularly good reasons ;) . My few experiences with Java left me wishing for something different.

>>What tools shall we write?
  As few as possible.  We should rely on previously written tools like Flex
and Bison if at all possible.

[Otieno Ododa]  

I haven't the faintest idea what either is, but I'll look them up ... intelligent editors seems to me to be a good idea, but the only reasons I can think of come from a beginner's perspective really.


>>What optimisations can we do?
  I think we'll have to know more about the structure of the language and
intermediate code before we start categorizing these.
>>
>>What will be the general structure of the compiler?
  Boy, this one is vague :)  I'm sure the standard front-end -> back-end
both using symbol-table will be the general structure.

[Otieno Ododa]  

An intelligent editor might take some of the burden of a compiler. If all source was saved in "somewhat compiled form", this might speed compilation, perhaps. Use a symbol table, shortened names for commands, something like assembly mnemonics which translate to actual commands. I don't know how sensible all that sounds, and I apologize if it sounds dumb ;) .

>>* 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.
>>
  We have to have a standard string class, I/O classes, OS classes,
Container classes, memory management if not garbage collected, general
search and sort, and math...that, naturally, is minimal.

[Otieno Ododa]  

A string class is a must, please ;) ! I despised the lack of 'useful' string functions in C, and I haven't played with anyone's string classes in C++. I heard somewhere that up to %80 of a program is for handling strings. Why make that harder for the programmer than it needs to be ?


>>How much and what syntactic sugars should we use?
  Enough, but not too much...how's that for a vague answer!

[Otieno Ododa]  

I don't have the faintest idea what a syntactic sugar is.

>>* The Project

[Otieno Ododa]  

More comments on the rest later. It's late, and I'm tired ;) .