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] |
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
Return to the
comp.compilers page.
Search the
comp.compilers archives again.