🚀 go-pugleaf

orion@grun.is (Halfdan Ingvarsson) writes:


>Hiya folks...

>  Erm. I was thinking of writing a (sort of :) compiler using
>my own language (a weirdo mixture of C, Pascal etc.. ) and I
>am getting a little short of ideas. As I don't want to describe
>it in whole, I'm gonna give you a general idea of what it shall
>be..
>  I'm going to make it very neat, small, fast and clean and
>make it produce code that lives up to that. It's probably going
>to be very Archimedes (yeah, yeah Ax000 too) specific, that is
>not portable code. The reason for that is that I'm going to
>implement SWI calls like procedure calls eg.
...

>So.. If anyone has some cool ideas or something dreamthings they'd like to
>see in a compiler I'd be glad to hear from them.
                                                      -Journal of Misfacts
>P.S. If I had some idea about what (blush) Object Oriented code was like
>(and no, I'm not talking about C++. It's crap) I'd also try to make this
>language OO... So be it.. And no flame wars please >:-)

How about letting every statement also define a value, so that it can
be used as an expression. For assignments, the obvious result is the
assigned value. For if-then-elses the result of the succeeding branch
is fine. For blocks, the result of the last statement, for procedure
calls the value of the body etc.

This would get the effect of C's special expressions: a=e, (p ? q : r)
(p , q) etc. and avoid the need for a return statement for functions.

The problems are if-then (without else) and while, as they might not
execute their bodies at all. One could force else-branches to all if
statements and add an else-branch to while, which will be used if the
test fails initially. Alternatively, one could have a "null" value
that would be returned in case the body is not executed.

Afeature I have sorely missed in compilers for C etc. is a cheap
tail-call: if the last thing you do in a procedure or function is to
call a procedure or function, this can be implemented as a goto rather
than a general procedure/function call. Also, the local variables of
the calling procedure need not be saved before the call, as they will
never be used again. Note that this is not a laguage feature, but a
compiler feature. This requires a callee-saves-registers strategy, but
that is often the simplest anyway.

OO features can be (and has been) added in myriad ways. I prefer the
original idea, where every object carries its own methods.
Essentially, an object is a record of values (fields) and procedures
(methods). To save space, the methods can be collected in a record
that is referred to by a pointer in the object record. This allows the
methods record to be shared by all objects in the class. A class
consists of a methods record and a "make" procedure that takes some
initial arguments and returns an object by setting the fields
according to the arguments and setting the method pointers to the
class' own method record.

Apart from typing problems, OO can be easily simulated if you allow
procedures as general values that can be stored and passed as
arguments. If you (like C) have no nested procedure definitions, a
pointer to the execution address is enough to represent a procedure.
If you have nested procedure definitions, you need also the
environment in which the procedure is defined. Pascal does this, but
only allows procedures as parameters, not as stored objects etc. The
reason is that the environment that a procedure value refers to might
not exist at the time it is called.

OO is interesting for the Arc mainly for desktop programming: you can
define a window-class that has methods for the messages that the
desktops returns from a polling call. In the broadest class all the
mask bits are set and most methods are null methods. When defining a
subclass, some mask bits are unset and the corresponding methods
defined. The remaining methods are inherited from the superclass.

torbenm@diku.dk (Torben AEgidius Mogensen) writes:

>Afeature I have sorely missed in compilers for C etc. is a cheap
>tail-call: if the last thing you do in a procedure or function is to
>call a procedure or function, this can be implemented as a goto rather
>than a general procedure/function call. Also, the local variables of

What do you mean? What if the tail-called function then tries to call
another function or (even worse) recurses? This could only work if
the tail-called function expected to recieve *exactly* the stack frame
that the tail-caller has had set up when it was called.

And remember that Acorn's C compiler (the ARM proc. call std.?) is clever
enough to notice when you call a function that does not call another (a
leaf function), and does not bother with most of the context-storing
operations involved in normal function calls.

-- 
_________________  "I'd like to answer this question in two ways:
  /____ _ _/_ __       First in my normal voice, and then
 // / //_//_ /_/       in a silly, high-pitched whine." (Monty Python)

