|[3 earlier articles]|
|Re: Grammars for future languages RWARD@math.otago.ac.nz (Roy Ward) (1995-10-26)|
|Re: Grammars for future languages firstname.lastname@example.org (1995-10-26)|
|Re: Grammars for future languages timd@Starbase.NeoSoft.COM (1995-10-30)|
|Re: Grammars for future languages email@example.com (1995-11-09)|
|Re: Grammars for future languages firstname.lastname@example.org (1995-11-04)|
|Re: Grammars for future languages email@example.com (1995-11-05)|
|Re: Grammars for future languages ECE@dwaf-hri.pwv.gov.za (John Carter) (1995-11-07)|
|Re: Grammars for future languages firstname.lastname@example.org (1995-11-08)|
|Re: Grammars for future languages email@example.com (1995-11-09)|
|Re: Grammars for future languages davids@ICSI.Berkeley.EDU (1995-11-10)|
|Re: Grammars for future languages firstname.lastname@example.org (1995-11-10)|
|Re: Grammars for future languages email@example.com (1995-11-12)|
|Re: Grammars for future languages RWARD@math.otago.ac.nz (Roy Ward) (1995-11-13)|
|[4 later articles]|
|From:||"John Carter" <ECE@dwaf-hri.pwv.gov.za>|
|Organization:||Dpt Water Affairs & Forestry (IWQS)|
|Date:||Tue, 7 Nov 1995 06:28:58 GMT|
I was going to let this one fly by, but having recently relooked at
Lisp after several years of working in Fortran, Algol, Pascal,
Basic, C, DCL, AWK, Actor, C++, I have been most impressed. My first
impression of this "code as data" idea of Lisp was "Nice, but I
don't need it very often". I initially ignored the macro facility.
Macros in most languages are merely a parametrized substitution
facility and do not really add anything beyond that which is already
available in terms of a function call. In Lisp a Macro invocation
can invoke a full blown Lisp program which goes way and beyond mere
parametrized substituion. A very large part of Common Lisp and CLOS
seems to be implemented as Macros.
The other point is the "infix" notation of ye olde FORmula
TRANslation and its descendants merely apes a very small part of
mathematical notation. Even then it doesn't do it very well. Which
mathematician beyond grade 2 ever wrote a * b + c * d? We all write
a b + c d. In fact you can generalize this to any "ring", the
multiplicative operator is always implicit. For example if a,b,c,d
were booleans, then a mathematician would write a b + c d meaning :-
(a and b) or (c and d).
What about array indexing? We write a(i) in FORTRAN and a[i] in C and
C++ merely because the highly limited ASCII character set doesn't
allow us subscripts.
Instead of superscripts FORTRAN at least had **, whereas C, C++ and
Pascal revert to Lisp style functional notation. Again we don't have
Sigma notation for summation and we don't have dee by dee t notation
for differentiation and we don't have integration signs. Why? ASCII
doesn't do it, but ye olde LISP style functional notation does it all.
Also mathematical notation changes from sub-field of mathematics to
sub-field. In relativistic calculations a[i]b[i] would probably imply
a summation over i from 0 to 3. We would need tensors, and
superscripts and subscripts would be array indices on covariant and
contravariant vectors. In electromagnetism we would need Del
operators, Cross products and dot products. Again, Lisp style does it
all, and even FORmula TRANSlation reverts to a poorer cousin of Lisp
style to cope.
In conclusion? Maybe the future will hold a greater subset of
mathematical notation. But I suspect LISP is such a simple, good idea
that variants of LISP will be what I will be programming in in twenty
years time. A glimpse at the new ISLISP standard shows there is a lot
of life in this way yet. Have a look at the implementation of OOPS
and generic functions in ISLISP and you will realize most of your
fiercest battles in C++ have vanished like a bad dream.
Institute for Water Quality Studies. Department of Water Affairs.
Internet : firstname.lastname@example.org Phone : 27-12-808-0374x194
Fax : 27-12-808-0338 [Host for Afwater list server]
Return to the
Search the comp.compilers archives again.