Re: Language design question

>Shaun Flisakowski <flisakow@ricotta.cs.wisc.edu> wrote:
>>It seems that with strong typing, there is no need for a dereferencing
>>operator, as the compiler could add these automatically. (I'd still
>>have an address-of operator)


Sorry to butt in so late in the thread, but I feel that no one has
adequately balanced some of the arguments given thus far.


> Thanks to everyone who replied. I've been (mostly) talked out
> of it, and will require a dereferencing operator for all calls
> except member selection, in which case the '.' will automatically
> add the derefences.


Have you looked at Wirth's last language Oberon? It dereferences
automatically. From what programming I have done in the language,
automatic dereferencing does not seem to be the problem others have
said it is. I wouldn't remove the feature if I were you. (There are
several Oberon compilers you can study to see how it is done.)


Some languages designers, such as Eiffel's Bertrand Meyers, believe
strongly that you *should* hide the difference between a direct and an
indirect type (i.e., between a statically allocated variable and a
dynamically allocated one) to gain the flexibility to change the type
without changing the text of the code.


> In case anyone is interested, I've made a webpage with some of
> my current ideas for the language:
> http://www.spf-15.com/omega.html


This is a personal preference of mine but... I would suggest you get
rid of the separation between interface and implementation. This is
one of the things that I did not like about Modula-2 as well as the
units extension to Pascal. I found it very annoying to have to "switch
contexts" to the interface definition just to specify some external
property. (C and C++ header files suffer from the same problem
although their textual-inclusion model compounds the trouble IMHO.) I
think that Java and Oberon got this one right (although Java's model
of external visibility is quirky and complex). By providing syntax in
which to specify symbol exportation in your implementation file, you
eliminate many problems without sacrificing separate compilation. For
speed of compilation, Oberon compilers either keep a separate symbol
file (essentially the precompiled external interface) or they include
the symbol data in the object file. Thus you get the best of all
worlds; separate compilation with good speed and you do not sacrifice
type safety.


Some would say "why do we need another language?" I contend that we
won't know we need another language until someone has designed it and
started doing great things with it. Good luck... ;-)


Mark


--
Mark K. Gardner
RADIANT Team
Network Engineering, CIC-5
Los Alamos National Laboratory
P.O. Box 1663, M.S. D451
Los Alamos, NM 87545
Email: mkg@lanl.gov
Phone: 1-505-665-4953

Return to the comp.compilers page.
Search the comp.compilers archives again.