Path: utzoo!utgpu!jarvis.csri.toronto.edu!mailrus!cs.utexas.edu!usc!snorkelwacker!mit-eddie!uw-beaver!zephyr.ens.tek.com!wrgate!teklds!daniels
From: daniels@teklds.WR.TEK.COM (Scott Daniels)
Newsgroups: comp.lang.misc
Subject: Re: Anyone want to design a language?
Message-ID: <1873@wrgate.WR.TEK.COM>
Date: 19 Feb 90 18:39:20 GMT
References: <22569:05:10:24@stealth.acf.nyu.edu> <8475@wpi.wpi.edu> <4489:05:14:19@stealth.acf.nyu.edu>
Sender: news@wrgate.WR.TEK.COM
Reply-To: daniels@teklds.WR.TEK.COM (Scott Daniels)
Followup-To: comp.lang.misc
Distribution: usa
Organization: Tektronix, Inc., Beaverton,  OR.
Lines: 78

A pet peeve: why only decimal radix for floating point?  How about a notation
like: d:xxx.xxx  Where d is the largest digit allowable in the radix, (thus
solving the "what base do I write the base in problem).  Then decimal 4.75
ould be 9:4.75, (hex) F:4.C, (octal) 7:4.6, or (binary) 1:100.11.  The 
base for the exponent should be the same as the radix of the number itself 
(So the exponent indicates radix-point shifts) Note: exponent separator better
be @ or something instead of `E'.

Another thing I would like to be able to do is to indicate that a function
is "pure" (only depends on its args), thus allowing the compiler to 
(1) complain when I violate that, and (2) compile-time evaluate values
to produce constants, and (3) expand inline as it sees fit.

On strings: SAIL had strings which consisted of a length and pointer part
I know this prevents the "infinite length string" idea, but (1) substrings
are easy, [lexing a line involves copying no character data], and (2) it is
(almost) as easy to get to the last few chars of a string as the first few.

On structures: 
(1) How about some way to provide structs which have negatively indexed 
    fields as well as positively indexed fields.  This allows structure 
    elaboration in two ways (great for protocol layering.)
(2) Rather than tightening the layout of records, have a modifier (like
    Pascal's "packed", but not optional to implement), which says "no
    padding", and otherwise use a loose rule that says 	"adding a field
    must not change the arrangement of variables previously placed," and
    explicitly "fields may be placed in holes in the structure".  Thus the
    compiler is free to use the same layout for the following structs 
    (assuming aligned ints):	
    struct { char c,d; int a; } and struct { char c; int a; char d; }
(3) Allow "anonymous" incorporation of a structure (or union): ie bring
    the field names to the same level as explicitly provided names, (of
    course name conflicts are errors).

On types: 	
>16. Basic types: int bits, uint bits
>I disagree. The basic types should be those types that the machine can
>handle quickly. The language must be efficient! It's perfectly fine to
>have a standard notation for ``a type long enough to handle N bits'' or
>``how many bits are in type X?'' but the language should not make
>restrictions on the size of basic types.
This was provided as a notation for accessing the basic types, but does 
not go far enough.  I would like to be able to give a range which must be 
representable (like integral[1..29]), and have the type chosen, I don't 
always know the number of bits (and I could always use [0:(1<<7)-1] for 
7-bitters).

>(Then again, every case in which portability takes second place to
>efficiency must be carefully considered and well documented. Two issues
>along these lines are bit sizes and the semantics of mod. As I feel very
>strongly that the second should be portable, I shouldn't assume that
>nobody feels the same way about the first. Then again, wouldn't a
>standard notation for your ``int 8'' be enough?)
How about ADDING an operation `modulo' in addition to `%'.  Then we can say
either "fast, fits integer divide," or "result in range [0,modulus)."

>I agree with C's philosophy of only allowing bit packing inside structures. 
But, it would be nice to have a packed vector of bits available somewhere
(inside structures only would be fine with me).

>Function arguments being structures: This could be useful if it's
>combined with a simple way to deal with the program stack.
This probably introduces another form of structure packing (and is a
good idea but...be sure to allow the compiler to delete unused variables
if it can remove them)

Type coersions:
    Something between C's "forget all your type checking" and many other 
language's "you can't get there from here."  How about a coersion that
has both `from' and `to' parts.  suppose: 
	coerce ::= ( to_type : from_type ) e
then for:	( dest_type : source_type ) e;
    It is an error if e is not "easily-coerced" to type "source_type", 
the internal conversion (to dest_type) is performed, and that is the
type of the whole expression.

-Scott Daniels
daniels@cse.ogi.edu