>orion@grun.is (Halfdan Ingvarsson) writes:
>
>
>>Hiya folks...
>
>>  Erm. I was thinking of writing a (sort of :) compiler using
>>my own language (a weirdo mixture of C, Pascal etc.. ) and I
>>am getting a little short of ideas. 
[...]
>>So.. If anyone has some cool ideas or something dreamthings they'd like to
>>see in a compiler I'd be glad to hear from them.
[...]

A number of years ago, someone suggested a "comfrom", to match a
"goto".  When it was first mentioned, it was as a joke.  However, the
more I thought about it, the more it appealed...

The idea is that both ends of the goto are labeled.  This has several
advantages:-
 
(1) At the target label, the "comefrom" clearly identifies the places
from which the current label can be reached, and just how many places.

(2) Also it will help to discourage indiscriminant use of the
"dreaded goto", without preventing its use in "appropiate" contexts.

(3) This would give the compiler more scope for picking up errors.



Gavin
-- 
Tomorrow's Society                              | flower_g@kosmos.wcc.govt.nz
    Depends on                                   ----------------------------
Today's Children  - help us raise them properly! 
*******  These comments have no known correlation with dept. policy!  *******

In article ... jwil1@cs.aukuni.ac.nz (TMOTA) writes:

   torbenm@diku.dk (Torben AEgidius Mogensen) writes:

   >Afeature I have sorely missed in compilers for C etc. is a cheap
   >tail-call: if the last thing you do in a procedure or function is to
   >call a procedure or function, this can be implemented as a goto rather
   >than a general procedure/function call. Also, the local variables of

   What do you mean? What if the tail-called function then tries to call
   another function or (even worse) recurses? This could only work if
   the tail-called function expected to recieve *exactly* the stack frame
   that the tail-caller has had set up when it was called.

Urk? You clean up the stack before you call the tail-called function, of
course. It's a standard optimisation, at least in the Lisp world. [The only
objection to it is that it can make debugging harder -- you lose the functions
that tail-called when you get the stack backtrace.]

   And remember that Acorn's C compiler (the ARM proc. call std.?) is clever
   enough to notice when you call a function that does not call another (a
   leaf function), and does not bother with most of the context-storing
   operations involved in normal function calls.

I'm not sure you said what you meant. There's no cleverness involved in calling
a leaf function (after all, who's to know that it *is* a leaf function?), it's
just that leaf functions don't need to carry all the baggage of a full function
call -- it's the code of the leaf that ``does not bother with most of the
context-storing operations''. [They don't carry the baggage because there's
very little that can go wrong inside them, so they don't need to record who
they are in case something does.]


--

Regards,    | It's strange how you suddenly discover bizarre and dangerous
Kers.       | holes in your knowledge.  I fell down one today. - Steve Knight

Gavin Flower writes:

>A number of years ago, someone suggested a "comfrom", to match a
>"goto".  When it was first mentioned, it was as a joke.  However, the
>more I thought about it, the more it appealed...

The "come from" was intended to be used * without * a corresponding goto,
so it would actually be a construct which would encourage really horrible,
disgusting, unstructured, <insert rude word here> core (oops, i meant code,
but core is probably appropriate too :-) ).

It has been implemented in some languages as a debugging tool---not to be
used in real code. Also, it has been implemented in INTERCAL, a joke
language, which encourages programming worse than found in the Obfuscated
C Programming Contest.

>The idea is that both ends of the goto are labeled.  This has several
>advantages:-

>(1) At the target label, the "comefrom" clearly identifies the places
>from which the current label can be reached, and just how many places.

>(2) Also it will help to discourage indiscriminant use of the
>"dreaded goto", without preventing its use in "appropiate" contexts.

>(3) This would give the compiler more scope for picking up errors.

But the way you propose it, it sounds actually very nice.

. . . . . . . . . . . . . . . . . . . . . . . . . . . G e r b e n   V o s   <><
Aconet: 8500/104!Gerben Vos  Internet: gpvos@cs.vu.nl
This .signature is a Usenet Olympic Record holder. Copy it now!

