Ada generics

Ada generics

[markww]

Hi,

I'm trying to compare generics in Ada vs C++ templates and Java
generics. Is there anything Ada generics can do that C++ or Java
cannot? I read that the Ada system was safer than C++ templates. I'm
just looking for some distinctive features.

Thanks

Re: Ada generics

[Dmitry A. Kazakov]

On 21 Dec 2006 06:14:54 -0800, markww wrote:

> I'm trying to compare generics in Ada vs C++ templates and Java
> generics. Is there anything Ada generics can do that C++ or Java
> cannot? I read that the Ada system was safer than C++ templates. I'm
> just looking for some distinctive features.

I cannot tell anything for Java, but Ada generics as compared with
templates are "more":

1. Contract-based (this is the most important feature)

2. Support separate compilation (1 is a premise to have this)

3. Generic object parameters can have any type (in C++ you cannot use
float, for example)

4. Generic object parameters can be mutable (in C++ only constants are
allowed)

5. Generic type parameters can be limited to a class of types, like any
integer type, or any type derived for some base, or any array type of
elements etc. In C++ matching is untyped.

6. Generic instance parameters. You can pass an instance as a parameter.

7. Generic packages (~namespaces). Anything you put in gets parametrized by
the formal parameters and instantiated upon the package instantiation.

8. Keyed association of generic parameters

9. Defaults for generic parameters

10. Nested generics and generic children

(I don't list what is less than in C++, because you didn't ask for it.
(:-))

-- 
Regards,
Dmitry A. Kazakov
http://www.dmitry-kazakov.de

Re: Ada generics

[Martin Krischik]

Dmitry A. Kazakov schrieb:

> 2. Support separate compilation (1 is a premise to have this)

C++ 2003 now has "export" templates which promises separate compilation. 
But it is an optional feature and only one compiler [1] implements it. I 
guess it is missing point 1 which makes it so difficult.

Anyway this brings me to:

11. Ada compiler vendors actually implement generics as they are 
described in the ISO standard while C++ often lack features.

Martin

[1] http://www.comeaucomputing.com/

Re: Ada generics

[Hyman Rosen]

Martin Krischik wrote:
> Dmitry A. Kazakov schrieb:
>
> > 2. Support separate compilation (1 is a premise to have this)
>
> C++ 2003 now has "export" templates which promises separate compilation.
> But it is an optional feature and only one compiler [1] implements it. I
> guess it is missing point 1 which makes it so difficult.

Remember that C++ templates support specializations while Ada generics
do not. That means that instantiating a generic will depend much more
heavily on the parameters than is the case in Ada. In the same vein,
the automatic type conversions that C++ supports and Ada does not also
affect the instantiated code. This makes compiling a template itself
not a terribly useful operation. The compiler can verify syntactical
correctness and can bind some names which are not dependent on the
parameters, but it can do very little else until instantiation.
Furthermore, because of the popularity of template metaprogramming,
compilers know to apply intensive inlining while compiling
instantiations, lessening the meaningfulness of separate compilation
even more.

Re: Ada generics

[Martin Krischik]

Dmitry A. Kazakov schrieb:

> 2. Support separate compilation (1 is a premise to have this)

C++ 2003 now has "export" templates which promises separate compilation. 
But it is an optional feature and only one compiler [1] implements it. I 
guess it is missing point 1 which makes it so difficult.

Anyway this brings me to:

11. Ada compiler vendors actually implement generics as they are 
described in the ISO standard while C++ often lack features.

Martin

[1] http://www.comeaucomputing.com/

Re: Ada generics

[Hyman Rosen]

Dmitry A. Kazakov wrote:
> 1. Contract-based (this is the most important feature)

The C++ community is working on something called "concepts" which will
be a way for templates to specify constraints on the parameters. The
difficulty in C++ is the presence of automatic conversions and
different overloaded operators. For example, you may have a template
which uses "x < y" for the objects declared to be of type parameter T.
When instantiating, there could be many ways of compiling this
statement depending on the nature of the type parameter. It can be a
member function of T taking one or two parameters, it can be a global
function taking two T parameters, or it can be a function taking
parameters not of type T but of a type to which T can be converted
automatically. Similarly, the return type can be bool, or it can be a
numeric type, or some object type that can be automatically converted
to bool. Automatic type conversion is a fixed part of the C++ universe,
and templates have to live and work within that environment.

In any case, it's never been clear to me why constraints on generic
parameters are considered to be so important by some people. Why not
let templates be instantiated with anything the caller likes? In C++,
if the parameters fail to satisfy some requirement in the template,
then the compilation will fail. If the compilation succeeds, then you
have a working instantiation. It's more likely that a constraint will
prevent an unforeseen but valid usage from working than that it will
catch some kind of error.

> 3. Generic object parameters can have any type (in C++ you cannot use
> float, for example)

Just a note on the float constraint. C++ considers instantiations
identical if their parameters are identical, and introducing floating
point can lead to ambiguities that the language designers chose to
avoid by fiat. It's just the usual floating point issues, e.g., is
1.0/3.0*3.0 the same as 1.0? On which platforms?

> 6. Generic instance parameters. You can pass an instance as a parameter.

C++ template parameters can themselves be template names. Is this
something similar?

> 7. Generic packages (~namespaces). Anything you put in gets parametrized by
> the formal parameters and instantiated upon the package instantiation.

In C++, classes serve the same purpose as do Ada packages, so this is
not really a difference.

> 9. Defaults for generic parameters

C++ templates parameters can also have default values. However the lack
of named association does mean that only a rightmost set can be elided.

> 10. Nested generics and generic children

C++ class templates can have further class templates declared inside
them, and class templates can inherit from other classes, so I don't
see a difference here.

Re: Ada generics

[Markus E Leypold]

"Hyman Rosen" <hyman.rosen@gmail.com> writes:

> In any case, it's never been clear to me why constraints on generic
> parameters are considered to be so important by some people. Why not
> let templates be instantiated with anything the caller likes? In C++,
> if the parameters fail to satisfy some requirement in the template,
> then the compilation will fail. If the compilation succeeds, then you
> have a working instantiation. It's more likely that a constraint will
> prevent an unforeseen but valid usage from working than that it will
> catch some kind of error.

The same kind of argument could be applied to type systems:

 | In any case, it's never been clear to me why typing is considered
 | to be so important by some people ... It's more likely that a type
 | will prevent an unforeseen but valid usage from working than that
 | it will catch some kind of error.

I think the purpose is not "catching errors" but more likely
delivering abstraction. A constraint gives rules how a user of
reusable component have to use the component and thus reserve freedom
for future implementation changes: "You have to use the compoment like
this. Other usages would perhaps work with the present implementation,
but we don't want to guarantee for future implementations. We might
want to change implementation." That basically is the other side of
the contract offered to the component users by the component
developers.

C++ templates are something like: If it links and if it works then
it's OK, if not, bad luck. That is not a contract, just the license to
abuse a given implementation. And the license top break any existing
implementation.


>> 3. Generic object parameters can have any type (in C++ you cannot use
>> float, for example)
>
> Just a note on the float constraint. C++ considers instantiations
> identical if their parameters are identical, and introducing floating
> point can lead to ambiguities that the language designers chose to
> avoid by fiat. It's just the usual floating point issues, e.g., is
> 1.0/3.0*3.0 the same as 1.0? On which platforms?

Which just goes to show how evil that approach is.

Regards -- Markus

Re: Ada generics

[Hyman Rosen]

Markus E Leypold wrote:
> I think the purpose is not "catching errors" but more likely delivering abstraction.

True enough. Right now, that has to be handled in C++ by documentation.
But the effect is just to let some things work that otherwise would be
stopped.

> Which just goes to show how evil that approach is.

Nonsense. C++'s approach to identifying instantiations serves it
excellently well in a variety of ways - traits classes,
metaprogramming, optimized specializations, and best of all, automatic
instantiation of function templates. You are simply displaying the
usual comp.lang.ada parochialism of "if Ada doesn't have it then you
don't need it". A non-type template parameter can be a reference to a
floating point object, by the way, so the lack isn't all that serious:
    extern double sin(double);
    extern double const epsilon = 1e-6;
    template <double (&F)(double), const double &E>
    double integrate(double from, double to) { ... }
    int main() { integrate<sin, epsilon>(0.0, 3.14); }

Re: Ada generics

[Markus E Leypold]

"Hyman Rosen" <hyman.rosen@gmail.com> writes:

> Markus E Leypold wrote:
>> I think the purpose is not "catching errors" but more likely delivering abstraction.
>
> True enough. Right now, that has to be handled in C++ by documentation.
> But the effect is just to let some things work that otherwise would be
> stopped.

But that is not enough. A language specification essentially provides
a vocabulary to describe interfaces between system components. It
talks about types, language objects that are in interfaces, which
parts of them are visible and what might be the permitted usage.

If that framework is missing you simply don't have the tools to
document the contract. 

Look at the empirical evidence how well components occuring "in the
wild" are documented in various languages. My impression is, that
languages with language mechanisms for modularization (like Ada,
Modula, Ocaml, ...) have a much better track record. YMMV.


>
>> Which just goes to show how evil that approach is.
>
> Nonsense. C++'s approach to identifying instantiations serves it
> excellently well in a variety of ways - traits classes,
> metaprogramming, optimized specializations, and best of all, automatic
> instantiation of function templates. 

You only have to do all that if you "instantiate" templates in header
files. If on the other side you have a separation into bodies and
interfaces there is a place where the package gets instantiated
(basically a place where the open parameters describing the data sizes
and stackframe layout are recorded). And that simply is the package
instance -- no need to generate code and no need to fold multiple
instantiation with the same parameters into one.

In Ada -- as I understand it -- an instantiation is simply identified
by the place where the

This approach is of cause not possible with header files (inclusion
vs. usage).

I do not want offer flame bait here, but ... -- I'm programming and
have been programming in a really wide range of languages, from
assembly to pure functional languages, and the older I become, the
more I'm appalled what a mess C++ is conceptually. 

You say, the right way in C++ is not types or interface constraints,
but "to handle it by documentation". I suggest, that the very, I'd
say, "openness" of most template definitions, make it just impossible
to define an abstract interface (i.e. to establish a contract between
component provider and component user).

Of course one can always employ "coding standards" top enforce the
required discipline. But that simply amounts to double work: First
write the component, then document it (or the other way
round). Instead of making a core part of the documentation into a part
of the language: The interface. And double work just results in the
"unnecessary" part being dropped under pressure.

I've compiled 20 years old Ada 83 code with Gnat after renaming just
some files. Have you ever tried to rebuild a C++-projekt from last
year or from 5 years ago?

> You are simply displaying the
> usual comp.lang.ada parochialism of "if Ada doesn't have it then you

No, I don't. Indeed, I can (in the mean time :-) point out very well,
where Ada misses the train for "the 21st century", except perhaps for
embedded programming.

But C++ simply is atrocious. Of course, now that there is so much code
around written in C++, a lot of people can earn their daily bread by
applying "social" and technical fixes to the language specification
bugs, like, coding standards, reading and applying the lessons from
Scott Meyers books and using memory debugger like valgrind. So
overall, and given the global employment situation it's perhaps a good
thing :-).

Not that coding standards are necessarily a bad thing: But they
shouldn't be cluttered with preaching ad-hoc fixes to something that
is actually a language problem. Dito valgrind is a good tool: But why
would I have to apply that to a desktop application?


> don't need it". A non-type template parameter can be a reference to a


The point is more about the things C++ doesn't have. :-)


> floating point object, by the way, so the lack isn't all that serious

>     extern double sin(double);
>     extern double const epsilon = 1e-6;
>     template <double (&F)(double), const double &E>
>     double integrate(double from, double to) { ... }
>     int main() { integrate<sin, epsilon>(0.0, 3.14); }


I fear you're proving my point here :-). I'm not talking about wether
things can be done at all. I'm mostly concerned how they are done, and
wether code written today can be read and understood in a finite
amount of time by the maintenance programmer who checks it out from
version control in 10 years time. 

