# 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