jwil1@cs.aukuni.ac.nz (TMOTA) writes:
>torbenm@diku.dk (Torben AEgidius Mogensen) writes:
>
>>Afeature I have sorely missed in compilers for C etc. is a cheap
>>tail-call: if the last thing you do in a procedure or function is to
>>call a procedure or function, this can be implemented as a goto rather
>>than a general procedure/function call.
>
>What do you mean? What if the tail-called function then tries to call
>another function or (even worse) recurses? This could only work if
>the tail-called function expected to recieve *exactly* the stack frame
>that the tail-caller has had set up when it was called.

Maybe my brain has been rotted by using HPs for too long, but I'm sure
that Norcroft C does tail call optimization (I'll give my Arc a break
from being a Tertis and Icon server some time, and check it).
Certainly lots of compilers (OK, I mean gcc) do it, and manage the
necessary frame fiddling.

It's occasionally useful for writing gross/cute things like:

int countBits (int i, int acc)
{
    return i == 0 ? acc : countBits (i & (i - 1), acc + 1);
}

(doubtless originally due to Martin Richards :-) I think Norcroft
produces near identical code for the above and an equivalent explicit
loop.

On designing languages in general, if you're trying to produce a fast
system language you could try something a bit like B (typeless C +/- a
bit), which would be fun. Once you start integrating all those
wonderful little features you love from Lisp and Icon and Eiffel et
al, you tend to lose some of the elegance and simplicity you meant to
achieve :-)

Cheers,
Charlie

Anything approximating an opinion is my own
and is not necessarily shared by my company

kers@hplb.hpl.hp.com (Chris Dollin) writes:
>   And remember that Acorn's C compiler (the ARM proc. call std.?) is clever
>   enough to notice when you call a function that does not call another (a
>   leaf function), and does not bother with most of the context-storing
>   operations involved in normal function calls.

>I'm not sure you said what you meant. There's no cleverness involved in calling
>a leaf function (after all, who's to know that it *is* a leaf function?), it's
			     ^^^^^^^^^^^^^ Mr. Compiler knows.

>just that leaf functions don't need to carry all the baggage of a full function
>call -- it's the code of the leaf that ``does not bother with most of the
>context-storing operations''. [They don't carry the baggage because there's
>very little that can go wrong inside them, so they don't need to record who
>they are in case something does.]

Actually, I thought that they didn't bother stacking anything because the
compiler *knows* they are leaf-functions. Leaf functions being defined as
functions which do not call any other functions; this means that you *know*
the function doesn't call anyone else, so you *know* that you don't need to
bother with stacking stuff that you would otherwise need to restore context
on return from a called function.
-- 
_________________  "I'd like to answer this question in two ways:
  /____ _ _/_ __       First in my normal voice, and then
 // / //_//_ /_/       in a silly, high-pitched whine." (Monty Python)

Halfdan Ingvarsson asks for ideas on new language features.

(deep breath)  Hokay, here we go:

Firstly, have a look at Oberon-2.  The descriptions are available by anonymous
ftp from ETH.  Some really neat ideas there.

1.  Generics.  Any new language worth its salt should consider this issue.  One
    of the reasons why Ada beats C++ for productivity is that generics beats
    object oriented for reuseability.  (the other reasons have to do with the
    great tools that come with Ada, and the strict licensing scheme which
    ensures compatability)

2.  Subranges.  At some stage I'd love to build a language which has *no*
    concept of fixed data-type sizes.  Of course, you could then have a
    library routine which defines a type Word (much like Modula-2's
    System.WORD) and Byte and so forth.  However, this is entirely a
    portability concept, and so is not really applicable to what you are trying
    to do, but even so, just think how nice it would be to be able to use
    320-bit integers...

3.  Overloading.  Ada has this, without being Object-oriented.  This coupled
    with generics gives you better reuseability than object instantiation.
    Both functional and operator please.  Don't worry about redefining
    operator precedence:  leave 'em as they are, and folks can work with that.

4.  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'.  In
    this way you could have a 'STRING OF CHARACTER' or a 'STRING OF INTEGER'.
    'STRING', like 'ARRAY' allocates space, but it can be resized etc
    dynamically.  Useful.

5.  Projection.  See previously mentioned Oberon-2.  This completely redefines
    the way inheritance and stuff works.  Keeps the language procedural rather
    than data-driven, which is nice for those of us who think in processes, not
    in data-flows.  Coupled with generics, should make life very interesting.
    Also, by combining with overloading gives similar capability to object-
    oriented, although dynamic binding might be tricky to fudge.

6.  Packages or Modules or *something*!  Preferably coping automatically with
    linking (C... yuck!).

7.  No limitations like 'strings can only be up to 255 in length'.  Yuck!

8.  There is no number 8.

9.  Can link up with C, including C I/O.

10. A good 'ABSTRACT' (or opaque) data type.  Modula-2 almost does it, but not
    quite, since it limits the size of its opaque types to the size of a
    pointer.  Ada goes one better, but then requires you to say what's actually
    in it, so what's the point?  Opaque data types enable data-hiding (great
    for abstraction purposes), and are all too often very useful.  In C, I
    kludge this by passing back a pointer to the type as a 'void *'.

