Dave Brueck <[EMAIL PROTECTED]> wrote:
...
> No, not at all - I'm just trying to better understand what you mean. Words
> like "generic" and "concepts" don't yet have a widely recognized, strict
> definition in the context of programming. If somebody has assigned some
> specific definition to them, that's great, it's just not universal yet so
> references and additional explanations are helpful.
Googling for "generic programming" (with the quotes) gets 100,000 +
hits. The first couple pages of hits, at least, seem to all be speaking
about exactly the same thing. The terminology appears to be settled
enough that Oxford's St Anne College feels they can organize a "Summer
School on Generic Programming", Nottingham University a "Workshop on
Generic Programming", etc, etc, without fearing ambiguity.
"Generic" by itself is one thing, but when we specifically mention
"Generic programming" I do not really see the ambiguity. Same for
"concepts" -- by itself it's too wide, to the point that it means
nothing, but put it next to "generic programming" and the resulting
26.000 hits seem to be mostly speaking about the very same thing, in as
much as one can tell from the first few pages of hits, "a concept is
defined as a family of abstractions that are all related by a common set
of requirements" to quote Musser.
Exactly what extra support Roman would want from Python for 'concepts',
beyond that offered by, say, C++, I'm not sure. Protocols, interfaces
and design-by-contract are other terms often used to try and capture
pretty similar issues. As far as I know the C++ community is unique in
routinely formalizing some PERFORMANCE requirements (pragmatics ahoy!-)
as part of their approach to generic programming -- but that's just an
important cultural issue, the LANGUAGE itself, C++ as it stands, offers
no way to say "this has O(N) perfrmance"... this kind of thing still
goes in comments, and in clauses in standardization documents.
When I say that a "protocol" includes pragmatics as well as syntax and
semantics, that's part of what I mean, in a handwaving kind of sense.
The *interface* to a Python dictionary/mapping includes a set of methods
with certain signatures; it expresses little beyond "syntax" issues.
The *semantics* of it include axioms that could and perhaps should be
formalized to define the connectedness among the methods, e.g. a long
list of things such as "for any x acceptable as a key and y acceptable
as a value into d, ...:
d[x] = y
assert x in d
del d[x]
assert x not in d
d[x] = y
z = d[x]
assert z is y
and so on, and so forth". The kind of things one would write in a unit
test... except that unit tests don't include universal quantifiers of
the form "for any x such that";-).
Finally, the *pragmatics* of a Python dictionary include "accessing d[x]
is pretty darn fast" although no doubt that could (I dunno if it should)
be formalized further.
As to how a "dictionary CONCEPT" might differ from a "dictionary
PROTOCOL", I'm not sure. They both should include syntax (interface),
semantics (behavior specs), and perhaps a sprinkling of pragmatics --
such as, O(...) performance specs for some operations, but mostly stuff
that's harder to formalize, such as, say:
x = malloc(N);
x = realloc(x, M):
when N is very very large, and M is MUCH smaller than N, SHOULD,
pragmatically, make some memory available for other uses (as opposed to
leaving it all in the block allocated for x) -- the kind of things that
don't get into formalized standards because handwaving is disliked
there, but can make a programmer's life miserable nevertheless (as this
very issue does with today's Python, which relies on these pragmatics in
a spot or two, and MacOSX' standard C library, which ignores them...).
Alex
--
http://mail.python.org/mailman/listinfo/python-list
