Path: utzoo!utgpu!news-server.csri.toronto.edu!cs.utexas.edu!know!zaphod.mps.ohio-state.edu!swrinde!emory!hubcap!mephisto!udel!carroll
From: carroll@udel.edu (Mark Carroll <MC>)
Newsgroups: comp.lang.misc
Subject: Re: Multi-compilers
Keywords: design, source
Message-ID: <31535@nigel.ee.udel.edu>
Date: 25 Sep 90 20:22:20 GMT
References: <2576@l.cc.purdue.edu> <9206@ccncsu.ColoState.EDU> <2581@l.cc.purdue.edu>
Sender: usenet@ee.udel.edu
Organization: University of Delaware
Lines: 57
Nntp-Posting-Host: dewey.udel.edu

In article <2581@l.cc.purdue.edu> cik@l.cc.purdue.edu (Herman Rubin) writes:
>
>The problem with PL/I and assemblers is the poor notation.  This even 
>occurs with the present languages, to more of an extent than many would
>recognize.  One of the important advantages of languages is the use of
>overloaded operators and relations, and converient use of standard
>mathematical notation.  
>

>Why is there an absolute value function rather than an absolute value
>operator?  Only because when Fortran was written, they were limited to
>a 48 character set (IBM punched cards, at the time).  This is also why
>** was used for exponentiation, and even * for multiplication.  I have
>used a dialect of Fortran which overloaded some of the "standard" functions,
>so that absolute value, logarithm, mod, etc., did not have to have any modifier
>indicating the type(s) of the arguments.  The compiler did the appropriate
>analysis.
>

First of all: functions versus operators is nothing more than a foolish
complaint on the basis of syntax. You don't like typing ABS(x)? Just
write yourself a quick filter that converts |x to ABS(X). It's probably
a whole two lines in awk or perl.

Second, for overloading: it exists. C++, or any object oriented language
allows full overloading. It will resolve things to the proper function
for the types involved. And it's even user extensible.

>A language is a set of macros to be interpreted by the compiler into machine
>procedures.  

This is where you really go off the wall.

A language is nothing but a set of Macros? Maybe I'll stop laughing and take
you seriously if you can show me any way of describing Smalltalk as  a set
of macros.

>There is no good reason why the user should not be allowed to
>add macros in convenient notation to this list, nor why many of the restric-
>tions on the current macros need be there.  If the machine can do something,
>the user should be able to invent a notation to do it, if necessary.  For
>example, I find the general vector operation on the CYBER 205, with its dozen
>optional fields, easy to explain in a notation easy to read and write.

I'm terribly happy for you.

Listen, if you're so hyped on the idea of writing your own super-macro
assembler, why don't you sit down and write a specification of the damned
thing. If you write the specification, I'll write the compiler. OK?

	<MC>

--
| Mark Craig Carroll: <MC> |"We the people want it straight for a change;
| CIS Graduate Student at  | cos we the people are getting tired of your games;
| University of Delaware   | If you insult us with cheap propaganda; 
| carroll@udel.edu         | We'll elect a precedent to a state of mind" -Fish