Path: utzoo!utgpu!jarvis.csri.toronto.edu!cs.utexas.edu!wuarchive!texbell!vector!attctc!smunews!ti-csl!m2!gateley
From: gateley@m2.csc.ti.com (John Gateley)
Newsgroups: comp.lang.misc
Subject: Re: Anyone want to design a language?
Message-ID: <111355@ti-csl.csc.ti.com>
Date: 19 Feb 90 16:38:07 GMT
References: <22569:05:10:24@stealth.acf.nyu.edu> <8475@wpi.wpi.edu>
Sender: news@ti-csl.csc.ti.com
Organization: TI Computer Science Center, Dallas
Lines: 112


In article <8475@wpi.wpi.edu> jhallen@wpi.wpi.edu (Joseph H Allen) writes:
<Ok, I'll bite.  Here's a compiled language I'd like to see:
<(1)	No semicolons.
<(2)	Except for end of line comments.  /* These comments are evil */
<(3)	Block structure indicated by indentation level:
<
<		while a!=b
<			int q		; Multi-line body
<			q=z*5
<			r+=foo(q)
<...

Now, just take it a little further: get rid of all infix notation,
and let "blocks" be denoted by ( and ) and you get:
(begin
  (while (!= a b)
    (let ((q integer))
      (= q (* z 5))
      (+= r (foo q))))
  
  ...)
and you have achieved a truly simple easy to use syntax where you
dont have to worry about indentation (the editor does it for you),
and programs which manipulate source code are much much easier to
write.

<(4)	Overloadable AND definable operators

Using syntax like I descibed above avoids this issue entirely (there is
no such thing as an operator). The guy that occurs in the first position
of ( ... ) can be overloaded/defined in well behaved ways easily.

<(5)	All characters allowed in symbols.

Using syntax like I described above, the ONLY characters not allowed
in symbols are (, ), and ; (for comments). In real life, this set usually
is a little bit larger, but not much.

<	the longest possible string which can be
<	a symbol is deteced:
<		if these are symbols:
<			abc
<			def
<			abcdef
<		then when the input sees:
<			defabc	; def is recognized and then abc is recognized

Uggh, gross!!

<	Symbol recognition should occure before constant recognition.  I.E.,
<	this way you can define:
<			int :4: = 5	; Make 4 equal to 5

You are starting to have to make lots of rules to handle
your way of life, it should be simple not complex, and
having to worry about details like "Does :4: means : 4 : or a symbol
named ":4:"" confuses people.

<(6)	Nifty C declarations which allow one type to be shared among multiple
<	declarations each of which might have an initializer.

Even better, lets support dynamic typing, then we can avoid this
issue as well.

<(7)	However, the convoluted C declaration system needs to be replaced:
<		instead of:
<			int **foo[]   an array of pointers to int pointers
<		do this:
<			[] * * int foo

Hmmm, this is very similar to my arguments for a simpler syntax:
by specifying everything in prefix notation, you avoid the
precedence problem (among other things). Even though you keep
operators and precedence for expressions, you want to remove them
from declarations! The first line is perfectly acceptable if you
remember the precedence/associativeness of [] and *. Of course, I
think that it should be ([] (* (* int))) for the type spec.

<(8)	Eliminate arrays.  They arn't needed.  Use pointers and macros
<	instead.

Ummm, if you pursue this argument ad infinitum (is that the right
latin word?), then you wind up with a turing machine, the lambda calculus,
or a combinatory logic, or some other beast which is close to impossible
to program in. On the other hand if you have a standard interface to
arrays, then looking at other peoples code will be easier: you won't
have to learn their version of the macros.

Perhaps, though, you meant provide a standard set of macros to implement
arrays on top of pointers, I have no argument with this.

<(10) Standard operators.  Grouped together in equal precidence:
< [HUGE TABLE DELETED]

I hate precedence: I can never remember which is which.
Instead, using the lisp-style syntax again avoids this issue:
everything is parenthesized automatically and you don't ever
have to worry about precedence.

(+ 2 (* 3 4) (- 5 6))

<(11)	Blocks return the last value generated:
<(12)	Statements return their last value:

Now go one step further and eliminate the concept of a statement: now
everything is an expression and returns values. In the spirit of something
posted somewhere recently: we have reduced the number 2 (statements and
expressions) to 1 (expressions).

John
gateley@m2.csc.ti.com