Oh well, some food for thought.
								Ug!

In article ... jwil1@cs.aukuni.ac.nz (TMOTA) writes:

   kers@hplb.hpl.hp.com (Chris Dollin) writes:
   >   And remember that Acorn's C compiler (the ARM proc. call std.?) is clever
   >   enough to notice when you call a function that does not call another (a
   >   leaf function), and does not bother with most of the context-storing
   >   operations involved in normal function calls.

   >I'm not sure you said what you meant. There's no cleverness involved in 
   >calling a leaf function (after all, who's to know that it *is* a leaf 
               				^^^^^^^^^^^^^ Mr. Compiler knows.
   >function?), it's just that leaf functions don't need to carry all the
   > baggage of a full function
   >call -- it's the code of the leaf that ``does not bother with most of the
   >context-storing operations''. [They don't carry the baggage because there's
   >very little that can go wrong inside them, so they don't need to record who
   >they are in case something does.]

   Actually, I thought that they didn't bother stacking anything because the
   compiler *knows* they are leaf-functions. Leaf functions being defined as
   functions which do not call any other functions; this means that you *know*
   the function doesn't call anyone else, so you *know* that you don't need to
   bother with stacking stuff that you would otherwise need to restore context
   on return from a called function.

The compiler knows that a function is a leaf function when it *compiles* it,
not when it compiles a *call* to it (your original remark - at the top - said 
``is clever enough to notice when you call [note this] a function that does not
call another'').

That is, what you *said* suggests that the compiler compiles *calls* to leaf
functions in a special way, and what I think you *meant* is that *leaf
functions* were compiled in a special way.

Otherwise I think we're in furious agreement.

--

Regards,    | "Layered protocols give the software implementor a chance to
Kers.       | ruin his performance in each layer." - Don Gillies

In article ... bwc@waikato.ac.nz (Ug!) writes:

|    Halfdan Ingvarsson asks for ideas on new language features.
|
|    (deep breath)  Hokay, here we go:
|
|    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.

| Generics. Any new language worth its salt should consider this
| issue. One of the reasons why Ada beats C++ for productivity is
| that generics beats object oriented for reuseability.  (the
| other reasons have to do with the great tools that come with
| Ada, and the strict licensing scheme which ensures
| compatability)

C++ *has* generics, although they call them ``templates'', they were added
late in the day, they have a horrid syntax [*1], and they silently explode
your code for you.

