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