Just to support my case: I think, the ARM and the Barnes book is good
enough to learn most of Ada if you got some background in "strongly"
statically typed languages (Pascal, ML, maybe Java) and some in
procedural languages (like C or Pascal). The Barnes book could be at
tiny bit more precise and complete in some points, but overall, it
makes a really good read.

C++ on the other side cannot be learned from the standard and book
X. Of course that might be my inability. The only good C++ book (IMHO)
are those "smart" hackish books like those of Scott Meyer. They make
good conversation pieces, but only highlight "intresting" corners of
the language. There is no book from which you can learn to read C++.

But as I said: YMVV.

Regards -- Markus 

Re: Ada generics

[Markus E Leypold]

Markus E Leypold <development-2006-8ecbb5cc8aREMOVETHIS@ANDTHATm-e-leypold.de> writes:

>> Nonsense. C++'s approach to identifying instantiations serves it
>> excellently well in a variety of ways - traits classes,
>> metaprogramming, optimized specializations, and best of all, automatic
>> instantiation of function templates. 
>
> You only have to do all that if you "instantiate" templates in header
> files. If on the other side you have a separation into bodies and
> interfaces there is a place where the package gets instantiated
> (basically a place where the open parameters describing the data sizes
> and stackframe layout are recorded). And that simply is the package
> instance -- no need to generate code and no need to fold multiple
> instantiation with the same parameters into one.
>
> In Ada -- as I understand it -- an instantiation is simply identified
> by the place where the

... package is instantiated.

>
> This approach is of cause not possible with header files (inclusion
> vs. usage).
>


Regards -- Markus

Re: Ada generics

[Marco]

> I've compiled 20 years old Ada 83 code with Gnat after renaming just
> some files. Have you ever tried to rebuild a C++-projekt from last
> year or from 5 years ago?

   How true, we just search for forgiving C++ compilers (such as Intel)
to keep pushing the old C++ forward.

  I suggest that the OP implement a generic sort, stack etc in each
language to get a feel for the differences. Then try creating instances.

Re: Ada generics

[Hyman Rosen]

Marco wrote:
>    How true, we just search for forgiving C++ compilers (such as Intel)
> to keep pushing the old C++ forward.

You would be much better served by getting a harsh and forbidding
C++ compiler that would reject all the old bad code. Then you could
just fix it once, even though it would be painful, and be done. I
recommend Comeau <http://www.comeaucomputing.com/tryitout/>.

Re: Ada generics

[Marco]

Hyman Rosen wrote:
> Marco wrote:
> >    How true, we just search for forgiving C++ compilers (such as Intel)
> > to keep pushing the old C++ forward.
>
> You would be much better served by getting a harsh and forbidding
> C++ compiler that would reject all the old bad code. Then you could
> just fix it once, even though it would be painful, and be done. I
> recommend Comeau <http://www.comeaucomputing.com/tryitout/>.

 I don't disagree but management doesn't want to spend the money.  It
is a just an example of old Ada code being in better shape than old C++
code.

Re: Ada generics

[Hyman Rosen]

Markus E Leypold wrote:
> But that is not enough. A language specification essentially provides
> a vocabulary to describe interfaces between system components. It
> talks about types, language objects that are in interfaces, which
> parts of them are visible and what might be the permitted usage.

With C++ templates you do that by reading the entire source of the
template. It's not unlike the other message recently posted which
complained of GNAT needing source code to perform inlining. If you
want a specification, you need to design the specification language
and it has to be expressive enough to say everything you need. In
the case of C++ templates, that's relatively difficult, and so the
source of the template itself serves as the specification for what
it accepts. Perhaps it's weird and chaotic, but it pretty much works.

> You only have to do all that if you "instantiate" templates in header
> files. ... no need to generate code and no need to fold multiple
> instantiation with the same parameters into one.

Header files have nothing to do with it, and there is every need to
do instantiation folding. C++ templates are not Ada generics. They are
all instantiated at compile time, and specialization means that the
distinction between an instantiation using one set of types or another
can be vastly greater than just a few layout parameters. If you don't
understand this essential difference, you're just going to be very
confused.

> In Ada -- as I understand it -- an instantiation is simply identified
> by the place where the package is instantiated.

Except that each time through the instantiation, the parameters aren't
necessarily the same, since there can be array sizes and subtypes and
discriminants involved.

> This approach is of cause not possible with header files (inclusion
> vs. usage).

Header files are a red herring. There are essential, not superficial,
language differences going on.

> Have you ever tried to rebuild a C++-projekt from last
> year or from 5 years ago?

Ugh. Have I ever. The main problem in this respect with C++ was that
the language became popular well ahead of its standard. That meant
that a million implementations bloomed, and vendors kept scrambling
to keep old code working while trying to adopt the new features in
the standard. Then the standard itself was hamstrung trying to not
break too much old code. I absolutely agree that the state of C++
code and the state of C++ compilers, and to some extent the state of
the standard itself, is a total mess.

Re: Ada generics

[Dmitry A. Kazakov]

On 22 Dec 2006 08:41:36 -0800, Hyman Rosen wrote:

> Dmitry A. Kazakov wrote:
>> 1. Contract-based (this is the most important feature)
> 
> The C++ community is working on something called "concepts" which will
> be a way for templates to specify constraints on the parameters. The
> difficulty in C++ is the presence of automatic conversions and
> different overloaded operators. For example, you may have a template
> which uses "x < y" for the objects declared to be of type parameter T.
> When instantiating, there could be many ways of compiling this
> statement depending on the nature of the type parameter. It can be a
> member function of T taking one or two parameters, it can be a global
> function taking two T parameters, or it can be a function taking
> parameters not of type T but of a type to which T can be converted
> automatically. Similarly, the return type can be bool, or it can be a
> numeric type, or some object type that can be automatically converted
> to bool. Automatic type conversion is a fixed part of the C++ universe,
> and templates have to live and work within that environment.

Automatic conversions do not represent any special case. If S is
convertible to T, then S is a subtype of T, in the sense that it inherits <
from it. When S defines <, that is equivalent to overriding <. C++'s
problem is in chaotic design. There is no need in a new concept of
"concept," sorry for an unintended pun. That concept is called class = a
set of types.

> In any case, it's never been clear to me why constraints on generic
> parameters are considered to be so important by some people. Why not
> let templates be instantiated with anything the caller likes? In C++,
> if the parameters fail to satisfy some requirement in the template,
> then the compilation will fail. If the compilation succeeds, then you
> have a working instantiation. It's more likely that a constraint will
> prevent an unforeseen but valid usage from working than that it will
> catch some kind of error.

There is an even better way. It could be called "genetic programming." Let
the template generate an arbitrary code. If it compiles, it goes into
production. Customers give a feedback...(:-))

>> 3. Generic object parameters can have any type (in C++ you cannot use
>> float, for example)
> 
> Just a note on the float constraint. C++ considers instantiations
> identical if their parameters are identical, and introducing floating
> point can lead to ambiguities that the language designers chose to
> avoid by fiat. It's just the usual floating point issues, e.g., is
> 1.0/3.0*3.0 the same as 1.0? On which platforms?

Exactly. The idea of structural matching is wrong. It is uncheckable. So
what language designers do? Ada designers drop the idea and go typed. C++
designers chaotically drop some cases and some checks in an attempt to save
something that cannot be.

[ BTW, I am unhappy with anonymous access types introduced in Ada 95. It
was the C++ way. ]

>> 6. Generic instance parameters. You can pass an instance as a parameter.
> 
> C++ template parameters can themselves be template names. Is this
> something similar?

Yes, I think so.

>> 7. Generic packages (~namespaces). Anything you put in gets parametrized by
>> the formal parameters and instantiated upon the package instantiation.
> 
> In C++, classes serve the same purpose as do Ada packages, so this is
> not really a difference.

It is actually the difference between packages in Ada and classes in C++.
They are not equivalent.

>> 10. Nested generics and generic children
> 
> C++ class templates can have further class templates declared inside
> them, and class templates can inherit from other classes, so I don't
> see a difference here.

I think that 10 and 7 are in fact the same question, and any difference is
not specific to generics/templates.

-- 
Regards,
Dmitry A. Kazakov
http://www.dmitry-kazakov.de

Re: Ada generics

[Hyman Rosen]

Dmitry A. Kazakov wrote:
> Automatic conversions do not represent any special case. If S is
> convertible to T, then S is a subtype of T

That simply is not the case in C++. Automatic conversions do not
define subtypes in any meaningful or useful sense. For example,
all the numeric types automatically convert to each other. It's
also possible to write automatic conversions between arbitrary
classes. It may be chaotic as you say, but that's the way the
language is, and templates have to work within that framework.
"Concepts" will be useful to those people who want the ability to
specify such constraints.

> Exactly. The idea of structural matching is wrong.

It's not wrong, and it's not even structural. It is in fact
matching by name, not by structure. It's only in the case of
constant expressions that things go a little awry. But if you
recall the discussions we've had here on implementing units,
it lets C++ do things that are impossible in Ada.

> It is actually the difference between packages in Ada and classes in C++.
> They are not equivalent.

Not entirely, naturally, but classes in C++ are used for the same
kind of structuring purposes as Ada packages. Certainly C++ classes
are used to define bundles of types, constants, and functions, and
that can be done generically.

Re: Ada generics

[Dmitry A. Kazakov]

On Mon, 25 Dec 2006 13:49:23 GMT, Hyman Rosen wrote:

> Dmitry A. Kazakov wrote:
>> Automatic conversions do not represent any special case. If S is
>> convertible to T, then S is a subtype of T
> 
> That simply is not the case in C++. Automatic conversions do not
> define subtypes in any meaningful or useful sense. For example,
> all the numeric types automatically convert to each other. It's
> also possible to write automatic conversions between arbitrary
> classes.

Ah, but it is not required for S<:T & T<:S be wrong. Two types can be
subtypes of each other like int and float are in C. It is a common
misconception about subtypes to believe that either must not hold. Observe,
that it is wrong in Ada either. Consider this:

   type T is range 1..100;
   subtype S is T;
   procedure Exported_To_Base (X : in out S);

   X : T;
begin
   Exported_To_Base (X);  -- It is fine!

See, the operation Exported_To_Base defined on S was exported to the base
type T. In other words T inherits it from S, which is equivalent to say
that T is a subtype of S. T and S are sub-/supertypes of each other.

>> Exactly. The idea of structural matching is wrong.
> 
> It's not wrong, and it's not even structural. It is in fact
> matching by name, not by structure.

But in foo<123>, 123 is not a name. It could be in some other language
where I could do:

int 123() const
{
   return ::124; // (:-))
}

But that would make many of instantiations ambiguous.

> It's only in the case of
> constant expressions that things go a little awry. But if you
> recall the discussions we've had here on implementing units,
> it lets C++ do things that are impossible in Ada.

You mean automatic instantiation here, but I don't want it. I also don't
want this solution for this problem. I even dare say that this is a bad
solution for *any* problem. Looking a bit more deeply into the issue, there
are two things to address:

1. compile-time computations

2. types computations (types algebra)

Generics and templates offer some quite weird and limited way to have 1.
and 2. Ask yourself, is it the only way?

-- 
Regards,
Dmitry A. Kazakov
http://www.dmitry-kazakov.de

Re: Ada generics

[Hyman Rosen]

Dmitry A. Kazakov wrote:
> Ah, but it is not required for S<:T & T<:S be wrong.

I get tired of arguing these semantics with you, so I just won't.

> But in foo<123>, 123 is not a name.

Why not? The integer 123 is the integer 123. If I say foo<123>,
I get a composite name formed of foo and 123. What's the difference
between the number 123 and the name 123?

> You mean automatic instantiation here, but I don't want it.

Well, I do, so I guess we're each using the proper language.

> Ask yourself, is it the only way?

No, but it's the only way that's simultaneously part of a systems
programming language that I'd want to use anyway.

Re: Ada generics

[Dmitry A. Kazakov]

On Tue, 26 Dec 2006 01:34:14 GMT, Hyman Rosen wrote:

> Dmitry A. Kazakov wrote:

>> But in foo<123>, 123 is not a name.
> 
> Why not? The integer 123 is the integer 123. If I say foo<123>,
> I get a composite name formed of foo and 123. What's the difference
> between the number 123 and the name 123?

Name (identifier) has referential semantics defined by the language.
Therefore when names are identical so are the language objects they refer
to. When you compare values of potentially different objects instead, then
the semantics of the comparison is not necessarily identity. In fact, it is
outside the language. This is why already foo<12.3> faces difficulties.
While foo<http://123.0.56.6> can't work at all.

>> Ask yourself, is it the only way?
> 
> No, but it's the only way that's simultaneously part of a systems
> programming language that I'd want to use anyway.

I don't see what systems programming has to do with templates.

-- 
Regards,
Dmitry A. Kazakov
http://www.dmitry-kazakov.de

Re: Ada generics

[Hyman Rosen]

Dmitry A. Kazakov wrote:
> When you compare values of potentially different objects instead, then
> the semantics of the comparison is not necessarily identity. In fact, it is
> outside the language.

I think the issue here is not unlike that faced by programming
languages when dealing with Unicode in identifiers. (I took a quick
glance through AI-285.) There are potentially several ways that a
character can be written in the source text, and the compilers must
decide what it is that is written, and which forms must be considered
identical and which distinct. There is certainly no problem in defining
by fiat the semantics for doing template floating-point arithmetic, but
the committee didn't think it was worth the effort. It's the sort of
thing that Ada goes through with its universal floats, but at least
there the application is of wider use.

> I don't see what systems programming has to do with templates.

C++ was written as an enhancement for people already using C. It gave
those people a great deal of extra expressive power, but they would not
have given up what they already had.

Re: Ada generics

[Dmitry A. Kazakov]

On 26 Dec 2006 08:23:32 -0800, Hyman Rosen wrote:

> Dmitry A. Kazakov wrote:
>> When you compare values of potentially different objects instead, then
>> the semantics of the comparison is not necessarily identity. In fact, it is
>> outside the language.
> 
> I think the issue here is not unlike that faced by programming
> languages when dealing with Unicode in identifiers. (I took a quick
> glance through AI-285.) There are potentially several ways that a
> character can be written in the source text, and the compilers must
> decide what it is that is written, and which forms must be considered
> identical and which distinct.

I didn't look at the AI, but it is definitely a different problem. The
language should be defined in terms of code points. The encoding of is
irrelevant. When some sequences of code points (=words) are considered
equivalent in the language like | and ! are in Ada, that is not yet
matching by structure. It were if Ada would be defined in terms of glyphs.
Fortunately it is not.

> There is certainly no problem in defining
> by fiat the semantics for doing template floating-point arithmetic, but
> the committee didn't think it was worth the effort. It's the sort of
> thing that Ada goes through with its universal floats, but at least
> there the application is of wider use.

We are talking not about floats, but about the principle of matching by
content. There is no any chance to hold on it:

   template <p> void foo<HALT(p)> ...

>> I don't see what systems programming has to do with templates.
> 
> C++ was written as an enhancement for people already using C. It gave
> those people a great deal of extra expressive power, but they would not
> have given up what they already had.

This is a different statement, which sounds a bit silly in the context of
the thread. Basically it is - many who learned C as the first language were
so devastated by this experience, so it would be just inhumane to ask them
to lean anything else. For this reason they must face that horror time and
again. I cannot judge. I am not a psychoanalytic, nor C was my first. (:-))

-- 
Regards,
Dmitry A. Kazakov
http://www.dmitry-kazakov.de

Re: Ada generics

[Hyman Rosen]

Dmitry A. Kazakov wrote:
> The language should be defined in terms of code points.
 > The encoding of is irrelevant.

And non-type template parameters are defined in terms of their
values. The expression used to formulate them is irrelevant.
An arbitrary-precision rational number package would be enough
to make floating-point template parameters be portably defined.
It's just not worth the work.

> matching by structure

To say that 1 + 1 and 2 are equivalent isn't matching by structure
as far as I'm concerned, but we're not going to agree on that one.

> We are talking not about floats, but about the principle of matching by
> content. There is no any chance to hold on it:
>    template <p> void foo<HALT(p)> ...

What's the problem with that? It's a compile-time operation on
constants. The compiler will just trundle along and it will either
halt, run out of resources, or continue running forever. All
language standards allow compilers to impose resource constraints
on the programs being compiled.

Re: Ada generics

[Dmitry A. Kazakov]

On Wed, 27 Dec 2006 01:44:52 GMT, Hyman Rosen wrote:

> Dmitry A. Kazakov wrote:
>> The language should be defined in terms of code points.
>  > The encoding of is irrelevant.
> 
> And non-type template parameters are defined in terms of their
> values. The expression used to formulate them is irrelevant.

Yes, if that expression were outside the language. The "encoding language"
is outside the programming language, so it is not the language problem, if
any. But because the expressions used in templates are language expressions
you have to consider them there.

> An arbitrary-precision rational number package would be enough
> to make floating-point template parameters be portably defined.

No, it would not. Consider 1.0 / 3.0

> It's just not worth the work.
> 
>> matching by structure
> 
> To say that 1 + 1 and 2 are equivalent isn't matching by structure
> as far as I'm concerned, but we're not going to agree on that one.

Surely it is. The language does define the formula 1+1 trivially equivalent
to 2. So because 1+1 is a formula the compiler shall prove that in all
valid states P(1+1) <=> P(2). In Ada it were improvable.

>> We are talking not about floats, but about the principle of matching by
>> content. There is no any chance to hold on it:
>>    template <p> void foo<HALT(p)> ...
> 
> What's the problem with that? It's a compile-time operation on
> constants. The compiler will just trundle along and it will either
> halt, run out of resources, or continue running forever. All
> language standards allow compilers to impose resource constraints
> on the programs being compiled.

But it is not same as having legal finite programs which cannot be compiled
no matter how much resources you have. The set of all programs were
subdivided into:

W - illegal programs
T - legal, but fundamentally non-compilable
U L(N) - legal and compilable with N resources, N<oo

Now:

1. how easy one can modify p from L(N) to become T?
[very]

2. is there a way to determine if some p outside L(N) is from any L(M>N)?
[no]

3. what is the use of p from T?
[none]

4. is it decidable whether p is in T or in W?
[no]

-- 
Regards,
Dmitry A. Kazakov
http://www.dmitry-kazakov.de

Re: Ada generics

[Hyman Rosen]

Dmitry A. Kazakov wrote:
> The "encoding language" is outside the programming language,
> so it is not the language problem

Remember that Ada wishes to be case-insensitive, so it cannot ignore
Unicode issues if it wishes to allow Unicode characters in identifiers.
Not to mention "normalization form KC".

> No, it would not. Consider 1.0 / 3.0

I believe an arbitrary-precision rational number package can portably
represent 1/3! An encoded name for an instantiation involving floating
point numbers could simply represent the number portably as a rational
in lowest terms.

> But it is not same as having legal finite programs which cannot be compiled
> no matter how much resources you have.

So what? Since templates form a compile-time Turing-complete language,
C++ compilers can be sent into calculations which may or may not
terminate, just like programs themselves have always been able to do.
No one has palpitations over the fact that for some programs you can't
tell whether they're wrong or just haven't finished yet. Why should
anyone worry that there are some programs which you can't tell whether
they're wrong or the compiler hasn't finished yet? In order for a
compilation to not terminate, it must constantly generate new
instantiations, so anyway real compilers will just notice and give up.

Re: Ada generics

[Dmitry A. Kazakov]

On 27 Dec 2006 11:06:36 -0800, Hyman Rosen wrote:

> Dmitry A. Kazakov wrote:
>> The "encoding language" is outside the programming language,
>> so it is not the language problem
> 
> Remember that Ada wishes to be case-insensitive,

That's no problem in a closed alphabet, like English/Latin.

> so it cannot ignore
> Unicode issues if it wishes to allow Unicode characters in identifiers.

Which is a BAD idea, IMO.

We cannot know anything about properties of letters in Klingon. As a
practical example consider Russian where e can be used (and is) in place of
ё see (http://en.wikipedia.org/wiki/%D0%81), but not reverse. Or, maybe we
should make Ada compilers capable to detect program written by Germans to
consider ü and ue same? Should we handle diacritical vowel points of Hebrew
as well? What about parsing the source right to left, or top to bottom?

> Not to mention "normalization form KC".

They reap what they sowed. Should Ada or C++ go into that mess? 

>> No, it would not. Consider 1.0 / 3.0
> 
> I believe an arbitrary-precision rational number package can portably
> represent 1/3! An encoded name for an instantiation involving floating
> point numbers could simply represent the number portably as a rational
> in lowest terms.

Huh, Ada.Numerics has pi and e...

>> But it is not same as having legal finite programs which cannot be compiled
>> no matter how much resources you have.
> 
> So what? Since templates form a compile-time Turing-complete language,
> C++ compilers can be sent into calculations which may or may not
> terminate, just like programs themselves have always been able to do.
> No one has palpitations over the fact that for some programs you can't
> tell whether they're wrong or just haven't finished yet. Why should
> anyone worry that there are some programs which you can't tell whether
> they're wrong or the compiler hasn't finished yet? In order for a
> compilation to not terminate, it must constantly generate new
> instantiations, so anyway real compilers will just notice and give up.

Because when the program does not compile the programmer would not know if
that was his bug or one of the compiler. This is a quite common problem in
C++ (and sadly in GNAT Ada), which wastes enormous human resources. And
this is the case where you actually wished to save them by providing this
"nice" feature. With a sufficient amount of memory, the programmer would
not be able to even decide, empirically, because theoretically it were
impossible anyway, if the compiler hangs or will crash later. I.e. you
might sit 5-10 minutes in hope that it manage to chew over that fancy
templates, before you would kill it in frustration. More memory you'll have
worse it will be.

BTW, it could be a yet another source of earning money. Consider numerous
chains of [expensive] tools for template "optimization." That is source
code conversions which would make compilation crashing faster! (:-))

-- 
Regards,
Dmitry A. Kazakov
http://www.dmitry-kazakov.de

Re: Ada generics

[Hyman Rosen]

Dmitry A. Kazakov wrote:
> They reap what they sowed. Should Ada or C++ go into that mess?

Well, they have. It comes of being unwilling to say to the rest of the
world that yes, this programming language is based on English, deal
with it. I expect that one day we will get many alternative sets of
keywords so that people can write "loop" and "type" and "generic" in
their own language.

> Huh, Ada.Numerics has pi and e...

I found this on the web:
    package Ada.Numerics is
    pragma Pure (Numerics);
        Argument_Error : exception;
        Pi : constant :=
3.14159_26535_89793_23846_26433_83279_50288_41971_69399_37511;
        e : constant :=
2.71828_18284_59045_23536_02874_71352_66249_77572_47093_69996;
    end Ada.Numerics;

Those look like rational numbers to me.

> Because when the program does not compile the programmer would not know if
> that was his bug or one of the compiler.

But that's already true. Many optimization techniques are NP-complete
and for certain cases they can take time exponential in the size of the
program.

> Consider numerous chains of [expensive] tools for template "optimization."

In fact, you can find discussions of C++ template techniques that are
analogous to consideration of ordinary algorithm complexity. You can
have templates that are like arrays, templates that are like linked
lists, and so on.

Re: Ada generics

[Dmitry A. Kazakov]

On 28 Dec 2006 08:29:15 -0800, Hyman Rosen wrote:

> Dmitry A. Kazakov wrote:
>> They reap what they sowed. Should Ada or C++ go into that mess?
> 
> Well, they have. It comes of being unwilling to say to the rest of the
> world that yes, this programming language is based on English, deal
> with it. I expect that one day we will get many alternative sets of
> keywords so that people can write "loop" and "type" and "generic" in
> their own language.

Yuck. Maybe it could turn an advantage for Ada being a niche language then.
I hope that a pressure to do that will not be high enough to carry out such
mess.