| Subranges.  At some stage I'd love to build a language which has
| *no* concept of fixed data-type sizes.  Of course, you could
| then have a library routine which defines a type Word (much like
| Modula-2's System.WORD) and Byte and so forth.  However, this is
| entirely a portability concept, and so is not really applicable
| to what you are trying to do, but even so, just think how nice
| it would be to be able to use 320-bit integers...

Lisp. Scheme. Poplog Pop11. Smalltalk. Don't forget ratios and complexes.

| Overloading.  Ada has this, without being Object-oriented.  This
| coupled with generics gives you better reuseability than object
| instantiation. Both functional and operator please.  Don't worry
| about redefining operator precedence:  leave 'em as they are,
| and folks can work with that.

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). [User-definable
precedence is, sadly, a Bad Idea.

| 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'.  In this way you could have a 'STRING OF
| CHARACTER' or a 'STRING OF INTEGER'. 'STRING', like 'ARRAY'
| allocates space, but it can be resized etc dynamically.  Useful.

Lists. Sets. Hash tables (both content and address based).

| Projection.  See previously mentioned Oberon-2.  This completely
| redefines the way inheritance and stuff works.  Keeps the
| language procedural rather than data-driven, which is nice for
| those of us who think in processes, not in data-flows.  Coupled
| with generics, should make life very interesting. Also, by
| combining with overloading gives similar capability to object-
| oriented, although dynamic binding might be tricky to fudge.

| Packages or Modules or *something*!  Preferably coping
| automatically with linking (C... yuck!).

Yes.

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

| There is no number 8.

Ahem. I deleted the section numbers when I reformatted the message.

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

| A good 'ABSTRACT' (or opaque) data type.  Modula-2 almost does
| it, but not quite, since it limits the size of its opaque types
| to the size of a pointer.  Ada goes one better, but then
| requires you to say what's actually in it, so what's the point?
| Opaque data types enable data-hiding (great for abstraction
| purposes), and are all too often very useful.  In C, I kludge
| this by passing back a pointer to the type as a 'void *'.

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

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

Words of advice:

Read Hoares ``Hints on Programming Language design''.

Favour simplicity of explanation over simplicity of implementation.

Make it easy to relate different language structures.

When in doubt, throw it out.

Avoid designing your first language. Experience shows that the second and
subsequent ones are better.

Programmers should not design languages; they're too close to the problem, and
want features that make some of their pet hates easier to cope with.

Non-programmers should not design languages; they have no idea what kinds of
things should go into a language.

Always have someone else critique your language. You don't have to do what
they say, but listen carefully to what they *do* say.

[*1] For compatability with the rest of the language.
--

Regards,    | "Layered protocols give the software implementor a chance to
Kers.       | ruin his performance in each layer." - Don Gillies

kers@hplb.hpl.hp.com (Chris Dollin) writes:

>In article ... jwil1@cs.aukuni.ac.nz (TMOTA) writes:

>   torbenm@diku.dk (Torben AEgidius Mogensen) writes:

>   >Afeature I have sorely missed in compilers for C etc. is a cheap
>   >tail-call: if the last thing you do in a procedure or function is to
>   >call a procedure or function, this can be implemented as a goto rather
>   >than a general procedure/function call. Also, the local variables of

>   What do you mean? What if the tail-called function then tries to call
>   another function or (even worse) recurses? This could only work if
>   the tail-called function expected to recieve *exactly* the stack frame
>   that the tail-caller has had set up when it was called.

>Urk? You clean up the stack before you call the tail-called function, of
>course. It's a standard optimisation, at least in the Lisp world. [The only
>objection to it is that it can make debugging harder -- you lose the functions
>that tail-called when you get the stack backtrace.]

>   And remember that Acorn's C compiler (the ARM proc. call std.?) is clever
>   enough to notice when you call a function that does not call another (a
>   leaf function), and does not bother with most of the context-storing
>   operations involved in normal function calls.

