NetNews Usenet Archive 1992 #18/NN_1992_18.iso/spool/comp/sys/acorn/tech/60

Internet Message Format | 1992-08-17 | 5.2 KB

From: [e-mail] (Chris Dollin)
Date: Tue, 18 Aug 1992 08:02:46 GMT
Subject: Re: New Language/Compiler (ideas wanted)
Message-ID: <[e-mail]>
Organization: Hewlett-Packard Laboratories, Bristol, UK.
Path: sparky!uunet!munnari.oz.au!mips!mips!sdd.hp.com!hpscdc!hplextra!otter.hpl.hp.com!hpltoad!cdollin!kers
Newsgroups: comp.sys.acorn.tech
References: <[e-mail]> <[e-mail]> <[e-mail]> <1992Aug18.114418.10160@waikato.a
Sender: [e-mail] (Usenet News Administrator)
Lines: 112
In-Reply-To: [e-mail]'s message of 18 Aug 92 11:44:18 +1200
Nntp-Posting-Host: cdollin.hpl.hp.com

In article ... [e-mail] (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''?]

   > 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.

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''.]

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.

I said:
   The restriction I have in mind for my language Pepper is that no object can
   have a length bigger than that which will fit in a fixnum (an small
   integer), which limits them to 2^29 elements.

Ug! queried:

   Hmm.  Why 2^29?  Shouldn't it be 2^31?  Anyway, both are reasonable approxi-
   mations of infinity at the moment.

Two bits for a tag.

I said:

   I'd vote *against* abstract data types and for a simple but powerful module
   structure. After all, all ADTs do is to restrict the names that the user is
   allowed access to -- they're not allowed to use the representational names,
   eg, the fields of a structure; rather, they have access via a set of
   procedures. But this is just what modules are for, so why conflate the two
   concepts? [C++ does this with classes, and look at the resulting mess.]

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?

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?

   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.

   An idea I didn't mention before: one of the things I dislike is implicit
   inheritance in procedural programming languages (i.e. global or semi-global
   variables).  If you want two routines to share access to a variable, then
   both should have to explicitly inherit it: it shouldn't be made global
   (ala C).

Use full lexical scoping and first-class procedures, as in Common Lisp, Scheme,
Pop11, Standard ML.

   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.

Other things: initialised declarations; unassignable names (``constants'');
incremental compilation; first-class procedures; first-class everything; full
lexical scoping.
--

Regards,                    | "I always prefered Sherlock Holmes to Dan Dare"
Kers.                       | Nathan Spring, in BBC2's _Star Cops_.