>> Huh, Ada.Numerics has pi and e...
> 
> I found this on the web:
>     package Ada.Numerics is
>     pragma Pure (Numerics);
>         Argument_Error : exception;
>         Pi : constant :=
> 3.14159_26535_89793_23846_26433_83279_50288_41971_69399_37511;
>         e : constant :=
> 2.71828_18284_59045_23536_02874_71352_66249_77572_47093_69996;
>     end Ada.Numerics;
> 
> Those look like rational numbers to me.

But they are not. If you are going to extend a language in this direction
you should introduce new numeric types, like rational /= float. Further
that does no solve the problem. Because float still exists. You cannot
define float as mathematical real, that would not be computable. You could
say (as it actually is), that float is an interval with rational bounds.
But then you would discover that intervals are incomparable (so the
empirical rule "never compare floats for equality.") This way or another,
it is cannot work.

-- 
Regards,
Dmitry A. Kazakov
http://www.dmitry-kazakov.de

Re: Ada generics

[Hyman Rosen]

Dmitry A. Kazakov wrote:
> > Those look like rational numbers to me.
> But they are not. ... This way or another, it is cannot work.

Of course it can. No matter how you represent the float parameters,
eventually they get used at runtime, at which point the representation
is converted to the closest floating-point number. But if you insist
that floats cannot be compared for equality, then the makers of C++
agreed with you, and left floating template parameters out for that
reason! I claim that I get to have it both ways, and I'm sure you'll
insist that I get to have neither :-) In any case, once again I think
we have come to an impasse over philosophy.

Re: Ada generics

[Georg Bauhaus]

On Thu, 2006-12-28 at 11:59 +0100, Dmitry A. Kazakov wrote:

> > so it cannot ignore
> > Unicode issues if it wishes to allow Unicode characters in identifiers.
> 
> Which is a BAD idea, IMO.
> 
> We cannot know anything about properties of letters in Klingon. As a
> practical example consider Russian where e can be used (and is) in place of
> ё see (http://en.wikipedia.org/wiki/%D0%81), but not reverse. Or, maybe we
> should make Ada compilers capable to detect program written by Germans to
> consider ü and ue same?

Yes, writing source code is a question of being practical, which is
probably not easily formalized... An international character set
for portable programs seems to leave only some choices open when
they should be practical, does it not?
Naturally, mathematical fancies like being complete,
free of contradictions, etc. are out of the question when it
comes to writing for both humans and computers. What's the point
of having a high level language when you are only allowed identifiers
that the most simplistic mechanical interpreter can "understand"?

Why is it that programmers become somewhat irrational and
impractical when it comes to character sets? They do try to devise
all kinds of pattern recognition algorithms, tricky transformations,
get the best out of fuzzy measurement procedures, and so on.
But not so with character sets. No no, every school child knows
that characters must be such and such ... (maybe the early exposition
to characters is to be held accountable here, everyone is an expert :-)

Anyway, do we have some data that we could discuss that would
explain the practical importance of Unicode/casing issues?
Or, do we have programmers who are well versed in
using a keyboard connected to a computer and still can't
write a program that can tell apple characters from orange
characters?

GNAT already supports the detection of identifiers that were 
spelled similarly. In case of errors, it lists their "relatives".
Surely a helpful feature, and a proof that practical handling of
natural language identifiers is possible.
As an example, as you have been referring to German, consider that
sharp s, 'ß', is usually written "SS" when capitalized.
So "Straße" tends to become "STRASSE". Now if you have a composite
word that has
- a 'ß', and
- an 's' right after it,
such as "Maßstab" (= scale, rule, yardstick), then from a simple
minded formalist's perspective I could argue:

  "Using Unicode is nonsense because there is no 1:1 mapping for the
  German word 'Maßstab' which will become 'MASSSTAB'. "SSS" is
  ambiguous, it could be "sß" or it could be "ßs". That's too big
  a challenge for a compiler write. So leave me alone with your
  Unicode and case insensitivity."

Is that what computer science has to answer when asked about
characters handling?

Challenge: Try to find a significant number of German words that
have an 's' before a 'ß'. What's the consequence of your findings?
Even if there are ambiguities in other languages, ambiguities are
not new to Ada (and C++, IIRC), and they have been addressed.

(It seems that the introduction of Unicode to Scheme 6 has recently
made Lisp case sensitive based on arguments such as the one above.
To me this shows "practicality" on the part of the language designer,
vulgo just compiler writer's laziness.)


If the programmers' representatives (the ARG for example) agree that
it is practical to exclude some casing rules or "representation rules",
such as "ue" <-> 'ü', I'm perfectly happy. Because the rule *is*
practical, it helps work, and to hell with mathematical fancies and game
theoretic character shuffling possibilities, when they do not
really matter.

>  What about parsing the source right to left, or top to bottom?

The writing direction problem is solved. Similarly, it seems possible
and practical to connect big endian and little endian computers,
and have them cooperate using algorithms. Both exist, as do apples
oranges, bananas, and pineapples. We can make nice fruit salads.

Re: Ada generics

[Dmitry A. Kazakov]

On Thu, 28 Dec 2006 18:35:06 +0100, Georg Bauhaus wrote:

> GNAT already supports the detection of identifiers that were 
> spelled similarly. In case of errors, it lists their "relatives".
> Surely a helpful feature, and a proof that practical handling of
> natural language identifiers is possible.
> As an example, as you have been referring to German, consider that
> sharp s, '�', is usually written "SS" when capitalized.
> So "Stra�e" tends to become "STRASSE". Now if you have a composite
> word that has
> - a '�', and
> - an 's' right after it,
> such as "Ma�stab" (= scale, rule, yardstick), then from a simple
> minded formalist's perspective I could argue:
> 
>   "Using Unicode is nonsense because there is no 1:1 mapping for the
>   German word 'Ma�stab' which will become 'MASSSTAB'. "SSS" is
>   ambiguous, it could be "s�" or it could be "�s". That's too big
>   a challenge for a compiler write. So leave me alone with your
>   Unicode and case insensitivity."
> 
> Is that what computer science has to answer when asked about
> characters handling?

No. CS is all about introducing formal languages in place of natural ones,
for obvious reasons.

Corollary: never ever make a formal language (Ada) dependent on a natural
one (German). That would make the former natural.

That's the answer of CS, IMO.

-- 
Regards,
Dmitry A. Kazakov
http://www.dmitry-kazakov.de

Re: Ada generics

[Georg Bauhaus]

On Fri, 2006-12-29 at 15:48 +0100, Dmitry A. Kazakov wrote:

> > Is that what computer science has to answer when asked about
> > characters handling?
> 
> No. CS is all about introducing formal languages in place of natural ones,
> for obvious reasons.

But Unicode and/or ISO 10646 *are* formal things.

> Corollary: never ever make a formal language (Ada) dependent on a natural
> one (German). That would make the former natural.

I don't see how identifier rules are natural (not formal), whatever
the natural language is that guides the choice of names in a
particular program. Because of I18N efforts
tool makers can do some work to make programming easier for humans,
even if this means supporting more than the most trivial
interpretation of character bit patterns.

Take Google as an example of why finding things that were spelled
"incorrectly" is so immensly useful. And successful.

Re: Ada generics

[Dmitry A. Kazakov]

On Fri, 29 Dec 2006 20:39:05 +0100, Georg Bauhaus wrote:

> On Fri, 2006-12-29 at 15:48 +0100, Dmitry A. Kazakov wrote:
> 
>>> Is that what computer science has to answer when asked about
>>> characters handling?
>> 
>> No. CS is all about introducing formal languages in place of natural ones,
>> for obvious reasons.
> 
> But Unicode and/or ISO 10646 *are* formal things.

Well, well.

>> Corollary: never ever make a formal language (Ada) dependent on a natural
>> one (German). That would make the former natural.
> 
> I don't see how identifier rules are natural (not formal), whatever
> the natural language is that guides the choice of names in a
> particular program.

Because these rules are subject of endless chaotic political changes. Why
Ada should depend on them? For example, on decisions made by the German
Supreme Court, the federal Ministry of the Interior and Bild?

> Take Google as an example of why finding things that were spelled
> "incorrectly" is so immensly useful. And successful.

Do you want programming languages acting as google? PL/1? Although of
course it was unable to produce 200K+ interpretations of a three-word
program. No, as a language Google were extremely bad.

-- 
Regards,
Dmitry A. Kazakov
http://www.dmitry-kazakov.de

Re: Ada generics

[Georg Bauhaus]

On Sat, 2006-12-30 at 10:58 +0100, Dmitry A. Kazakov wrote:

> >> Corollary: never ever make a formal language (Ada) dependent on a natural
> >> one (German). That would make the former natural.
> > 
> > I don't see how identifier rules are natural (not formal), whatever
> > the natural language is that guides the choice of names in a
> > particular program.
> 
> Because these rules are subject of endless chaotic political changes.

I don't know about ISO or ARG political changes--besides
the rather interesting glimpses at language debates during
Ada 9X in the archives, if you want to call this politics.

But where is the chaos in the simplified Unicode rules that
have been adopted for Ada 2005 (or 2007)? You won't need
thermodynamics to find out whether or not a given word
is an identifier?

Should the characters '1' and 'l' be removed from the
Ada standard characters because that's a similar chaos?
Should there be a ruling about Finalisation versus
Finalization?


> > Take Google as an example of why finding things that were spelled
> > "incorrectly" is so immensly useful. And successful.
> 
> Do you want programming languages acting as google?

No, by referring to the usefulness of Google search I meant that

 * People value Google search service because it finds
   things, even noticing possible spelling errors,
   and it overcomes lack of structure of "the internet".
 * Programs have spelling errors, lack perfect structure.
---------------------------------------------------
 * Program analysis will provide better errors/warnings/info
   if identifier spelling, syntax, languages, etc. are given
   the attention they deserve instead of asking humans to
   always provide proper, clean, simplified input.

Perhaps compilers can profit from a notion of Almost-Homograph.
Something like soundex. When "overriding" is missing, this
circuitry could warn programmers of too similar identifiers.
Or of a possible misspelling of Finalisation.
Or was it Finalization?


 -- Georg 

Re: Ada generics

[Dmitry A. Kazakov]

On Sat, 30 Dec 2006 15:53:24 +0100, Georg Bauhaus wrote:

> On Sat, 2006-12-30 at 10:58 +0100, Dmitry A. Kazakov wrote:
> 
>>>> Corollary: never ever make a formal language (Ada) dependent on a natural
>>>> one (German). That would make the former natural.
>>> 
>>> I don't see how identifier rules are natural (not formal), whatever
>>> the natural language is that guides the choice of names in a
>>> particular program.
>> 
>> Because these rules are subject of endless chaotic political changes.
> 
> I don't know about ISO or ARG political changes--besides
> the rather interesting glimpses at language debates during
> Ada 9X in the archives, if you want to call this politics.

I didn't mean ISO, I did real politic, "Rechtschreibreform" etc.

> Should the characters '1' and 'l' be removed from the
> Ada standard characters because that's a similar chaos?

This is an issue of a proper font selection. These glyphs need not to be
same.

> Should there be a ruling about Finalisation versus
> Finalization?

No, and for exactly same reason why there should also be no ruling that ss
= �.

-- 
Regards,
Dmitry A. Kazakov
http://www.dmitry-kazakov.de

Re: Ada generics

[Georg Bauhaus]

On Mon, 2007-01-01 at 14:00 +0100, Dmitry A. Kazakov wrote:

> > Should there be a ruling about Finalisation versus
> > Finalization?
> 
> No, and for exactly same reason why there should also be no ruling that ss
> = ß.

Should we deny problem domain facts just so that we have very
simple rules for parsers? Where German is written, there is a
simple rule: For writing "ß" in upper case, use "SS".
That's not too hard a challenge to computer science in my view,
but I'll leave that to psychologists to answer when it comes
to the views of actual computer scientists. :-)

You could deny the freedom to write following very normal and
fairly simple writing rules to Ada users in Germany of course. 

Re: Ada generics

[Dmitry A. Kazakov]

On Tue, 02 Jan 2007 11:04:24 +0100, Georg Bauhaus wrote:

> On Mon, 2007-01-01 at 14:00 +0100, Dmitry A. Kazakov wrote:
> 
>>> Should there be a ruling about Finalisation versus
>>> Finalization?
>> 
>> No, and for exactly same reason why there should also be no ruling that ss
>> = �.
> 
> Should we deny problem domain facts just so that we have very
> simple rules for parsers? Where German is written, there is a
> simple rule: For writing "�" in upper case, use "SS".

This is not a domain of the programming language, but one of the natural
language. Somebody was too lazy to write 'sz' and invented a digraph '�'.
Others in other natural languages might come (and did) to even more crazy
ideas like "don't" = "do not". Why should that bother us?

> That's not too hard a challenge to computer science in my view,
> but I'll leave that to psychologists to answer when it comes
> to the views of actual computer scientists. :-)

