More comments

[Matthew Tuck]

Tanton Gibbs wrote:

> Syntactic Sugar - I am a big fan of minimal features.  I think that the
> idea of 10 ways to do the same thing is bad, especially, if like SQL,
> each way has different performance gains.  While syntactic sugars are
> theoretically a mapping, many times this is not the case.  We have to
> make sure that there is not a difference in performance and that each
> sugar is truly a boon and not just another neat way of doing something.
> For example, a for loop really does save time, but the common die if X
> structure is not necessarily better than if( X ) die.

There are two points to make here about the for loop.  The first is that
the most important thing is for shorthands for be semantically a
mapping.  As for performance, that is another issue.  You can either
leave it as a shorthand and code generate smarter, make the optimiser
smart enough to convert the longhand to the most efficient form, or
both.  It depends on the shorthand.

As for the die if X as opposed to if X die, I think it is beneficial to
do what shorthands do best, make things shorter.  We shouldn't support
English-style ten ways to do things.  But in my opinion, if there is a
significant gain in screen real estate, leading to improved readability
(which reverse form does when it replaces closed form, but not open
form), and it is a common construct (which it is), then it is OK.

> JVM - I still really have problems with the idea of compiling to JVM.
> First, we would be dealing with a dynamic language that is in its
> infancy.  Secondly, we would be dealing with a VM that was designed for
> a specific language, one that is not ours.  Finally, there are many
> differnt implementations of the JVM that don't conform to any standard,
> even though SUN has a standard.  The court case will hopefully straigten
> out MS, but there are still other VM manufacturers.

I would think the JVM would be backwards compatible, so I don't see it
at a major problem.

We might have problems in that the JVM doesn't allow certain things to
be done, or makes it really hard to do.  We really need someone who's
looked at it more.  The Java Native Interface might help here.

I don't know that there is a problem with different VMs, as long as
there is a JVM for each platform that supports us.  Of course, it would
be better if it didn't have to be downloaded.

> Here is what I recommend.  My idea is to have a platform independent
> binary object file that could be further compiled to any platform.  Not
> the idea of Just In Time compiling, and not the "C" object file idea,
> but a fully linked "slim binary" that could be compiled further to any
> platform by the compiler.  Therefore, the programmer could tell the
> intelligent editor to compile to Pentium II architecture or SUN SPARC
> arcitecture and it will be able to do both from the same binary object
> file.

How does this sound.  You start with source files, one for each module. 
Then you compile each, getting compiled module files.  Then you can link
a set of compiled module files.  The output is an aggregated
platform-independent file, with inter-module optimisation if you
desire.  Then we can implement subcompilers and VMs.

I think we should definitely keep our options open though, as someone
might want to write direct back-ends.

I think the "Just-In-Time" compiling is pretty much the same as slim
binaries.  Definitely not C object files, they are too low-level to do
inter-module optimisations.  I cringe at the thought of all the bloated
C executables out there (and they say C is efficient).

> Intelligent Editor - We have to be really careful with this idea, which
> is a good one.  The part we have to be careful with is not to interfere
> with the programmer.

Yes, that is something I am concerned with.  You can change the way they
do what they want to do, but not what they want to do.  Here's some bad
intelligent editor features: bad indenting, can't save unless it
compiles, interfering (possibly multiple) dialogs.

> VB is case in point, it is too restrictive towards mistakes.  If
> a variable is not declared, or the syntax is not correct then VB will
> cause enormous interference to the programmer.  I like the idea of a
> small symbol out to the side, perhaps color coordinated, to tell the
> type of error and allow the programmer to immediately fix it or
> wait until later.  However, some types of syntax errors are hard to
> catch, such as no semicolon.  Also, undeclared variables and functions
> are also hard to handle because of libraries that could be linked to.
> Keeping it compiled as you go is also a good idea, however I'm about out
> time, so I'll write back later.

Scanning and parsing errors in intelligent editors depends fairly
intimately on the details of how you edit the program, I don't want to
get into that yet.  Definitely type checking errors are the easiest to
pick up using this system.  Also take into account that since a checker
handles errors better than a parser, we could actually move some parse
errors into the checker by letting some things through the parser and
catching them in the checker.

Yes, there is a problem here.  Libraries aren't really as much of a
problem though, because you'd have to give the full name unless you used
an Ada like if.  Say you reference an A.  The compiler looks for an A,
sees it somewhere.  The reference is hooked onto that A.  Then you
declare an A.  It's hooked onto the wrong variable.  There are several
options I can think of:

(a) Rehook onto the local variable.  I'm not convinced this is best.  If
had lower nested classes using the higher a their semantics would
change.
(b) Give warnings that there is a conflict and do some default
behaviour, or ask what to do.
(c) Don't allow the same name to be used in nested classes as is used
higher up.  Some languages do this.

I think either b or c, or some combination.  Since we are using an
intelligent editing, we could comfortably do a global rename.

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