Re: Ada 2005?

[jayessay <nospam@foo.com>]

"Dmitry A. Kazakov" <mailbox@dmitry-kazakov.de> writes:

> >> I doubt that CLOS seriously approaches the problem.
> > 
> > That's an odd statement, and it is just uninformed opinion which
> > happens to be factually incorrect.
> 
> Maybe

There is no "maybe" about it.  You clearly have not studied this and
therefore any comment you make on it is indeed uninformed opinion.


> , but the very first page introduces "no-applicable-method". It is a
> non-starter for me. In my view the goal of safe MD design is to make
> dispatch failures impossible (checked at compile time).

For true MD, that requires solving the halting problem in any Turing
complete setting.  Good luck on your hopeless quest.  OTOH, if you
restrict things enough, what you are talking about is simply
overloading.  Ada already has that.


> BTW, I am deeply unsatisfied with Ada's "MD" raising run-time
> exceptions. It is tolerable because there was no better way, and
> only as an intermediate state to be replaced by a "right" MD in the
> future.

First, raising runtime exceptions is not only reasonable, it is the
only thing possible in non trivial situations.

Second, Ada has no MD.  That is a fact.  I make the prediction that it
will never have an MD.  Not because it is not possible to get "right"
(a context sensitive notion if there ever was one), but because the
language simply does not have the proper machinery to support it.  You
basically require a MOP and that will never be added to Ada for many
reasons, not the least of which is that it would simply be "too hard".


> > If you really would like to
> > understand the issues you should read the hyperspec sections noted
> > above as a start.  This will give you a programmer's (user's) view of
> > things albeit from a language specification angle.
> >
> > More information as to the what, hows, and wherefores can be found in
> > (1) and further insight and rationale is detailed in the MOP (2).
> > 
> > It's worth noting that CLOS method combination is actually
> > programmable.  There are several versions supplied as part of the
> > specification (including the 'standard method combination'), but the
> > protocol and semantics of how to define others is also defined and
> > specified.
> 
> I don't think it is a good idea. I believe that there must be one right
> way.

There is no such thing as "one right way" in any non trivial problem
solving context.  It has long been known in problem solving (not just
computation) that multiple ways of attacking a problem, and shifting
among those ways, tends to yield the the better solutions.

I thought Ada folks understood this (Ada being a multiparadigm
language).  The position you state looks much more like a Pythonista,
where the above is not just a mantra but the central dogmatism.  If
you like the idea of "the one right way" for any
computational/software issue, Python is definitely the place to be.
Not that they're "right", but they believe they are.


> Though, there might be some variations, in the case of commutative
> methods for example. But they should be "projections" of the main
> schemata.

I've seen situations where this claim is completely at odds with
reality.  Hence, your position would remove expressivity and force
programmers into pounding square pegs into round holes.  This is
_always_ a bad thing, though it is something that most language models
do impose.


> I really, wouldn't allow programmers to play with fire.

What you call "playing with fire", is simply another tool, with a well
defined and specified protocol.  Can it be abused?  Yes.  Does it
require someone above average to use it properly?  Most likely.  Can
it be exactly the right thing for an elegant solution to a thorny
problem?  Yes.

Being a denizen of cla I realize you are probably a B&D software
development proponent, and I suppose in certain contexts (mediocre
programmers, large beauracracies) your sentiment here makes sense.
But in general it is a bad idea which at best tends to produce what I
like to term "superior mediocrity" (which, to be fair, often wins big
in the "marketplace").


/Jon

-- 
'j' - a n t h o n y at romeo/charley/november com