* Ada generics @ 2006-12-21 14:14 markww 2006-12-21 15:42 ` Dmitry A. Kazakov ` (2 more replies) 0 siblings, 3 replies; 62+ messages in thread From: markww @ 2006-12-21 14:14 UTC (permalink / raw) 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 ^ permalink raw reply [flat|nested] 62+ messages in thread
* Re: Ada generics 2006-12-21 14:14 Ada generics markww @ 2006-12-21 15:42 ` Dmitry A. Kazakov 2006-12-22 7:59 ` Martin Krischik ` (2 more replies) 2006-12-21 16:55 ` Hyman Rosen 2006-12-22 3:01 ` Steve 2 siblings, 3 replies; 62+ messages in thread From: Dmitry A. Kazakov @ 2006-12-21 15:42 UTC (permalink / raw) 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 ^ permalink raw reply [flat|nested] 62+ messages in thread
* Re: Ada generics 2006-12-21 15:42 ` Dmitry A. Kazakov @ 2006-12-22 7:59 ` Martin Krischik 2006-12-22 16:14 ` Hyman Rosen 2006-12-22 7:59 ` Martin Krischik 2006-12-22 16:41 ` Hyman Rosen 2 siblings, 1 reply; 62+ messages in thread From: Martin Krischik @ 2006-12-22 7:59 UTC (permalink / raw) To: mailbox 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/ ^ permalink raw reply [flat|nested] 62+ messages in thread
* Re: Ada generics 2006-12-22 7:59 ` Martin Krischik @ 2006-12-22 16:14 ` Hyman Rosen 0 siblings, 0 replies; 62+ messages in thread From: Hyman Rosen @ 2006-12-22 16:14 UTC (permalink / raw) 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. ^ permalink raw reply [flat|nested] 62+ messages in thread
* Re: Ada generics 2006-12-21 15:42 ` Dmitry A. Kazakov 2006-12-22 7:59 ` Martin Krischik @ 2006-12-22 7:59 ` Martin Krischik 2006-12-22 16:41 ` Hyman Rosen 2 siblings, 0 replies; 62+ messages in thread From: Martin Krischik @ 2006-12-22 7:59 UTC (permalink / raw) 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/ ^ permalink raw reply [flat|nested] 62+ messages in thread
* Re: Ada generics 2006-12-21 15:42 ` Dmitry A. Kazakov 2006-12-22 7:59 ` Martin Krischik 2006-12-22 7:59 ` Martin Krischik @ 2006-12-22 16:41 ` Hyman Rosen 2006-12-22 17:33 ` Markus E Leypold 2006-12-23 11:43 ` Dmitry A. Kazakov 2 siblings, 2 replies; 62+ messages in thread From: Hyman Rosen @ 2006-12-22 16:41 UTC (permalink / raw) 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. ^ permalink raw reply [flat|nested] 62+ messages in thread
* Re: Ada generics 2006-12-22 16:41 ` Hyman Rosen @ 2006-12-22 17:33 ` Markus E Leypold 2006-12-22 18:26 ` Hyman Rosen 2006-12-23 11:43 ` Dmitry A. Kazakov 1 sibling, 1 reply; 62+ messages in thread From: Markus E Leypold @ 2006-12-22 17:33 UTC (permalink / raw) "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 ^ permalink raw reply [flat|nested] 62+ messages in thread
* Re: Ada generics 2006-12-22 17:33 ` Markus E Leypold @ 2006-12-22 18:26 ` Hyman Rosen 2006-12-22 20:59 ` Markus E Leypold 0 siblings, 1 reply; 62+ messages in thread From: Hyman Rosen @ 2006-12-22 18:26 UTC (permalink / raw) 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); } ^ permalink raw reply [flat|nested] 62+ messages in thread
* Re: Ada generics 2006-12-22 18:26 ` Hyman Rosen @ 2006-12-22 20:59 ` Markus E Leypold 2006-12-22 21:01 ` Markus E Leypold ` (2 more replies) 0 siblings, 3 replies; 62+ messages in thread From: Markus E Leypold @ 2006-12-22 20:59 UTC (permalink / raw) "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 ^ permalink raw reply [flat|nested] 62+ messages in thread
* Re: Ada generics 2006-12-22 20:59 ` Markus E Leypold @ 2006-12-22 21:01 ` Markus E Leypold 2006-12-23 14:09 ` Marco 2006-12-25 14:20 ` Hyman Rosen 2 siblings, 0 replies; 62+ messages in thread From: Markus E Leypold @ 2006-12-22 21:01 UTC (permalink / raw) 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 ^ permalink raw reply [flat|nested] 62+ messages in thread
* Re: Ada generics 2006-12-22 20:59 ` Markus E Leypold 2006-12-22 21:01 ` Markus E Leypold @ 2006-12-23 14:09 ` Marco 2006-12-25 14:23 ` Hyman Rosen 2006-12-25 14:20 ` Hyman Rosen 2 siblings, 1 reply; 62+ messages in thread From: Marco @ 2006-12-23 14:09 UTC (permalink / raw) > 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. ^ permalink raw reply [flat|nested] 62+ messages in thread
* Re: Ada generics 2006-12-23 14:09 ` Marco @ 2006-12-25 14:23 ` Hyman Rosen 2006-12-29 14:13 ` Marco 0 siblings, 1 reply; 62+ messages in thread From: Hyman Rosen @ 2006-12-25 14:23 UTC (permalink / raw) 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/>. ^ permalink raw reply [flat|nested] 62+ messages in thread
* Re: Ada generics 2006-12-25 14:23 ` Hyman Rosen @ 2006-12-29 14:13 ` Marco 0 siblings, 0 replies; 62+ messages in thread From: Marco @ 2006-12-29 14:13 UTC (permalink / raw) 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. ^ permalink raw reply [flat|nested] 62+ messages in thread
* Re: Ada generics 2006-12-22 20:59 ` Markus E Leypold 2006-12-22 21:01 ` Markus E Leypold 2006-12-23 14:09 ` Marco @ 2006-12-25 14:20 ` Hyman Rosen 2 siblings, 0 replies; 62+ messages in thread From: Hyman Rosen @ 2006-12-25 14:20 UTC (permalink / raw) 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. ^ permalink raw reply [flat|nested] 62+ messages in thread
* Re: Ada generics 2006-12-22 16:41 ` Hyman Rosen 2006-12-22 17:33 ` Markus E Leypold @ 2006-12-23 11:43 ` Dmitry A. Kazakov 2006-12-25 13:49 ` Hyman Rosen 1 sibling, 1 reply; 62+ messages in thread From: Dmitry A. Kazakov @ 2006-12-23 11:43 UTC (permalink / raw) 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 ^ permalink raw reply [flat|nested] 62+ messages in thread
* Re: Ada generics 2006-12-23 11:43 ` Dmitry A. Kazakov @ 2006-12-25 13:49 ` Hyman Rosen 2006-12-25 14:39 ` Dmitry A. Kazakov 0 siblings, 1 reply; 62+ messages in thread From: Hyman Rosen @ 2006-12-25 13:49 UTC (permalink / raw) 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. ^ permalink raw reply [flat|nested] 62+ messages in thread
* Re: Ada generics 2006-12-25 13:49 ` Hyman Rosen @ 2006-12-25 14:39 ` Dmitry A. Kazakov 2006-12-26 1:34 ` Hyman Rosen 0 siblings, 1 reply; 62+ messages in thread From: Dmitry A. Kazakov @ 2006-12-25 14:39 UTC (permalink / raw) 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 ^ permalink raw reply [flat|nested] 62+ messages in thread
* Re: Ada generics 2006-12-25 14:39 ` Dmitry A. Kazakov @ 2006-12-26 1:34 ` Hyman Rosen 2006-12-26 9:11 ` Dmitry A. Kazakov 0 siblings, 1 reply; 62+ messages in thread From: Hyman Rosen @ 2006-12-26 1:34 UTC (permalink / raw) 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. ^ permalink raw reply [flat|nested] 62+ messages in thread
* Re: Ada generics 2006-12-26 1:34 ` Hyman Rosen @ 2006-12-26 9:11 ` Dmitry A. Kazakov 2006-12-26 16:23 ` Hyman Rosen 0 siblings, 1 reply; 62+ messages in thread From: Dmitry A. Kazakov @ 2006-12-26 9:11 UTC (permalink / raw) 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 ^ permalink raw reply [flat|nested] 62+ messages in thread
* Re: Ada generics 2006-12-26 9:11 ` Dmitry A. Kazakov @ 2006-12-26 16:23 ` Hyman Rosen 2006-12-26 19:28 ` Dmitry A. Kazakov 0 siblings, 1 reply; 62+ messages in thread From: Hyman Rosen @ 2006-12-26 16:23 UTC (permalink / raw) 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. ^ permalink raw reply [flat|nested] 62+ messages in thread
* Re: Ada generics 2006-12-26 16:23 ` Hyman Rosen @ 2006-12-26 19:28 ` Dmitry A. Kazakov 2006-12-27 1:44 ` Hyman Rosen 0 siblings, 1 reply; 62+ messages in thread From: Dmitry A. Kazakov @ 2006-12-26 19:28 UTC (permalink / raw) 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 ^ permalink raw reply [flat|nested] 62+ messages in thread
* Re: Ada generics 2006-12-26 19:28 ` Dmitry A. Kazakov @ 2006-12-27 1:44 ` Hyman Rosen 2006-12-27 9:21 ` Dmitry A. Kazakov 0 siblings, 1 reply; 62+ messages in thread From: Hyman Rosen @ 2006-12-27 1:44 UTC (permalink / raw) 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. ^ permalink raw reply [flat|nested] 62+ messages in thread
* Re: Ada generics 2006-12-27 1:44 ` Hyman Rosen @ 2006-12-27 9:21 ` Dmitry A. Kazakov 2006-12-27 19:06 ` Hyman Rosen 0 siblings, 1 reply; 62+ messages in thread From: Dmitry A. Kazakov @ 2006-12-27 9:21 UTC (permalink / raw) 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 ^ permalink raw reply [flat|nested] 62+ messages in thread
* Re: Ada generics 2006-12-27 9:21 ` Dmitry A. Kazakov @ 2006-12-27 19:06 ` Hyman Rosen 2006-12-28 10:59 ` Dmitry A. Kazakov 0 siblings, 1 reply; 62+ messages in thread From: Hyman Rosen @ 2006-12-27 19:06 UTC (permalink / raw) 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. ^ permalink raw reply [flat|nested] 62+ messages in thread
* Re: Ada generics 2006-12-27 19:06 ` Hyman Rosen @ 2006-12-28 10:59 ` Dmitry A. Kazakov 2006-12-28 16:29 ` Hyman Rosen ` (2 more replies) 0 siblings, 3 replies; 62+ messages in thread From: Dmitry A. Kazakov @ 2006-12-28 10:59 UTC (permalink / raw) 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 ^ permalink raw reply [flat|nested] 62+ messages in thread
* Re: Ada generics 2006-12-28 10:59 ` Dmitry A. Kazakov @ 2006-12-28 16:29 ` Hyman Rosen 2006-12-29 11:12 ` Dmitry A. Kazakov 2006-12-28 17:35 ` Georg Bauhaus 2006-12-29 0:09 ` Randy Brukardt 2 siblings, 1 reply; 62+ messages in thread From: Hyman Rosen @ 2006-12-28 16:29 UTC (permalink / raw) 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. ^ permalink raw reply [flat|nested] 62+ messages in thread
* Re: Ada generics 2006-12-28 16:29 ` Hyman Rosen @ 2006-12-29 11:12 ` Dmitry A. Kazakov 2006-12-29 14:56 ` Hyman Rosen 0 siblings, 1 reply; 62+ messages in thread From: Dmitry A. Kazakov @ 2006-12-29 11:12 UTC (permalink / raw) 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 ^ permalink raw reply [flat|nested] 62+ messages in thread
* Re: Ada generics 2006-12-29 11:12 ` Dmitry A. Kazakov @ 2006-12-29 14:56 ` Hyman Rosen 0 siblings, 0 replies; 62+ messages in thread From: Hyman Rosen @ 2006-12-29 14:56 UTC (permalink / raw) 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. ^ permalink raw reply [flat|nested] 62+ messages in thread
* Re: Ada generics 2006-12-28 10:59 ` Dmitry A. Kazakov 2006-12-28 16:29 ` Hyman Rosen @ 2006-12-28 17:35 ` Georg Bauhaus 2006-12-29 14:48 ` Dmitry A. Kazakov 2006-12-29 0:09 ` Randy Brukardt 2 siblings, 1 reply; 62+ messages in thread From: Georg Bauhaus @ 2006-12-28 17:35 UTC (permalink / raw) 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. ^ permalink raw reply [flat|nested] 62+ messages in thread
* Re: Ada generics 2006-12-28 17:35 ` Georg Bauhaus @ 2006-12-29 14:48 ` Dmitry A. Kazakov 2006-12-29 19:39 ` Georg Bauhaus 2006-12-30 2:25 ` Randy Brukardt 0 siblings, 2 replies; 62+ messages in thread From: Dmitry A. Kazakov @ 2006-12-29 14:48 UTC (permalink / raw) 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 ^ permalink raw reply [flat|nested] 62+ messages in thread
* Re: Ada generics 2006-12-29 14:48 ` Dmitry A. Kazakov @ 2006-12-29 19:39 ` Georg Bauhaus 2006-12-30 9:58 ` Dmitry A. Kazakov 2006-12-30 2:25 ` Randy Brukardt 1 sibling, 1 reply; 62+ messages in thread From: Georg Bauhaus @ 2006-12-29 19:39 UTC (permalink / raw) 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. ^ permalink raw reply [flat|nested] 62+ messages in thread
* Re: Ada generics 2006-12-29 19:39 ` Georg Bauhaus @ 2006-12-30 9:58 ` Dmitry A. Kazakov 2006-12-30 14:53 ` Georg Bauhaus 0 siblings, 1 reply; 62+ messages in thread From: Dmitry A. Kazakov @ 2006-12-30 9:58 UTC (permalink / raw) 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 ^ permalink raw reply [flat|nested] 62+ messages in thread
* Re: Ada generics 2006-12-30 9:58 ` Dmitry A. Kazakov @ 2006-12-30 14:53 ` Georg Bauhaus 2007-01-01 13:00 ` Dmitry A. Kazakov 0 siblings, 1 reply; 62+ messages in thread From: Georg Bauhaus @ 2006-12-30 14:53 UTC (permalink / raw) 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 ^ permalink raw reply [flat|nested] 62+ messages in thread
* Re: Ada generics 2006-12-30 14:53 ` Georg Bauhaus @ 2007-01-01 13:00 ` Dmitry A. Kazakov 2007-01-02 10:04 ` Georg Bauhaus 0 siblings, 1 reply; 62+ messages in thread From: Dmitry A. Kazakov @ 2007-01-01 13:00 UTC (permalink / raw) 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 ^ permalink raw reply [flat|nested] 62+ messages in thread
* Re: Ada generics 2007-01-01 13:00 ` Dmitry A. Kazakov @ 2007-01-02 10:04 ` Georg Bauhaus 2007-01-02 11:11 ` Dmitry A. Kazakov 0 siblings, 1 reply; 62+ messages in thread From: Georg Bauhaus @ 2007-01-02 10:04 UTC (permalink / raw) 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. ^ permalink raw reply [flat|nested] 62+ messages in thread
* Re: Ada generics 2007-01-02 10:04 ` Georg Bauhaus @ 2007-01-02 11:11 ` Dmitry A. Kazakov 2007-01-02 12:33 ` Georg Bauhaus 2007-01-03 19:33 ` Alexander E. Kopilovich 0 siblings, 2 replies; 62+ messages in thread From: Dmitry A. Kazakov @ 2007-01-02 11:11 UTC (permalink / raw) 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 ^ permalink raw reply [flat|nested] 62+ messages in thread
* Re: Ada generics 2007-01-02 11:11 ` Dmitry A. Kazakov @ 2007-01-02 12:33 ` Georg Bauhaus 2007-01-02 13:51 ` Dmitry A. Kazakov 2007-01-03 19:33 ` Alexander E. Kopilovich 1 sibling, 1 reply; 62+ messages in thread From: Georg Bauhaus @ 2007-01-02 12:33 UTC (permalink / raw) 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. :-) ^ permalink raw reply [flat|nested] 62+ messages in thread
* Re: Ada generics 2007-01-02 12:33 ` Georg Bauhaus @ 2007-01-02 13:51 ` Dmitry A. Kazakov 2007-01-02 14:45 ` Georg Bauhaus 0 siblings, 1 reply; 62+ messages in thread From: Dmitry A. Kazakov @ 2007-01-02 13:51 UTC (permalink / raw) 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 ^ permalink raw reply [flat|nested] 62+ messages in thread
* Re: Ada generics 2007-01-02 13:51 ` Dmitry A. Kazakov @ 2007-01-02 14:45 ` Georg Bauhaus 2007-01-03 10:10 ` Dmitry A. Kazakov 0 siblings, 1 reply; 62+ messages in thread From: Georg Bauhaus @ 2007-01-02 14:45 UTC (permalink / raw) 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. :-) ^ permalink raw reply [flat|nested] 62+ messages in thread
* Re: Ada generics 2007-01-02 14:45 ` Georg Bauhaus @ 2007-01-03 10:10 ` Dmitry A. Kazakov 2007-01-03 14:20 ` Hyman Rosen 2007-01-03 14:55 ` Georg Bauhaus 0 siblings, 2 replies; 62+ messages in thread From: Dmitry A. Kazakov @ 2007-01-03 10:10 UTC (permalink / raw) 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 ^ permalink raw reply [flat|nested] 62+ messages in thread
* Re: Ada generics 2007-01-03 10:10 ` Dmitry A. Kazakov @ 2007-01-03 14:20 ` Hyman Rosen 2007-01-03 14:55 ` Georg Bauhaus 1 sibling, 0 replies; 62+ messages in thread From: Hyman Rosen @ 2007-01-03 14:20 UTC (permalink / raw) 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. ^ permalink raw reply [flat|nested] 62+ messages in thread
* Re: Ada generics 2007-01-03 10:10 ` Dmitry A. Kazakov 2007-01-03 14:20 ` Hyman Rosen @ 2007-01-03 14:55 ` Georg Bauhaus 2007-01-04 10:15 ` Dmitry A. Kazakov 1 sibling, 1 reply; 62+ messages in thread From: Georg Bauhaus @ 2007-01-03 14:55 UTC (permalink / raw) 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? ^ permalink raw reply [flat|nested] 62+ messages in thread
* Re: Ada generics 2007-01-03 14:55 ` Georg Bauhaus @ 2007-01-04 10:15 ` Dmitry A. Kazakov 0 siblings, 0 replies; 62+ messages in thread From: Dmitry A. Kazakov @ 2007-01-04 10:15 UTC (permalink / raw) 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 ^ permalink raw reply [flat|nested] 62+ messages in thread
* Re: Ada generics 2007-01-02 11:11 ` Dmitry A. Kazakov 2007-01-02 12:33 ` Georg Bauhaus @ 2007-01-03 19:33 ` Alexander E. Kopilovich 2007-01-04 10:27 ` Dmitry A. Kazakov 1 sibling, 1 reply; 62+ messages in thread From: Alexander E. Kopilovich @ 2007-01-03 19:33 UTC (permalink / raw) To: comp.lang.ada 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. ^ permalink raw reply [flat|nested] 62+ messages in thread
* Re: Ada generics 2007-01-03 19:33 ` Alexander E. Kopilovich @ 2007-01-04 10:27 ` Dmitry A. Kazakov 2007-01-04 15:00 ` Alexander E. Kopilovich 0 siblings, 1 reply; 62+ messages in thread From: Dmitry A. Kazakov @ 2007-01-04 10:27 UTC (permalink / raw) 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 ^ permalink raw reply [flat|nested] 62+ messages in thread
* Re: Ada generics 2007-01-04 10:27 ` Dmitry A. Kazakov @ 2007-01-04 15:00 ` Alexander E. Kopilovich 2007-01-05 10:32 ` Dmitry A. Kazakov 0 siblings, 1 reply; 62+ messages in thread From: Alexander E. Kopilovich @ 2007-01-04 15:00 UTC (permalink / raw) To: comp.lang.ada 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. ^ permalink raw reply [flat|nested] 62+ messages in thread
* Re: Ada generics 2007-01-04 15:00 ` Alexander E. Kopilovich @ 2007-01-05 10:32 ` Dmitry A. Kazakov 0 siblings, 0 replies; 62+ messages in thread From: Dmitry A. Kazakov @ 2007-01-05 10:32 UTC (permalink / raw) [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 ^ permalink raw reply [flat|nested] 62+ messages in thread
* Re: Ada generics 2006-12-29 14:48 ` Dmitry A. Kazakov 2006-12-29 19:39 ` Georg Bauhaus @ 2006-12-30 2:25 ` Randy Brukardt 2006-12-30 10:13 ` Dmitry A. Kazakov 1 sibling, 1 reply; 62+ messages in thread From: Randy Brukardt @ 2006-12-30 2:25 UTC (permalink / raw) [-- 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. ^ permalink raw reply [flat|nested] 62+ messages in thread
* Re: Ada generics 2006-12-30 2:25 ` Randy Brukardt @ 2006-12-30 10:13 ` Dmitry A. Kazakov 2007-01-04 1:09 ` Randy Brukardt 0 siblings, 1 reply; 62+ messages in thread From: Dmitry A. Kazakov @ 2006-12-30 10:13 UTC (permalink / raw) 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 ^ permalink raw reply [flat|nested] 62+ messages in thread
* Re: Ada generics 2006-12-30 10:13 ` Dmitry A. Kazakov @ 2007-01-04 1:09 ` Randy Brukardt 2007-01-04 10:07 ` Dmitry A. Kazakov 0 siblings, 1 reply; 62+ messages in thread From: Randy Brukardt @ 2007-01-04 1:09 UTC (permalink / raw) [-- 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. ^ permalink raw reply [flat|nested] 62+ messages in thread
* Re: Ada generics 2007-01-04 1:09 ` Randy Brukardt @ 2007-01-04 10:07 ` Dmitry A. Kazakov 2007-01-05 1:32 ` Randy Brukardt 0 siblings, 1 reply; 62+ messages in thread From: Dmitry A. Kazakov @ 2007-01-04 10:07 UTC (permalink / raw) 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 ^ permalink raw reply [flat|nested] 62+ messages in thread
* Re: Ada generics 2007-01-04 10:07 ` Dmitry A. Kazakov @ 2007-01-05 1:32 ` Randy Brukardt 2007-01-05 4:46 ` Randy Brukardt ` (2 more replies) 0 siblings, 3 replies; 62+ messages in thread From: Randy Brukardt @ 2007-01-05 1:32 UTC (permalink / raw) "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. ^ permalink raw reply [flat|nested] 62+ messages in thread
* Re: Ada generics 2007-01-05 1:32 ` Randy Brukardt @ 2007-01-05 4:46 ` Randy Brukardt 2007-01-05 9:08 ` Jean-Pierre Rosen 2007-01-05 20:14 ` Georg Bauhaus 2 siblings, 0 replies; 62+ messages in thread From: Randy Brukardt @ 2007-01-05 4:46 UTC (permalink / raw) 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. ^ permalink raw reply [flat|nested] 62+ messages in thread
* Re: Ada generics 2007-01-05 1:32 ` Randy Brukardt 2007-01-05 4:46 ` Randy Brukardt @ 2007-01-05 9:08 ` Jean-Pierre Rosen 2007-01-05 20:14 ` Georg Bauhaus 2 siblings, 0 replies; 62+ messages in thread From: Jean-Pierre Rosen @ 2007-01-05 9:08 UTC (permalink / raw) 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 ^ permalink raw reply [flat|nested] 62+ messages in thread
* Re: Ada generics 2007-01-05 1:32 ` Randy Brukardt 2007-01-05 4:46 ` Randy Brukardt 2007-01-05 9:08 ` Jean-Pierre Rosen @ 2007-01-05 20:14 ` Georg Bauhaus 2007-01-06 0:14 ` Randy Brukardt 2 siblings, 1 reply; 62+ messages in thread From: Georg Bauhaus @ 2007-01-05 20:14 UTC (permalink / raw) 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 } ^ permalink raw reply [flat|nested] 62+ messages in thread
* Re: Ada generics 2007-01-05 20:14 ` Georg Bauhaus @ 2007-01-06 0:14 ` Randy Brukardt 0 siblings, 0 replies; 62+ messages in thread From: Randy Brukardt @ 2007-01-06 0:14 UTC (permalink / raw) "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. ^ permalink raw reply [flat|nested] 62+ messages in thread
* Re: Ada generics 2006-12-28 10:59 ` Dmitry A. Kazakov 2006-12-28 16:29 ` Hyman Rosen 2006-12-28 17:35 ` Georg Bauhaus @ 2006-12-29 0:09 ` Randy Brukardt 2006-12-29 11:11 ` Dmitry A. Kazakov 2 siblings, 1 reply; 62+ messages in thread From: Randy Brukardt @ 2006-12-29 0:09 UTC (permalink / raw) [-- 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. ^ permalink raw reply [flat|nested] 62+ messages in thread
* Re: Ada generics 2006-12-29 0:09 ` Randy Brukardt @ 2006-12-29 11:11 ` Dmitry A. Kazakov 2006-12-30 2:40 ` Randy Brukardt 0 siblings, 1 reply; 62+ messages in thread From: Dmitry A. Kazakov @ 2006-12-29 11:11 UTC (permalink / raw) 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 ^ permalink raw reply [flat|nested] 62+ messages in thread
* Re: Ada generics 2006-12-29 11:11 ` Dmitry A. Kazakov @ 2006-12-30 2:40 ` Randy Brukardt 0 siblings, 0 replies; 62+ messages in thread From: Randy Brukardt @ 2006-12-30 2:40 UTC (permalink / raw) "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. ^ permalink raw reply [flat|nested] 62+ messages in thread
* Re: Ada generics 2006-12-21 14:14 Ada generics markww 2006-12-21 15:42 ` Dmitry A. Kazakov @ 2006-12-21 16:55 ` Hyman Rosen 2006-12-21 18:22 ` markww 2006-12-22 3:01 ` Steve 2 siblings, 1 reply; 62+ messages in thread From: Hyman Rosen @ 2006-12-21 16:55 UTC (permalink / raw) 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. ^ permalink raw reply [flat|nested] 62+ messages in thread
* Re: Ada generics 2006-12-21 16:55 ` Hyman Rosen @ 2006-12-21 18:22 ` markww 0 siblings, 0 replies; 62+ messages in thread From: markww @ 2006-12-21 18:22 UTC (permalink / raw) 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 ^ permalink raw reply [flat|nested] 62+ messages in thread
* Re: Ada generics 2006-12-21 14:14 Ada generics markww 2006-12-21 15:42 ` Dmitry A. Kazakov 2006-12-21 16:55 ` Hyman Rosen @ 2006-12-22 3:01 ` Steve 2 siblings, 0 replies; 62+ messages in thread From: Steve @ 2006-12-22 3:01 UTC (permalink / raw) "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) ^ permalink raw reply [flat|nested] 62+ messages in thread
end of thread, other threads:[~2007-01-06 0:14 UTC | newest] Thread overview: 62+ messages (download: mbox.gz / follow: Atom feed) -- links below jump to the message on this page -- 2006-12-21 14:14 Ada generics markww 2006-12-21 15:42 ` Dmitry A. Kazakov 2006-12-22 7:59 ` Martin Krischik 2006-12-22 16:14 ` Hyman Rosen 2006-12-22 7:59 ` Martin Krischik 2006-12-22 16:41 ` Hyman Rosen 2006-12-22 17:33 ` Markus E Leypold 2006-12-22 18:26 ` Hyman Rosen 2006-12-22 20:59 ` Markus E Leypold 2006-12-22 21:01 ` Markus E Leypold 2006-12-23 14:09 ` Marco 2006-12-25 14:23 ` Hyman Rosen 2006-12-29 14:13 ` Marco 2006-12-25 14:20 ` Hyman Rosen 2006-12-23 11:43 ` Dmitry A. Kazakov 2006-12-25 13:49 ` Hyman Rosen 2006-12-25 14:39 ` Dmitry A. Kazakov 2006-12-26 1:34 ` Hyman Rosen 2006-12-26 9:11 ` Dmitry A. Kazakov 2006-12-26 16:23 ` Hyman Rosen 2006-12-26 19:28 ` Dmitry A. Kazakov 2006-12-27 1:44 ` Hyman Rosen 2006-12-27 9:21 ` Dmitry A. Kazakov 2006-12-27 19:06 ` Hyman Rosen 2006-12-28 10:59 ` Dmitry A. Kazakov 2006-12-28 16:29 ` Hyman Rosen 2006-12-29 11:12 ` Dmitry A. Kazakov 2006-12-29 14:56 ` Hyman Rosen 2006-12-28 17:35 ` Georg Bauhaus 2006-12-29 14:48 ` Dmitry A. Kazakov 2006-12-29 19:39 ` Georg Bauhaus 2006-12-30 9:58 ` Dmitry A. Kazakov 2006-12-30 14:53 ` Georg Bauhaus 2007-01-01 13:00 ` Dmitry A. Kazakov 2007-01-02 10:04 ` Georg Bauhaus 2007-01-02 11:11 ` Dmitry A. Kazakov 2007-01-02 12:33 ` Georg Bauhaus 2007-01-02 13:51 ` Dmitry A. Kazakov 2007-01-02 14:45 ` Georg Bauhaus 2007-01-03 10:10 ` Dmitry A. Kazakov 2007-01-03 14:20 ` Hyman Rosen 2007-01-03 14:55 ` Georg Bauhaus 2007-01-04 10:15 ` Dmitry A. Kazakov 2007-01-03 19:33 ` Alexander E. Kopilovich 2007-01-04 10:27 ` Dmitry A. Kazakov 2007-01-04 15:00 ` Alexander E. Kopilovich 2007-01-05 10:32 ` Dmitry A. Kazakov 2006-12-30 2:25 ` Randy Brukardt 2006-12-30 10:13 ` Dmitry A. Kazakov 2007-01-04 1:09 ` Randy Brukardt 2007-01-04 10:07 ` Dmitry A. Kazakov 2007-01-05 1:32 ` Randy Brukardt 2007-01-05 4:46 ` Randy Brukardt 2007-01-05 9:08 ` Jean-Pierre Rosen 2007-01-05 20:14 ` Georg Bauhaus 2007-01-06 0:14 ` Randy Brukardt 2006-12-29 0:09 ` Randy Brukardt 2006-12-29 11:11 ` Dmitry A. Kazakov 2006-12-30 2:40 ` Randy Brukardt 2006-12-21 16:55 ` Hyman Rosen 2006-12-21 18:22 ` markww 2006-12-22 3:01 ` Steve
This is a public inbox, see mirroring instructions for how to clone and mirror all data and code used for this inbox