Again, why use C?
Soren Renner — 2002-10-30 19:03:01
> > Many thanks for taking the time to look at this in detail (much more
> than I did!). Case 3 was new to me. I think if a library contains
> "virtual" operators either the language, or at least the interpreter,
> should help identify them. This is kind of tricky today as libraries
> may consist of multiple LIBRA or DEFINE statements, the symbol
> namespace is global and definitions and executable code may be
> interleaved.
>
> One solution given the current interpreter would be to do something like:
>
> DEFINE virtual == "error: Undefined virtual symbol encountered." quit.
> DEFINE mysymbol == virtual.
>
> Or alternatively define a new primitive to flag all symbols in a list
> virtual if they are still undefined:
>
> [mysymbol1 mysymbol2 mysymbol3] virtualdefs.
>
> The undefs command could then explicitly list all symbols defined as
> "virtual" in addition to those with no definition at all.
>
> This approach is, however, only slightly more useful than code
> comments and a convention that programmers must remember to
> adopt. Personally I'd rather have libraries become more
> object-oriented with a hierarchy of namespaces and symbols explicitly
> defined as either public, private or virtual. This would also remove
> the need for HIDE.
>
> To enforce compile time checking of virtual symbols though I think the
> language would have to prevent the interleaving of definitions with
> executable code.
These issues arise only because C is such a horrible language.
Please ignore me as usual, sr
>
Manfred von Thun — 2002-11-04 06:43:20
On Wed, 30 Oct 2002, Soren Renner wrote:
[ apropos something suggested by Nick Forde: ]
[ ... ]
> > To enforce compile time checking of virtual symbols though I think
the
> > language would have to prevent the interleaving of definitions with
> > executable code.
>
>
> These issues arise only because C is such a horrible language.
Actually, these issues have nothing to do with the implementation
language C, exactly the same issues would arise if a different
implementation language had been chosen for Joy.
When writing an interpreter for a language (with or without OO)
in an implementation language (with or without OO), one has to
write the whole name-space handling from scratch anyhow.
This is different in the case of garbage collection: here it
can help a lot if the interpreter for the implemented language
can use the memory management of the implementation language.
In my first version ("Joy0") I had to write a garbage collector
myself - and it was OK for my initial work. But the John Cowan
added a more general one (in "Joy1") that is much better.
> Please ignore me as usual, sr
- Manfred