Re: Rational for not making cursor tagged in Containers

[Georg Bauhaus <bauhaus@futureapps.de>]

On Fri, 2007-04-20 at 12:39 +0200, Dmitry A. Kazakov wrote:
> On Fri, 20 Apr 2007 12:56:23 +0200, Georg Bauhaus wrote:

> >    type Foo is interface record ...
> >  ... There is no
> > way of knowing whether reading or writing a record component will
> > just move some bits, or try to compute the first prime number of
> > the 1969 lottery on the way.
> 
> And you claim to know it. Always? With all possible pragmas applied,
> including Pack, as well as representation clauses like for X'Address use
> ...?

The practical difference between a simple record and a programmer-
defined record interface implementation is a set of fixed rules in
the first case and full (sub)programs in the second case.

>  As for me, I don't know it in 90% cases, and in 99% of these, I just
> don't care.

Right, I assume you don't care to known what an assignment to
a record component does because you either rely on the
thing being a "sufficiently normal" data component or you can
trust the authors of the program and assume they haven't
introduced an overly ambitious algorithm for Adjust that
would let your application hang for a while.

> BTW, Ada has private types from the day one.

If the type in question is private, there is nothing
to argue about. But your record type construction interface
wasn't private; and it didn't announce that Mumble isn't
just a record component. To emphasize: I don't want to loose
comparatively simple building blocks (records) just because
some smart programmers can build similar things (implementing
record interfaces) with more effects. I'm not forced to provide
get {} and set {} in C#, and neither assigners in Eiffel.


> > And, considering Controlled, forcing *all* types to be derived
> > from this base suffers from the same effects for the same reason.
> 
> Because multiple-inheritance is *the* answer. You need not to force anybody
> to anything if an interface (and an implementation of) can be added later.

This is where it becomes dangerous, I think. Suggesting that programmers
can implement "linguistic interfaces" forces programmers to be language
designers, profiting from decades of language research, compilation
technology, etc. etc..


> But more things you have hard-wired
> in the language, more complex it becomes for everybody, you, me, the
> compiler vendor and the Pentium.

If the hard-wired features of a language don't suit your problem, or
your solution, it might become a complex issue to work around
the language. Using a language construction language (sic) that suits
your problem solution will be a more pleasant experience. But for whom?
A reader will have to acquire complex language construction language
rules; just as look-at-my-neat-domain-language-macros
are both clever and not recommended in the general case (by Graham).



> > Not every programming team consists of real or even wannabe
> > language designers. But who else has even got a chance of knowing
> > what they are doing to a larger program when implementing the
> > concept of record?
> 
> Why they are allowed to implement a concept of task,

Uh, what do you mean? Ordering entry calls? Specifying rules
of conditional acceptance? In the more common case, I find
that much better than using a language that "gives you the
freedom to roll your own" tasking.

>  Where do you draw the line?

For a general purpose language, I draw the line where the
programmers would otherwise be forced to fiddle with
the tiny bits usually done by compilers. The operations
of private types are not tiny bits, but forcing plain record
component assignments to be full subprograms should not be
the default in Ada.