Simplicity of implementation does not justify doing wrong things! (:-))

-- 
Regards,
Dmitry A. Kazakov
http://www.dmitry-kazakov.de

Re: Ada generics

[Georg Bauhaus]

On Tue, 2007-01-02 at 12:11 +0100, Dmitry A. Kazakov wrote:
 
> > Should we deny problem domain facts just so that we have very
> > simple rules for parsers? Where German is written, there is a
> > simple rule: For writing "ß" in upper case, use "SS".
> 
> This is not a domain of the programming language,

Programming languages use natural language words for good
reasons, for example, because we can think and communicate
more clearly referring to things using descriptive names.
Programming problems cannot reasonably described in full
using only formal symbolism.
Why give up descriptive names just because natural language
words can be slightly more difficult to parse than words
tailored to the needs of the most stupid computer programs?

>  but one of the natural
> language. Somebody was too lazy to write 'sz' and invented a digraph 'ß'.

'ß' is just the concatenation of long s and short s. You will
find long s in old English, too. Strictly, 'Sz' was hardly ever
written, neither was 'zz' as in "wazzer" instead of "wasser" (water).
The rule is: 'ß' becomes 'SS' in upper case. Other languages have
different rules, but they have rules, too.

> Others in other natural languages might come (and did) to even more crazy
> ideas like "don't" = "do not". Why should that bother us?
> 
> > That's not too hard a challenge to computer science in my view,
> > but I'll leave that to psychologists to answer when it comes
> > to the views of actual computer scientists. :-)
> 
> Simplicity of implementation does not justify doing wrong things! (:-))

Indeed, this is why I like to be able to write identifiers
that are written correctly, and not wrong just because we are
given only 7bit-ASCII identifiers as written in
Computeranglosaxonian. :-)

Re: Ada generics

[Dmitry A. Kazakov]

On Tue, 02 Jan 2007 13:33:07 +0100, Georg Bauhaus wrote:

> On Tue, 2007-01-02 at 12:11 +0100, Dmitry A. Kazakov wrote:
>  
>>> Should we deny problem domain facts just so that we have very
>>> simple rules for parsers? Where German is written, there is a
>>> simple rule: For writing "ß" in upper case, use "SS".
>> 
>> This is not a domain of the programming language,
> 
> Programming languages use natural language words for good
> reasons, for example, because we can think and communicate
> more clearly referring to things using descriptive names.

Come on, why on earth "water" is a descriptive name of water. I find "вода"
far more descriptive! (:-)) Natural language words (even pictographs)
describe absolutely nothing but themselves. 

> Programming problems cannot reasonably described in full
> using only formal symbolism.

So what? Maybe mathematical analysis cannot be described in first-order
logic, but that does not mean that "fairy wear boots" were a statement in
either.

> Why give up descriptive names just because natural language
> words can be slightly more difficult to parse than words
> tailored to the needs of the most stupid computer programs?

Why give up? It is not a language business. The language treats *any* names
equally. Any application domain meaning of names is outside the language.

>>> That's not too hard a challenge to computer science in my view,
>>> but I'll leave that to psychologists to answer when it comes
>>> to the views of actual computer scientists. :-)
>> 
>> Simplicity of implementation does not justify doing wrong things! (:-))
> 
> Indeed, this is why I like to be able to write identifiers
> that are written correctly,

Mathematicians use much less descriptive identifies being absolutely free
to use Latin, Greek and Hebrew alphabets. Yet nobody even tried to use full
words. Why?

> and not wrong just because we are
> given only 7bit-ASCII identifiers as written in
> Computeranglosaxonian. :-)

Yet another "German" rule: "a_b" = "ab"? In that spirit, what about
middle-endian integer literals and postfix forms for all function calls?
(:-))

-- 
Regards,
Dmitry A. Kazakov
http://www.dmitry-kazakov.de

Re: Ada generics

[Georg Bauhaus]

On Tue, 2007-01-02 at 14:51 +0100, Dmitry A. Kazakov wrote:

> Come on, why on earth "water" is a descriptive name of water.

"Water" is a descriptive name in the context of a program
using "water" as an identifier. We rely on readers to be able
to give meaning to "water". (Fortunately, we are not forced
to write "WATER" all the time.)

>  I find "вода"
> far more descriptive! (:-))

I wouldn't hesitate to write "вода" in a Russian only program.
In fact, when I translated UI messages for the Serna XML editor
from English into German, it was helpful being able to look
into a Russian dictionary. The developers are from Russia,
and in a few cases the Russian translation of the UI messages 
had good hints to the intended meaning of the English phrases.

>  Natural language words (even pictographs)
> describe absolutely nothing but themselves. 

(How can you be certain of this? :-)

> > Programming problems cannot reasonably described in full
> > using only formal symbolism.
> 
> So what?

It means a programming language should enable its users to choose
good names. To me, this means reasonable flexibility in the choice
of identifiers. We are not yet used to writing π in a geometry program
even though it is an obvious choice for all involved. A few decades
ago, People weren't expecting to be able to write A := {1, 3 .. 15}
when using SETL. They instead had to revert to trigraphs for the
braces and such, IIRC. This has changed. So maybe some day Ada
programmers will be fine with Greek π in geometry programs,
and use ω occasionally, for local variables that have to do with
spinning things.

> The language treats *any* names
> equally. Any application domain meaning of names is outside the language.

I don't think application domain names can be chosen properly if
you won't let application domains influence language design,
including identifier spelling rules (in say 5% of future
programs if Randy's estimates will turn out to be true).


> >> Simplicity of implementation does not justify doing wrong things! (:-))
> > 
> > Indeed, this is why I like to be able to write identifiers
> > that are written correctly,
> 
> Mathematicians use much less descriptive identifies being absolutely free
> to use Latin, Greek and Hebrew alphabets. Yet nobody even tried to use full
> words. Why?

Mathematicians use full words almost all the time when they
explain their reasoning to human readers. 

echo "Let I ⊂ N be a finite index set. For all k ∈ I, P(k)." | wc
      1      15      58

cat | wc
for k in I loop
   assert(P(k));
end loop;
      3       8      43

How many math books or papers are there that use a more terse
mode of expression?

> Yet another "German" rule: "a_b" = "ab"? In that spirit, what about
> middle-endian integer literals and postfix forms for all function calls?
> (:-))

These are not character set and casing issues, and you know it. :-)

Re: Ada generics

[Dmitry A. Kazakov]

On Tue, 02 Jan 2007 15:45:27 +0100, Georg Bauhaus wrote:

> On Tue, 2007-01-02 at 14:51 +0100, Dmitry A. Kazakov wrote:
> 
>> I find "вода" far more descriptive! (:-))
> 
> I wouldn't hesitate to write "вода" in a Russian only program.

Ah, but then you are in a big trouble, because "вода", "воде", "водой",
"воды", "водами", "водах" would all be equivalent in terms of what they
describe, i.e. "water", "lack of content", "confusion making", "being
ignorant", "alcohol drink", "time passed", "equivalence", "being down"?
Should Ada compilers learn Russian inflection rules?

The idea that programs should look like COBOL is just wrong.

>> Natural language words (even pictographs)
>> describe absolutely nothing but themselves. 
> 
> (How can you be certain of this? :-)

As a proof consider a human being who does not know written Russian.

>>> Programming problems cannot reasonably described in full
>>> using only formal symbolism.
>> 
>> So what?
> 
> It means a programming language should enable its users to choose
> good names. To me, this means reasonable flexibility in the choice
> of identifiers. We are not yet used to writing π in a geometry program
> even though it is an obvious choice for all involved. A few decades
> ago, People weren't expecting to be able to write A := {1, 3 .. 15}
> when using SETL. They instead had to revert to trigraphs for the
> braces and such, IIRC. This has changed. So maybe some day Ada
> programmers will be fine with Greek π in geometry programs,
> and use ω occasionally, for local variables that have to do with
> spinning things.

And run into mess. Can you tell me what is what without resorting to a
binary editor in the following:

К, K, Κ, Қ

>> The language treats *any* names
>> equally. Any application domain meaning of names is outside the language.
> 
> I don't think application domain names can be chosen properly if
> you won't let application domains influence language design,
> including identifier spelling rules (in say 5% of future
> programs if Randy's estimates will turn out to be true).

But you have no chance to achieve that. How are you support identifiers
like "man-eating," (not to be mixed with "man eating")?

>>>> Simplicity of implementation does not justify doing wrong things! (:-))
>>> 
>>> Indeed, this is why I like to be able to write identifiers
>>> that are written correctly,
>> 
>> Mathematicians use much less descriptive identifies being absolutely free
>> to use Latin, Greek and Hebrew alphabets. Yet nobody even tried to use full
>> words. Why?
> 
> Mathematicians use full words almost all the time when they
> explain their reasoning to human readers. 
> 
> echo "Let I ⊂ N be a finite index set. For all k ∈ I, P(k)." | wc
>       1      15      58

Huh, none of these words is an *identifier*! They just don't use
descriptive identifiers, neither for free variables, nor for functions.

> How many math books or papers are there that use a more terse
> mode of expression?
> 
>> Yet another "German" rule: "a_b" = "ab"? In that spirit, what about
>> middle-endian integer literals and postfix forms for all function calls?
>> (:-))
> 
> These are not character set and casing issues, and you know it. :-)

But ss = ß wasn't either!

BTW, nobody answered if "іf" and "аccess" were legal Ada 2005 identifiers.
Are they?

-- 
Regards,
Dmitry A. Kazakov
http://www.dmitry-kazakov.de

Re: Ada generics

[Hyman Rosen]

Dmitry A. Kazakov wrote:
> And run into mess. Can you tell me what is what without resorting to a
> binary editor in the following:
>
> К, K, Κ, Қ

This very issue has caused no amount of consternation in the browser
universe, because people have set up spoof and phishing sites using
characters which look like English but aren't.

Re: Ada generics

[Georg Bauhaus]

On Wed, 2007-01-03 at 11:10 +0100, Dmitry A. Kazakov wrote:
> On Tue, 02 Jan 2007 15:45:27 +0100, Georg Bauhaus wrote:
> 
> > On Tue, 2007-01-02 at 14:51 +0100, Dmitry A. Kazakov wrote:
> > 
> >> I find "вода" far more descriptive! (:-))
> > 
> > I wouldn't hesitate to write "вода" in a Russian only program.
> 
> Ah, but then you are in a big trouble, because "вода", "воде", "водой",
> "воды", "водами", "водах" would all be equivalent in terms of what they
> describe, i.e. "water", "lack of content", "confusion making", "being
> ignorant", "alcohol drink", "time passed", "equivalence", "being down"?
> Should Ada compilers learn Russian inflection rules?

Declination etc. can be overcome by object oriented spelling.
Always use the nominative, and have ":=" etc. indicate the other
cases. :-)

As for ambiguity, English is full of it, too. "Springs" has at
least three different meanings I can think of. The plural is
actually used in one package naming idiom (package - plural,
type - singular). So if you have an ASCII 7bit named Springs
package, what's in it?


> The idea that programs should look like COBOL is just wrong.

Having looked at Cobol from time to time, I don't agree.
I find it neither verbose nor unclear. (Fortran >= 95 uses far
more words in some cases.)

> >> Natural language words (even pictographs)
> >> describe absolutely nothing but themselves. 
> > 
> > (How can you be certain of this? :-)
> 
> As a proof consider a human being who does not know written Russian.

