Re: Current work in compiler/language design.

Since the last few responses were for what I clearly delineated
(verbatim: "Really *my* opinion here:"), thanks for taking such an
interest, bringing me up to date on a few things, and letting me
known your opinions, too;-) Anyway, further opinion exchanges:


On OO being 'hype':


OO is not just hype, just read up on one of the myriad of '92 material on
the subject ('91 got passe a while ago), they clearly show why the
concepts are better, do solve many problems, provide better structure,
etc. I won't go into it since the literature is so stuffed already, but I
recommend one should read up if you haven't already done so. I know
empirically the concepts are correct. And I still contend that
technologies (such as computers and compilers) should support this
paradigm well.


eifrig@blaze.cs.jhu.edu (Jonathan Eifrig) writes (3 quotes):
// Depending on what you mean by "just adding it as a new OO feature,"
// this is either vacuous or erroneous. If you mean that anything someone can


OO constructs are among many other. They offer good structure and can
offer good structure to other constructs. too. I meant I could easily add
other constructs into a common OO language without violating anything or
just use OO to program in another paradigm, since it is general purpose.
But if you add OO constructs, or even imperative constructs to a more
specialized language (say functional), aren't you violating that languages
philosophy? In OO, you are supposed to match the problem domain closely,
so other paradigms are considered ok if called for. OO proponents support
a model as close to reality and natural as possible, and this is its goal.


//NJ/SML does this as well). As far as complaining about "function calls
//at run time," I prefer that my functions are called at run time as opposed
//to compile time; that's called "program execution." :-)


I meant method lookup, ha ha on me. As I've said before, I think both
should be provided, just not at the expense of each other.


//ML via the "function" named ";", in the following manner:
//
// fun ; (a, b) = b


Um, if a function named ; is used and the expressions (statements) are
considered arguments, then since in every language I've heard of there is
no predefined order of evaluation for arguments (although I disagree with
this, another opinion), e1 may not come before e2 (part of sequencing is a
linear ordering, as I recall) and with lazy evaluation, wouldn't one
wonder if an argument (statement) even gets evaluated? I admit I could be
missing something.


spitzak@girtab.usc.edu (William Spitzak) writes (1 quote):
// I have been programming professionally in C++ for about a year now,
// implementing a GUI library, and have used exactly ONE virtual function.
// ...
// mercilessly as an Ignoramous for not seeing the marvelous benefits of
// dynamic binding. I'm sorry, I'm blind. I do not see them.
//
// Am I missing something? Please enlighten me. Or does even a single person
// out there think the same as me? And is this a hot topic in langauge design?
Dynamic facilities allow one to use objects without foreknowledge of what
they are. This is very general purpose and powerful. A lot of
environments (some currently in Smalltalk) require an ability to grab any
object, look at it, work with it, etc. such as a debugger or run-time
controller. In a static language this is difficult but in a dynamic
language this is simple and natural. (See Coplien, "Advanced C++
Programming Styles and Idioms", '92 for lots of examples requiring dynamic
typing and on what you must do to C++ (with virtual functions) to emulate
dynamic typing (and it isn't pretty)). Distributed programming also calls
for dynamic typing, since message selection is performed at run-time. And
typically so do databases and persistent objects, if the programs don't
have wired-in knowledge about the types supported. And typically so do
dynamic classes, if you want to pass a message to an object of a newly
created class, and so do ..., etc, etc., etc.


On multi-methods:


It is common (I could provide references) for multi-methods to be
presented as a new solution (multiple-polymorphism?) to an old problem.
Functions came before, the OO receiver, selector, and arguments message
came after. Since multi-methods are just functions, I think they should
be presented as functions and this is *not* the way they are presented in
the literature. Anyway, I would provide both forms of invocations,
regardless of syntax, unless someone contends multi-methods are a (clean)
superset of OO messaging.


On Lisp:


It appears most (or a lot) of Lisp is now compiled, and according to one
respondent, when stripped bare runs twice as slow as standard code.
Some dialects provide static typing, and I'll assume they provide dynamic
typing too. But some say Lisp has a natural syntax:
Natural syntax : if a plus b times c equals zero ...
Typical syntax : if a + b * c == 0 then ...
Unnatural syntax : (if (== (+ a (* b d)) 0 ) ... )


Unnatural means that for this trivial last example I first drew the tree
(wheh, first time) then after 3 attempts at polish prefix notation (opps,
a little slippage there) and matching lots of parenthesis (thank god for
vi:%), I got it. Like this syntax or not it is not natural, most people
do expressions infix.


On functional:


Its good to hear this community is now bootstrapping their compilers. But
I still think it is best for mathematics since it is based on lambda
calculus (OO is based on a model close to reality) and it is best for a
language to match a problem domain with a low impedance mismatch(closely).


I'll attribute posting my previous opinions as a late-night, haven't done
this in 2 or 3 years, get it off my chest, let someone know what to look
into (and not just academic) diatribe. Anyway, its been interesting,
sorry if I did a little feather ruffling.


Bob Hathaway
objsys@netcom.com
--

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