The Burning Questions

[Matthew Tuck]

Otieno Ododa wrote:

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

Parse trees are a tree that the a compile converts the program into.  So
for example, if you had a statement "a := 3" for assigning 3 to "a", you
might get a tree something like:

                                    ...
                                     |
                                     v
                                 statement
                                     |
                                     v
                                assignment
                                |        |
                                v        v
                                a        3

right at the top of the tree is "program".

Syntactic sugar is something added to programming languages to make them
shorter, and therefore more readable and writeable.  It's really any
feature which maps onto another, but is shorter than the other.  The
shorthand only covers a subset of the cases covered by the feature it
maps onto however, which is why both features are present.

A "for" loop could be considered a shorthand for a "while", since it
applies to less situations but is easier to write than if you had to
write it with "while".  When a language gets more advanced features
there is often more to consider, so it gets longer to write.  You can
support the older feature, which is simpler, and map it onto the more
complex feature.

The important point is that it is a mapping, so it is a not another
feature for doing the same sort of thing.  You often see languages where
you can do A with B and C with D.  A better scheme is doing A with B and
A or C with D.

Static and dynamic binding refers to whether or not the libraries are
stored within the program, or in a DLL (dynamically linked/bound
library).  I think you referred to the VB DLLs, and the tradeoffs
between the two.

I'll try to get some really good definitions onto the glossary in short
time.

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

Output to C is more difficult than JVM I would imagine since you still
have to write C libraries to make up for the lack of portability of C. 
I think C++ is implied, there aren't many C-only compilers anymore.  C++
features can be used as needed.

Tweaking compiler generated output is not recommended - it tends to be
garbage.  If you've ever seen obfuscated C you'll know what I mean. 
There's no indentation, which could be improved with a pretty printer,
but also after optimisation it could be really hard to interpret or
change.  We could leave common optimisations to the C compiler but long
term I think we should look to putting them all in the Ultra compiler.

What is it you don't like about Java?  We do you think could be better?

> I haven't the faintest idea what either is, but I'll look them up

Flex is a tool for taking a scanner specification and generating a
scanner, Bison does the same for parsers.  Basically the idea is to
automate the compiler generation process.  The early stages of the
compiler are relatively easy to automate - the further on you get the
harder it is.  But tools exist for generating entire compilers from
specifications.

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

The main obstacles have been learning how to maintain the flexibility of
text editing.  My opinion is that the advantages are so great they
offset the losses.  And I think of more things that can be done with
them everyday.

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

An intelligent editor basically moves the scanner and parser into the
editor rather than the compiler.  But it doesn't have to stop there. 
Semantic errors such as type errors could also be caught while you're
typing the program - think of all the slack time between keystrokes. 
When you reference a variable that does not exist, an unobtrusive but
visible red circle appears to the left of the statement.  Declare the
variable and it will disappear.  The rest of the compiler could also be
done in the background.  By the time you go to compile, most might
already by done.  The is called incremental compilation by the way. 
Some work might need to be discarded, but there's power to burn, as long
as typing gets the highest priority.

How much is would speed up is up for grabs though.  Most compile time is
spent in optimisation and code generation I believe.  I don't think that
mnemonics are the way to go.  It's been tried with C and APL, it's quite
hard to read.  COBOL is too much is the other direction.  Most languages
tend to get a good mix.  It's often said that a program is read much
more than it's written.

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

I don't think there's any doubt of not having String support.  In my
proposal, Strings are sequences, somewhat like in C.  There would be
heaps of sequence operations, and also string-specific operations.

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