So to a Russian, a Russian language word describes something. Right?


> And run into mess. Can you tell me what is what without resorting to a
> binary editor in the following:
> 
> К, K, Κ, Қ

Same as 1 and l, O and 0, nothing new here.
BTW, I don't need a binary editor for distinguishing similar shapes.
An editor that informs about its characters is enough. (This character
thing on the screen should be an object, anyway.)


>  How are you support identifiers
> like "man-eating," (not to be mixed with "man eating")?

Like before: identifiers of a formal language still permit adding
clarity. Man_Eating_Activity, or Man_Eater, plus comments,
etc. whatever fits best. 



> > Mathematicians use full words almost all the time when they
> > explain their reasoning to human readers. 
> > 
> > echo "Let I ⊂ N be a finite index set. For all k ∈ I, P(k)." | wc
> >       1      15      58
> 
> Huh, none of these words is an *identifier*! They just don't use
> descriptive identifiers, neither for free variables, nor for functions.

I was referring the the "uncompiled math source code" and its use
of full words in math declarations, definitions, proofs and so on.
Which also include "For all".
Doesn't
 "Let I ⊂ N be ..."
look quite similar to
 "declare subtype I is N ..."?

OTOH, there is one more argument in favor of π and other symbols:
mathematicians will feel at home.


> > These are not character set and casing issues, and you know it. :-)
> 
> But ss = ß wasn't either!

I think it has all to do with permitted character sets in Ada 2005
and the case insensitivity rules. 

> BTW, nobody answered if "іf" and "аccess" were legal Ada 2005 identifiers.
> Are they?

Randy pointed you to the answer in the manual I think; the AARM
specifically talks about these words. Or are you saying the RM doesn't
answer this question?

Re: Ada generics

[Dmitry A. Kazakov]

On Wed, 03 Jan 2007 15:55:54 +0100, Georg Bauhaus wrote:

> On Wed, 2007-01-03 at 11:10 +0100, Dmitry A. Kazakov wrote:
>> On Tue, 02 Jan 2007 15:45:27 +0100, Georg Bauhaus wrote:
>> 
>>> On Tue, 2007-01-02 at 14:51 +0100, Dmitry A. Kazakov wrote:
>>> 
>>>> I find "вода" far more descriptive! (:-))
>>> 
>>> I wouldn't hesitate to write "вода" in a Russian only program.
>> 
>> Ah, but then you are in a big trouble, because "вода", "воде", "водой",
>> "воды", "водами", "водах" would all be equivalent in terms of what they
>> describe, i.e. "water", "lack of content", "confusion making", "being
>> ignorant", "alcohol drink", "time passed", "equivalence", "being down"?
>> Should Ada compilers learn Russian inflection rules?
> 
> Declination etc. can be overcome by object oriented spelling.
> Always use the nominative, and have ":=" etc. indicate the other
> cases. :-)

Nope, inflections is true and only OO! (:-)) You have an Indo-European root
(=object) "вод" (or maybe "wodr"̥) and add a method using a suffix -а, -е
etc! Positional systems like in English are old fashioned functional! (:-))

>>>> Natural language words (even pictographs)
>>>> describe absolutely nothing but themselves. 
>>> 
>>> (How can you be certain of this? :-)
>> 
>> As a proof consider a human being who does not know written Russian.
> 
> So to a Russian, a Russian language word describes something. Right?

It does something to anybody. Maybe, you could train a cat to recognize
some of written words. That does not make them descriptive. 

>> And run into mess. Can you tell me what is what without resorting to a
>> binary editor in the following:
>> 
>> К, K, Κ, Қ
> 
> Same as 1 and l, O and 0, nothing new here.

No, it is not. There exist fonts where 1, l, I, | have recognizably
distinctive glyphs. Differently to this, Cyrillic and Latin *share* letters
and so glyphs of A, B, C, E, H, I, K, M, O, P, T, X. With this, ANY
reserved word of Ada could be spelt in a way that at least one letter would
be Cyrillic. That would make it a legal identifier, as Randy has confirmed.
I consider this as a disaster. Not because I enjoy reserved words (a half
of them are unnecessary anyway), but because it demolishes the foundations
of the language design.

> BTW, I don't need a binary editor for distinguishing similar shapes.
> An editor that informs about its characters is enough. (This character
> thing on the screen should be an object, anyway.)

But that is obviously wrong! According to the Ada standard, Latin C and
Cyrillic C are two different identifiers. Glyphs tell lies!

>> Huh, none of these words is an *identifier*! They just don't use
>> descriptive identifiers, neither for free variables, nor for functions.
> 
> I was referring the the "uncompiled math source code" and its use
> of full words in math declarations, definitions, proofs and so on.

Such issues are to be covered by comments. In a comment you are free to
place any stuff, except for playing with format effectors.

-- 
Regards,
Dmitry A. Kazakov
http://www.dmitry-kazakov.de

Re: Ada generics

[Alexander E. Kopilovich]

Dmitry A. Kazakov wrote:

>Others in other natural languages might come (and did) to even more crazy
>ideas like "don't" = "do not".

It might seem crazy only if you forget that the primary purpose of written
form of natural language is to provide an adequate storage and long-distance
communication tool for a speech.

The form "don't" for "do not" did not emerge as a variation of written English
- it just reflects some actual spoken form.

> Why should that bother us?

Well, obviously it may sometimes bother us in literals. In identifiers we can,
as a rule, restrict ourselves to "canonical forms" without any loss of power
of expression. The problem, though, is that only a fraction of programmers
are able to resist the temptation of adding a touch of a literal to identifier.

>The idea that programs should look like COBOL is just wrong.

The idea is the programs should be readable. But readability is a complex
issue, it heavily depends on the psychological features of particular reader,
on particular purpose of reading and on circumstances (time available etc.).
Sometimes COBOL is the best, sometimes an opposite extremity - APL - is the
best.

And if the programs should be readable not only by professional programmers,
but also by those problem domain experts who aren't programmers themselves
then the customs of particular problem domain also influence readability.

>>> Mathematicians use much less descriptive identifies being absolutely free
>>> to use Latin, Greek and Hebrew alphabets. Yet nobody even tried to use full
>>> words. Why?
>> 
>> Mathematicians use full words almost all the time when they
>> explain their reasoning to human readers. 
>> 
>> echo "Let I ? N be a finite index set. For all k ? I, P(k)." | wc
>>       1      15      58
>
>Huh, none of these words is an *identifier*! They just don't use
>descriptive identifiers, neither for free variables, nor for functions.

Well, mathematicians generally do not use multi-letter words for identifiers
for variables in formulas - just for readability of the latter.

As for functions - well, as a rule, identifier for a function is also a single
letter, although all (or almost all) standard functions have multi-letter
identifiers - Sin, Cos, etc.

Many operators and functionals have multi-letter identifiers. For example,
differential operators div, rot, grad and functional for matrices Tr (aka Sp).

Long words are regularly used as identifiers for classes (vs. objects) and
functors (Hom, Tor, etc.) .

And finally, even identifiers for variables in formulas quite often actually
consist of 2, 3 or even more tokens: subscripts (not related to arrays) and
superscripts, asterisks, tildas, etc. are frequent components of identifiers
for variables.

Re: Ada generics

[Dmitry A. Kazakov]

On Wed,  3 Jan 2007 22:33:54 +0300 (MSK), Alexander E. Kopilovich wrote:

> Dmitry A. Kazakov wrote:
> 
>>Others in other natural languages might come (and did) to even more crazy
>>ideas like "don't" = "do not".
> 
> It might seem crazy only if you forget that the primary purpose of written
> form of natural language is to provide an adequate storage and long-distance
> communication tool for a speech.
> 
> The form "don't" for "do not" did not emerge as a variation of written English
> - it just reflects some actual spoken form.

Phonetic writing systems are in a clear contradiction with the objectives
of "an adequate storage and long-distance communication." Can you read
medieval Russian texts?

> And if the programs should be readable not only by professional programmers,
> but also by those problem domain experts who aren't programmers themselves
> then the customs of particular problem domain also influence readability.

No. Programs aren't literature, you know. That is why programming languages
aren't natural ones.

-- 
Regards,
Dmitry A. Kazakov
http://www.dmitry-kazakov.de

Re: Ada generics

[Alexander E. Kopilovich]

Dmitry A. Kazakov wrote:

>> the primary purpose of written
>> form of natural language is to provide an adequate storage and long-distance
>> communication tool for a speech.
>> 
>> The form "don't" for "do not" did not emerge as a variation of written English
>> - it just reflects some actual spoken form.
>
>Phonetic writing systems are in a clear contradiction with the objectives
>of "an adequate storage and long-distance communication."

