Re: Language design question

"Joachim Durchholz" <joachim.durchholz@halstenbach.com.or.de>
16 Feb 2000 23:43:10 -0500

          From comp.compilers

Related articles
Language design question flisakow@ricotta.cs.wisc.edu (2000-02-13)
Re: Language design question world!cfc@uunet.uu.net (Chris F Clark) (2000-02-13)
Re: Language design question jejones@microware.com (James Jones) (2000-02-15)
Re: Language design question flisakow@ricotta.cs.wisc.edu (2000-02-15)
Re: Language design question mkg@lanl.gov (2000-02-16)
Re: Language design question joachim.durchholz@halstenbach.com.or.de (Joachim Durchholz) (2000-02-16)
Re: Language design question joachim.durchholz@halstenbach.com.or.de (Joachim Durchholz) (2000-02-17)
Re: Language design question kst@cts.com (Keith Thompson) (2000-02-19)
Re: Language design question thp@roam-thp2.cs.ucr.edu (Tom Payne) (2000-02-19)
Re: Language design question Andrew.Walker@nottingham.ac.uk (Dr A. N. Walker) (2000-02-27)
Re: Language design question hannah@mamba.pond.sub.org (2000-03-21)
Re: Language design question frederic_guerin@yahoo.com (Frederic) (2000-03-25)
[1 later articles]
| List of all articles for this month |

From: "Joachim Durchholz" <joachim.durchholz@halstenbach.com.or.de>
Newsgroups: comp.compilers
Date: 16 Feb 2000 23:43:10 -0500
Organization: Compilers Central
References: 00-02-065 00-02-074
Keywords: design

Shaun Flisakowski wrote:
> > Does anyone see any problem with [not having an explicit
> > dereference operator] that I'm overlooking?
> > Are there any existing langues that handle this similarly?


Ah, now I understand the question (lazy me not reading lots of code).


Yes, there is. Eiffel does not have an explicit dereferencing
operator; it just has path expressions of the form "base.selector",
where "selector" can be an attribute or a parameterless function,
returning either a direct attribute or a reference to an object. For
the theory behind the first aspect of this language design, take a
look at http://www.elj.com/elj/v1/n1/bm/urp/. (A word of caution: the
author, Bertrand Meyer, can put his arguments in a very convincing
manner even if he is dead wrong. This doesn't mean he is dead wrong
very often, this is more the exception... but it means that you have
to be careful to spot the assumptions that are the basis for his
reasoning, and evaluate whether your assumptions match his or not.)


Language-wise, unifying references and nonreferences is not a problem,
and it's also not a problem in programming. It does make for some
confusion when it comes to discussions that dwell on the fine points
of references, sharing, and such, so this is less a technical question
(no problems here) but a psychological one (do the programmers
understand what they're doing - and if they don't understand, is the
language constructed so that it does not matter?).


Regards,
Joachim


Post a followup to this message

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