🚀 go-pugleaf

Chris Dollin writes:
>Ug! writes [responding to me]:
> 
>    Beware: Lisp is essentially an interpreter, even when it's compiled.
> 
> Would you like to explain the grounds on which you base this claim? [What do
> you mean by ``essentially'' and ``interpreter''?]

Not really - I think you know what I mean.  I qualify Lisp as an interpreter,
since much lisp code actually writes lisp programs which are then executed at
some stage.  I also qualify Smalltalk as an interpreter though, so maybe I'm
wrong.

>    > Lisp. Scheme. Poplog Pop11. Smalltalk. Don't forget ratios and complexes.
> 
>    Oh I know.  But ratios and complexes can be added where needed.  They 
>    shouldn't be a 'standard part' of the language.  
> 
> I think the standard library *is* part of the language, and I'd rather have
> ratios and complexes than not.

Ah, right!  In which case, by all means!  I try to distinguish between
languages which are operator & type rich, and languages which are library
rich.  Oberon is a classic example.  A minimalist language with a huge set
of libraries.  Smalltalk is another good example.  However, if you view the
standard libraries of a language as part of the language itself, then by all
means add all of these things.

I was objecting to them being added as base types and so forth.  The Modula-2
ISO workgroup added COMPLEX as a base type, which I think is rediculous!

> I suggested user-defined operators. Ug! said:
> 
>    Hmm.  Perhaps.  The problem then is that you have to pake allowances for
>    all symbols and symbol combinations in the parser.  Tricky.  I'd go for
>    simplicity, and just allow the built in operators to be overloaded.
> 
> Tricky? *Tricky*? TRICKY?
> 
> ``Trivial'' is the word I'd use. Lexical analysers clump up letters into
> identifiers all the time; what's to stop them clumping up sign characters into
> operator names? There is *no* problem here, despite what C++ language
> designers may have tried to tell you. [They're stuck with supporting the
> lexis of C, and wimped out on requiring whitespace for utterances such as
> ``x+++y''.]

Read what I said again.  Was I talking about lexical analysis?  No.  I was
talking about parsing.  Perhaps you feel user defined operators are trivial
to parse; I don't agree.

> I said:
> 
>    > Lists. Sets. Hash tables (both content and address based).
> 
> Ug! said:
> 
>    Exactly.  All of these are implementable though.  
> 
> [Presumably he means on top of the language.] Yes, but see my remarks above
> about the library. Hash tables (especially address-based ones) are possibly
> the single most useful data structures ever invented.

By all means.  All of these (and more) should be in the libraries.

> I said:
> 
>    I'd vote *against* abstract data types and for a simple but powerful module
>    structure...
> 
> Ug! said:
> 
>    The reason is reuseability.  You can fudge it by returning some sort of
>    'handle' (usually an index into a list), but if you are going to return a 
>    handle, why not return the object itself?  Yes,  OO gets around it.  I'm 
>    not a fan of OO though.
> 
> I'd put the object in the heap and return its address -- a perfectly good
> handle for the object. I suspect we're at cross-purposes here; what do ADTs
> gain you in reusability that module scoping does not?

When you have to pass back some sort of handle to the user of a module: not
internally to a module.  Like C's and Basic's file handles, for example.

> Ug! responds to my ``GARBAGE COLLECTION'':
> 
>    Ooo.  Garbage Collection.  Nice.  Still, a big hit in speed/performace,
>    etc.  See Modula-3 (also has freely available ftp'able descriptions).
> 
> What big hit did you have in mind?

Garbage collection is fine, but it really does need hardware to support it.
There has been a lot of work done on stopping the 'sudden hit' (i.e. the
machine freezes while garbage collection takes place), which early versions
of Lisp and Smalltalk suffered from.  Most of them however now require a
steady percentage of the processors time in which to perform garbage
collection.  Without hardware, this can be quite noticeable, especially as
memory fills.  (from experience with Smalltalk)

>    For simplicities sake, however, I am often willing to forgo it.  But is is
>    definately a nice idea.
> 
> For simplicitys sake, I'd put it in. I've written too much C, and handled my
> own store allocation too often, to want to force the poor programmer to do it
> themselves. 

Oh come on!  This is probably the first time this guy has implemented a
programming language and you want him to put in grabage collection?!!!  Be
reasonable!  Better to implement a language without garbage collection than
get bogged down and not manage to implement it at all!

>    Modula-2 fundges a solution with local modules.  But in the case where
>    A & B share X.  B & C share Y.
>    ...ouch.  But it happens (all to commonly).  Some sort of explicit 
>    inheritance control in this case would be nice.
> 
> What does it buy you? Use modules and put up with the fact that B can see X.
> If necessary have the compiler tell you. The idea is nice, but in practice
> it's just make-work for the programmer.

Data hiding gains you quite a bit.  Read some stuff on software engineering.
Essentially its a quality assurance measure.

> Other things:
>    initialised declarations;

Yes!  Good point!  I'd go one step further: typable constants, not just for
initialisation.  (constant arrays and records are *so* useful in Modula-2)

> unassignable names (``constants'');

Yes.  Constants please!

> incremental compilation;

Maybe.

> first-class procedures; first-class everything; full lexical scoping.

Can you explain these a little more?  I'm not that familiar with Common Lisp
or Scheme, I'm afraid.
							Ug!