Well, so how about sound recorder systems (from Edison's phonograph to CD)
and about phones (from analog to IP) ? Are all those systems in a clear
contradiction with the objectives of their primary purpose?

> Can you read medieval Russian texts?

Well, I didn't try really - just because I did not meet medieval Russian texts
of any interest for me (I'm not a historian). But I had quite a few occasions
to read excerps from medieval English texts (14-16 centures), and although it
was an unplesant experience (especially annoying was the exchange of meaning
between "u" and "v" in 14th century), it was not really hard work. And given
the distance in time of more than 5 rather dynamic centures, the notation
proved itself good enough, I think.

>> And if the programs should be readable not only by professional programmers,
>> but also by those problem domain experts who aren't programmers themselves
>> then the customs of particular problem domain also influence readability.
>
>No. Programs aren't literature, you know.

Well, it is true that professional application programs aren't a reading for
a layman. But problem domain experts aren't lay people within their problem
domain. They are necessary participants in the developments of serious
applications. They certainly need not to read the application sources in their
entirety (for example, the GUI stuff), but if they are too deprived of reading
essential functional parts of the sources then there either will be a dangerous
gap or the middlemen of uncertain quality.

Re: Ada generics

[Dmitry A. Kazakov]

[Sorry for this off-topic]

On Thu,  4 Jan 2007 18:00:42 +0300 (MSK), Alexander E. Kopilovich wrote:

> Dmitry A. Kazakov wrote:
> 
>>> the primary purpose of written
>>> form of natural language is to provide an adequate storage and long-distance
>>> communication tool for a speech.
>>> 
>>> The form "don't" for "do not" did not emerge as a variation of written English
>>> - it just reflects some actual spoken form.
>>
>>Phonetic writing systems are in a clear contradiction with the objectives
>>of "an adequate storage and long-distance communication."
> 
> Well, so how about sound recorder systems (from Edison's phonograph to CD)

The purpose of a sound recording system is, as tells its name, recoding
sounds. Whether that can be used for storage and communication depends on
other factors. Speech is phonetic per definition of.

> and about phones (from analog to IP) ?

Quite poor storage and communication tools. But again, that does not
characterize properties phonetic writing systems. For what it is worth,
people prefer SMS. Also compare selling rates of PDAs vs. dictaphones. CDs
and DVDs volumes written with data vs. audio content, TV vs. radio quotes,
TV vs. videotext etc.

-- 
Regards,
Dmitry A. Kazakov
http://www.dmitry-kazakov.de

Re: Ada generics

[Randy Brukardt]

[-- Warning: decoded text below may be mangled, UTF-8 assumed --]
[-- Attachment #1: Type: text/plain, Size: 1711 bytes --]


On Thu, 28 Dec 2006 18:35:06 +0100, Georg Bauhaus wrote:

> GNAT already supports the detection of identifiers that were
 > spelled similarly. In case of errors, it lists their "relatives".
> Surely a helpful feature, and a proof that practical handling of
> natural language identifiers is possible.
> As an example, as you have been referring to German, consider that
> sharp s, '�', is usually written "SS" when capitalized.
> So "Stra�e" tends to become "STRASSE". Now if you have a composite
> word that has
> - a '�', and
> - an 's' right after it,
> such as "Ma�stab" (= scale, rule, yardstick), then from a simple
> minded formalist's perspective I could argue:
>
>   "Using Unicode is nonsense because there is no 1:1 mapping for the
>   German word 'Ma�stab' which will become 'MASSSTAB'. "SSS" is
>   ambiguous, it could be "s�" or it could be "�s". That's too big
>   a challenge for a compiler write. So leave me alone with your
>   Unicode and case insensitivity."
>
> Is that what computer science has to answer when asked about
> characters handling?

For what it's worth, Ada says that all three of these represent the same
identifier. That's not ideal, but it's the best that we can do without
dropping into the character handling mess ourselves.

This is even more interesting when you consider that there are alternative
spellings for reserved words. For instance "acce�" is identical to "access".
(See 2.3(5.c/2) in the AARM for more examples). We wrestled with that quite
a while before deciding that such identifiers had to be illegal
(2.3(5.3/2)); we didn't want them appearing in programs in place of reserved
words.

                                        Randy.

Re: Ada generics

[Dmitry A. Kazakov]

On Fri, 29 Dec 2006 20:25:28 -0600, Randy Brukardt wrote:

> For what it's worth, Ada says that all three of these represent the same
> identifier. That's not ideal, but it's the best that we can do without
> dropping into the character handling mess ourselves.
> 
> This is even more interesting when you consider that there are alternative
> spellings for reserved words. For instance "acceß" is identical to "access".
> (See 2.3(5.c/2) in the AARM for more examples). We wrestled with that quite
> a while before deciding that such identifiers had to be illegal
> (2.3(5.3/2)); we didn't want them appearing in programs in place of reserved
> words.

Yuck. Would "acceβ" with Greek beta (β) and "if" with Cyrillic і in it be
valid identifiers?

-- 
Regards,
Dmitry A. Kazakov
http://www.dmitry-kazakov.de

Re: Ada generics

[Randy Brukardt]

[-- Warning: decoded text below may be mangled, UTF-8 assumed --]
[-- Attachment #1: Type: text/plain, Size: 2108 bytes --]

"Dmitry A. Kazakov" <mailbox@dmitry-kazakov.de> wrote in message
news:1a9k0vk46bqrq.1cx6cdld0wd9f$.dlg@40tude.net...
> On Fri, 29 Dec 2006 20:25:28 -0600, Randy Brukardt wrote:
>
> > For what it's worth, Ada says that all three of these represent the same
> > identifier. That's not ideal, but it's the best that we can do without
> > dropping into the character handling mess ourselves.
> >
> > This is even more interesting when you consider that there are
alternative
> > spellings for reserved words. For instance "acce�" is identical to
"access".
> > (See 2.3(5.c/2) in the AARM for more examples). We wrestled with that
quite
> > a while before deciding that such identifiers had to be illegal
> > (2.3(5.3/2)); we didn't want them appearing in programs in place of
reserved
> > words.
>
> Yuck. Would "acce?" with Greek beta (?) and "if" with Cyrillic ? in it be
> valid identifiers?

Sure, the upper case of a Greek beta is still a Greek beta, it's not "SS"
(and doesn't look anything like "ss", either). I don't know much about
Cyrillic, so I don't know the answer to that (but I suspect you do).

I would guess that you'll want some external style rules to prevent bogus
mixing of letters from different character sets. That's not any worse that
the style rules for capitalization and indentation that Gnat can enforce.

I've always limited myself to using the characters commonly available on
Windows systems (roughly 680 glyphs), and there needs to be something that
checks for use of letters that won't necessarily display well. But all of
that is outside of the language.

It should be pointed out that one of the reasons for Ada's support of
Unicode is that we had a long discussion of how to support Latin-9 (which
contains the euro symbol). Eventually, we decided that that way lies
madness - at least by using Unicode, there is only one definition to worry
about, rather than a set of them. My only regret is that we didn't find a
way to include real runtime UTF-8 support in the language: it's wasteful to
store everything as 32-bit characters.

                            Randy.

Re: Ada generics

[Dmitry A. Kazakov]

On Wed, 3 Jan 2007 19:09:17 -0600, Randy Brukardt wrote:

> "Dmitry A. Kazakov" <mailbox@dmitry-kazakov.de> wrote in message
> news:1a9k0vk46bqrq.1cx6cdld0wd9f$.dlg@40tude.net...

>> Yuck. Would "acce?" with Greek beta (?) and "if" with Cyrillic ? in it be
>> valid identifiers?
> 
> Sure, the upper case of a Greek beta is still a Greek beta, it's not "SS"
> (and doesn't look anything like "ss", either). I don't know much about
> Cyrillic, so I don't know the answer to that (but I suspect you do).

My God. A good third of the Latin and Cyrillic glyphs are same. Practically
all vowels are. That means that *any* reserved word of Ada can be spelt as
a proper identifier!

(and of course, there is no any chance to reverse this nightmare...)

> It should be pointed out that one of the reasons for Ada's support of
> Unicode is that we had a long discussion of how to support Latin-9 (which
> contains the euro symbol). Eventually, we decided that that way lies
> madness - at least by using Unicode, there is only one definition to worry
> about, rather than a set of them. My only regret is that we didn't find a
> way to include real runtime UTF-8 support in the language: it's wasteful to
> store everything as 32-bit characters.

Ah, that's because we still don't have proper subtypes in the language. If
all strings were derived from the same root with no requirement to share
the representation, we could add UTF-8 and 125xWide strings without any
trouble.

-- 
Regards,
Dmitry A. Kazakov
http://www.dmitry-kazakov.de

Re: Ada generics

[Randy Brukardt]

"Dmitry A. Kazakov" <mailbox@dmitry-kazakov.de> wrote in message
news:p6pjtv7qcu1s.vpcba1tkhwba$.dlg@40tude.net...
> On Wed, 3 Jan 2007 19:09:17 -0600, Randy Brukardt wrote:
>
> > "Dmitry A. Kazakov" <mailbox@dmitry-kazakov.de> wrote in message
> > news:1a9k0vk46bqrq.1cx6cdld0wd9f$.dlg@40tude.net...
>
> >> Yuck. Would "acce?" with Greek beta (?) and "if" with Cyrillic ? in it
be
> >> valid identifiers?
> >
> > Sure, the upper case of a Greek beta is still a Greek beta, it's not
"SS"
> > (and doesn't look anything like "ss", either). I don't know much about
> > Cyrillic, so I don't know the answer to that (but I suspect you do).
>
> My God. A good third of the Latin and Cyrillic glyphs are same.
Practically
> all vowels are. That means that *any* reserved word of Ada can be spelt as
> a proper identifier!

Yes, and so what? There would be little ambiguity introduced by using (say)
"overriding" as an identifier, so the meaning would be obvious to the
reader, and it won't confuse the compiler (usually it's more confusing to
the writer who didn't remember that some word is reserved). There are some
of them that should be avoided, of course, but there aren't many of those.

However, you alluded to a real concern in another message. That is, it's
possible to write two different identifiers that look the same. That would
be confusing and possibly cause problems. But that's already possible
(depending on the font), so it just is a slight expansion of a problem that
already exists. And it certainly can be handled with style checkers
(identifiers containing mixes of Latin, Cyrillic, or Greek characters are
suspicious, as are identifiers differing only by the replacement of Latin
characters with Cyrillic equivalents).

If that is a real concern, just insist that all of your programs are edited
with a 1984-vintage MS-DOS editor (like I do ;-), and you won't possibly be
able to have a problem. Indeed, I expect most programmers will continue to
do this (use tools that don't support Unicode), so any new problems will be
limited.

> (and of course, there is no any chance to reverse this nightmare...)

I don't see a nightmare, but I do see a need to have decent style rules
around the writing of identifiers. That's necessary even in Ada 83, they're
just more complex now.

                                Randy.

Re: Ada generics

[Randy Brukardt]

I wrote:

...
> I don't see a nightmare, but I do see a need to have decent style rules
> around the writing of identifiers. That's necessary even in Ada 83,
they're
> just more complex now.

And automated checking of those rules, like the warning Gnat gives for
capitalization problems. Hopefully Adacore is listening...

                    Randy.

Re: Ada generics

[Jean-Pierre Rosen]

Randy Brukardt a �crit :
> However, you alluded to a real concern in another message. That is, it's
> possible to write two different identifiers that look the same. That would
> be confusing and possibly cause problems. But that's already possible
> (depending on the font), so it just is a slight expansion of a problem that
> already exists. And it certainly can be handled with style checkers
> (identifiers containing mixes of Latin, Cyrillic, or Greek characters are
> suspicious, as are identifiers differing only by the replacement of Latin
> characters with Cyrillic equivalents).
> 
:-) This check is already implemented in the wavefront version of 
AdaControl (not yet in the public version).

-- 
---------------------------------------------------------
            J-P. Rosen (rosen@adalog.fr)
Visit Adalog's web site at http://www.adalog.fr

Re: Ada generics

[Georg Bauhaus]

On Thu, 2007-01-04 at 19:32 -0600, Randy Brukardt wrote:

> If that is a real concern, just insist that all of your programs are edited
> with a 1984-vintage MS-DOS editor (like I do ;-), and you won't possibly be
> able to have a problem. Indeed, I expect most programmers will continue to
> do this (use tools that don't support Unicode), so any new problems will be
> limited.

Maybe there is a chance that UTF-8 will show its advantages in
a trouble free transition from Latin-1 to UTF-8 where possible
(string literals made for 8bit character set displays might need
attention, I guess).
First, many tools can use UTF-8 files: Anything based on Eclipse works
well with UTF-8, GPS does, and VS.NET uses UTF-8 in all sorts of places.
VIM works just fine with UTF-8 files, and Emacs, having started
from the more general MULE character system supports Unicode, too,
in recent editions.

Second, recoding files from Latin-1 to UTF-8 should be no more than
a small shell script invoking the iconv tool, and then looking
at string literals in files that need to be ISO-8859-X encoded.
FWIW, 

#! /bin/sh
# Functions to help with the creation of UTF-8 Ada files from Latin-1
# Ada files
# Needs: grep, mawk (AWK that supports \ooo notation for characters)

ada_pat='\.\(ads\|adb\|ada\|spc\|bdy\)'
   # regular expression describing file name extensions of Ada files

repl_in_dir()
{
   # Copy Ada files from $1 to $2, replacing ISO-8859-1 characters with
   # corresponding UTF-8 characters. Call with two full paths.

   source=$1
   target=$2
   here=$(pwd)  # save current directory
   cd $source
   ls | grep "${ada_pat}$" | while read file
   do
      cat $file | iconv -f ISO_8859-1  -t UTF-8 > $target/$file
   done
   cd $here
}


check_strings()
{
   # List string literals X that have Character'pos(X(k)) > 8#177#
   # Run this in a directory of Ada files. Output is prefixed with
   # file name and line number.

   ls | grep "${ada_pat}$" | while read file
   do
      cat $file | { env FILENAME=$file mawk '
                      BEGIN  { OFS=":" }
                      /"[\000-\177]*[^\000-\177]/ {
                            print ENVIRON["FILENAME"],NR, $0
                      }'
                  }
   done
}

Re: Ada generics

[Randy Brukardt]

"Georg Bauhaus" <bauhaus@arcor.de> wrote in message
news:1168028046.28234.27.camel@localhost...
> On Thu, 2007-01-04 at 19:32 -0600, Randy Brukardt wrote:
>
> > If that is a real concern, just insist that all of your programs are
edited
> > with a 1984-vintage MS-DOS editor (like I do ;-), and you won't possibly
be
> > able to have a problem. Indeed, I expect most programmers will continue
to
> > do this (use tools that don't support Unicode), so any new problems will
be
> > limited.
>
> Maybe there is a chance that UTF-8 will show its advantages in
> a trouble free transition from Latin-1 to UTF-8 where possible
> (string literals made for 8bit character set displays might need
> attention, I guess).

You missed the point, I think. I was responding to Dmitry's concern about
distinct identifiers that look alike. One way to avoid this is to use tools
that *only* support Latin-1. Then it's pretty hard to have that problem,
especially if you use a decent font.

There's nothing wrong with UTF-8, and that's certainly the preferred way to
get Unicode characters. But if you use UTF-8, then you have to face the
potential problem of confusing identifiers. As Dmitry says, the glyphs of
many distinct characters can be the same and usually are (for example,
between Latin and Cyrillic). Checking for that can only be done with tools
outside of the language (although they could be built into the compiler, as
Gnat does for some style checks). If you're not willing or able to use such
tools, then stick with Latin-1 only programs.

Recoding to UTF-8 actually introduces a potential problem where none existed
before. So it's not something that should be done unless you really need
Unicode characters...

                                Randy.

Re: Ada generics

[Randy Brukardt]

[-- Warning: decoded text below may be mangled, UTF-8 assumed --]
[-- Attachment #1: Type: text/plain, Size: 2537 bytes --]

"Dmitry A. Kazakov" <mailbox@dmitry-kazakov.de> wrote in message
news:15jxp8z1iu5fk.1oeihvavjghgg$.dlg@40tude.net...
> On 27 Dec 2006 11:06:36 -0800, Hyman Rosen wrote:
>
> > Dmitry A. Kazakov wrote:
> >> The "encoding language" is outside the programming language,
> >> so it is not the language problem
> >
> > Remember that Ada wishes to be case-insensitive,
>
> That's no problem in a closed alphabet, like English/Latin.
>
> > so it cannot ignore
> > Unicode issues if it wishes to allow Unicode characters in identifiers.
>
> Which is a BAD idea, IMO.
>
> We cannot know anything about properties of letters in Klingon. As a
> practical example consider Russian where e can be used (and is) in place
of
> ? see (http://en.wikipedia.org/wiki/%D0%81), but not reverse. Or, maybe we
> should make Ada compilers capable to detect program written by Germans to
> consider � and ue same? Should we handle diacritical vowel points of
Hebrew
> as well? What about parsing the source right to left, or top to bottom?

The Unicode standard has grappled with these issues and produced results
which are useful for the vast majority of languages. Surely Ada is not going
to repeat that work (and arguments). And Ada is not going to drop case
insensitivity and start claiming that "this" and "This" are somehow
different.

> > Not to mention "normalization form KC".
>
> They reap what they sowed. Should Ada or C++ go into that mess?

Well, that's irrelevant because they have. Ada 2005 says that the semantics
of a program not in Normalization form KC are implementation-defined.
(2.1(4.1/2)). That was done because there was concern about programs that
are represented differently being treated the same (we originally considered
requiring converting into that form).

Similarly, upper case conversion is defined by various Unicode properties
(such as Upper Case Mapping) (2.1(5/2)). It should be noted that such
conversions aren't necessarily reversible, but that's irrelevant to
identifier equivalence. Identifier equivalence is defined in 2.3(5-5.3/2).

This is more complicated than the English-only definition, but it was
thought to be mandatory to get approval of a new standard. (This sort of
internationalization is being required of all languages: C++ has a number of
proposals on the table for handling this as well.) It's also a ramification
of case insensitivity - the only alternative would be to completely abandon
it, and that would be very bad for compatibility with Ada 95.

                                    Randy.

Re: Ada generics

[Dmitry A. Kazakov]

On Thu, 28 Dec 2006 18:09:20 -0600, Randy Brukardt wrote:

>> They reap what they sowed. Should Ada or C++ go into that mess?
> 
> Well, that's irrelevant because they have. Ada 2005 says that the semantics
> of a program not in Normalization form KC are implementation-defined.
> (2.1(4.1/2)). That was done because there was concern about programs that
> are represented differently being treated the same (we originally considered
> requiring converting into that form).
> 
> Similarly, upper case conversion is defined by various Unicode properties
> (such as Upper Case Mapping) (2.1(5/2)). It should be noted that such
> conversions aren't necessarily reversible, but that's irrelevant to
> identifier equivalence. Identifier equivalence is defined in 2.3(5-5.3/2).
> 
> This is more complicated than the English-only definition, but it was
> thought to be mandatory to get approval of a new standard. (This sort of
> internationalization is being required of all languages: C++ has a number of
> proposals on the table for handling this as well.) It's also a ramification
> of case insensitivity - the only alternative would be to completely abandon
> it, and that would be very bad for compatibility with Ada 95.

I don't see why letters of identifiers must be all Unicode letters. I
wouldn't allow anything but Latin. In any case it just cannot be
open-ended.

-- 
Regards,
Dmitry A. Kazakov
http://www.dmitry-kazakov.de

Re: Ada generics

[Randy Brukardt]

"Dmitry A. Kazakov" <mailbox@dmitry-kazakov.de> wrote in message
news:136rh3gzy2wpd.agw4naavc1ge$.dlg@40tude.net...
...
> > This is more complicated than the English-only definition, but it was
> > thought to be mandatory to get approval of a new standard. (This sort of
> > internationalization is being required of all languages: C++ has a
number of
> > proposals on the table for handling this as well.) It's also a
ramification
> > of case insensitivity - the only alternative would be to completely
abandon
> > it, and that would be very bad for compatibility with Ada 95.
>
> I don't see why letters of identifiers must be all Unicode letters. I
> wouldn't allow anything but Latin. In any case it just cannot be
> open-ended.

Because higher ups at ISO/IEC has said that such things need to be allowed.
If you want an ISO/IEC standard, you have to be responsive to their wishes.
Personally, I think anything beyond 8-bit characters is going too far (even
for strings): if it's not worth doing in English, its not worth doing! [For
me, the universe revolves around Madison, WI and everyone should speak
(American) English (dropping all of those other archaic languages) so that
everyone can communicate without unnecessary barriers. This is very similar
to my stand on Ada vs. other programming languages. But I'm not particularly
surprised when someone disagrees with any of those positions... ;-)]

And it's not "open-ended". It follows a published standard (Unicode), just
like the earlier versions of Ada followed other published standards (ISO/IEC
10646 in the case of Ada 95).

In any case, Unicode identifiers are part of the Ada Amendment. And I would
be very surprised if we went backwards on that; such a change would be very
incompatible. (I personally don't believe that many programs will use
Unicode identifiers, but it's likely to be non-zero, maybe 5%.)

                                          Randy.

Re: Ada generics

[Hyman Rosen]

markww wrote:
> I'm trying to compare generics in Ada vs C++ templates

There are fundamental differences between the two languages in how
generics work that relate back to how types themselves work.

In C++, a type is a completely static thing. You can read a type
declaration in the code and know everything there is to know about it.
In Ada, types are much more dynamic - they can include information
known only at run type, such as array sizes and discriminant values. (I
don't know Ada, so pardon me if I'm wrong in the Ada details.)
Accordingly, C++ types don't have a lifetime as such, existing for the
life of the program, but Ada types have the same lifetime as other
objects in the scope in which they are declared. Among other things,
this means that C++ types can be assigned unique names at compile time
while Ada types cannot.

Now, imagine you have a generic which wants to take a type parameter.

In C++, because types are fixed and uniquely named, the generic itself
can be instantiated at compile time. The compiler has all the
information it needs. Furthermore, the instantiated generic can also be
uniquely named. This becomes the paradigm of generic instantiation in
C++ - to do it all in the compiler. Thus, generics may take non-type
parameters as well, but they must all be constant (or refer to the
address of a static object). As an additional consequence, C++ is able
to identify instantiations with each other based on identity of the
template parameters so that, for example, the type std::vector<int> in
one file is exactly the same type as std::vector<int> in a second file.
It also makes automatic instantiation of function templates easier,
since again the full set of needed instantiations is known at compile
time, and instantiations with the same set of parameters are identified
with each other. For example, in a function template containing a
static variable, there is one such variable generated for each
different set of instantiation parameters.

In Ada things are different. Because types have lifetimes and contain
runtime information, generic instantiations must also. Furthermore, in
Ada even functions and procedures have lifetimes, because they nest and
have access to outer variables. Now it is not possible to know at
compile time how many generics need to be instantiated, and you cannot
identify a generic instantiation simply by looking at the generic and
its parameters. Each instantiation is separate, and that makes
automatic instantiation of generic functions problematic, because it
may be difficult to know when to do a new instantiation and when to
reuse an existing one. On the other hand, since you are already so
dynamic, there doesn't need to be any restriction on non-type
parameters, and so in Ada you can instantiate generics on
locally-scoped functions and objects.

Because(?) Ada requires explicit instantiations, it has no notion of
generic specializations. This means that in Ada you cannot do
metaprogramming the way you can in C++. In Ada a generic has one and
only one implementation, whereas in C++ a template can be specialized
for different sets of template parameters. On the other hand, Ada is
much more friendly to generic sharing, that is, having a single or a
few compiled functions that can act at runtime as particular
instantiated functions.

Re: Ada generics

[markww]

Hyman Rosen wrote:
> markww wrote:
> > I'm trying to compare generics in Ada vs C++ templates
>
> There are fundamental differences between the two languages in how
> generics work that relate back to how types themselves work.
>
> In C++, a type is a completely static thing. You can read a type
> declaration in the code and know everything there is to know about it.
> In Ada, types are much more dynamic - they can include information
> known only at run type, such as array sizes and discriminant values. (I
> don't know Ada, so pardon me if I'm wrong in the Ada details.)
> Accordingly, C++ types don't have a lifetime as such, existing for the
> life of the program, but Ada types have the same lifetime as other
> objects in the scope in which they are declared. Among other things,
> this means that C++ types can be assigned unique names at compile time
> while Ada types cannot.
>
> Now, imagine you have a generic which wants to take a type parameter.
>
> In C++, because types are fixed and uniquely named, the generic itself
> can be instantiated at compile time. The compiler has all the
> information it needs. Furthermore, the instantiated generic can also be
> uniquely named. This becomes the paradigm of generic instantiation in
> C++ - to do it all in the compiler. Thus, generics may take non-type
> parameters as well, but they must all be constant (or refer to the
> address of a static object). As an additional consequence, C++ is able
> to identify instantiations with each other based on identity of the
> template parameters so that, for example, the type std::vector<int> in
> one file is exactly the same type as std::vector<int> in a second file.
> It also makes automatic instantiation of function templates easier,
> since again the full set of needed instantiations is known at compile
> time, and instantiations with the same set of parameters are identified
> with each other. For example, in a function template containing a
> static variable, there is one such variable generated for each
> different set of instantiation parameters.
>
> In Ada things are different. Because types have lifetimes and contain
> runtime information, generic instantiations must also. Furthermore, in
> Ada even functions and procedures have lifetimes, because they nest and
> have access to outer variables. Now it is not possible to know at
> compile time how many generics need to be instantiated, and you cannot
> identify a generic instantiation simply by looking at the generic and
> its parameters. Each instantiation is separate, and that makes
> automatic instantiation of generic functions problematic, because it
> may be difficult to know when to do a new instantiation and when to
> reuse an existing one. On the other hand, since you are already so
> dynamic, there doesn't need to be any restriction on non-type
> parameters, and so in Ada you can instantiate generics on
> locally-scoped functions and objects.
>
> Because(?) Ada requires explicit instantiations, it has no notion of
> generic specializations. This means that in Ada you cannot do
> metaprogramming the way you can in C++. In Ada a generic has one and
> only one implementation, whereas in C++ a template can be specialized
> for different sets of template parameters. On the other hand, Ada is
> much more friendly to generic sharing, that is, having a single or a
> few compiled functions that can act at runtime as particular
> instantiated functions.

Thanks for your detailed responses, I appreciate it,

Mark

Re: Ada generics

[Steve]

"markww" <markww@gmail.com> wrote in message 
news:1166710494.869393.108730@a3g2000cwd.googlegroups.com...
> Hi,
>
> I'm trying to compare generics in Ada vs C++ templates and Java
> generics. Is there anything Ada generics can do that C++ or Java
> cannot? I read that the Ada system was safer than C++ templates. I'm
> just looking for some distinctive features.
>
> Thanks
>

The most distinct feature in my view is that if the code for the generic 
compiles then an instantiation of the generic will also compile.

I have in the past tried to instantiate a C++ template and received a 
compile time error deeply nested in the template source code, due to some 
specific requirement that was not met instantiating the template.  For 
instance the template may require that some specific method be implemented 
by a type used to instantiate the template.

Steve
(The Duck)