From mboxrd@z Thu Jan 1 00:00:00 1970 X-Spam-Checker-Version: SpamAssassin 3.4.4 (2020-01-24) on polar.synack.me X-Spam-Level: X-Spam-Status: No, score=-0.3 required=5.0 tests=BAYES_00, REPLYTO_WITHOUT_TO_CC autolearn=no autolearn_force=no version=3.4.4 X-Google-Thread: 103376,21960280f1d61e84 X-Google-Attributes: gid103376,public X-Google-Language: ENGLISH,ASCII Path: g2news2.google.com!news3.google.com!border1.nntp.dca.giganews.com!nntp.giganews.com!newsfeed00.sul.t-online.de!t-online.de!newsfeed.freenet.de!news.teledata-fn.de!newsfeed.arcor.de!newsspool2.arcor-online.net!news.arcor.de.POSTED!not-for-mail From: "Dmitry A. Kazakov" Subject: Re: How come Ada isn't more popular? Newsgroups: comp.lang.ada User-Agent: 40tude_Dialog/2.0.15.1 MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: 8bit Reply-To: mailbox@dmitry-kazakov.de Organization: cbb software GmbH References: <1169531612.200010.153120@38g2000cwa.googlegroups.com> <1mahvxskejxe1$.tx7bjdqyo2oj$.dlg@40tude.net> <2tfy9vgph3.fsf@hod.lan.m-e-leypold.de> <1g7m33bys8v4p.6p9cpsh3k031$.dlg@40tude.net> Date: Wed, 31 Jan 2007 11:55:33 +0100 Message-ID: <14hm72xd3b0bq$.axktv523vay8$.dlg@40tude.net> NNTP-Posting-Date: 31 Jan 2007 11:55:33 CET NNTP-Posting-Host: 8a83fd51.newsspool1.arcor-online.net X-Trace: DXC=P:nKEc3N7OK78PK[oJ2ng@ic==]BZ:afN4Fo<]lROoRA^YC2XCjHcbIC[MFWR]hO8BDNcfSJ;bb[EFCTGGVUmh?DLK[5LiR>kgBe74HTDIc@5O X-Complaints-To: usenet-abuse@arcor.de Xref: g2news2.google.com comp.lang.ada:8765 Date: 2007-01-31T11:55:33+01:00 List-Id: On Mon, 29 Jan 2007 16:50:16 +0100, Markus E Leypold wrote: > "Dmitry A. Kazakov" writes: > >> On Sun, 28 Jan 2007 16:06:48 +0100, Markus E Leypold wrote: >> >>> "Dmitry A. Kazakov" writes: >>> >>>> On Sun, 28 Jan 2007 00:24:27 +0100, Markus E Leypold wrote: >> >>>> Generics is a wrong answer and always was. As well as built-in lists you >>>> are praising is, because what about trees of strings, trees of lists etc. >>>> You cannot build every and each type of containers in. >>> >>> You missed my point. :-). A language with a Hinldey-Milner type system >>> has a 'tree of something' type where something can be anything in >>> every given instance of usage. >> >> You have X of Y. Granted, you can play with Y, but what about X? > > I don't understand the question ... X = tree, Y = something. What about X = something, Y = character. Example: fixed size strings, unbounded strings, suffix tree. Here the container (X) varies, the element does not. It is a quite common situation when you wished to change the containers on the fly. >> The point is, the language should not have either X or Y built-in. What > > Pursuing this argument further, a language also shouldn't have strings > built in etc. :-). Yes, sure. The standard library can provide them, but there must be no magic in. The user should be able to describe string type in language terms without loss of either performance or compatibility. > What I think, is, that having at least lists in the "standard library" > and by that I mean functional lists, not arrays, not "containers", > helps tremendously because that is such a common use case. > >> should be built-in is "of". The type system should be able to handle >> parallel type hierarchies of X's and Y's bound by the relation "of". > > Yes. And exactly that is what a Hindley-Milner type system has built > in. The lists in Haskell and Ocaml are just in the standard library > (conceptually -- knowing that they are here, makes it easy to compile > them by special rules and get a more efficient implementation or have > special instructions in the underlying VM or reduction mechanism). I doubt it can. I am too lazy to check. (:-)) But the uncomfortable questions you (the type system) should answer are like: Y1 <: Y2 => X of Y1 <: X of Y2 is container of subtypes a subtype? X1 <: X2 => X1 of Y <: X2 of Y is sub-container a subtype? There is no universal answer. Sometimes yes, sometimes not. Consider yes examples: String vs. Wide_String (case 1) Unbounded_String vs. String (case 2) Unbounded_String vs. Wide_String (mixed case) >>> So you get 'tree of foo' from it and 'tree of bar' when you use it >>> like this, but there are no generics instantiated. There are trade >>> offs, of course (like that you probably can't design such a language >>> without GC and without loosing a certain degree of control of the >>> representation of types), >> >> It is not obvious. I saw to good arguments for GC, so far. (it tend to >> repeat in c.l.a and comp.object, a lot of foam around mouths... (:-)) > > Foam, yes :-). But you have to admit, that allowing a GC without ever > having an actual implementation (execpt Martin Krischik's adaption of > the B�hm collector) just too much teasing: You could have it, but no, > it's not there. It was left open for those who might need it. It seems that nobody came... (:-)) No seriously, I don't consider GC as a problem. Just give me "X of Y." Then I would take X = access. An do whatever memory collection I want! See? There is absolutely no need to have built-in GC, if you have abstract referential (access) interfaces. Note additional advantage: you can have different GC's handling objects of same types in the same application! >> To me GC is about indeterminable scopes, upward closures and >> other things I don't want to have... > > If yout have only downward scopes for "closures" and memory allocation > this will, finally, interact badly with the fact that "implicit > (i.e. static type safe) casting" of classes is also only possible > downwards. My impression is, that all these things together rule out > some useful designs, that would otherwise possible. Or to say it > differenty: Object orientation w/o indeterminable scopes, upward > closures and GC doesn't work well. Some abstractions cannot be > implemented. Umm, I cannot tell. It is an interesting point. I am not sure if it is true, because we already can return T'Class, and surely we should develop the language towards making X of Y'Class possible. As a simple intermediate stage we could allow X (T: Tag) of Y'Class (T). In Ada syntax: type Coherent_Array (Element_Tag : ) is array (Integer range <>) of Element'Class (Element_Type); Here the discriminant of the array determines the specific types of all its elements. > This, of course is just a gut feeling. I do not know about research or > empiricial studies that examine the influence that these various > restrictions have on each other and how they act together. My feeling is that upward closures destroy the idea of type. However, somehow we surely need type objects in some form, for making distributed systems, for instance (how to marshal non-objects?) >> Let types-1 be values, make them values. Then they will need no >> declarations, just literals. Soon you will discover some types-2 which >> still require declarations. Make them values too. An so on. At some level n >> you will have to stop. Now, rename type-n = "type". value, type-k> "value". See? You are where you have started. > > I do not understand your argument here. Care to give some example and > I'll try write down how it is down in i.e. OCaml? Perhaps we're > talking on cross purposes too, since I'm not sure I really wanted to > desire the thing you insist I want. :-) You have the following hierarchy: values type-1 = types (sets of values + operations) type-2 = types of types (sets of types + operations to compose types) type-3 = types of types of types (...) ... type-n ... type-oo [ value-k = type-k-1 ] As an example of type-2 you can consider parametrized types. Instances of them are type-1 (=value-2). Types declared in generic Ada packages are type-1. All of them considered together ("generic type") is a type-2. Another example of type-2 in Ada is formal generic type: generic type T is range <>; "range <>" is type-2. The actual T is type-1 (=value-2). >>> Languages of the Algol-FORTRAN-C-Pascal-Ada group are all far from >>> that ideal. Since a lot of programming these days is general list >>> manipulation, everyday jobs become painful. >> >> There always was Lisp, for those who prefer declarations spelt in the form >> of bracket structures... > > I'm not talking about syntax. I'm talking about types. Which -- > strictly speaking -- lisp hasn't. there is only one (static) type in a > dynamic type system, which is one large union (discriminant) type. I think one could argue that types in Lisp are (), (()), ((())), ... but I don't believe it deserves much attention. (:-)) >>> Has anybody here aver wondered about the popularity of "scripting", >>> like with Perl, PHP, Python and so on? >> >> I did. > > And? What was the result of your considerations? :-) The Original Sin is the reason. They are sent upon us as a punishment... (:-)) [...] > You make me laugh :-). So what Ada should do, is to introduce a > String256 with appropriate restriction, and then we will succeed. Good > plan ... :-))). Not in this life ... Use Ada and be saved... (:-)) >>>> In my view there are three great innovations Ada made, which weren't >>>> explored at full: >>>> >>>> 1. Constrained subtypes (discriminants) >>>> 2. Implementation inheritance without values (type N is new T;) >>>> 3. Typed classes (T /= T'Class) >>> >>> Here 2 things are missing: >>> >>> - parameterized types (see Java generics and the ML type system, the >>> first is just borrowing from the latter). >> >> See pos.1. The constraint is the parameter of. In rare cases you wanted >> different values of parameters producing isolated types you would apply 2 >> to 1. > > Again I do not know what you're denying here... I deny them as types-2. The huge advantage of pos.1 is that the result is type-1. The consequence: you can have common values. With type-2 values (value-1) of different values (type-1) of type-2 are of different types => you cannot put them into one container. >>> - Separation of implementation and type or to put it differently >>> inheritance and subtyping compatibility. See the ocaml type system. >> >> That should be interface inheritance from concrete types. Yes, Ada misses >> that. > > No, what I want is even different. 2 values / objects in the OCaml way > of objects are just compatible if their type signatures (which are > calculated by the type inference engine) agree or better one is > contained in the other. This is a weaker contract than in Ada where at > least a behavioural part of the contract is implied by inheriting the > implementation, but which (except for generic packages) is useless, > since you can destroy behaviour by overwriting a method with a > misbehaved procedure. I don't see difference yet. When you inherit only interface, you drop all the implementation or its parts. This is one issue. Type inference, if you mean that, is a different one. I doubt that inference is a right way. >>> I admit the contracts are weaker for allowing to instante a >>> generic with a package with the "right type signature" as >>> parameter instead of requiring an instance of another specific >>> generic. >> >> There should be no generics at all... > > I'm not sure. Generics provide a relatively stric contract model. I > like this. But the instantation requirement is cumbersome if compared > with the way parameterized types work in other langauges (and that is > exactly what I'm pulling from generics most of the time: parameterized > types). Parameterized types are now 1:1 substitute for generics. ML > has functors too, for a good reason. But they are what makes everyday > live bearable. We don't need parametrized types (type-2). We can well do almost everything with parametrized subtypes (type-1). That is the pos.1. Compare: type String is array (Positive range <>) of Character; -- type-1, subtype is parametrized by the bounds generic First : Positive; Last : Positive; package type String is array (First..Last) of Character; -- type-2, type is parametrized by the bounds I don't want the latter. Everything that can be made within type-1 must be done there. >>> But what is absolutely annoying, is, that the compatibility of >>> objects is determined by inheritance instead by the type >>> signature. >> >> I see it otherwise. Because "compatibility" is undecidable (for both the >> computer and the programmer), the language must be strongly and >> manifestedly typed. > > Since the contract can be broken by new methods anyway, the only thing > that counts from a type safety point of view, is, not to break the > abstraction to the underlying processor / VM, that is, to be able to > call the methods with the right number of parameters and the right > representation of the parameters (at the machine level). So the type > signature is enough. This is a strange argument. Yes, you cannot verify the semantics, exactly therefore types come into play. Type only names the behavior, so that it can be checked formally *without* looking into actual behavior. > It's really bothersome that one cannot supply a class X which is > compatible to another class Y by just writing out the right methods. This is interface inheritance + supertyping + inheritance. It works as follows: Given: X, Y independent types. Required: To use Y where the interface of X is expected. You create a supertype Z for Y which is a subtype of X. The compiler will check the contract and require you to implement necessary adaptors. Done. >>> This makes things like the factory pattern necessary >>> and it really doesn't work in general case. (And yes, Java and C++ >>> share this defect). >> >> I am not sure what you mean, but when 3 is considered as 1, then >> dispatching on bare type tags might become possible. > > 3? 1? Please elaborate? Is "dispatching on bare type tags" a good or a > bad thing? You lost me there ... (my fault probably). You can consider type tag as a discriminant so pos.3 is a case of pos.1. When you make an abstract factory it is usually so that you know somehow the type you want to create (=you have the tag of), but you don't have yet any object of that type. I.e. you have to dispatch on the bare tag to the factory function. > But my dear Dmitry -- What does your sentence "All strings have fixed > length ..." mean than in this context, eh? That for any given X there exist a function X'Length. We should carefully distinguish properties of values and types. -- Regards, Dmitry A. Kazakov http://www.dmitry-kazakov.de