🚀 go-pugleaf

On Thu, 26 Jul 90 16:01:58 GMT Preston Briggs said:
>In article <INFO-M2%90072611375987@UCF1VM.BITNET> Modula2 List
>        <INFO-M2%UCF1VM.BITNET@jade.berkeley.edu> writes:
>
>>Nope, but I like to see that too (with uniary/binary operations,
>>...
>
>You don't want much I guess.  Try Ada maybe, or Clu, Russell, ML, ...

Not not much just 7/8th of the cake :-)


>
>More to the point, try to define a language with all that stuff.
>Then try to implement it.  Then try to use it.

I think it would be easier to define than to implement.  Some things
could be implemented now via a preprocessor approach, similar to early
C++ implementations.  Using it would certainly be the easiest part :-)
Yes, you are right it's not a overnight/week/month project, but if I
didn't sit around thinking about things like this I'd probably be out
on the street getting in trouble facing a long spiral decent into
a evil life that would eventually 'lead to no good'.


>Then try to implement it.  Then try to use it.
>*I* certainly don't want to maintain programs that redefine
>precedence of existing operators.  The other features sound

You have a good point there.  The reason I included existing
operators was to prevent 'wrapping' and allow such things as the
definition of a CARDINAL (operator) INTEGER operation
(for convenience).  I think that defining the precedence of operators
is a good compliment to op overloading.  I could live without
redefining the existing operators.  I agree that such features
can open a BIG CAN'O WORMS for programmers responsible for maintaining
such code, but so can features like pointers, co-routines and
absolute memory addressing.  The fact that features/extentions
'can' be abused is not reason to eliminate them.


>(more or less) ok when considered alone; building a complete language
>that has all the neat features you like is hard work.
>Of course, people DO work on these things all the time.
>The results are often interesting and exciting.

True, but some people have more time than ideas, others more ideas than
time (I'm one of the fortunate few who is burdened with either ideas or
time ;-)  May some bright hard working person will 'get hold' of this
and Modula-2++ (with x cheese) will be born.  With the right subset of
features a compiler could be bootstrapped with out 'much' superhuman
effort.

BTW, bless the 'peoples' that work on these things, they really do
make a better world (or at least a better virtual world).


>
>On the other hand, one of the attractions of Modula-2 (and Oberon) is the
>minimalism.  These are languages I can hope to understand, in toto.
>
>Regarding all the bit field stuff, I often use bitsets for
>such things.

I was thinking more in terms of PACKed arrays, more for saving core
or addressing devices.  BITSETs seem to me to be a afterthought.
I'd like to be able to have a multi-dimensional array of 4 bit units
(actually I like to be able to handle dynamic bit field widths as in
LZW encoding, but I can't think of a 'good' way to implement it).
Course I'd like to be able to treat these nybbles as a new data
type and apply op overloading to them.


>
>--
>Preston Briggs                          looking for the great leap forward
>preston@titan.rice.edu

Greg