Re: Ada 2005?

[jayessay <nospam@foo.com>]

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


> On 23 Dec 2004 13:09:34 -0500, jayessay wrote:
> >>> For true MD, that requires solving the halting problem in any Turing
> >>> complete setting.
> >> 
> >> What about any proof?
> > 
> > One Hint: I/O.  There are many others.
> 
> You should define MD in a way which would not involve the Great Theory of
> All, otherwise anything would become unsolvable...

Your comment is irrelevant on a number of counts.  I/O is hardly the
"Great Theory of All", it is simply a part of the real world.  As
another hint: classwide parameters.


> > However, these rules really have nothing to do with restricting
> > "dynamic declarations" (Ada is static and so of course there are no
> > dynamic declarations at all).
> 
> This is wrong.

So where can you _declare_ a new entity at runtime?


> Not all dynamic declarations are of primitive operations.
> Ada is a statically *typed* language.

Yeah.  So?


> >>>> 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.
> >> 
> >> Again, the goal of proper design is to have no such situations.
> > 
> > Then you should not have dynamic dispatch at all.
> 
> Where that follows from?

Try to figure it out.  It will do you good.


> > That's completely irrelevant to the problem.  The issue is whether any
> > given actual call will find a match in the table.  The tables are
> > trivial, it is the flow analysis that is (in the general case)
> > impossible.
> 
> We have different general cases. Ada is not a dynamically typed language.
> The reason for that was: not to have your "general case".

The general case is simply one where you cannot determine at compile
time things like uninitialized variables, the specific type of a class
wide variable at any given point in time, etc.  These still apply to
Ada.  I'm not sure you actually understand any of this as you keep
making these irrelevant or incorrect claims.


> case, it is trivial to find a match. Moreover it requires bounded time.
> Otherwise, I guess polymorphic calls would never be adopted in Ada. The
> problems with implementation of MD in Ada lie elsewhere.

MD is irrelevant to to this point, which is the need for runtime
exceptions.  Ada has these and you can easily get them with it's
polymorphic calls (which cannot be MD), i.e., Constraint_Error can be
raised.  What's more, some of these constraint errors are _exactly_
the equivalent of "method not found" (which is similar to, but _not_
the same as, no-applicable-method).  It is disappointing that you
don't understand this.


> >>> Second, Ada has no MD. That is a fact.
> >> 
> >> MD = "more to have than one dispatching parameter".
> >> 
> >> So clearly, Ada has MD.
> > 
> > Ah, so you define it away.  MD = "Multiple Dispatch" in the orignal
> > context of this thread which is /= more than one dispatching
> > parameter.  This should be obvious.  Ada does not have MD, to argue
> > otherwise just makes you look silly.
> 
> Care to give another definition of MD?

No, the original, as I noted here was and is the one under discussion
and it is quite proper.  In particular it means that Ada has no MD.
There is nothing controversial about this, and several books
(including even the Rationale) mention this and discuss how an Ada
programmer can achieve a simple version of MD by rolling their own via
redispatch.


> > OTOH, I'm not sure why a "meta language" is somehow an intrinsically
> > "wrong idea".
> 
> Because it is difficult to talk two languages for a person who is not
> "above average" or else does not suffer from split personality...

That's so poor an argument/justification that it is not worth
discussing.  It borders on "internet kook" talk.  More on this below.


> >>> 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.
> >> 
> >> Yes, this is exactly Ada's way (tm). Moreover, both pegs and the plate
> >> are made of hard steel. So the programmer will spend a lot of time
> >> pounding on.  This has an important educational effect. Maybe next time
> >> [s]he will thinkfirst.
> > 
> > I don't think this is "Ada's way".  I sure hope it isn't because it is
> > the dumbest thing anyone could advocate.  The "education" any
> > intelligent person would get from this would be, "this language is an
> > extremely poor means for expressing elegant correct solutions."
> 
> An *intelligent* person would notice difference in shapes.

The point is an elegant solution cannot be expressed cleanly without
recourse to pounding because the language lacks the proper
expressivity.  An intelligent person will notice and be annoyed that
they are being required by the tool to pound away and/or to abandon
their solution for a lesser one.  Which leads to,


> The level of intelligence is inversely proportional to the time
> spent on pounding...

Yes.  This means that in this case, intelligent people will _abandon_
the tool (in this case the language) so that the elegant correct
solution can be expressed without pounding.


> >>> 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.
> >> 
> >> Bottom line:
> >> *rejected*
> > 
> > Bottom line: You will not be able to solve a large class of (non
> > trivial) problems as they will require far too much work to find a
> > means to express their solution.
> 
> Which quote "would require someone above average to use it properly". How
> much above?

The question you pose is (mis)leading and pretty irrelevant.  A
slightly better question would be "how many such people do you need?"
Answer: enough.  This is not a facetious answer as the requirements
will vary from project to project, but typically you will not need
more than a few.  Here is an analogy that is pretty apropos:

Does use of the calculus require an engineer above average to use it
properly?  Most likely.  Can it be exactly the right thing for an
elegant solution to a thorny problem?  Yes.  How much above average
does the engineer need to be?  Depends.  How many of these do you
need?  Enough.  Would any of this in any way suggest to anyone who has
any idea of what they are doing that they should not use the calculus
in these circumstances?  No.


/Jon

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