🚀 go-pugleaf

Chris Dollin writes:
>Ug! writes:
> |    Firstly, have a look at Oberon-2.  The descriptions are available 
> |    by anonymous ftp from ETH.  Some really neat ideas there.
> 
> Make sure you've looked hard at Lisp, Scheme, and Pop11 too. The pure
> functional languages are also a good source of ideas.

Mmm.  Yes.  However, Oberon, in all of its implementations is a strictly
minimalist language, which is why I suggested it.  In that sense, Lisp would
probably be good alos, but I've no doubt that he's already considered this.
Someone else mentioned an idea of every statement returning a value: this is
very much in keeping with the ideas behind functional languages.

Beware: Lisp is essentially an interpreter, even when it's compiled.

> | Generics. Any new language worth its salt should consider this
> | issue.
> 
> C++ *has* generics, although they call them ``templates''...

Yes, well...

> | Subranges.  At some stage I'd love to build a language which has
> | *no* concept of fixed data-type sizes...
> 
> 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 suppose Smalltalk is okay, since
*everyting* is part of the sort of library).  I'm a great fan of procedural
languages though - not one for functional or object-oriented stuff.  The
suggestion was in the same way that Ada copes, rather than Lisp/Smalltalk.

> | Overloading.
> 
> Common Lisp + CLOS has this. If you want to do it properly, allow
> user-definable operator *symbols*, don't restrict them to built-in operators
> (both Ada and C++ have this totally unnecessary restriction).

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.

> | One of the things I would like is a 'string' concept, which
> | automatically handles groups (arrays) of items which grow and
> | shrink - maybe a 'bag'.
> 
> Lists. Sets. Hash tables (both content and address based).

Exactly.  All of these are implementable though.  So is the 'string' concept I
mentioned for that matter, but the minute you put one in, the others all
become simple to implement using it.  I suggested the 'string' once, since of
course, strings of characters are oh-so-common.

> | No limitations like 'strings can only be up to 255 in length'.
> | Yuck!
> 
> 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 immediate-value
> integer), which limits them to 2^29 elements. This limits bit arrays to 64Mb.
> Fortunately this restriction seems unlikely to bite for a few years yet.

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

> | Can link up with C, including C I/O.
> 
> Yes, cross-calling in some manner is essential. What's more difficult -- but
> necessary in the long run -- is to give C some way of calling *your* routines.

Yes.  I think that the Acorn language Kernel idea should help somewhat in this
though.

> | A good 'ABSTRACT' (or opaque) data type.
> 
> 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.]

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.

> Have we said ``Garbage collection'' yet? Have garbage collection. Have Garbage
> Collection. HAVE GARBAGE COLLECTION.

Ooo.  Garbage Collection.  Nice.  Still, a big hit in speed/performace, etc.
See Modula-3 (also has freely available ftp'able descriptions).

For simplicities sake, however, I am often willing to forgo it.  But is is
definately a nice idea.

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

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.

A possibility is to look at what Modula-3 does with it's multiple definitions
for a single module.

Have fun!
							Ug!