>I'm not sure you said what you meant. There's no cleverness involved in calling
>a leaf function (after all, who's to know that it *is* a leaf function?), it's
>just that leaf functions don't need to carry all the baggage of a full function
>call -- it's the code of the leaf that ``does not bother with most of the
>context-storing operations''. [They don't carry the baggage because there's
>very little that can go wrong inside them, so they don't need to record who
>they are in case something does.]

This is basically the old caller-saves/callee-saves controversy:
caller-saves makes tail-call optimization easy, callee-saves makes
leaf-call optimizations easy.

The reason callee-saves is bad for tail calls, is that it can't see if
it is called from a tail position (unless a separate entry point or
parameter specifies this). The reason caller saves is bad for leaf
call optimization is that things are already saved, so you can't avoid
doing so.

Both of these problems can be partially solved by using a mixture of
caller saves and callee saves strategies.

	Torben Mogensen (torbenm@diku.dk)

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!

In article ... bwc@waikato.ac.nz (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_.

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!

In article ... bwc@waikato.ac.nz (Ug!) writes:

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

Well, it seems to me then that you regard a language as ``essentially
interpreted'' if the compiler happens to be available at run-time. OK, it's a
definition; I can live with it, but I don't like it.

[Agreement about having a rich library deleted.]

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

But there *is* no parsing problem. The lexical analyser recognises operator
symbols (such as ``++'', ``:-'', ``<>'', ``/=='', ``$!##!''), and says to the
parser ``operator symbol, precedence nnn''. The parser is using a grammar
like:

    Expr_nn ::= Expr_nn [Op_nn Expr_mm]		(mm < nn, say)

and just eats the operator symbol -- in just the same way as it does for
*existing* languages; it just so happens that the spellings allowed for
operator names have become more varied.

Now, the only difficulty I can see is that if you feel that user-defined
operators must necessarily have user-defined precedences. *Then* it gets
tricky to parse, because you need the precedences fed back to the lexer *while
the parse is happening*. Yukk. So you *disallow* it; it's not useful enough.
Give all non-standard operators the same precedence (I suggest just tighter
than assignment, if you have assignment).

Existance proofs: Algol 68 (but that had user-defined priorities), and HP-SL,
the specification language we did here at the Labs, which had user-defined
operators in almost the style I describe. There were no parsing problems due
to UDOs.

[More agreement on the utility of various library types.]

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

No, that wasn't what I meant. If you represent an object by its address,
export the object type, but *not* any of the representation-based operations,
(all of which is what you get from what I call a ``module''), then you're just
as abstract as an ADT. Hence the abstractness is nothing to do with the
data-type, it's just to do with name-hiding.

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

My experience with garbage collection is with Poplog (on VAXes and HP
68K-based workstations), where the ``sudden freeze'' was never long enough to
be a nusiance (until X arrived in the system. Sigh.), and with my own language
Pepper, where the GC time is noticable but the code could be improved no end.
So, unless real-time is an issue, I don't believe the performance hit is
particularly important.

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

Now *that* is a good argument. Just so long as we agree that it's a practical
matter of someone implementing their first language, rather than a desirable
property of languages.

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

I *know* what data-hiding buys you. I am strongly in favour of data-hiding.
Block structure is one form of such (inner is hidden from outer). But the
requirement of making procedures declare all they import is *too onerous*; it
was tried in Euclid, for example, and they ended up (so I hear) with the
compiler constructing the import lists for the programmer.

Modules allow you to do data-hiding (rather, name-hiding). Within a module, it
doesn't seem worth it to require that all names ``falling'' into a procedure
be declared as such. Who are you hiding from? If it's *really* important, use
more modules -- that's what they're there for.

[Agreement -- broadly -- on initialised declarations and typed constants,
deleted.]

|> incremental compilation;
|
| Maybe.

Well, it's harder to do. But it's a good design goal (I think).

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

Tale this little example written in Pepper (the current compiler can't handle
it, but that's just laziness on my part; I can tell you how it *will* be
implemented if you want):

	define adder( n ) as
		define add_n( m ) as n + m enddefine;
		add_n
	enddefine;

	val add1 = adder( 1 );
	val add2 = adder( 2 );

	add1( 41 ) =>

	** 42

``adder'' is a procedure which, when called with some value ``n'', returns a
procedure which, when applied to some argument ``m'', delivers the sum of
``n'' and ``m''. ``add1'' and ``add2'' are procedures delivered by ``adder''
for different n's -- they have a variable ``n'' *each*.

Lexical scoping means that ``n'' is in scope in the region of text in which it
is declared, including in any nested procedures (here, ``add_n''). (Even
Pascal can do this, although C cannot.) *Full* lexical scoping means that the
variable ``n'' will persist for as long as necessary -- in this case, it
cannot be allocated on the stack, as it needs to survive ``adder'' so that it
remains available to (some instance of) ``add_n''.

``First-class everything'' means that all objects (values) have (in some
sense) equal rights; being passed as parameters, returned as results, stored
in data-structures, or assigned. This applies particularly to procedures,
which are often short-changed (C only admits them with the locution
``pointer-to-function'', and doesn't permit them to be declared nested; see
``full lexical scoping'').

As a language design rule, it says you should make the distinction between
an object (value) and its name clear. Unfortunately, first-class-ness usually
needs garbage collection to make it possible ...
--

Regards,    | ``In fingers of trees, and valleys of gold    | Judy Tzuke
Kers.       | I watch as you outshine the charlatan foe.''  | Higher & Higher

In article <1992Aug17.132929.10141@waikato.ac.nz>, bwc@waikato.ac.nz (Ug!) writes:
> Halfdan Ingvarsson asks for ideas on new language features.
> 
> (deep breath)  Hokay, here we go:
> 
> Firstly, have a look at Oberon-2.  The descriptions are available by anonymous
> ftp from ETH.  Some really neat ideas there.
> 
> 1.  Generics.  Any new language worth its salt should consider this issue.  One
>     of the reasons why Ada beats C++ for productivity is that generics beats
>     object oriented for reuseability.  (the other reasons have to do with the
>     great tools that come with Ada, and the strict licensing scheme which
>     ensures compatability)
> 
> 2.  Subranges.  At some stage I'd love to build a language which has *no*
>     concept of fixed data-type sizes.  Of course, you could then have a
>     library routine which defines a type Word (much like Modula-2's
>     System.WORD) and Byte and so forth.  However, this is entirely a
>     portability concept, and so is not really applicable to what you are trying
>     to do, but even so, just think how nice it would be to be able to use
>     320-bit integers...
> 
> 3.  Overloading.  Ada has this, without being Object-oriented.  This coupled
>     with generics gives you better reuseability than object instantiation.
>     Both functional and operator please.  Don't worry about redefining
>     operator precedence:  leave 'em as they are, and folks can work with that.
> 
> 4.  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'.  In
>     this way you could have a 'STRING OF CHARACTER' or a 'STRING OF INTEGER'.
>     'STRING', like 'ARRAY' allocates space, but it can be resized etc
>     dynamically.  Useful.
> 
> 5.  Projection.  See previously mentioned Oberon-2.  This completely redefines
>     the way inheritance and stuff works.  Keeps the language procedural rather
>     than data-driven, which is nice for those of us who think in processes, not
>     in data-flows.  Coupled with generics, should make life very interesting.
>     Also, by combining with overloading gives similar capability to object-
>     oriented, although dynamic binding might be tricky to fudge.
> 
> 6.  Packages or Modules or *something*!  Preferably coping automatically with
>     linking (C... yuck!).
> 
> 7.  No limitations like 'strings can only be up to 255 in length'.  Yuck!
> 
> 8.  There is no number 8.
> 
> 9.  Can link up with C, including C I/O.
> 
> 10. A good 'ABSTRACT' (or opaque) data type.  Modula-2 almost does it, but not
>     quite, since it limits the size of its opaque types to the size of a
>     pointer.  Ada goes one better, but then requires you to say what's actually
>     in it, so what's the point?  Opaque data types enable data-hiding (great
>     for abstraction purposes), and are all too often very useful.  In C, I
>     kludge this by passing back a pointer to the type as a 'void *'.
> 

  11. Intelligent type casting. 

  12. Library orientated (ties in with 6).


From Martin Glanvill		(mcg@waikato.ac.nz)

Dept. Maths 							      @@@@@/|@
University of Waikato						      @@@@/ |@
Hamilton							      @@@/__|@
New Zealand							      @@/   |@
								      @@@@@@@@

----------------****=====| A quote to make your day |======****-----------------
Always tell him he is handsome, especially if he is not.
-------------------------------------------------------------------------------

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

So?  I'd call this a real plus.  Machines are a lot faster than they
used to be and I look forward to the day when we remove the
compilation step again.  I think programmer optimization costs more
than run time optimization, obviouslt, so now it's just a matter of
waiting until machines are fast enough that the users can live with
the response time as well.


				Jordan