Re: [Oopic-compiler-devel] Testing...

[D. D. M. <dd...@mc...>]

In-line reply style....(and these are just my opinion).

> Also, some possible things we might want to discuss:
>
> * What level of C language support are we aiming for?  Full ANSI C (minus
>   floats etc) ?

K&Rv1 at minimum, downgraded to fit the micro.

No matter which script(s) we choose, we will have the same problems that
Savage is hammered for--"but you didn't include ____".

I suggest starting with one (see below).

> * What other languages do we want to support?

No need to do a visual one, seems that Scott's well on the way with that
one.

I'm indifferent to additional scripting syntax (see below).

> * Do we want a mode that allows "standard" OOPic BASIC/C/JAVA to be
>   compiled?

This is just another way of asking what language to support.

> * What platforms do we want to support?

I'm agnostic about this.  A DOS/Windows command line is sufficient.  I can
use UltraEdit and Makefiles for my 'IDE'.

> * What implementation language(s) do we want to use?

I've been around long enough to have, at one time, established fluency in
languages whose initials would consume much of the alphabet.  C is probably
common denominator.

> * Should we use a compiler compiler, such as flex/bison/lex/yacc ?

(target of 'see below')
Why not.  These would allow the automatic generation of much of the effort
based on a grammer definition.  And as we would publish the inputs to these
tools, a knowledgabel person could independantly extend the scripting tool
to suit themselves.

I'was reading a quick into to compiler writing using these tools just
recently.  I'll look the URL up.

> * What extra features do we want to support?

I might suggest the script clearly differentiate between the VC and the
interpreted code.
Something like the Delphi unit divisions (e.g., implementation,
initialization, finalization keywords -- reference
http://delphi.about.com/library/weekly/aa061802b.htm)

Include files.  Other standard C-preprocessor stuff.

Libraries of routines, both VC and slow-script stuff.


> * What bugs in the existing languages do we specifically want to address?

Dennis Clark's bug list should be inspected.  Recently James L Harris
(22-APR-2004) published a seriesl of un-addressed issues in the IDE--these
should be considered.

If we do not advance the 'state of the art', our effort may be personally
satisfying, but probably generally useless.



New item on list:

Are we making a collection of command line tools, or are we considering an
IDE?

My vote is command line tools, similar to Andrew's recently exposed work.





Daniel