Discriminated records are not the most efficient, but ...

Discriminated records are not the most efficient, but ...

[Yannick Duchêne (Hibou57)]

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.

Re: Discriminated records are not the most efficient, but ...

[Yannick Duchêne (Hibou57)]

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.

Re: Discriminated records are not the most efficient, but ...

[Yannick Duchêne (Hibou57)]

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”.

Re: Discriminated records are not the most efficient, but ...

[Yannick Duchêne (Hibou57)]

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).

Re: Discriminated records are not the most efficient, but ...

[Florian Weimer]

* 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.)

Re: Discriminated records are not the most efficient, but ...

[Yannick Duchêne (Hibou57)]

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)

Re: Discriminated records are not the most efficient, but ...

[Yannick Duchêne (Hibou57)]

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)

Re: Discriminated records are not the most efficient, but ...

[Peter C. Chapin]

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

Re: Discriminated records are not the most efficient, but ...

[Yannick Duchêne (Hibou57)]

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

Re: Discriminated records are not the most efficient, but ...

[J-P. Rosen]

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

Re: Discriminated records are not the most efficient, but ...

[Yannick Duchêne (Hibou57)]

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

Re: Discriminated records are not the most efficient, but ...

[Niklas Holsti]

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
       .      @       .

Re: Discriminated records are not the most efficient, but ...

[Simon Wright]

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)).

Re: Discriminated records are not the most efficient, but ...

[Martin]

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

Re: Discriminated records are not the most efficient, but ...

[Georg Bauhaus]

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

Re: Discriminated records are not the most efficient, but ...

[Martin]

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

Re: Discriminated records are not the most efficient, but ...

[Yannick Duchêne (Hibou57)]

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

Re: Discriminated records are not the most efficient, but ...

[Yannick Duchêne (Hibou57)]

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

Re: Discriminated records are not the most efficient, but ...

[Yannick Duchêne (Hibou57)]

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”.

Re: Discriminated records are not the most efficient, but ...

[Yannick Duchêne (Hibou57)]

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

Re: Discriminated records are not the most efficient, but ...

[Florian Weimer]

* 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.

Re: Discriminated records are not the most efficient, but ...

[Yannick Duchêne (Hibou57)]

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

Re: Discriminated records are not the most efficient, but ...

[Dmitry A. Kazakov]

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

Re: Discriminated records are not the most efficient, but ...

[Yannick Duchêne (Hibou57)]

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

Re: Discriminated records are not the most efficient, but ...

[Dmitry A. Kazakov]

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

Re: Discriminated records are not the most efficient, but ...

[Florian Weimer]

* 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.