* Discriminated records are not the most efficient, but ...
@ 2010-08-21 21:18 Yannick Duchêne (Hibou57)
2010-08-21 21:57 ` Yannick Duchêne (Hibou57)
0 siblings, 1 reply; 26+ messages in thread
From: Yannick Duchêne (Hibou57) @ 2010-08-21 21:18 UTC (permalink / raw)
Discriminated records are not the most efficient, but ... other ways to do
are likely to be turned into program logic errors.
Fully agree with this (do not like the technique of returning a special
value to indicate a state, which is a common practice with YouKnowWho).
Here is precisely a quote in this area:
> Often these tags are folded into the type as "reserved values",
> and their occurrence is not consistently checked: this is a fairly
> common source of programming errors
http://en.wikipedia.org/wiki/Tagged_union
(in “Advantages and disadvantages”)
Well, this efficiency leak should at least be really weighted (heavy in
this/that case ? not heavy ?) instead of supposed by reflex.
This may be a good “Warning: suspicious design” topic to check for
compilers, but I do not see a way how a compilers could determine such a
suspicious design is in use (honestly, I have an idea, but prefer not to
talk about it, because this would requires a bloat in the language).
This is an example where, while Ada help, sometime it needs your help in
return.
^ permalink raw reply [flat|nested] 26+ messages in thread
* Re: Discriminated records are not the most efficient, but ... 2010-08-21 21:18 Discriminated records are not the most efficient, but Yannick Duchêne (Hibou57) @ 2010-08-21 21:57 ` Yannick Duchêne (Hibou57) 2010-08-22 5:39 ` Yannick Duchêne (Hibou57) 0 siblings, 1 reply; 26+ messages in thread From: Yannick Duchêne (Hibou57) @ 2010-08-21 21:57 UTC (permalink / raw) Le Sat, 21 Aug 2010 23:18:35 +0200, Yannick Duchêne (Hibou57) <yannick_duchene@yahoo.fr> a écrit: > http://en.wikipedia.org/wiki/Tagged_union An opportunity to notice how Ada provides the concept to map this element of functional programming to its imperative language. And there may be others which can be easily mapped to Ada. Model in ML or SML (prototyping at a very abstract level) and implement in Ada (get safety and efficiency) ? May be an option for *some* applications. ^ permalink raw reply [flat|nested] 26+ messages in thread
* Re: Discriminated records are not the most efficient, but ... 2010-08-21 21:57 ` Yannick Duchêne (Hibou57) @ 2010-08-22 5:39 ` Yannick Duchêne (Hibou57) 2010-08-22 20:40 ` Yannick Duchêne (Hibou57) 0 siblings, 1 reply; 26+ messages in thread From: Yannick Duchêne (Hibou57) @ 2010-08-22 5:39 UTC (permalink / raw) Le Sat, 21 Aug 2010 23:57:19 +0200, Yannick Duchêne (Hibou57) <yannick_duchene@yahoo.fr> a écrit: > An opportunity to notice how Ada provides the concept to map this > element of functional programming to its imperative language. And there > may be others which can be easily mapped to Ada. Model in ML or SML > (prototyping at a very abstract level) and implement in Ada (get safety > and efficiency) ? May be an option for *some* applications. A new episode in the great series “Beyond The Type” :) Let me first give you a short (S)ML excerpt: datatype Tree = Leaf of int | Node of Tree * Tree; Think of it as an Ada discriminated record, like type Tree_Kind is (A_Leaf, A_Node); type Tree_Type (Kind : Tree_Kind); type Tree_Access is access all Tree_Type; type Tree_Type (Kind : Tree_Kind) is record case Kind is when A_Leaf => Leaf : Integer; when A_Node => Left, Right : Tree_Access; end case; end record; In datatype Tree = Leaf of int | Node of Tree * Tree; “Tree” is an SML type, “Leaf” and “Node” are SML constructors. Think of these latters as two primitives functions returning each a subtype of Tree_Type: Now, an SML function defined as fun Foo (Leaf (Value)) = Value | Foo (Node (Leaf (_), Leaf (Value))) = Value; (here, the underscore “_” has the same meaning as with Prolog) Think of it as the equivalent Ada function: function Foo (Tree : Tree_Type) return Integer is begin case Tree.Kind is when A_Leaf => return Tree.Leaf; when A_Node => return Tree.Left.Leaf; end case; end Foo; OK. You will enjoy one more the awesome Ada case statement and its heavy reliability which will help you avoid most errors. But things might go wrong as you may guess. What if Tree.Left is not actually a “Tree_Type (A_Leaf)” ? Bam!, Run-Time Error! Eh, logic error, compiler cannot statically catch it. I may guess you may like to say “where does it drive us, his silly 'untyped' interpreted language will be far more worst”. Wait a minute boys and girls, and let the magic play. First of all, I know you already have a Janus or GNAT (aren't you ?), so I will not bother about it. But you may not already have either an SML-SJ or MLTon. Here are links (we will resume right after, don't go away right now): http://www.smlnj.org/ (dated as far as October 2000, but still works as much fine as it was doing ten years ago) http://mlton.org/ (more like an alive app, dated as near as 2008) Open SML-NJ (an interactive interpreter, MLTon on the other side is a native code optimizing with global analysis compiler) first, at the SML-NJ prompt, type: datatype Tree = Leaf of (int) | Node of (Tree * Tree); (same as the one at the message opening, except standing on a single line) Now, type fun Foo (Leaf (Value)) = Value | Foo (Node (Leaf (_), Leaf (Value))) = Value; What happens ? You should get a stdIn:28.1-28.77 Warning: match nonexhaustive Leaf Value => ... Node (Leaf _,Leaf Value) => ... “Warning: match nonexhaustive”. This one is as cool as an error message from an Ada compiler. What does it means ? You will see (or you may guess straight away). Now, type the following: fun Foo (Leaf (Value)) = Value | Foo (Node (_, Right)) = Foo (Right); Now you should get.... no warning any more. What Foo is supposed to stand for ? I give you the name of the function I was playing with : Last_Leaf. Now, you see why the first one was wrong, and why the second one is OK. The first one exactly match the one defined in Ada above, which would have passed compilation stage without hearing a fly bzzz. But this same, did not avoided a warning from SML-NJ. So, what is the difference ? Abstraction : SML sees the constructors as part of the structure definition, while an Ada compiler would be unlikely so attempt such an analysis (the construction is a function for an Ada compiler, not part of of any type definition). Types and constructors are tied to each others. Time to say also, SML is not “untyped”, its type-inference oriented. I had an adventure with such a thing, needless to say it is unmaintainable with an application as soon as it goes beyond 5_000 or 10_000 lines of source (Ada is really nicer there and even above, it will keep going nice). But this is nice at smaller level, as it is terse, which is mostly welcome some time, just like when you are writing down something on a paper. So my purpose is not to say it is like Ada, not at all: it is different, while also formal enough to be usable. It has a different point of view, which makes it able to see what an Ada compiler will not see in an algorithm, simply because type and constructors are not opaque to each others. What would be the best here, with the possibility of an human error in mind ? Abstraction designed in SML (caught the algorithmic design error) and implementation design in Ada which is the only one which can handle things in the large (and efficiently with sharper designed types) as it is unlikely your application will be such a tiny thing. What about that last episode of “Beyond The Type” ? Did you liked it ? P.S. I really did have this error while playing with SML-NJ. And when I understood what the error standed for and how I could fix it, I said “Was, great, I love this waring message”. ^ permalink raw reply [flat|nested] 26+ messages in thread
* Re: Discriminated records are not the most efficient, but ... 2010-08-22 5:39 ` Yannick Duchêne (Hibou57) @ 2010-08-22 20:40 ` Yannick Duchêne (Hibou57) 2010-08-22 20:47 ` Florian Weimer 0 siblings, 1 reply; 26+ messages in thread From: Yannick Duchêne (Hibou57) @ 2010-08-22 20:40 UTC (permalink / raw) Le Sun, 22 Aug 2010 07:39:45 +0200, Yannick Duchêne (Hibou57) <yannick_duchene@yahoo.fr> a écrit: > (here, the underscore “_” has the same meaning as with Prolog) This “_” is nice for analysis, as it explicitly state a given component of a structure is not used in a given branch of a recursive algorithm (or even not recursive). I feel this help to express clean analysis. Funny: I came to an SML tutorial containing a whole paragraph talking about Ada and how some SML constructs can be mapped to Ada. It said (they seemed to like Pascal and Algol also): Roughly speaking (that is their wording) * Structures in ML corresponds to Package in Ada * Signature corresponds to an Ada Package Interface * Functor corresponds to Generic Package in Ada But they was wrong in one point, as they also ended with: “However, ML admits structures (not just types) as parameters to functors.” Probably they never heard about “package formal parameter”. I suppose they knew about Ada 83 and this was not there with this one (but was this really the case ?) They also forget about discriminated records (but they did not claim their match/match list was exhaustive). ^ permalink raw reply [flat|nested] 26+ messages in thread
* Re: Discriminated records are not the most efficient, but ... 2010-08-22 20:40 ` Yannick Duchêne (Hibou57) @ 2010-08-22 20:47 ` Florian Weimer 2010-08-22 22:07 ` Yannick Duchêne (Hibou57) 2010-08-23 1:52 ` Yannick Duchêne (Hibou57) 0 siblings, 2 replies; 26+ messages in thread From: Florian Weimer @ 2010-08-22 20:47 UTC (permalink / raw) * Yannick Duchêne (Hibou57): > But they was wrong in one point, as they also ended with: > > “However, ML admits structures (not just types) as parameters to > functors.” > > Probably they never heard about “package formal parameter”. I suppose > they knew about Ada 83 and this was not there with this one (but was > this really the case ?) But doesn't that mean that the package you want to pass has to be an instance of a generic package? I haven't seen that programming style much. (Ada hasn't got another way to express module types, so this shouldn't come as a surprise.) ^ permalink raw reply [flat|nested] 26+ messages in thread
* Re: Discriminated records are not the most efficient, but ... 2010-08-22 20:47 ` Florian Weimer @ 2010-08-22 22:07 ` Yannick Duchêne (Hibou57) 2010-08-22 22:11 ` Yannick Duchêne (Hibou57) 2010-08-23 3:06 ` Peter C. Chapin 2010-08-23 1:52 ` Yannick Duchêne (Hibou57) 1 sibling, 2 replies; 26+ messages in thread From: Yannick Duchêne (Hibou57) @ 2010-08-22 22:07 UTC (permalink / raw) Le Sun, 22 Aug 2010 22:47:24 +0200, Florian Weimer <fw@deneb.enyo.de> a écrit: > But doesn't that mean that the package you want to pass has to be an > instance of a generic package? I haven't seen that programming style > much. Yes, as said in 12.7(2) http://www.adaic.org/standards/05rm/html/RM-12-7.html So let say it can do it with restrictions (while that's easy to turn any package into a generic package, without any formal parameters... but you will have to do the same for all child packages). > (Ada hasn't got another way to express module types, so this shouldn't > come as a surprise.) By the way, a generic package does not define a type, so there is no module type (if I understand you correctly). In Ada they are all compilation units. But they defines an interface, which from an abstract point of view make it something like a typed object, for a package instance, or something may be a bit like a type for a none-instantiated generic package (i.e. the package definition). But you will not be able to derive a package from another package (there is nothing like “type package Z is new Y with ... end Z;”) ; so this would be rather limited view of a type. However, you have Tagged types and Records which can be derived and have primitives and a state just like packages does, but you will not be able to define a type inside of a tagged or record definition. The package in Ada, is really an architectural and organizational element (which includes reusability, via generic packages) and does not concretely intersect with the type system (except from some abstract point of view). The only thing I know which would the more look like a package and a type in the mean time, is task or protected types. This is more really a type (and can indeed be defined like type, while this is not required), as it can be used to recursively define another type (a task type may be a component of a record, or component of an array as examples) while a package cannot (there is nothing like defining a record with a package type component or an array of packages). I am not sure if a task is considered a compilation unit or not (I have check the RM, it says No... but I am still not sure, I feel it should be) Thanks for the interesting point you raised. (hope I did not said any erroneous things in this reply) ^ permalink raw reply [flat|nested] 26+ messages in thread
* Re: Discriminated records are not the most efficient, but ... 2010-08-22 22:07 ` Yannick Duchêne (Hibou57) @ 2010-08-22 22:11 ` Yannick Duchêne (Hibou57) 2010-08-23 3:06 ` Peter C. Chapin 1 sibling, 0 replies; 26+ messages in thread From: Yannick Duchêne (Hibou57) @ 2010-08-22 22:11 UTC (permalink / raw) Le Mon, 23 Aug 2010 00:07:45 +0200, Yannick Duchêne (Hibou57) <yannick_duchene@yahoo.fr> a écrit: > But you will not be able to derive a package from another package (there > is nothing like “type package Z is new Y with ... end Z;”) ; so this > would be rather limited view of a type. But you have child packages (still does not make it a type though lol) ^ permalink raw reply [flat|nested] 26+ messages in thread
* Re: Discriminated records are not the most efficient, but ... 2010-08-22 22:07 ` Yannick Duchêne (Hibou57) 2010-08-22 22:11 ` Yannick Duchêne (Hibou57) @ 2010-08-23 3:06 ` Peter C. Chapin 2010-08-23 3:50 ` Yannick Duchêne (Hibou57) 1 sibling, 1 reply; 26+ messages in thread From: Peter C. Chapin @ 2010-08-23 3:06 UTC (permalink / raw) On 2010-08-22 18:07, Yannick Duchêne (Hibou57) wrote: > I am not sure if a task is considered a compilation unit or not (I have > check the RM, it says No... but I am still not sure, I feel it should be) Tasks aren't compilation units because they can't be compiled on their own. They must be contained in something else (such as a package or subprogram). Peter ^ permalink raw reply [flat|nested] 26+ messages in thread
* Re: Discriminated records are not the most efficient, but ... 2010-08-23 3:06 ` Peter C. Chapin @ 2010-08-23 3:50 ` Yannick Duchêne (Hibou57) 2010-08-23 6:25 ` J-P. Rosen 2010-08-23 6:40 ` Niklas Holsti 0 siblings, 2 replies; 26+ messages in thread From: Yannick Duchêne (Hibou57) @ 2010-08-23 3:50 UTC (permalink / raw) Le Mon, 23 Aug 2010 05:06:53 +0200, Peter C. Chapin <chapinp@acm.org> a écrit: > Tasks aren't compilation units because they can't be compiled on their > own. They must be contained in something else (such as a package or > subprogram). > > Peter I see the point, but... this is the same for functions and procedures (except the entry point procedure or function). I've just checked deeper: compilation_unit includes subunit, which includes separates, which can be a separate task_body (follow links starting at 10.1.1). But, if you follow from compilation_unit to library_unit_declaration, you cannot reach anything like a task (or a protected). Detailed: * subunit may be: separate (parent_unit_name) subprogram_body | package_body | task_body | protected_body * library_unit_declaration may be: subprogram_declaration | package_declaration | generic_declaration | generic_instantiation * library_unit_body may be: subprogram_body | package_body So task or protected are compilation_unit... only when separate ? So what makes it not a compilation_unit when not separate ? Unless I am missing something else, this seems strange to me. -- * 3 lines of concise statements is readable, 10 pages of concise statements is unreadable ; * 3 lines of verbose statements may looks unuseful, 10 pages of verbose statements will never looks too much pedantic ^ permalink raw reply [flat|nested] 26+ messages in thread
* Re: Discriminated records are not the most efficient, but ... 2010-08-23 3:50 ` Yannick Duchêne (Hibou57) @ 2010-08-23 6:25 ` J-P. Rosen 2010-08-23 8:09 ` Yannick Duchêne (Hibou57) 2010-08-23 6:40 ` Niklas Holsti 1 sibling, 1 reply; 26+ messages in thread From: J-P. Rosen @ 2010-08-23 6:25 UTC (permalink / raw) Le 23/08/2010 05:50, Yannick Duchêne (Hibou57) a écrit : > So task or protected are compilation_unit... only when separate ? So > what makes it not a compilation_unit when not separate ? > > Unless I am missing something else, this seems strange to me. > Don't be fooled by the word "unit". In Ada, you have program units and compilation units, and they are orthogonal. -Program unit: a logical unit that can have behaviour (i.e. statements). -Compilation unit: something that can be given to the compiler without being nested into something else. For example, a package is one program unit. It is made of two parts, spec and body, where each is a compilation unit (can be compiled separately). A task is a type, not a module. Therefore, it is a program unit, not a compilation unit. However, any separate body can be compiled separately (of course!), and is a compilation unit. -- --------------------------------------------------------- J-P. Rosen (rosen@adalog.fr) Visit Adalog's web site at http://www.adalog.fr ^ permalink raw reply [flat|nested] 26+ messages in thread
* Re: Discriminated records are not the most efficient, but ... 2010-08-23 6:25 ` J-P. Rosen @ 2010-08-23 8:09 ` Yannick Duchêne (Hibou57) 0 siblings, 0 replies; 26+ messages in thread From: Yannick Duchêne (Hibou57) @ 2010-08-23 8:09 UTC (permalink / raw) Le Mon, 23 Aug 2010 08:25:59 +0200, J-P. Rosen <rosen@adalog.fr> a écrit: > -Compilation unit: something that can be given to the compiler without > being nested into something else. That's clearly expressed. So I suppose the reason why procedures and functions are always a compilation unit (listed as subprogram_unit) is because they may be an entry point. I was not afraid a compiler could forget to compile something, this was just I was wondering if something was broken in the wordings from the RM. -- * 3 lines of concise statements is readable, 10 pages of concise statements is unreadable ; * 3 lines of verbose statements may looks unuseful, 10 pages of verbose statements will never looks too much pedantic ^ permalink raw reply [flat|nested] 26+ messages in thread
* Re: Discriminated records are not the most efficient, but ... 2010-08-23 3:50 ` Yannick Duchêne (Hibou57) 2010-08-23 6:25 ` J-P. Rosen @ 2010-08-23 6:40 ` Niklas Holsti 2010-08-23 7:33 ` Simon Wright 2010-08-23 8:13 ` Yannick Duchêne (Hibou57) 1 sibling, 2 replies; 26+ messages in thread From: Niklas Holsti @ 2010-08-23 6:40 UTC (permalink / raw) Yannick Duchêne (Hibou57) wrote: > Le Mon, 23 Aug 2010 05:06:53 +0200, Peter C. Chapin <chapinp@acm.org> a > écrit: >> Tasks aren't compilation units because they can't be compiled on their >> own. They must be contained in something else (such as a package or >> subprogram). >> >> Peter > I see the point, but... this is the same for functions and procedures > (except the entry point procedure or function). Subprograms can be compiled on their own, without being enclosed in a package. See, for example, RM 10.1.1(31). (In that example, the subprogram is a child of a package, but that is not essential.) In my applications, such stand-alone subprograms are often generic, and their instantiations occur in a package and use the rich environment that the instantiating package provides. But also non-generic subprograms can be compiled on their own. -- Niklas Holsti Tidorum Ltd niklas holsti tidorum fi . @ . ^ permalink raw reply [flat|nested] 26+ messages in thread
* Re: Discriminated records are not the most efficient, but ... 2010-08-23 6:40 ` Niklas Holsti @ 2010-08-23 7:33 ` Simon Wright 2010-08-23 11:44 ` Martin 2010-08-23 8:13 ` Yannick Duchêne (Hibou57) 1 sibling, 1 reply; 26+ messages in thread From: Simon Wright @ 2010-08-23 7:33 UTC (permalink / raw) Niklas Holsti <niklas.holsti@tidorum.invalid> writes: > Subprograms can be compiled on their own, without being enclosed in a > package. And a main subprogram is usually a compilation unit, ie not in a package (though I can't see anything that actually requires that, http://www.adaic.com/standards/05rm/html/RM-10-2.html (7)). ^ permalink raw reply [flat|nested] 26+ messages in thread
* Re: Discriminated records are not the most efficient, but ... 2010-08-23 7:33 ` Simon Wright @ 2010-08-23 11:44 ` Martin 2010-08-23 13:16 ` Georg Bauhaus 0 siblings, 1 reply; 26+ messages in thread From: Martin @ 2010-08-23 11:44 UTC (permalink / raw) On 23 Aug, 08:33, Simon Wright <si...@pushface.org> wrote: > Niklas Holsti <niklas.hol...@tidorum.invalid> writes: > > Subprograms can be compiled on their own, without being enclosed in a > > package. > > And a main subprogram is usually a compilation unit, ie not in a package > (though I can't see anything that actually requires that,http://www.adaic.com/standards/05rm/html/RM-10-2.html(7)). Used to be required in Ada83 (see http://archive.adaic.com/standards/83lrm/html/lrm-10-01.html#10.1 - just before 'Notes') but Ada95 relaxed the rules. -- Martin ^ permalink raw reply [flat|nested] 26+ messages in thread
* Re: Discriminated records are not the most efficient, but ... 2010-08-23 11:44 ` Martin @ 2010-08-23 13:16 ` Georg Bauhaus 2010-08-23 13:32 ` Martin 2010-08-23 17:02 ` Yannick Duchêne (Hibou57) 0 siblings, 2 replies; 26+ messages in thread From: Georg Bauhaus @ 2010-08-23 13:16 UTC (permalink / raw) On 23.08.10 13:44, Martin wrote: > On 23 Aug, 08:33, Simon Wright <si...@pushface.org> wrote: >> Niklas Holsti <niklas.hol...@tidorum.invalid> writes: >>> Subprograms can be compiled on their own, without being enclosed in a >>> package. >> >> And a main subprogram is usually a compilation unit, ie not in a package >> (though I can't see anything that actually requires that,http://www.adaic.com/standards/05rm/html/RM-10-2.html(7)). > > Used to be required in Ada83 (see http://archive.adaic.com/standards/83lrm/html/lrm-10-01.html#10.1 > - just before 'Notes') but Ada95 relaxed the rules. package Empty is pragma Elaborate_Body (Empty); end Empty; with Ada.Text_IO; package body Empty is begin Ada.Text_IO.Put_Line ("Psst!"); end Empty; $ gnatchop empty.ada && gnatmake -z empty -- Georg ^ permalink raw reply [flat|nested] 26+ messages in thread
* Re: Discriminated records are not the most efficient, but ... 2010-08-23 13:16 ` Georg Bauhaus @ 2010-08-23 13:32 ` Martin 2010-08-23 17:02 ` Yannick Duchêne (Hibou57) 1 sibling, 0 replies; 26+ messages in thread From: Martin @ 2010-08-23 13:32 UTC (permalink / raw) On 23 Aug, 14:16, Georg Bauhaus <rm.dash-bauh...@futureapps.de> wrote: > On 23.08.10 13:44, Martin wrote: > > > On 23 Aug, 08:33, Simon Wright <si...@pushface.org> wrote: > >> Niklas Holsti <niklas.hol...@tidorum.invalid> writes: > >>> Subprograms can be compiled on their own, without being enclosed in a > >>> package. > > >> And a main subprogram is usually a compilation unit, ie not in a package > >> (though I can't see anything that actually requires that,http://www.adaic.com/standards/05rm/html/RM-10-2.html(7)). > > > Used to be required in Ada83 (seehttp://archive.adaic.com/standards/83lrm/html/lrm-10-01.html#10.1 > > - just before 'Notes') but Ada95 relaxed the rules. > > package Empty is > pragma Elaborate_Body (Empty); > end Empty; > > with Ada.Text_IO; > package body Empty is > begin > Ada.Text_IO.Put_Line ("Psst!"); > end Empty; > > $ gnatchop empty.ada && gnatmake -z empty > > -- Georg Yup, note Ada83 allowed implementations to support this too - it just defined a 'minimum' level of support for a main subprograms as a library-level parameterless procedure (NB: not function!). -- Martin ^ permalink raw reply [flat|nested] 26+ messages in thread
* Re: Discriminated records are not the most efficient, but ... 2010-08-23 13:16 ` Georg Bauhaus 2010-08-23 13:32 ` Martin @ 2010-08-23 17:02 ` Yannick Duchêne (Hibou57) 1 sibling, 0 replies; 26+ messages in thread From: Yannick Duchêne (Hibou57) @ 2010-08-23 17:02 UTC (permalink / raw) Le Mon, 23 Aug 2010 15:16:30 +0200, Georg Bauhaus <rm.dash-bauhaus@futureapps.de> a écrit: > package Empty is > pragma Elaborate_Body (Empty); > end Empty; > > with Ada.Text_IO; > package body Empty is > begin > Ada.Text_IO.Put_Line ("Psst!"); > end Empty; > > $ gnatchop empty.ada && gnatmake -z empty So the “-z” option can be used even without providing an external entry point. Did not knew and good to know. The only kind of case I used an application with a package initialization as an entry point, was always with a C entry point invoking adainit (using -z for Builder and -n for Binder). -- * 3 lines of concise statements is readable, 10 pages of concise statements is unreadable ; * 3 lines of verbose statements may looks unuseful, 10 pages of verbose statements will never looks too much pedantic ^ permalink raw reply [flat|nested] 26+ messages in thread
* Re: Discriminated records are not the most efficient, but ... 2010-08-23 6:40 ` Niklas Holsti 2010-08-23 7:33 ` Simon Wright @ 2010-08-23 8:13 ` Yannick Duchêne (Hibou57) 1 sibling, 0 replies; 26+ messages in thread From: Yannick Duchêne (Hibou57) @ 2010-08-23 8:13 UTC (permalink / raw) Le Mon, 23 Aug 2010 08:40:21 +0200, Niklas Holsti <niklas.holsti@tidorum.invalid> a écrit: > Subprograms can be compiled on their own, without being enclosed in a > package. See, for example, RM 10.1.1(31). (In that example, the > subprogram is a child of a package, but that is not essential.) OK. Believe me, I've never noticed this before (and never seen it any where until right now) Thanks for the point. -- * 3 lines of concise statements is readable, 10 pages of concise statements is unreadable ; * 3 lines of verbose statements may looks unuseful, 10 pages of verbose statements will never looks too much pedantic ^ permalink raw reply [flat|nested] 26+ messages in thread
* Re: Discriminated records are not the most efficient, but ... 2010-08-22 20:47 ` Florian Weimer 2010-08-22 22:07 ` Yannick Duchêne (Hibou57) @ 2010-08-23 1:52 ` Yannick Duchêne (Hibou57) 2010-08-23 5:14 ` Yannick Duchêne (Hibou57) 1 sibling, 1 reply; 26+ messages in thread From: Yannick Duchêne (Hibou57) @ 2010-08-23 1:52 UTC (permalink / raw) Le Sun, 22 Aug 2010 22:47:24 +0200, Florian Weimer <fw@deneb.enyo.de> a écrit: > But doesn't that mean that the package you want to pass has to be an > instance of a generic package? I haven't seen that programming style > much. Now I've just seen about Structures and Functors (you seems to know ML, do you ?), and we could say “Ada's functors” can only get functors as parameter, not structures. This should be kept in mind while mapping from ML to Ada, while honestly, this would be a matter only when there are children packages. But as such a package would typically encapsulate an ADT, this will most of time not be a matter, as most commonly such a package will not have children (because this is not needed if well designed, except if you want to extend with access to some private parts and that is really required.. otherwise, siblings rooted somewhere may be a better option). And any way, as Dmitry would tell you (and I agree): “generics hierarchies are not always so fun”. ^ permalink raw reply [flat|nested] 26+ messages in thread
* Re: Discriminated records are not the most efficient, but ... 2010-08-23 1:52 ` Yannick Duchêne (Hibou57) @ 2010-08-23 5:14 ` Yannick Duchêne (Hibou57) 2010-08-23 5:43 ` Florian Weimer 2010-09-04 18:49 ` Florian Weimer 0 siblings, 2 replies; 26+ messages in thread From: Yannick Duchêne (Hibou57) @ 2010-08-23 5:14 UTC (permalink / raw) Le Mon, 23 Aug 2010 03:52:14 +0200, Yannick Duchêne (Hibou57) <yannick_duchene@yahoo.fr> a écrit: > Now I've just seen about Structures and Functors (you seems to know ML, > do you ?), and we could say “Ada's functors” can only get functors as > parameter, not structures. I need to correct something or else what I wrote will be confusing and incomplete. In Ada : formal parameters may refer to a generic package. However, instantiation of such a package will requires a package instance in place of that formal parameter. In ML : a functor has the following signature: “structure -> structure”. So at first sight, this may seems ML functors cannot model Ada packages. But as a functor takes a structure to return a structure, this is exactly the same as with an Ada generic instantiation. As in ML a functor cannot create a structure signature and can only create a structure matching a structure signature, finally, application of an ML functor exactly match the process of instantiating an Ada generic. Conclusion: the Ada package system can be properly modeled with ML. Note: in ML, the parameters appears only at the functor definition, not in the signature, thus, the signature match Ada's package specification, *excluding the formal part* ; thus is correspond to what is between the “package Name” and “end Name;”. [*] Application of an ML functor = Ada generic instantiation Definition of an ML functor = Ada generic body Definition of an ML signature = Ada specification of a package or generic package (formal part excluded) And a one way equivalence Ada generic specification is the same as ML signature + ML functor's signature. That is fun, we may be able to model the Ada language :) This is a new view on Ada, I like that. There was first the LRM, later there was Ada Semantic Interface Specification (ASIS), now I get the beginning of an Ada model in a formal language. [*] With that in mind, the choice made for Ada to have the formal part preceding the package name, seems less strange! For the requirement of static checking on public interface, Ada simply required to have both signature (structure and functor) at one place and the choice to have the formal part preceding the generic package name, simply make these still clearly separated, while both at the same place. Clever syntactic choice they made! CheckMe: is there is a way to have a functor signature in ML ? -- * 3 lines of concise statements is readable, 10 pages of concise statements is unreadable ; * 3 lines of verbose statements may looks unuseful, 10 pages of verbose statements will never looks too much pedantic ^ permalink raw reply [flat|nested] 26+ messages in thread
* Re: Discriminated records are not the most efficient, but ... 2010-08-23 5:14 ` Yannick Duchêne (Hibou57) @ 2010-08-23 5:43 ` Florian Weimer 2010-08-23 7:55 ` Yannick Duchêne (Hibou57) 2010-09-04 18:49 ` Florian Weimer 1 sibling, 1 reply; 26+ messages in thread From: Florian Weimer @ 2010-08-23 5:43 UTC (permalink / raw) * Yannick Duchêne (Hibou57): > In ML : a functor has the following signature: “structure -> > structure”. So at first sight, this may seems ML functors cannot model > Ada packages. But as a functor takes a structure to return a > structure, this is exactly the same as with an Ada generic > instantiation. As in ML a functor cannot create a structure signature > and can only create a structure matching a structure signature, > finally, application of an ML functor exactly match the process of > instantiating an Ada generic. Except that ML favors structural typing, and Ada is focused strongly on nominal typing. > Conclusion: the Ada package system can be properly modeled with ML. Standard ML doesn't support functors nested in structures and higher-order functors, but both are a common extension. > Definition of an ML signature = Ada specification of a package or > generic package (formal part excluded) No, these two aren't equivalent. You cannot apply a specification to a package to get a new package (with a restricted interface, as some sort of type conversion). In Standard ML, you can. ^ permalink raw reply [flat|nested] 26+ messages in thread
* Re: Discriminated records are not the most efficient, but ... 2010-08-23 5:43 ` Florian Weimer @ 2010-08-23 7:55 ` Yannick Duchêne (Hibou57) 2010-08-23 8:06 ` Dmitry A. Kazakov 0 siblings, 1 reply; 26+ messages in thread From: Yannick Duchêne (Hibou57) @ 2010-08-23 7:55 UTC (permalink / raw) Le Mon, 23 Aug 2010 07:43:26 +0200, Florian Weimer <fw@deneb.enyo.de> a écrit: > Except that ML favors structural typing, and Ada is focused strongly > on nominal typing. Yes, via pattern matching. Nominal typing implies structural typing, but structural typing does not implies nominal. Let say so the proper model would be name * structure, with the name as a kind of tag. This would properly express the nominal typing. Suppose nominal typing more deals with architecture and organization than with semantic. But there also have a semantic obviously, via their structure and primitives. Properties exposed on a type T1 structurally defined as Pattern1 | Pattern2 | ... | PatternN will also be exposed on a type T2 identified by name and with the same structure as T1. If T2 is a type defined in Ada, the patterns may be expressed by either the type definition and optionally functions returning T2. If T2 is defined as a record, then this definition may only expose some of these properties, not all. Ex. it may say the type is recursive, but will not say How it is (as it will be part of the implementation only). Its T1 equivalence allows to infer more about it. To be honest, patterns are still unable to tell about circularity (unification kept apart, but unification is not part of patterns anyway, it expressed only at runtime). > Standard ML doesn't support functors nested in structures The difference is scope (what is the path to access from this to that), not semantic. Interesting point, which may leads to discuss about ways of refactoring a package hierarchy. Let B be a generic or none-generic child of A which is either generic or not generic ; let C be the set of what A and B refer to in common (transitivity may need to be applied to get a proper C set, which is always valid, as circular dependencies are not allowed). Turn C into a package imported by A and B, and architectural view kept apart, you have the same semantic. This is not a surprise, as package are intended to manage scopes and express architecture layout. We may just get a model of the semantic, nothing else. The model will not be a model of the organization, rather a model of the dependencies (that is semantic). Think about package elaboration: defining an order of elaboration is enough, there is no real recursivity. This could always be turned into a package after another, which is another way to say, there is a semantic equivalence which does not requite nesting, rather just reference to one or more previous siblings. > and higher-order functors, but both are a common extension. Unlikely to be a matter to model an imperative language. Ada does not know about functions returning functions, except indirectly via tagged types. If you meant generic generating an other generic, bay be the idea above is an option (providing it is not erroneous). >> Definition of an ML signature = Ada specification of a package or >> generic package (formal part excluded) > > No, these two aren't equivalent. You cannot apply a specification to > a package to get a new package (with a restricted interface, as some > sort of type conversion). In Standard ML, you can. You mean the structure type ? Like in “structure Foo: BAR = struct ... end;” ? For the other matter: if it can do what Ada cannot do, that just suggest it can model Ada in that area. -- * 3 lines of concise statements is readable, 10 pages of concise statements is unreadable ; * 3 lines of verbose statements may looks unuseful, 10 pages of verbose statements will never looks too much pedantic ^ permalink raw reply [flat|nested] 26+ messages in thread
* Re: Discriminated records are not the most efficient, but ... 2010-08-23 7:55 ` Yannick Duchêne (Hibou57) @ 2010-08-23 8:06 ` Dmitry A. Kazakov 2010-08-23 8:26 ` Yannick Duchêne (Hibou57) 0 siblings, 1 reply; 26+ messages in thread From: Dmitry A. Kazakov @ 2010-08-23 8:06 UTC (permalink / raw) On Mon, 23 Aug 2010 09:55:44 +0200, Yannick Duch�ne (Hibou57) wrote: > Nominal typing implies structural typing, Nominal type equivalence is when two types considered same when their names are same. It cannot imply structural typing. -- Regards, Dmitry A. Kazakov http://www.dmitry-kazakov.de ^ permalink raw reply [flat|nested] 26+ messages in thread
* Re: Discriminated records are not the most efficient, but ... 2010-08-23 8:06 ` Dmitry A. Kazakov @ 2010-08-23 8:26 ` Yannick Duchêne (Hibou57) 2010-08-23 8:43 ` Dmitry A. Kazakov 0 siblings, 1 reply; 26+ messages in thread From: Yannick Duchêne (Hibou57) @ 2010-08-23 8:26 UTC (permalink / raw) Le Mon, 23 Aug 2010 10:06:46 +0200, Dmitry A. Kazakov <mailbox@dmitry-kazakov.de> a écrit: > Nominal type equivalence is when two types considered same when their > names > are same. It cannot imply structural typing. Should have said “Full Name” instead of Name. In Ada, same full name (after any renaming resolution done) implies the same structure, or implies it holds at least the same structure (if you consider the views of a type of a class), which is enough to hold logical properties inferred from the structure. You may have Package1.Type1 and package2.Type1 with different structure, but they do not have the same name... oops, same full name. -- * 3 lines of concise statements is readable, 10 pages of concise statements is unreadable ; * 3 lines of verbose statements may looks unuseful, 10 pages of verbose statements will never looks too much pedantic ^ permalink raw reply [flat|nested] 26+ messages in thread
* Re: Discriminated records are not the most efficient, but ... 2010-08-23 8:26 ` Yannick Duchêne (Hibou57) @ 2010-08-23 8:43 ` Dmitry A. Kazakov 0 siblings, 0 replies; 26+ messages in thread From: Dmitry A. Kazakov @ 2010-08-23 8:43 UTC (permalink / raw) On Mon, 23 Aug 2010 10:26:28 +0200, Yannick Duchêne (Hibou57) wrote: > Le Mon, 23 Aug 2010 10:06:46 +0200, Dmitry A. Kazakov > <mailbox@dmitry-kazakov.de> a écrit: >> Nominal type equivalence is when two types considered same when their >> names are same. It cannot imply structural typing. > Should have said “Full Name” instead of Name. No matter, it is the names which are matched, not the objects they denote. Names themselves can be matched in different ways, e.g. Foo = foO, Standard.Integer = Integer etc. > In Ada, same full name (after any renaming resolution done) implies the > same structure, or implies it holds at least the same structure (if you > consider the views of a type of a class), which is enough to hold logical > properties inferred from the structure. This require definition of "structure". The language at least tries to avoid references to the structure, because it break fundamental concepts of the language design (abstractness, information hiding, separation of interface and implementation etc). If you replace "structure" to "behavior" then, yes, same thing has same behavior. -- Regards, Dmitry A. Kazakov http://www.dmitry-kazakov.de ^ permalink raw reply [flat|nested] 26+ messages in thread
* Re: Discriminated records are not the most efficient, but ... 2010-08-23 5:14 ` Yannick Duchêne (Hibou57) 2010-08-23 5:43 ` Florian Weimer @ 2010-09-04 18:49 ` Florian Weimer 1 sibling, 0 replies; 26+ messages in thread From: Florian Weimer @ 2010-09-04 18:49 UTC (permalink / raw) * Yannick Duch�ne (Hibou57): > Conclusion: the Ada package system can be properly modeled with ML. The functor aspect perhaps. But Ada packages are open in the sense that you can add child packages to them (with increased access privileges) without cooperation from the parent. This is not possible in Standard ML. > CheckMe: is there is a way to have a functor signature in ML ? No, not in Standard ML. ^ permalink raw reply [flat|nested] 26+ messages in thread
end of thread, other threads:[~2010-09-04 18:49 UTC | newest] Thread overview: 26+ messages (download: mbox.gz / follow: Atom feed) -- links below jump to the message on this page -- 2010-08-21 21:18 Discriminated records are not the most efficient, but Yannick Duchêne (Hibou57) 2010-08-21 21:57 ` Yannick Duchêne (Hibou57) 2010-08-22 5:39 ` Yannick Duchêne (Hibou57) 2010-08-22 20:40 ` Yannick Duchêne (Hibou57) 2010-08-22 20:47 ` Florian Weimer 2010-08-22 22:07 ` Yannick Duchêne (Hibou57) 2010-08-22 22:11 ` Yannick Duchêne (Hibou57) 2010-08-23 3:06 ` Peter C. Chapin 2010-08-23 3:50 ` Yannick Duchêne (Hibou57) 2010-08-23 6:25 ` J-P. Rosen 2010-08-23 8:09 ` Yannick Duchêne (Hibou57) 2010-08-23 6:40 ` Niklas Holsti 2010-08-23 7:33 ` Simon Wright 2010-08-23 11:44 ` Martin 2010-08-23 13:16 ` Georg Bauhaus 2010-08-23 13:32 ` Martin 2010-08-23 17:02 ` Yannick Duchêne (Hibou57) 2010-08-23 8:13 ` Yannick Duchêne (Hibou57) 2010-08-23 1:52 ` Yannick Duchêne (Hibou57) 2010-08-23 5:14 ` Yannick Duchêne (Hibou57) 2010-08-23 5:43 ` Florian Weimer 2010-08-23 7:55 ` Yannick Duchêne (Hibou57) 2010-08-23 8:06 ` Dmitry A. Kazakov 2010-08-23 8:26 ` Yannick Duchêne (Hibou57) 2010-08-23 8:43 ` Dmitry A. Kazakov 2010-09-04 18:49 ` Florian Weimer
This is a public inbox, see mirroring instructions for how to clone and mirror all data and code used for this inbox