Convention for naming of packages

Convention for naming of packages

[Yannick Duchêne (Hibou57)]

Hi people out there,

There use to be here, discussions about naming convention of types,  
focusing on whether or not the _Type suffix should be used (I personally  
opted for it). Don't want to come back to this one here, but about another  
common (common for me) name conflict: package names which conflict with  
object names, as package names are often derived from a type name with any  
suffix removed, and as type names are often derived from generic object  
names, comes a name conflict with object names and packages names.

Most of time this does not occur, but when it do, it do. In the mean time,  
I would like to as much strictly as possible, rely on one naming  
convention for packages.

I am thinking the plural could play this role. There may be a limitation  
to its application, as I feel to know some English nouns do not have a  
plural, or are spelled the same for both their singular and plural.

Do you know another better and constant convention well suited for package  
names? Note: I don't mind if the convention does not match the one of  
standard packages (I use _Type, and standard packages don't, and I never  
bothered).

I'm seeking for any idea from any source.

Have a sweet time.

-- 
“Syntactic sugar causes cancer of the semi-colons.” [1]
“Structured Programming supports the law of the excluded muddle.” [1]
[1]: Epigrams on Programming — Alan J. — P. Yale University

Re: Convention for naming of packages

[Jeffrey Carter]

On 02/09/2012 02:10 PM, Yannick Duchêne (Hibou57) wrote:
>
> I am thinking the plural could play this role. There may be a limitation to its
> application, as I feel to know some English nouns do not have a plural, or are
> spelled the same for both their singular and plural.

The plural is used a lot in the standard library (Ada.Strings, Ada.Containers).

The present participle is sometimes useful (Widget_Handling, Town_Marshalling).

I've also seen instances where _Management was meaningful and solved this kind 
of conflict.

-- 
Jeff Carter
"IMHO, Interfaces are worthless."
Randy Brukardt
117

--- Posted via news://freenews.netfront.net/ - Complaints to news@netfront.net ---

Re: Convention for naming of packages

[Simon Wright]

"Yannick Duchêne (Hibou57)" <yannick_duchene@yahoo.fr> writes:

> I am thinking the plural could play this role. There may be a
> limitation to its application, as I feel to know some English nouns do
> not have a plural, or are spelled the same for both their singular and
> plural.

See http://www.rinkworks.com/words/wordforms.shtml. 

As to not having a plural, there may be some, such as perhaps Anger or
Weather; but I wouldn't feel bad about

   package Weathers is
      type Weather_Type is ...

since we'd all know what you meant.

On the other hand, if you are a _Type person, why would you need the
plural form for the package?

   package Weather is
      type Weather_Type is ...

   package Weathers is
      type Weather is ...

Re: Convention for naming of packages

[J-P. Rosen]

Le 09/02/2012 22:10, Yannick Duchêne (Hibou57) a écrit :
> Do you know another better and constant convention well suited for
> package names? Note: I don't mind if the convention does not match the
> one of standard packages (I use _Type, and standard packages don't, and
> I never bothered).
> 
For packages used for classes, you might consider the convention
described in "A naming convention for packages in Ada9X", that you can
download from http://www.adalog.fr/publica2.htm

-- 
J-P. Rosen
Adalog
2 rue du Docteur Lombard, 92441 Issy-les-Moulineaux CEDEX
Tel: +33 1 45 29 21 52, Fax: +33 1 45 29 25 00
http://www.adalog.fr

Re: Convention for naming of packages

[Mart van de Wege]

"Yannick Duchêne (Hibou57)" <yannick_duchene@yahoo.fr> writes:

>
> I am thinking the plural could play this role. There may be a
> limitation to its application, as I feel to know some English nouns do
> not have a  plural, or are spelled the same for both their singular
> and plural.

package Hobbitses is
    type Hobbit is record
        Name : String;
        Has_Precious : Boolean;
     end record;
End Hobbitses

Sorry, I couldn't resist.

-- 
"We will need a longer wall when the revolution comes."
    --- AJS, quoting an uncertain source.

Re: Convention for naming of packages

[Brian Drummond]

On Thu, 09 Feb 2012 22:10:12 +0100, Yannick Duchêne (Hibou57) wrote:

> Hi people out there,
> 
> There use to be here, discussions about naming convention of types,
> focusing on whether or not the _Type suffix should be used (I personally
> opted for it). Don't want to come back to this one here, but about
> another common (common for me) name conflict: package names which
> conflict with object names...

If you have accepted _type, then why not _pkg for consistency?

Then you have
Weather : Weather_type := Weather_pkg.predict;

I have seen this as a requirement in (VHDL) coding standards.
But where plurals are more appropriate, I would prefer them.
- Brian

Re: Convention for naming of packages

[Yannick Duchêne (Hibou57)]

Le Fri, 10 Feb 2012 13:19:47 +0100, Brian Drummond  
<brian@shapes.demon.co.uk> a écrit:
> If you have accepted _type, then why not _pkg for consistency?

I don't use _Type because I enjoy it, rather due to the too many conflict  
which occurs otherwise. I prefer abstract names, which ends to be the same  
as the one you use for type.

_Pkg is an abbreviation, something which I would like to avoid, for a  
matter of style. I mean uncommon abbreviation, and names like HTML, CSS,  
are OK. I also would like to avoid suffix proliferation and use these only  
when strongly required.

> Then you have
> Weather : Weather_type := Weather_pkg.predict;
>
> I have seen this as a requirement in (VHDL) coding standards.
> But where plurals are more appropriate, I would prefer them.

When the package is named after an object name, I agree (some package are  
named after an operation name, a pattern name, and other non‑objects).

Will have a look at VHDL style convention.

-- 
“Syntactic sugar causes cancer of the semi-colons.” [1]
“Structured Programming supports the law of the excluded muddle.” [1]
[1]: Epigrams on Programming — Alan J. — P. Yale University

Re: Convention for naming of packages

[Yannick Duchêne (Hibou57)]

Le Fri, 10 Feb 2012 10:47:45 +0100, Mart van de Wege <mvdwege@mail.com> a  
écrit:
> package Hobbitses is
>     type Hobbit is record
>         Name : String;
>         Has_Precious : Boolean;
>      end record;
> End Hobbitses
>
> Sorry, I couldn't resist.

Okay, Hobbits also stands for the singular of something which is different  
than Hobbit.

Sorry, could not resist to check :-D


-- 
“Syntactic sugar causes cancer of the semi-colons.” [1]
“Structured Programming supports the law of the excluded muddle.” [1]
[1]: Epigrams on Programming — Alan J. — P. Yale University

Re: Convention for naming of packages

[Yannick Duchêne (Hibou57)]

Le Thu, 09 Feb 2012 23:35:51 +0100, J-P. Rosen <rosen@adalog.fr> a écrit:
> For packages used for classes, you might consider the convention
> described in "A naming convention for packages in Ada9X", that you can
> download from http://www.adalog.fr/publica2.htm

I remember I already read something similar. You were the author too. This  
was about Mixin / Facet (both names were used). On my own side, I would  
also suggest Aspect, as the term seems more common (think about “Aspect  
Programming”).

I use part of the convention recommended in this paper, that's the reason  
why I use Instance_Type in many place since long ;) This indeed end to be  
handy in the long run, and not only for the reasons exposed in the paper:  
this also help readability as it emphases relationship of the main type  
with the other auxiliary types defined in a package. In other words, this  
avoid useless noise and add emphases to roles. Being constant is often  
good (save cognitive loads), and this convention afford consistency.


-- 
“Syntactic sugar causes cancer of the semi-colons.” [1]
“Structured Programming supports the law of the excluded muddle.” [1]
[1]: Epigrams on Programming — Alan J. — P. Yale University

Re: Convention for naming of packages

[Yannick Duchêne (Hibou57)]

Le Thu, 09 Feb 2012 22:39:51 +0100, Jeffrey Carter  
<spam.jrcarter.not@spam.not.acm.org> a écrit:
> The plural is used a lot in the standard library (Ada.Strings,  
> Ada.Containers).
I had this in minde, though this was not common enough. After I read you  
yesterday, I changed my mind and feel at rest with the plural now.

> The present participle is sometimes useful (Widget_Handling,  
> Town_Marshalling).
Noted.

> I've also seen instances where _Management was meaningful and solved  
> this kind of conflict.
Idem.


Will go for plural so.


Now I am seeking for something even more difficult: conflict between  
function names and object names. This can be solved using prefixed  
notation, but I want to avoid it to not bloat source too much. A too long  
full name is not readable and can just make people think Ada is  
definitively over‑wordy (as J.P. Rosen explained in a paper, people tends  
to keep in mind bad points first about Ada).

To be honest, this conflict typically occurs when I want a local constant  
to hold the value returned by a function, to avoid invocation of this  
function multiple time. That's a common idiom, although I feel this may be  
based on wrong assumptions about compiler efficiency, while not the only  
one reason. I feel it's often good to substitute a single name to a whole  
expression.

A quick example.


    function Object (Param : Param_Type) return Object_Type;

    procedure Scan is
       Object : constant Object_Type := Object (Param);
       -- Or alternatively: “Object : constant Object_Type renames Object  
(Param);”
    begin
       for I in Index_Type loop
          ... Object ...
          -- Instead of ... Object (Param) ...
       end loop;
    end;

Object conflict with Object. I can use prefix and have

    Object : constant Object_Type := Repository_Package.Object (Param);

instead of

    Object : constant Object_Type := Object (Param);


But I would like to avoid the Repository_Package prefix for the previously  
given reasons. I remember I knew a language (cannot remember which one)  
which was fine with this, as this language considered Object to not  
already be defined when it was encountering Object (Param).

Thus

    Object : constant Object_Type := Object (Param);

was defining Object with an initial value and right after hiding the  
Object function.

The problem does not occurs with either record type (as members are all  
prefixed) and subprogram parameters, as these are assigned by the caller.  
The latter may be an idea, so this could be a solution:


    procedure Scan is
       procedure Scan (Object : in Object_Type) is
       begin
          for I in Index_Type loop
             ... Object ...
             -- Instead of ... Object (Param) ...
          end loop;
       end,
    begin
       Scan (Object (Param));
    end;

I don't know what to think about it, looks too much like a big trick in  
Ada source and this is even much longer than using the previous prefix  
notation along with a local constant.

What do you feel about this?


-- 
“Syntactic sugar causes cancer of the semi-colons.” [1]
“Structured Programming supports the law of the excluded muddle.” [1]
[1]: Epigrams on Programming — Alan J. — P. Yale University

Re: Convention for naming of packages

[Georg Bauhaus]

On 10.02.12 16:07, Yannick Duchêne (Hibou57) wrote:

>    function Object (Param : Param_Type) return Object_Type;

Does Object do anything? Does it, for example, make an object
from Param? Is it in some kind of relationship between the
function Object and its Param? Is Object different from
Object_Type--other than being a function, not a type?

An obvious prefix in the first case might be Make_.

If it is possible to describe the relationship of the function
and its parameters, there might be a word in the description
that can serve as part of the function's name.

If Object is different from Object_Type, then the difference
likely has a description. Again, it might be possible
to find words in this description that will do for the function
and/or the type, words that have more meaning than _Type.

When I imagine a function to be a table, the parameters and the
result being the columns, I sometimes find a good name for
the whole thing, in context.

Re: Convention for naming of packages

[Georg Bauhaus]

On 10.02.12 16:07, Yannick Duchêne (Hibou57) wrote:

>    Object : constant Object_Type := Object (Param);

(1) Does Object do anything? Does it, for example, make an object
from Param? (2) Is there some kind of relationship between the
function Object and its Param? (3) Is Object different from
Object_Type--other than being a function, not a type?

If any of the questions has a positive answer,
the answer should generate solutions.

(1) An obvious prefix for the function name might be Make_.

(2) If it is possible to describe the relationship of the function
and its parameters, there might be a word in the description
that can serve as part of the function's name.

(3) If Object is different from Object_Type, then the difference
likely has a description. Again, it might be possible
to find words in this description that will do for the function
and/or the type, words that have more meaning than _Type.

When I imagine a function to be a table, the parameters and the
result being the columns, I sometimes find a good name for
the whole thing, in context.

Re: Convention for naming of packages

[Pascal Obry]

Le 09/02/2012 22:39, Jeffrey Carter a écrit :
> On 02/09/2012 02:10 PM, Yannick Duchêne (Hibou57) wrote:
>>
>> I am thinking the plural could play this role. There may be a
>> limitation to its
>> application, as I feel to know some English nouns do not have a
>> plural, or are
>> spelled the same for both their singular and plural.
> 
> The plural is used a lot in the standard library (Ada.Strings,
> Ada.Containers).

Yes but the first question is do we want to have use clauses or not.

Using use it is fine to do:

   package Shapes is
      type Shape is ...
   end Shapes;

   with Shapes; use Shapes;
   O : Shape;

It would be awful to write:

   with Shapes;
   O : Shapes.Shape;

I try avoiding use clauses, so my naming is more:

   package Shape is
      type Object is tagged ...
   end Shape;

   with Shapes;
   O : Shape.Object;

For tagged type I like Object or Instance.

For other type, well it depends:

   package Server is
      type Data is record ...

or

   package Server is
      type Handle is record ...

Giving good names is the hardest part for me, not sure I have the best
scheme, but you asked me :)

Pascal.

-- 

--|------------------------------------------------------
--| Pascal Obry                           Team-Ada Member
--| 45, rue Gabriel Peri - 78114 Magny Les Hameaux FRANCE
--|------------------------------------------------------
--|    http://www.obry.net  -  http://v2p.fr.eu.org
--| "The best way to travel is by means of imagination"
--|
--| gpg --keyserver keys.gnupg.net --recv-key F949BD3B

Re: Convention for naming of packages

[Yannick Duchêne (Hibou57)]

Le Fri, 10 Feb 2012 18:09:00 +0100, Georg Bauhaus  
<rm.dash-bauhaus@futureapps.de> a écrit:

> On 10.02.12 16:07, Yannick Duchêne (Hibou57) wrote:
>
>>    Object : constant Object_Type := Object (Param);
>
> (1) Does Object do anything? Does it, for example, make an object
> from Param? (2) Is there some kind of relationship between the
> function Object and its Param? (3) Is Object different from
> Object_Type--other than being a function, not a type?

No, it really returns an object and do nothing else (pure functions). I  
may be wrong with the choice of “Param” name. Better think of it as:

    Object : constant Object_Type := Object (Object_Of_Another_Type);

Object may returns/*be* an attribute (which may not really exist in the  
full view of the type if that's an opaque type) of its parameter(s). Some  
of these attributes may be kind of view. Thus, providing Instance_Type is  
defined, you may have things like:

    function Attribute_1 (Instance : Instance_Type) return Attribute_1_Type;
    function Attribute_2 (Instance : Instance_Type) return Attribute_2_Type;
    function View_1 (Instance : Instance_Type) return View_1_Type;
    function View_2 (Instance : Instance_Type) return View_2_Type;

For attributes, I though about something like a Get_ prefix, which is  
similar in some way to the Make_ prefix you suggest. But I want to avoid a  
prefix if possible. As I want a constant convention, this would mean using  
Get_ or Make_ everywhere. If I wanted to use Get_ only where conflict are  
likely to occurs, this would be weird and drafty (some function will have  
a Get_ prefixed, some others won't… not clean). Moreover, and as you later  
mentioned arrays, I would like to keep the ability to use the same  
convention for arrays and functions, as I see arrays as just a special  
kind of function and don't expect to emphases any distinction between  
arrays and functions. If ever the function was implemented with an array,  
which would be named Make_Something, this would be weird too.

Similarly, for views, I though about an As_ prefix. Being far less common  
and short while still correct english, this one could be OK and I don't  
mind for an As_ prefix. Having something like this would looks natural  
enough:

    View_Name : constant View_Name_Type := As_View_Name (Instance);

If a view may be seen as a special kind of attributes, the reversed is not  
true. I cannot name all attributes like this. So this would really be OK  
for views, and only views.

Function returning attributes, thus, accessors, are far more common. So a  
Get_ prefix would not be welcome. And this make it too much looks like an  
action, while the mentioned function are supposed to be pure.

For subprograms setting value, I don't mind to use a Set_ prefix  
everywhere, this looks natural, not bloating, and that's another story,  
there is no kind of conflict with object names here.


> When I imagine a function to be a table, the parameters and the
> result being the columns, I sometimes find a good name for
> the whole thing, in context.

What I want to avoid, is to think of a context which is too much specific  
and choose a name on that basis. That would mean the package specification  
may change each time an implementation create a context with conflicts.  
The package specification have to be designed with use case in mind, but  
should not be changed for each context which would occur later.

-- 
“Syntactic sugar causes cancer of the semi-colons.” [1]
“Structured Programming supports the law of the excluded muddle.” [1]
[1]: Epigrams on Programming — Alan J. — P. Yale University

Re: Convention for naming of packages

[Yannick Duchêne (Hibou57)]

Le Fri, 10 Feb 2012 18:21:51 +0100, Pascal Obry <pascal@obry.net> a écrit:
> Giving good names is the hardest part for me

For me too


-- 
“Syntactic sugar causes cancer of the semi-colons.” [1]
“Structured Programming supports the law of the excluded muddle.” [1]
[1]: Epigrams on Programming — Alan J. — P. Yale University

Re: Convention for naming of packages

[Jeffrey Carter]

On 02/10/2012 05:19 AM, Brian Drummond wrote:
>
> Weather : Weather_type := Weather_pkg.predict;

Let's be consistent:

Weather_Variable : Weather_Package.Weather_Type := Weather_Package.Predict_Function;

-- 
Jeff Carter
"Your mother was a hamster and your father smelt of elderberries."
Monty Python & the Holy Grail
06

--- Posted via news://freenews.netfront.net/ - Complaints to news@netfront.net ---

Re: Convention for naming of packages

[Randy Brukardt]

[-- Warning: decoded text below may be mangled, UTF-8 assumed --]
[-- Attachment #1: Type: text/plain, Size: 1554 bytes --]

"Yannick Duch�ne (Hibou57)" <yannick_duchene@yahoo.fr> wrote in message 
news:op.v9gxmhjnule2fv@douda-yannick...
...
>Now I am seeking for something even more difficult: conflict between 
>function names and object names. This can be solved using prefixed 
>notation, but I want to avoid it to not bloat source too much. A too long 
>full name is not readable and can just make people think Ada is 
>definitively over-wordy (as J.P. Rosen explained in a paper, people tends 
>to keep in mind bad points first about Ada).

We faced this problem in Claw. One thing that often works is for function 
names to be verbs, and object names to be nouns.

>    function Object (Param : Param_Type) return Object_Type;

In Claw, this function would be called "Create". And then there is no 
conflict.

...
>But I would like to avoid the Repository_Package prefix for the previously 
>given reasons.

We chose the naming in Claw because it worked best both with people who 
write the prefix most of the time (that is, the "use-adverse") and those who 
rarely write the prefix (the "use-friendly"). But I would hope no one would 
be against using the tools built into Ada to deal with this sort of 
situation - there are always cases where prefixes are needed to eliminate 
ambiguity. So we didn't try to find naming that is completely unambigious 
(that's impossible in general in any case, since you're going to be using 
lots of packages that you didn't design, starting with the ones in the 
Standard.)

                                             Randy.

Re: Convention for naming of packages

[Randy Brukardt]

"Pascal Obry" <pascal@obry.net> wrote in message 
news:4f355230$0$21451$ba4acef3@reader.news.orange.fr...
...
> It would be awful to write:
>
>   with Shapes;
>   O : Shapes.Shape;

But this is exactly what Claw does, as it is best for reusable code to work 
well for both "use-friendly" and "use-adverse". The above is far less 
frequent than calls, and the alternative of "Object" for the type is 
actively hostile to the "use-friendly". Unless a package is only going to be 
used under a single style-guide (that is, within your organization), it 
really ought to be friendly to both approaches. (Which admittedly increases 
the level of difficulty for naming.)

[Note: Claw actually uses "Shape_Type" for type names, so the above actually 
looks like (using a decent name for the objec):
    Triangle : Shapes.Shape_Type;
It definitely makes object declarations look redundant, but doing that 
allows all other uses to not be redundant.]

One thing I neglected to mention in my last post is that under no 
circumstances should the name of the type appear in (OO) subprogram names. 
The object parameter to the subprogram should be named well enough to give 
the content for the "use-friendly" (and if it is not, the client has more 
problems than we can help them with), and the package name will give the 
context for the "use-adverse".

We spend quite a bit of effort on designing and adopting a consistent naming 
for Claw, as I was convinced that naming was going to have a huge impact on 
the usability of the product. (And I had plenty of experience with the 
haphazard naming used in the Janus/Ada code base, and I didn't want to 
repeat that.)

                                            Randy.

Re: Convention for naming of packages

[Simon Wright]

"Randy Brukardt" <randy@rrsoftware.com> writes:

> [Note: Claw actually uses "Shape_Type" for type names, so the above
> actually looks like (using a decent name for the objec):
>     Triangle : Shapes.Shape_Type;

I feel that does rather depend on the name's scope and how many other
names are declared in that scope.

> One thing I neglected to mention in my last post is that under no
> circumstances should the name of the type appear in (OO) subprogram
> names.  The object parameter to the subprogram should be named well
> enough to give the content for the "use-friendly" (and if it is not,
> the client has more problems than we can help them with), and the
> package name will give the context for the "use-adverse".

In most cases the subprogram name tells what it does, and the object
parameter might just as well be called 'This'. As for the other
parameters .. my style recommendations, which may seem a bit odd but
were derived from experience (of others' sins!) are

   As a matter of style, always name parameters from the point of view
   of the operation's caller, not from your point of view as
   implementer. Try to make the names read well, especially if the
   caller uses named parameter association:

      SNTP.User.Receive_Broadcasts_Via
        (The_Agent => Service,
         Reporting_To => S_Support.Receiver'Access);

   Don't use long parameter names that repeat the type name. There is
   plenty of context available to the reader, and you make it more
   difficult than it need be to follow coding standards that ask for
   limits on line lengths.

(neither parameter is of a tagged type).

Re: Convention for naming of packages

[Yannick Duchêne (Hibou57)]

Le Sat, 11 Feb 2012 10:22:18 +0100, Simon Wright <simon@pushface.org> a  
écrit:
> In most cases the subprogram name tells what it does, and the object
> parameter might just as well be called 'This'. As for the other
> parameters .. my style recommendations, which may seem a bit odd but
> were derived from experience (of others' sins!) are
>
>    As a matter of style, always name parameters from the point of view
>    of the operation's caller, not from your point of view as
>    implementer. Try to make the names read well, especially if the
>    caller uses named parameter association:

That's why I was looking for a name for that too. Your comments exclude  
“Me” as an option, because although short, this express a point of view  
 from the inside. Same comment with Self, which is just a longer variant of  
Me. “This” is indeed fine. Except that as I use Instance_Type for the  
(main) type name when the purpose of the package is to define a type, this  
logically suggest Instance as the parameter name. I feel it's too long. So  
I though using This_Type instead of Instance_Type could be an option, but  
failed to see it as natural, and feel “Objects.This_Type” does not read as  
nice as “Ojects.Instance_Type” do. Someone with another opinion?

Well “function F (This : Instance_Type) return Some_Type;” and “F (This =>  
Object);” may read nice enough after all, even if the parameter name and  
the type name does not match well.

-- 
“Syntactic sugar causes cancer of the semi-colons.” [1]
“Structured Programming supports the law of the excluded muddle.” [1]
[1]: Epigrams on Programming — Alan J. — P. Yale University

Re: Convention for naming of packages

[Martin Dowie]

Yannick Duchêne (Hibou57 ) <yannick_duchene@yahoo.fr> wrote:
> Hi people out there,
> 
> There use to be here, discussions about naming convention of types,  
> focusing on whether or not the _Type suffix should be used (I personally 
> opted for it). Don't want to come back to this one here, but about another  
> common (common for me) name conflict: package names which conflict with 
> object names, as package names are often derived from a type name with any  
> suffix removed, and as type names are often derived from generic object 
> names, comes a name conflict with object names and packages names.
> 
> Most of time this does not occur, but when it do, it do. In the mean time,  
> I would like to as much strictly as possible, rely on one naming  
> convention for packages.
> 
> I am thinking the plural could play this role. There may be a limitation 
> to its application, as I feel to know some English nouns do not have a  
> plural, or are spelled the same for both their singular and plural.
> 
> Do you know another better and constant convention well suited for package  
> names? Note: I don't mind if the convention does not match the one of  
> standard packages (I use _Type, and standard packages don't, and I never 
> bothered).
> 
> I'm seeking for any idea from any source.
> 
> Have a sweet time.


Another option is to prefix the type with A_ (or An_). This has the benefit
of mirroring the indefinite article nature of types (ie Class v Object).
You can then name the packages as appropriate - most times plurals make
sense but not always.

Takes a little getting used to but is actually very readable and has all
the benefits of _Type without the 'ugliness'. 

-- Martin


-- 
-- Sent from my iPad

Re: Convention for naming of packages

[Yannick Duchêne (Hibou57)]

Le Sat, 11 Feb 2012 11:17:41 +0100, Yannick Duchêne (Hibou57)  
<yannick_duchene@yahoo.fr> a écrit:

> Le Sat, 11 Feb 2012 10:22:18 +0100, Simon Wright <simon@pushface.org> a  
> écrit:
>> In most cases the subprogram name tells what it does, and the object
>> parameter might just as well be called 'This'.

Finally I will either not keep this one, or else, complete it. "This"  
as‑as and alone, don't map well on all subprograms.

Fine with that:

    Print (This => …);  -- Operation
    Update (This => …); -- Operation

But not with that:

    Set_Weight (This => …, Value => …); -- Setter
    Weight (This => …);                 -- Getter
    Relation (This => …, Foo => …);     -- Expression

An solution could be:

    Set_Weight (On => …, Value => …); -- Setter
    Weight (Of => …);                 -- Getter
    Relation (From => …, Foo => …);   -- Expression

(so far, don't care about the other choice needed for "Of" which is a  
reserved word) This do not name things, and try to mimic English grammar.  
Same comment with "This". This/On/Of/From don't look like object names,  
they mimic natural language. Good or bad? I'm hesitating, and have both  
feeling at the same time.

In any case, if things needs all to be properly named, naming from the  
user point of view, ends into bad name from the implementation/self point  
of view. So a corresponding renaming could be advisable in implementation.

Ex.

    Me : constant Instance_Type renames This;
    Me : constant Instance_Type renames On;
    Me : constant Instance_Type renames Of;
    Me : constant Instance_Type renames From;

Would be rather pleasant to read and unlikely to make people shout "Hey,  
that's too much wordy! That's just bloat!".

What's your feeling?


-- 
“Syntactic sugar causes cancer of the semi-colons.” [1]
“Structured Programming supports the law of the excluded muddle.” [1]
[1]: Epigrams on Programming — Alan J. — P. Yale University

Re: Convention for naming of packages

[Simon Wright]

"Yannick Duchêne (Hibou57)" <yannick_duchene@yahoo.fr> writes:

> Le Sat, 11 Feb 2012 11:17:41 +0100, Yannick Duchêne (Hibou57)
> <yannick_duchene@yahoo.fr> a écrit:
>
>> Le Sat, 11 Feb 2012 10:22:18 +0100, Simon Wright
>> <simon@pushface.org> a écrit:
>>> In most cases the subprogram name tells what it does, and the object
>>> parameter might just as well be called 'This'.
>
> Finally I will either not keep this one, or else, complete it. "This"
> as‑as and alone, don't map well on all subprograms.
>
> Fine with that:
>
>    Print (This => …);  -- Operation
>    Update (This => …); -- Operation
>
> But not with that:
>
>    Set_Weight (This => …, Value => …); -- Setter
>    Weight (This => …);                 -- Getter
>    Relation (This => …, Foo => …);     -- Expression

Personally I wouldn't use named association for the first
(dispatching/oblect) parameter. I saw Foo (This => This, ...) too
often. And now you'd say

   Foo.Set_Weight (Value => ...); or
   Foo.Set_Weight (To => ...);
   Bar := Foo.Weight;

> In any case, if things needs all to be properly named, naming from the
> user point of view, ends into bad name from the implementation/self
> point  of view. So a corresponding renaming could be advisable in
> implementation.
>
> Ex.
>
>    Me : constant Instance_Type renames This;
>    Me : constant Instance_Type renames On;
>    Me : constant Instance_Type renames Of;
>    Me : constant Instance_Type renames From;
>
> Would be rather pleasant to read and unlikely to make people shout
> "Hey, that's too much wordy! That's just bloat!".
>
> What's your feeling?

I think I would say it was bloat. One very quickly gets used to 'This'
(especially when using a code generator which always uses 'This' for the
object parameter!). But for one of the longer 'functional' names I was
mentioning earlier, it certainly could make sense.

In my current project I found myself saying

   type Attribute_Element is new Element with record
      ...
   end record;
   overriding
   procedure Resolve (A : in out Attribute_Element);
   overriding
   procedure Output (A : Attribute_Element; To : Ada.Text_IO.File_Type);

because 'This' seemed inappropriate. But it was only a vague feeling.

Re: Convention for naming of packages

[Yannick Duchêne (Hibou57)]

Le Sat, 11 Feb 2012 21:06:36 +0100, Simon Wright <simon@pushface.org> a  
écrit:
>> Fine with that:
>>
>>    Print (This => …);  -- Operation
>>    Update (This => …); -- Operation
>>
>> But not with that:
>>
>>    Set_Weight (This => …, Value => …); -- Setter
>>    Weight (This => …);                 -- Getter
>>    Relation (This => …, Foo => …);     -- Expression
>
> Personally I wouldn't use named association for the first
> (dispatching/oblect) parameter. I saw Foo (This => This, ...) too
> often. And now you'd say
>
>    Foo.Set_Weight (Value => ...); or
>    Foo.Set_Weight (To => ...);
>    Bar := Foo.Weight;
>

Doted notation is excluded for me, as tagged types are not so common and  
don't want a distinction between static/dynamic linking (and dispatching  
may be hidden anyway).

Still worth nothing for others who use doted notation.

>> Ex.
>>
>>    Me : constant Instance_Type renames This;
>>    Me : constant Instance_Type renames On;
>>    Me : constant Instance_Type renames Of;
>>    Me : constant Instance_Type renames From;
>>
>> Would be rather pleasant to read and unlikely to make people shout
>> "Hey, that's too much wordy! That's just bloat!".
>>
>> What's your feeling?
>
> I think I would say it was bloat. One very quickly gets used to 'This'
> (especially when using a code generator which always uses 'This' for the
> object parameter!). But for one of the longer 'functional' names I was
> mentioning earlier, it certainly could make sense.
Excuse me, I'm not sure I understand the sentence “But for one of the  
longer 'functional' names I was mentioning earlier”, at least I could not  
track it back (that's why I feel I did not understand).

-- 
“Syntactic sugar causes cancer of the semi-colons.” [1]
“Structured Programming supports the law of the excluded muddle.” [1]
[1]: Epigrams on Programming — Alan J. — P. Yale University

Re: Convention for naming of packages

[Simon Wright]

"Yannick Duchêne (Hibou57)" <yannick_duchene@yahoo.fr> writes:

> Le Sat, 11 Feb 2012 21:06:36 +0100, Simon Wright <simon@pushface.org>
> a écrit:

>> I think I would say it was bloat. One very quickly gets used to
>> 'This' (especially when using a code generator which always uses
>> 'This' for the object parameter!). But for one of the longer
>> 'functional' names I was mentioning earlier, it certainly could make
>> sense.
> Excuse me, I'm not sure I understand the sentence “But for one of the
> longer 'functional' names I was mentioning earlier”, at least I could
> not track it back (that's why I feel I did not understand).

I was thinking of the parameters in

   SNTP.User.Receive_Broadcasts_Via
     (The_Agent => Service,
      Reporting_To => S_Support.Receiver'Access);

Re: Convention for naming of packages

[J-P. Rosen]

Le 11/02/2012 02:06, Randy Brukardt a �crit :
>> It would be awful to write:
>>
>>   with Shapes;
>>   O : Shapes.Shape;
> 
> But this is exactly what Claw does, as it is best for reusable code to work 
> well for both "use-friendly" and "use-adverse". 
Well, a "use friendly" (as I am) needs not be a "use maniac". Of course,
Object is intended to be used with the package name (but not necessarily
other elements declared in the package). Nothing prevents you from
qualifying with a package name inside a use clause for that package!

-- 
J-P. Rosen
Adalog
2 rue du Docteur Lombard, 92441 Issy-les-Moulineaux CEDEX
Tel: +33 1 45 29 21 52, Fax: +33 1 45 29 25 00
http://www.adalog.fr

Re: Convention for naming of packages

[Yannick Duchêne (Hibou57)]

Le Sun, 12 Feb 2012 20:53:16 +0100, J-P. Rosen <rosen@adalog.fr> a écrit:
> Nothing prevents you from
> qualifying with a package name inside a use clause for that package!

And conversely, nothing prevents one to Used a package designed for "use  
unfriendly".


-- 
“Syntactic sugar causes cancer of the semi-colons.” [1]
“Structured Programming supports the law of the excluded muddle.” [1]
[1]: Epigrams on Programming — Alan J. — P. Yale University

Re: Convention for naming of packages

[BrianG]

On 02/10/2012 09:24 AM, Yannick Duchêne (Hibou57) wrote:
> Le Fri, 10 Feb 2012 10:47:45 +0100, Mart van de Wege <mvdwege@mail.com>
> a écrit:
>> package Hobbitses is
>> type Hobbit is record
>> Name : String;
    Pocketses : array (1..2) of Pants.Pocket
              := (Content => (Tuppence, Precious));
>> Has_Precious : Boolean;
>> end record;
>> End Hobbitses
>>
>> Sorry, I couldn't resist.
>
> Okay, Hobbits also stands for the singular of something which is
> different than Hobbit.
>
> Sorry, could not resist to check :-D
>
Couldn't help throwing in my two cents.

-- 
---
BrianG
000
@[Google's email domain]
.com

Re: Convention for naming of packages

[BrianG]

On 02/10/2012 07:56 PM, Randy Brukardt wrote:
> "Yannick Duch�ne (Hibou57)"<yannick_duchene@yahoo.fr>  wrote in message
> news:op.v9gxmhjnule2fv@douda-yannick...
> ...
>> Now I am seeking for something even more difficult: conflict between
>> function names and object names. This can be solved using prefixed
>> notation, but I want to avoid it to not bloat source too much. A too long
>> full name is not readable and can just make people think Ada is
>> definitively over-wordy (as J.P. Rosen explained in a paper, people tends
>> to keep in mind bad points first about Ada).
>
> We faced this problem in Claw. One thing that often works is for function
> names to be verbs, and object names to be nouns.
>
>>     function Object (Param : Param_Type) return Object_Type;
>
> In Claw, this function would be called "Create". And then there is no
> conflict.
>
Unless the function is meant to "Object" to the Param (i.e. raise an 
objection):

    function Object (Param : Param_Type) return Object_Type is
       Objection : exception;
    begin
       raise Objection;
    end Object;

Sorry, I couldn't help myself; I'll blame it on the Hobbitses.  Yeah, I 
know it's not legal.

-- 
---
BrianG
000
@[Google's email domain]
.com

Re: Convention for naming of packages

[Dmitry A. Kazakov]

On Sun, 12 Feb 2012 22:19:08 +0100, Yannick Duch�ne (Hibou57) wrote:

> Le Sun, 12 Feb 2012 20:53:16 +0100, J-P. Rosen <rosen@adalog.fr> a �crit:
>> Nothing prevents you from
>> qualifying with a package name inside a use clause for that package!
> 
> And conversely, nothing prevents one to Used a package designed for "use  
> unfriendly".

Conflicting names do.

Use-friendly design requires much work for a reason, you invest at one end
to gain something at the other.

If names like This, That, Self, Object are felt satisfactory, then I have a
simpler schema:

  - parameters: A1, ..., An,
  - procedures: F1, ...,  Fn,
  - variables: V1, ..., Vn
  - types: T1, ..., Tn
  - packages: P1, ..., Pn

-- 
Regards,
Dmitry A. Kazakov
http://www.dmitry-kazakov.de

Re: Convention for naming of packages

[Yannick Duchêne (Hibou57)]

Le Mon, 13 Feb 2012 09:53:56 +0100, Dmitry A. Kazakov  
<mailbox@dmitry-kazakov.de> a écrit:

> On Sun, 12 Feb 2012 22:19:08 +0100, Yannick Duchêne (Hibou57) wrote:
>
>> Le Sun, 12 Feb 2012 20:53:16 +0100, J-P. Rosen <rosen@adalog.fr> a  
>> écrit:
>>> Nothing prevents you from
>>> qualifying with a package name inside a use clause for that package!
>>
>> And conversely, nothing prevents one to Used a package designed for "use
>> unfriendly".
>
> Conflicting names do.
Of course, but nothing is absolute. Conflict can be all solved with prefix  
or renaming. There will be some conflict, but not all will conflict.

-- 
“Syntactic sugar causes cancer of the semi-colons.” [1]
“Structured Programming supports the law of the excluded muddle.” [1]
[1]: Epigrams on Programming — Alan J. — P. Yale University

Re: Convention for naming of packages

[Yannick Duchêne (Hibou57)]

Le Sat, 11 Feb 2012 10:22:18 +0100, Simon Wright <simon@pushface.org> a  
écrit:
>    As a matter of style, always name parameters from the point of view
>    of the operation's caller, not from your point of view as
>    implementer.
Was thinking this distinction only occurs when you try to mimic natural  
language and do not when you name parameters as objects.

To get back to a simple exemple:

    function F (Instance : Instance_Type) return Result_Type;

There is no internal point of view or user point of view here, the  
parameter is named as an object.

I just don't like it, because its too long for named parameter  
associations like "F (Instance => Foo)", especially when numerous  
parameters follows. I don't mind with declarations and bodies.

May be better to forget about this aspect for now and don't care about  
identifiers's size too much.

-- 
“Syntactic sugar causes cancer of the semi-colons.” [1]
“Structured Programming supports the law of the excluded muddle.” [1]
[1]: Epigrams on Programming — Alan J. — P. Yale University

Re: Convention for naming of packages

[Yannick Duchêne (Hibou57)]

Le Fri, 10 Feb 2012 18:09:00 +0100, Georg Bauhaus  
<rm.dash-bauhaus@futureapps.de> a écrit:

> On 10.02.12 16:07, Yannick Duchêne (Hibou57) wrote:
>
>>    Object : constant Object_Type := Object (Param);
>
> (1) Does Object do anything? Does it, for example, make an object
> from Param? (2) Is there some kind of relationship between the
> function Object and its Param? (3) Is Object different from
> Object_Type--other than being a function, not a type?
>
> If any of the questions has a positive answer,
> the answer should generate solutions.
>
> (1) An obvious prefix for the function name might be Make_.

The common practice is not to use a prefix, and use either Make or Create  
alone.

This practice works fine, so as a derived question, I was questioning  
myself about the conversion functions: if we name creation function Make  
or Create, shouldn't conversion functions be named the same way using a  
single word like Casted or Converted? (adjectives because these are  
function)

This may cause ambiguities in some context, but not more the Create/Make  
and type qualification is always available to solve ambiguities.

What's your feeling?

-- 
“Syntactic sugar causes cancer of the semi-colons.” [1]
“Structured Programming supports the law of the excluded muddle.” [1]
[1]: Epigrams on Programming — Alan J. — P. Yale University

Re: Convention for naming of packages

[Georg Bauhaus]

On 13.02.12 09:53, Dmitry A. Kazakov wrote:

> If names like This, That, Self, Object are felt satisfactory, then I have a
> simpler schema:
> 
>   - parameters: A1, ..., An,
>   - procedures: F1, ...,  Fn,
>   - variables: V1, ..., Vn
>   - types: T1, ..., Tn
>   - packages: P1, ..., Pn
> 

Google's JavaScript compiler outputs identifiers like these.

Re: Convention for naming of packages

[Yannick Duchêne (Hibou57)]

Le Mon, 13 Feb 2012 11:45:23 +0100, Georg Bauhaus  
<rm.dash-bauhaus@futureapps.de> a écrit:
>> If names like This, That, Self, Object are felt satisfactory, then I  
>> have a
>> simpler schema:
>>
>>   - parameters: A1, ..., An,
>>   - procedures: F1, ...,  Fn,
>>   - variables: V1, ..., Vn
>>   - types: T1, ..., Tn
>>   - packages: P1, ..., Pn
>>
>
> Google's JavaScript compiler outputs identifiers like these.

That's on purpose and is a different matter. This is named "obfuscation".  
This serves two purposes: preserve confidentiality when that's expected,  
and reduce stream size (even after Deflate compression, this still has an  
impact on stream size).

-- 
“Syntactic sugar causes cancer of the semi-colons.” [1]
“Structured Programming supports the law of the excluded muddle.” [1]
[1]: Epigrams on Programming — Alan J. — P. Yale University

Re: Convention for naming of packages

[Dmitry A. Kazakov]

On Mon, 13 Feb 2012 10:12:09 +0100, Yannick Duch�ne (Hibou57) wrote:

> Le Mon, 13 Feb 2012 09:53:56 +0100, Dmitry A. Kazakov  
> <mailbox@dmitry-kazakov.de> a �crit:
> 
>> On Sun, 12 Feb 2012 22:19:08 +0100, Yannick Duch�ne (Hibou57) wrote:
>>
>>> Le Sun, 12 Feb 2012 20:53:16 +0100, J-P. Rosen <rosen@adalog.fr> a  
>>> �crit:
>>>> Nothing prevents you from
>>>> qualifying with a package name inside a use clause for that package!
>>>
>>> And conversely, nothing prevents one to Used a package designed for "use
>>> unfriendly".
>>
>> Conflicting names do.
> Of course, but nothing is absolute. Conflict can be all solved with prefix  
> or renaming.

1. If you could meaningfully rename it afterwards, why would not you name
it properly at the original declaration point?

2. Renaming is sufficiently broken in Ada, e.g. types cannot be renamed;
often renaming is not renaming but an equivalent object declaration instead
etc.

-- 
Regards,
Dmitry A. Kazakov
http://www.dmitry-kazakov.de

Re: Convention for naming of packages

[Yannick Duchêne (Hibou57)]

Le Mon, 13 Feb 2012 12:03:05 +0100, Dmitry A. Kazakov  
<mailbox@dmitry-kazakov.de> a écrit:
> 1. If you could meaningfully rename it afterwards, why would not you name
> it properly at the original declaration point?
The context is then not the same.

The most trivial example comes with Instance_Type. That's not the same  
when it stands for the main type of a package and when it is used along  
with many other types. Can be compared with generics in some way.

When something is named after its role, then the context matters, and the  
name may change with the context.

-- 
“Syntactic sugar causes cancer of the semi-colons.” [1]
“Structured Programming supports the law of the excluded muddle.” [1]
[1]: Epigrams on Programming — Alan J. — P. Yale University

Re: Convention for naming of packages

[Yannick Duchêne (Hibou57)]

Le Mon, 13 Feb 2012 12:57:48 +0100, Yannick Duchêne (Hibou57)  
<yannick_duchene@yahoo.fr> a écrit:
> The most trivial example comes with Instance_Type. That's not the same  
> when it stands for the main type of a package […]

Before I forget this question: in a similar manner, I am seeking for a  
generic name for procedure or function, when the main purpose of a package  
is a procedure or function. I though Apply and Eval or Get of Value could  
be option (Value being my current favorite for pure functions), but I'm  
not clearly fine with any one of these.

I know seeking for this kind of genericity is a disputable target, but  
that's something in which I believe (kind of experiment at least) and I  
will simply drop it anyway, if I don't feel OK with any name.

Just telling here in case anyone already did the same.

-- 
“Syntactic sugar causes cancer of the semi-colons.” [1]
“Structured Programming supports the law of the excluded muddle.” [1]
[1]: Epigrams on Programming — Alan J. — P. Yale University

Re: Convention for naming of packages

[Dmitry A. Kazakov]

On Mon, 13 Feb 2012 12:57:48 +0100, Yannick Duch�ne (Hibou57) wrote:

> Le Mon, 13 Feb 2012 12:03:05 +0100, Dmitry A. Kazakov  
> <mailbox@dmitry-kazakov.de> a �crit:
>> 1. If you could meaningfully rename it afterwards, why would not you name
>> it properly at the original declaration point?
> The context is then not the same.
> 
> The most trivial example comes with Instance_Type. That's not the same  
> when it stands for the main type of a package and when it is used along  
> with many other types. Can be compared with generics in some way.

This is a good example of a bad name, which tells nothing about the thing.
Of course it is legitimate to use one bad name in place of other bad name.

> When something is named after its role, then the context matters, and the  
> name may change with the context.

No. The user's context cannot matter to the role, as it contradicts to all
principles of reuse, information hiding and good design. Even less the
declaration context is appropriate to influence the name.

-- 
Regards,
Dmitry A. Kazakov
http://www.dmitry-kazakov.de

Re: Convention for naming of packages

[Yannick Duchêne (Hibou57)]

Le Mon, 13 Feb 2012 14:01:16 +0100, Dmitry A. Kazakov  
<mailbox@dmitry-kazakov.de> a écrit:
> No. The user's context cannot matter to the role, as it contradicts to  
> all
> principles of reuse, information hiding and good design. Even less the
> declaration context is appropriate to influence the name.
On the contrary, that's exactly what an abstract name do.

Abstract name does not mean random name.

-- 
“Syntactic sugar causes cancer of the semi-colons.” [1]
“Structured Programming supports the law of the excluded muddle.” [1]
[1]: Epigrams on Programming — Alan J. — P. Yale University

Re: Convention for naming of packages

[Dmitry A. Kazakov]

On Mon, 13 Feb 2012 13:30:17 +0100, Yannick Duchêne (Hibou57) wrote:

> Le Mon, 13 Feb 2012 12:57:48 +0100, Yannick Duchêne (Hibou57)  
> <yannick_duchene@yahoo.fr> a écrit:
>> The most trivial example comes with Instance_Type. That's not the same  
>> when it stands for the main type of a package […]
> 
> Before I forget this question: in a similar manner, I am seeking for a  
> generic name for procedure or function, when the main purpose of a package  
> is a procedure or function. I though Apply and Eval or Get of Value could  
> be option (Value being my current favorite for pure functions), but I'm  
> not clearly fine with any one of these.

These are the result of Ada lacking means to declare user-defined
dereference/delegation operations. I know no good schema for naming these.
Ada 2012 might show itself better in that respect eliminating need in
explicit naming of some of such operations.

-- 
Regards,
Dmitry A. Kazakov
http://www.dmitry-kazakov.de

Re: Convention for naming of packages

[Dmitry A. Kazakov]

On Mon, 13 Feb 2012 14:04:38 +0100, Yannick Duch�ne (Hibou57) wrote:

> Le Mon, 13 Feb 2012 14:01:16 +0100, Dmitry A. Kazakov  
> <mailbox@dmitry-kazakov.de> a �crit:
>> No. The user's context cannot matter to the role, as it contradicts to  all
>> principles of reuse, information hiding and good design. Even less the
>> declaration context is appropriate to influence the name.
> On the contrary, that's exactly what an abstract name do.

Abstract to what? In first place it should abstract the context of usage.
Does your name depend on where you are?

> Abstract name does not mean random name.

It means invariant to irrelevant (abstracted away) issues.

-- 
Regards,
Dmitry A. Kazakov
http://www.dmitry-kazakov.de

Re: Convention for naming of packages

[Yannick Duchêne (Hibou57)]

Le Mon, 13 Feb 2012 14:07:51 +0100, Dmitry A. Kazakov  
<mailbox@dmitry-kazakov.de> a écrit:
>> Before I forget this question: in a similar manner, I am seeking for a
>> generic name for procedure or function, when the main purpose of a  
>> package
>> is a procedure or function. I though Apply and Eval or Get of Value  
>> could
>> be option (Value being my current favorite for pure functions), but I'm
>> not clearly fine with any one of these.
>
> These are the result of Ada lacking means to declare user-defined
> dereference/delegation operations. I know no good schema for naming  
> these.
It may don't hurt to give examples if you tried some.

> Ada 2012 might show itself better in that respect eliminating need in
> explicit naming of some of such operations.
I don't see. What do you mean, concretely?


-- 
“Syntactic sugar causes cancer of the semi-colons.” [1]
“Structured Programming supports the law of the excluded muddle.” [1]
[1]: Epigrams on Programming — Alan J. — P. Yale University

Re: Convention for naming of packages

[Yannick Duchêne (Hibou57)]

Le Mon, 13 Feb 2012 14:19:58 +0100, Dmitry A. Kazakov  
<mailbox@dmitry-kazakov.de> a écrit:
>> On the contrary, that's exactly what an abstract name do.
>
> Abstract to what? In first place it should abstract the context of usage.
The role of something in the structure it belongs to, is not the same as  
the role it may be given in a use case.

Ex. A file may be a source, a destination, a backup support, a memory  
auxiliary, and so on. In the package defining the file, to me, the type is  
just the type of the thing defined by the package.

A package defines either, a domain, some relationships, a process, an  
object type (at least to me), possibly some other high level concepts too.  
Let talk about a package defining an object, to keep one single example.  
An object type has methods for creation; you name it Create, not  
Create_XXXX_Type. A type has an instance type, I name it Instance_Type,  
not XXXX_Type; similarly, if it's tagged, I will systematically define a  
Class_Type. Some type may be named Element_Type, because that is their  
role if the package defines a container object. That Element_Type may be a  
Symbol_Type in some contexts.

The role in a structure in not the same as the role given in a use‑case or  
larger structure.

The example with Element_Type which may be a Symbol_Type in some context,  
explains why I said this may be compared to genericity.

Static genericity seems adopted without too much objections in the “crowd”  
of Ada application authors.


> Does your name depend on where you are?
In formal terms, my name is not a name, it's an identifier (although not  
strictly unique in practice, as some name+surname pairs may be homonyms).

-- 
“Syntactic sugar causes cancer of the semi-colons.” [1]
“Structured Programming supports the law of the excluded muddle.” [1]
[1]: Epigrams on Programming — Alan J. — P. Yale University

Re: Convention for naming of packages

[Dmitry A. Kazakov]

On Mon, 13 Feb 2012 15:01:07 +0100, Yannick Duch�ne (Hibou57) wrote:

> Le Mon, 13 Feb 2012 14:07:51 +0100, Dmitry A. Kazakov  
> <mailbox@dmitry-kazakov.de> a �crit:
>>> Before I forget this question: in a similar manner, I am seeking for a
>>> generic name for procedure or function, when the main purpose of a  
>>> package
>>> is a procedure or function. I though Apply and Eval or Get of Value  
>>> could
>>> be option (Value being my current favorite for pure functions), but I'm
>>> not clearly fine with any one of these.
>>
>> These are the result of Ada lacking means to declare user-defined
>> dereference/delegation operations. I know no good schema for naming  
>> these.
> It may don't hurt to give examples if you tried some.

There is little to try: Get_Value or Value or Get. Not much choice.

>> Ada 2012 might show itself better in that respect eliminating need in
>> explicit naming of some of such operations.
> I don't see. What do you mean, concretely?

Ada 2012 has implicit dereference aspect which could potentially eliminate
stuff like Get_Value and Set_Value.

-- 
Regards,
Dmitry A. Kazakov
http://www.dmitry-kazakov.de

Re: Convention for naming of packages

[Yannick Duchêne (Hibou57)]

Le Mon, 13 Feb 2012 15:59:18 +0100, Dmitry A. Kazakov  
<mailbox@dmitry-kazakov.de> a écrit:
> Ada 2012 has implicit dereference aspect which could potentially  
> eliminate
> stuff like Get_Value and Set_Value.
Oh, I missed that. Which is the RM section concerned?


-- 
“Syntactic sugar causes cancer of the semi-colons.” [1]
“Structured Programming supports the law of the excluded muddle.” [1]
[1]: Epigrams on Programming — Alan J. — P. Yale University

Re: Convention for naming of packages

[Dmitry A. Kazakov]

On Mon, 13 Feb 2012 15:20:30 +0100, Yannick Duchêne (Hibou57) wrote:

> A package defines either, a domain, some relationships, a process, an  
> object type (at least to me), possibly some other high level concepts too.  
> Let talk about a package defining an object, to keep one single example.

Don't think that singletone is a good idea. In any case, its use is quite
marginal in Ada, if any.

> An object type has methods for creation;

A singletone may not have such method. Semantically, you should not be able
create a singletone explicitly.

> The example with Element_Type which may be a Symbol_Type in some context,  
> explains why I said this may be compared to genericity.
> 
> Static genericity seems adopted without too much objections in the “crowd”  
> of Ada application authors.

Static polymorphism is OK so long the semantics of overloaded entities is
same. The semantics of Element_Type is? Element + type? That looks far too
thin.

-- 
Regards,
Dmitry A. Kazakov
http://www.dmitry-kazakov.de

Re: Convention for naming of packages

[Dmitry A. Kazakov]

On Mon, 13 Feb 2012 16:05:26 +0100, Yannick Duch�ne (Hibou57) wrote:

> Le Mon, 13 Feb 2012 15:59:18 +0100, Dmitry A. Kazakov  
> <mailbox@dmitry-kazakov.de> a �crit:
>> Ada 2012 has implicit dereference aspect which could potentially  
>> eliminate
>> stuff like Get_Value and Set_Value.
> Oh, I missed that. Which is the RM section concerned?

4.1.5.

P.S. I didn't evaluate it. It is difficult to say how useful aspects are.
The relation to polymorphism (dynamic, static, ad-hoc), is unclear. Only
dynamic polymorphism is really useful for programming en large.

-- 
Regards,
Dmitry A. Kazakov
http://www.dmitry-kazakov.de

Re: Convention for naming of packages

[Yannick Duchêne (Hibou57)]

Le Mon, 13 Feb 2012 16:11:49 +0100, Dmitry A. Kazakov  
<mailbox@dmitry-kazakov.de> a écrit:

> On Mon, 13 Feb 2012 15:20:30 +0100, Yannick Duchêne (Hibou57) wrote:
>
>> A package defines either, a domain, some relationships, a process, an
>> object type (at least to me), possibly some other high level concepts  
>> too.
>> Let talk about a package defining an object, to keep one single example.
>
> Don't think that singletone is a good idea. In any case, its use is quite
> marginal in Ada, if any.
>
>> An object type has methods for creation;
>
> A singletone may not have such method. Semantically, you should not be  
> able
> create a singletone explicitly.

Seems my wording was unclear. I meant a package describing, specifying (by  
Package, I mean the interface, not the body) something. A package is not  
an instance of the object if discribes (when its purpose is to describe an  
object), it defines it. I you want to say it by mean of singleton, so I  
would see only one: an instance of a kind of meta‑class. The only  
instanciation provided by a package, is its body (when applicable), not  
the object it describes.


>> The example with Element_Type which may be a Symbol_Type in some  
>> context,
>> explains why I said this may be compared to genericity.
>>
>> Static genericity seems adopted without too much objections in the  
>> “crowd”
>> of Ada application authors.
>
> Static polymorphism is OK so long the semantics of overloaded entities is
> same. The semantics of Element_Type is? Element + type? That looks far  
> too thin.
The semantic may be thin, if the semantic is thin, then its specification  
cannot be said too much thin for the sole reason it's thin.

Element_Type would be Element + Type, as you say, and also what appears as  
the second parameter of an Add method. Its presence as the second  
parameter of Add defines what Element_Type is (not just its name “Element”  
and its Type status in the Ada source text).

This may be thin, while still enough and all if nothing more is expected.  
The name “Element” is an hint for the reader, a reminder of the main  
abstraction which applies to it.

-- 
“Syntactic sugar causes cancer of the semi-colons.” [1]
“Structured Programming supports the law of the excluded muddle.” [1]
[1]: Epigrams on Programming — Alan J. — P. Yale University

Re: Convention for naming of packages

[Dmitry A. Kazakov]

On Mon, 13 Feb 2012 17:24:12 +0100, Yannick Duchêne (Hibou57) wrote:

> Le Mon, 13 Feb 2012 16:11:49 +0100, Dmitry A. Kazakov  
> <mailbox@dmitry-kazakov.de> a écrit:
> 
>> On Mon, 13 Feb 2012 15:20:30 +0100, Yannick Duchêne (Hibou57) wrote:
>>
>>> An object type has methods for creation;
>>
>> A singletone may not have such method. Semantically, you should not be  
>> able create a singletone explicitly.
> 
> Seems my wording was unclear. I meant a package describing, specifying (by  
> Package, I mean the interface, not the body) something. A package is not  
> an instance of the object if discribes (when its purpose is to describe an  
> object), it defines it.

It is a quite uncommon use anyway. I mean to have a package of instances of
some types.

But certainly if that happens the instance always have meaningful names
rather than "Object". E.g.

package Units.Base is
   Current : constant Unit;
   Luminescence : constant Unit;
   Temperature : constant Unit;
   ...

I think that any thing worth a name can be named. If not, that is because
some language deficiency.

>>> The example with Element_Type which may be a Symbol_Type in some context,
>>> explains why I said this may be compared to genericity.
>>>
>>> Static genericity seems adopted without too much objections in the “crowd”
>>> of Ada application authors.
>>
>> Static polymorphism is OK so long the semantics of overloaded entities is
>> same. The semantics of Element_Type is? Element + type? That looks far  
>> too thin.

> The semantic may be thin, if the semantic is thin, then its specification  
> cannot be said too much thin for the sole reason it's thin.
> 
> Element_Type would be Element + Type, as you say, and also what appears as  
> the second parameter of an Add method. Its presence as the second  
> parameter of Add defines what Element_Type is (not just its name “Element”  
> and its Type status in the Ada source text).

It is a language deficiency here, namely the generics. If the type of the
class (of the container type) could be properly typed, you would not need
to have meaningless names in meaningless packages the only purpose of which
is meaningless instantiation.

But even with generics, it is another deficiency that the element type (or
the class of) cannot be asked from the container type it belongs to, as
well as the type of the index and the type of sets of indices.

Yes, I am aware of dangers of type inference. Anonymous access types was an
error. But T'Class was right. It is a very delicate balance each time. So
far, it seems to me that element and index types should be anonymous.

Anyway, outside the stuff caused by the generic plague, and
container-member-index relationships (record types belong here as well),
names can and shall be meaningful. 
 
-- 
Regards,
Dmitry A. Kazakov
http://www.dmitry-kazakov.de

Re: Convention for naming of packages

[Yannick Duchêne (Hibou57)]

Le Mon, 13 Feb 2012 18:19:16 +0100, Dmitry A. Kazakov  
<mailbox@dmitry-kazakov.de> a écrit:
> It is a quite uncommon use anyway. I mean to have a package of instances  
> of
> some types.
>
> But certainly if that happens the instance always have meaningful names
> rather than "Object". E.g.
>
> package Units.Base is
>    Current : constant Unit;
>    Luminescence : constant Unit;
>    Temperature : constant Unit;
>    ...
This is a good example, but still not a singleton, that's a specification,  
there is no need for an instantion here.

About package holding singleton really holding singleton, like say a Log  
package which would create a singleton file "Log.File" objct, I believe  
that's not good for re‑usability (ex. what about multiple task?). Better  
provide a type with a constructor, and if a file is to be shared between  
multiple "Log.Instance_Type" instance, then its up to the implementation  
to create allocate one and create association between the shared object  
and object created by users.

That's all small‑talks :-P

> I think that any thing worth a name can be named. If not, that is because
> some language deficiency.

I believe a language deficiency, if it really exist, always provide the  
filling of that deficiency first. I don't feel one here, even if I agree I  
may think the thing a different way with another language. A single thing  
is not a deficiency alone, it is a deficiency with respect to a whole. The  
whole seems rather Okay to me so far.

What lacks for me here, is some paper with in deep talks about naming  
convention in numerous ways. Most paper just talks about naming convention  
just as a quick overview. I see the deficiency here, not in the language  
(deficiency of culture of the language, not deficiency of the language).

>> The semantic may be thin, if the semantic is thin, then its  
>> specification
>> cannot be said too much thin for the sole reason it's thin.
>>
>> Element_Type would be Element + Type, as you say, and also what appears  
>> as
>> the second parameter of an Add method. Its presence as the second
>> parameter of Add defines what Element_Type is (not just its name  
>> “Element”
>> and its Type status in the Ada source text).
>
> It is a language deficiency here, namely the generics. If the type of the
> class (of the container type) could be properly typed, you would not need
> to have meaningless names in meaningless packages the only purpose of  
> which is meaningless instantiation.
I don't what kind of language construct you imagine, but I am pretty sure  
these construct would requires dedicated keywords somewhere, some keywords  
which would be the exact same as the names I am looking for.

Ada's reserved word "type", is not meaningless, it's an high level concept  
(so is obviously abstract). Or else I did not understand your words?

> But even with generics, it is another deficiency that the element type  
> (or
> the class of) cannot be asked from the container type it belongs to, as
> well as the type of the index and the type of sets of indices.
Seems you are wishing Introspection in Ada. Funny for someone who dislike  
languages which provides it ;-)

Will fall to the same comment as above anyway. Type would just play some  
of the roles of packages (not all roles, some roles), and you would need  
some way to refer to things. Here, you will be back to the need of some  
name to refer to it.

If a container type, named Container_Type can provide itself the type for  
its index. How can you refer to it, if not via some expression, like  
"Container_Type.Index_Type"?

Or else have you something different in mind? Could you write‑down a tiny  
example using pseudo‑code to make it clearer?

-- 
“Syntactic sugar causes cancer of the semi-colons.” [1]
“Structured Programming supports the law of the excluded muddle.” [1]
[1]: Epigrams on Programming — Alan J. — P. Yale University

Re: Convention for naming of packages

[Dmitry A. Kazakov]

On Mon, 13 Feb 2012 19:10:41 +0100, Yannick Duchêne (Hibou57) wrote:

> Le Mon, 13 Feb 2012 18:19:16 +0100, Dmitry A. Kazakov  
> <mailbox@dmitry-kazakov.de> a écrit:
>> It is a quite uncommon use anyway. I mean to have a package of instances of
>> some types.
>>
>> But certainly if that happens the instance always have meaningful names
>> rather than "Object". E.g.
>>
>> package Units.Base is
>>    Current : constant Unit;
>>    Luminescence : constant Unit;
>>    Temperature : constant Unit;
>>    ...
> This is a good example, but still not a singleton,

That was an example of singleton values.

> that's a specification, there is no need for an instantion here.

This one for singleton objects:

package Standard_IO is
   Input : File_Type;  -- Assuming File_Type limited
   Output : File_Type;
   Error : File_Type;

Here is an example for singleton type:

task Scheduler is
   ...

(Though singleton types are always suspicious for bad design)

> About package holding singleton really holding singleton, like say a Log  
> package which would create a singleton file "Log.File" objct, I believe  
> that's not good for re‑usability (ex. what about multiple task?). Better  
> provide a type with a constructor,

Constructor = constructor or constructor = constructing function? The
latter is bad design.

As for the example with log file, it is better not to expose it:

package Logging is
   type Category is mod ...;
   Warning : constant Category;
   Error : constant Category;
   Info : constant Category;
   Any : constant Category;
   ...
   procedure Log (Event : Category; Text : String; Stamp : Time := Clock);
   ...
end Logging;

> What lacks for me here, is some paper with in deep talks about naming  
> convention in numerous ways.

J-P provided one. He is one, whom opinion you can always trust (even if you
disagree).

>>> The semantic may be thin, if the semantic is thin, then its specification
>>> cannot be said too much thin for the sole reason it's thin.
>>>
>>> Element_Type would be Element + Type, as you say, and also what appears as
>>> the second parameter of an Add method. Its presence as the second
>>> parameter of Add defines what Element_Type is (not just its name “Element”
>>> and its Type status in the Ada source text).
>>
>> It is a language deficiency here, namely the generics. If the type of the
>> class (of the container type) could be properly typed, you would not need
>> to have meaningless names in meaningless packages the only purpose of  
>> which is meaningless instantiation.
> I don't what kind of language construct you imagine, but I am pretty sure  
> these construct would requires dedicated keywords somewhere, some keywords  
> which would be the exact same as the names I am looking for.

Class in T'Class is not a reserved word. Neither Unchecked_Access in
X'Unchecked_Access is. Some Ada's reserved words were promoted for no good
reason, but rather because of Ada 83 tradition.

>> But even with generics, it is another deficiency that the element type (or
>> the class of) cannot be asked from the container type it belongs to, as
>> well as the type of the index and the type of sets of indices.

> Seems you are wishing Introspection in Ada. Funny for someone who dislike  
> languages which provides it ;-)

As I said it is a delicate balance. You can have it neither all nominal nor
all inferred.

> If a container type, named Container_Type can provide itself the type for  
> its index. How can you refer to it, if not via some expression, like  
> "Container_Type.Index_Type"?

T'Index. Note that this is not an expression proper because in a statically
typed language the algebra of types is separated from the core (object)
language. The type and type-valued operations are not the first class
citizens. Types in Ada have a meta language with rudimentary expressions of
its own. Yes it should be extended a bit, but not too much. Otherwise you
could lose the property of being statically typed.

-- 
Regards,
Dmitry A. Kazakov
http://www.dmitry-kazakov.de

Re: Convention for naming of packages

[Yannick Duchêne (Hibou57)]

Le Mon, 13 Feb 2012 22:02:17 +0100, Dmitry A. Kazakov  
<mailbox@dmitry-kazakov.de> a écrit:
>>> package Units.Base is
>>>    Current : constant Unit;
>>>    Luminescence : constant Unit;
>>>    Temperature : constant Unit;
>>>    ...
>> This is a good example, but still not a singleton,
>
> That was an example of singleton values.
That's an example way to declare symbols. I feel singleton as constant are  
apart (I use this too). Interesting topic, but would drift from naming  
conventions.

>> that's a specification, there is no need for an instantion here.
>
> This one for singleton objects:
>
> package Standard_IO is
>    Input : File_Type;  -- Assuming File_Type limited
>    Output : File_Type;
>    Error : File_Type;
>
> Here is an example for singleton type:
Personally, I prefer functions instead of this (don't want to comment more  
on that, would drift from naming convention too).


>> About package holding singleton really holding singleton, like say a Log
>> package which would create a singleton file "Log.File" objct, I believe
>> that's not good for re‑usability (ex. what about multiple task?). Better
>> provide a type with a constructor,
>
> Constructor = constructor or constructor = constructing function? The
> latter is bad design.
I never get into trouble with this. If I am likely to get into troubles  
with it, I would like to know before it happens and have a chance to  
prevent it before, obviously. On the mean time, I'm not a big tagged type  
user, and feel to understand your objections to it, mainly applies to  
tagged types hierarchies. I would enjoy some pointers on the web on this  
topic. However, as long as I think "creation function", there are little  
risk I will get surprised with Ada's creation functions.

> As for the example with log file, it is better not to expose it:
>
> package Logging is
>    type Category is mod ...;
>    Warning : constant Category;
>    Error : constant Category;
>    Info : constant Category;
>    Any : constant Category;
>    ...
>    procedure Log (Event : Category; Text : String; Stamp : Time :=  
> Clock);
>    ...
> end Logging;

I agree (as a side not, I would also add a Source parameter to this :-P ).

>> What lacks for me here, is some paper with in deep talks about naming
>> convention in numerous ways.
>
> J-P provided one. He is one, whom opinion you can always trust (even if  
> you disagree).
I trust his paper, and read the one he pointed since long. As you probably  
noticed, I use the convention he pointed to, with just a tiny variation.  
Still does not cover enough of my concerns. And by the way, although I  
trust him, I don't necessarily have to always agree with him: a good  
practice is like a good spelling to me, the good spelling of a word  
depends on the language (a word well spelled in a language is no good in  
another language, what ever how much it is well spelled in its original  
language); similarly, a practice is likely to apply fine in a context  
where a set of other practices also applies. And this depend on the target  
and applications among others criteria.

Anyway, the paper he pointed to, although valuable, does not cover the  
questions I raised (but make me raise these questions in some way!). And I  
found no deeper papers on the web, except the ones from J.P. Rosen and  
some Quality & Style Guide for Ada (unfortunately, I don't adhere to most  
of the naming conventions from this Quality & Style Guides).

That's why I am experimenting during the opportunity of a short enough  
application, to not have to experiment later on a bigger one (would  
inevitably drives to hard disappointments).

>> If a container type, named Container_Type can provide itself the type  
>> for
>> its index. How can you refer to it, if not via some expression, like
>> "Container_Type.Index_Type"?
>
> T'Index. Note that this is not an expression proper because in a  
> statically
> typed language the algebra of types is separated from the core (object)
> language. The type and type-valued operations are not the first class
> citizens. Types in Ada have a meta language with rudimentary expressions  
> of
> its own. Yes it should be extended a bit, but not too much. Otherwise you
> could lose the property of being statically typed.
Yes, I was wrong when I used the word "expression" for that purpose.

T'Index vs T.Index may be an interesting topic, but an extrapolating one  
(as Ada is actually not this way) I don't want to go into now.


Well, I will go on with my "Run"/"Apply"/"Value"/"Evaluated"/"Get" and so  
on, with the hope I will end into something stable and satisfying with  
clear enough definitions.


-- 
“Syntactic sugar causes cancer of the semi-colons.” [1]
“Structured Programming supports the law of the excluded muddle.” [1]
[1]: Epigrams on Programming — Alan J. — P. Yale University

Re: Convention for naming of packages

[Yannick Duchêne (Hibou57)]

Le Sun, 12 Feb 2012 22:19:08 +0100, Yannick Duchêne (Hibou57)  
<yannick_duchene@yahoo.fr> a écrit:

> Le Sun, 12 Feb 2012 20:53:16 +0100, J-P. Rosen <rosen@adalog.fr> a écrit:
>> Nothing prevents you from
>> qualifying with a package name inside a use clause for that package!
>
> And conversely, nothing prevents one to Used a package designed for "use  
> unfriendly".

Also worth noting too, is this example from J.P. Rosen, in a paper  
explaining the OO Model of Ada 2005.

    with Ada.Text_IO; use Ada.Text_IO;
    with Calendar;
    package Persistance is
       type Services is interface;
       procedure Read
         (F : in File_Type;
          Item : out Services) is abstract;
       procedure Write
         (F : in File_Type;
          Item : in Services) is abstract;
       procedure Set_Expiration
         (To_Date : in Calendar.Time) is null;
    end Persistance;

Note how he Used Ada.Text_IO and just Withed Ada.Calendar.


-- 
“Syntactic sugar causes cancer of the semi-colons.” [1]
“Structured Programming supports the law of the excluded muddle.” [1]
[1]: Epigrams on Programming — Alan J. — P. Yale University

Re: Convention for naming of packages

[Yannick Duchêne (Hibou57)]

Le Tue, 14 Feb 2012 11:18:49 +0100, Yannick Duchêne (Hibou57)  
<yannick_duchene@yahoo.fr> a écrit:
> Also worth noting too, is this example from J.P. Rosen, in a paper  
> explaining the OO Model of Ada 2005.
>
> […]
>
> Note how he Used Ada.Text_IO and just Withed Ada.Calendar.

To note quote him erroneously, I also wanted to retrieve something first.  
Here is:

> A word of clarification first: the issue is not so much on wether
> using the use clause or not, than on using full names vs.short names.  
> […] Therefore, let's state the issue this way:
> "should full names be prefered to short names in the general
> case, knowing that the other convention is always possible
> for some special cases?"

Quoted from “In defense of the Use clause”.


-- 
“Syntactic sugar causes cancer of the semi-colons.” [1]
“Structured Programming supports the law of the excluded muddle.” [1]
[1]: Epigrams on Programming — Alan J. — P. Yale University

Re: Convention for naming of packages

[Dmitry A. Kazakov]

On Tue, 14 Feb 2012 10:08:37 +0100, Yannick Duchêne (Hibou57) wrote:

> Le Mon, 13 Feb 2012 22:02:17 +0100, Dmitry A. Kazakov  
> <mailbox@dmitry-kazakov.de> a écrit:

>>> About package holding singleton really holding singleton, like say a Log
>>> package which would create a singleton file "Log.File" objct, I believe
>>> that's not good for re‑usability (ex. what about multiple task?). Better
>>> provide a type with a constructor,
>>
>> Constructor = constructor or constructor = constructing function? The
>> latter is bad design.
> I never get into trouble with this. If I am likely to get into troubles  
> with it, I would like to know before it happens and have a chance to  
> prevent it before, obviously. On the mean time, I'm not a big tagged type  
> user, and feel to understand your objections to it, mainly applies to  
> tagged types hierarchies.

You may have a constructor for a singleton type because constructor cannot
be called explicitly and you cannot get rid of the constructor anyway. The
constructor is generated by the compiler (except for misuses of the pragma
Import (Ada, etc).

You shall never provide a constructing function (=factory) for singleton
types. A factory can be used several times, which you, as a package
provider, cannot control.

-- 
Regards,
Dmitry A. Kazakov
http://www.dmitry-kazakov.de

Re: Convention for naming of packages

[Yannick Duchêne (Hibou57)]

Le Tue, 14 Feb 2012 14:33:43 +0100, Dmitry A. Kazakov  
<mailbox@dmitry-kazakov.de> a écrit:
> You shall never provide a constructing function (=factory) for singleton
> types.
It's initialized at package elaboration. A function can still be used to  
return the kind of reference to the singleton. Lazy initialization may  
also be used, while always under controle of package elaboration, which  
will be the only one to set the initial value of the Inialized flag to  
False.

That said, I have a strange feeling I missed what you wanted to point. Did  
I?

> A factory can be used several times, which you, as a package
> provider, cannot control.
For a singleton? (yes, I finally must have missed something)


-- 
“Syntactic sugar causes cancer of the semi-colons.” [1]
“Structured Programming supports the law of the excluded muddle.” [1]
[1]: Epigrams on Programming — Alan J. — P. Yale University

Re: Convention for naming of packages

[Dmitry A. Kazakov]

On Tue, 14 Feb 2012 15:40:03 +0100, Yannick Duch�ne (Hibou57) wrote:

> Le Tue, 14 Feb 2012 14:33:43 +0100, Dmitry A. Kazakov  
> <mailbox@dmitry-kazakov.de> a �crit:
>> You shall never provide a constructing function (=factory) for singleton
>> types.
> It's initialized at package elaboration. A function can still be used to  
> return the kind of reference to the singleton.

But that is either not a constructing function or else not a singleton.

The former is because such a function would not return the target type.

The latter is if you consider access type as a stand-alone object. In that
case there could be more than one pointer objects, because you provided a
way to create them by giving a factory that returns a pointer.

> Lazy initialization may  
> also be used, while always under controle of package elaboration, which  
> will be the only one to set the initial value of the Inialized flag to  
> False.

You shall not expose this implementation detail in the interface.

> That said, I have a strange feeling I missed what you wanted to point. Did  
> I?

No a point, just an almost tautological statement: singleton shall have no
factory.

> (yes, I finally must have missed something)

Once you sorted out references from objects, public from private,
constructors from factory functions...

-- 
Regards,
Dmitry A. Kazakov
http://www.dmitry-kazakov.de

Re: Convention for naming of packages

[Yannick Duchêne (Hibou57)]

Le Mon, 13 Feb 2012 16:23:14 +0100, Dmitry A. Kazakov  
<mailbox@dmitry-kazakov.de> a écrit:

> On Mon, 13 Feb 2012 16:05:26 +0100, Yannick Duchêne (Hibou57) wrote:
>
>> Le Mon, 13 Feb 2012 15:59:18 +0100, Dmitry A. Kazakov
>> <mailbox@dmitry-kazakov.de> a écrit:
>>> Ada 2012 has implicit dereference aspect which could potentially
>>> eliminate
>>> stuff like Get_Value and Set_Value.
>> Oh, I missed that. Which is the RM section concerned?
>
> 4.1.5.
>
> P.S. I didn't evaluate it. It is difficult to say how useful aspects are.
> The relation to polymorphism (dynamic, static, ad-hoc), is unclear. Only
> dynamic polymorphism is really useful for programming en large.

By the way, Ada has another kind of delagation too, and since long: user  
defined storage pools.

(just added this comment for readers of this Usenet)


-- 
“Syntactic sugar causes cancer of the semi-colons.” [1]
“Structured Programming supports the law of the excluded muddle.” [1]
[1]: Epigrams on Programming — Alan J. — P. Yale University

Re: Convention for naming of packages

[Manuel Collado]

El 14/02/2012 12:51, Yannick Duch�ne (Hibou57) escribi�:
> Le Tue, 14 Feb 2012 11:18:49 +0100, Yannick Duch�ne (Hibou57)
> <yannick_duchene@yahoo.fr> a �crit:
>> Also worth noting too, is this example from J.P. Rosen, in a paper
>> explaining the OO Model of Ada 2005.
>> [�]
>> Note how he Used Ada.Text_IO and just Withed Ada.Calendar.
>
> To note quote him erroneously, I also wanted to retrieve something
> first. Here is:
>
>> A word of clarification first: the issue is not so much on wether
>> using the use clause or not, than on using full names vs.short names.
>> [�] Therefore, let's state the issue this way:
>> "should full names be prefered to short names in the general
>> case, knowing that the other convention is always possible
>> for some special cases?"
>
> Quoted from �In defense of the Use clause�.

I have a personal criteria about the choice of short/long identifiers:

    The length of an identifier should be proportional to the
    "distance" between uses of it and its definition.

Examples:
- The control variable of a for loop that span few lines can be really 
short (a single letter).
- The name of a frequently used external identifier can be relatively 
short (but meaningful) and used unqualified (use clause).
- The name of an infrequently used procedure defined in a particular 
module of a large library should be written in full (not abbreviated 
form) and always written fully qualified.

Hope this helps.
-- 
Manuel Collado - http://lml.ls.fi.upm.es/~mcollado

Re: Convention for naming of packages

[Simon Wright]

Manuel Collado <m.collado@domain.invalid> writes:

> I have a personal criteria about the choice of short/long identifiers:
>
>    The length of an identifier should be proportional to the
>    "distance" between uses of it and its definition.

Log of the scope in lines? Square root? (:ducks:)

I've adopted AdaCore's convention to use J instead of the (potentially
confusing) I in

   for J in Foo'Range loop

Re: Convention for naming of packages

[Niklas Holsti]

On 12-02-15 06:09 , Simon Wright wrote:
> Manuel Collado<m.collado@domain.invalid>  writes:
>
>> I have a personal criteria about the choice of short/long identifiers:
>>
>>     The length of an identifier should be proportional to the
>>     "distance" between uses of it and its definition.

I do the same, informally.

>
> Log of the scope in lines? Square root? (:ducks:)
>

It could be amusing to try to measure the correlation from sources. 
Perhaps a job for ASIS...

> I've adopted AdaCore's convention to use J instead of the (potentially
> confusing) I in
>
>     for J in Foo'Range loop

I tend to use the first letter of the array or type identifier:

    for E in Events_Type loop
       for L in Event_Description(E).Lines'Range loop
          Print (Event_Description(E).Lines(L)));
       end loop;
    end loop;

-- 
Niklas Holsti
Tidorum Ltd
niklas holsti tidorum fi
       .      @       .

Re: Convention for naming of packages

[J-P. Rosen]

Le 15/02/2012 05:09, Simon Wright a �crit :
> I've adopted AdaCore's convention to use J instead of the (potentially
> confusing) I in
> 
>    for J in Foo'Range loop

Recently, I adopted the convention to use the first letter of the array
(rather than the systematic I):

for T in Tab'range...
for A in Arr'range...
-- 
J-P. Rosen
Adalog
2 rue du Docteur Lombard, 92441 Issy-les-Moulineaux CEDEX
Tel: +33 1 45 29 21 52, Fax: +33 1 45 29 25 00
http://www.adalog.fr

Re: Convention for naming of packages

[Simon Wright]

"J-P. Rosen" <rosen@adalog.fr> writes:

> Le 15/02/2012 05:09, Simon Wright a écrit :
>> I've adopted AdaCore's convention to use J instead of the (potentially
>> confusing) I in
>> 
>>    for J in Foo'Range loop
>
> Recently, I adopted the convention to use the first letter of the array
> (rather than the systematic I):
>
> for T in Tab'range...
> for A in Arr'range...

I see your and Niklas's point, but it seems less strong in

   for J in 0 .. DOM.Core.Nodes.Length (Nodes) - 1 loop

(I already have an N in scope; I think I cut it a bit fine there, N's
scope is 110 lines in the particular instance)

Re: Convention for naming of packages

[Yannick Duchêne (Hibou57)]

Le Wed, 15 Feb 2012 07:13:03 +0100, Niklas Holsti  
<niklas.holsti@tidorum.invalid> a écrit:
> I tend to use the first letter of the array or type identifier:
>
>     for E in Events_Type loop
>        for L in Event_Description(E).Lines'Range loop
>           Print (Event_Description(E).Lines(L)));
>        end loop;
>     end loop;

Common practice indeed, worth noted explicitly, thanks for that. The same  
occurs also with S for a string parameter which is really just a string.

But the shorter a name is, the more likely conflict raises. When it  
occurs, using two letters identifier looks quicly hugly and drafty, so the  
best is then to fall‑back to regular short names.

-- 
“Syntactic sugar causes cancer of the semi-colons.” [1]
“Structured Programming supports the law of the excluded muddle.” [1]
[1]: Epigrams on Programming — Alan J. — P. Yale University

Re: Convention for naming of packages

[Yannick Duchêne (Hibou57)]

Le Wed, 15 Feb 2012 05:09:01 +0100, Simon Wright <simon@pushface.org> a  
écrit:
> I've adopted AdaCore's convention to use J instead of the (potentially
> confusing) I in

Font matters. We lack fonts with clear distinction between I and l as the  
ones we already have with clear distinction between 0 and O.

-- 
“Syntactic sugar causes cancer of the semi-colons.” [1]
“Structured Programming supports the law of the excluded muddle.” [1]
[1]: Epigrams on Programming — Alan J. — P. Yale University

Re: Convention for naming of packages

[Georg Bauhaus]

On 15.02.12 07:13, Niklas Holsti wrote:

> I tend to use the first letter of the array or type identifier:
> 
>    for E in Events_Type loop
>       for L in Event_Description(E).Lines'Range loop
>          Print (Event_Description(E).Lines(L)));
>       end loop;
>    end loop;

In a nested loop, I found it helps (me) if at least one of the loop
variables has a meaningful name (with "meaningful" to be defined in a
moment). There is one exception. In cases like matrix computations,
single letter variables are justified by readers' expectations, they
are thus meaningful identifiers (which gives a definition of
"meaningful").  This choice of identifiers happens to match Python
(pylint) conventions,


    for row in data:
        if any (non_zero (c) for c in row):
            result.append (sum (row))


The corresponding Ada, if using arrays, will IMHO warrant the
replacement of identifier "c" with a word, since the two occurrences
of C will look oddly out of style in Ada. (Before Ada 2012, there was
no syntactical notion of an iterator like that of current Python,
so the loops look more involved.) It doesn't hurt (me) that Col is
reminiscent of the full word "column"; the abbreviation seemed an
established convention, and, therefore

    for Row in Data'Range loop
       for Col in Data(Row)'Range loop
          if Non_Zero (Data(Row)(Col)) then
             Result.Append (Sum (Data (Row)));
             exit;
          end if;
       end loop;
    end loop;

When I wrote this using R in place of Row, and C in place of Col,
something odd happened. R made me think of "resistance"!
And this disturbing phenomenon, recursively, made me wonder about C ...

The arguments in favor of words in Ada hinge on the validity
of having readers' expectations guide the choice of identifiers.
The set of readers includes, admittedly, oneself.

Re: Convention for naming of packages

[Georg Bauhaus]

On 15.02.12 12:27, Yannick Duchêne (Hibou57) wrote:
> Le Wed, 15 Feb 2012 05:09:01 +0100, Simon Wright <simon@pushface.org> a écrit:
>> I've adopted AdaCore's convention to use J instead of the (potentially
>> confusing) I in
> 
> Font matters. We lack fonts with clear distinction between I and l as the ones
> we already have with clear distinction between 0 and O.

Which one of the zeros is the empty set ∅, and which one
is Danish ø? :-)

Motto: Don't use characters as symbols.

Re: Convention for naming of packages

[Georg Bauhaus]

On 15.02.12 12:39, Georg Bauhaus wrote:

> When I wrote this using R in place of Row, and C in place of Col,
> something odd happened. R made me think of "resistance"!
> And this disturbing phenomenon, recursively, made me wonder about C ...

I should add that R now reminds me of R, the statistics
program (GNU R). That's likely because we have been talking
about R here the day before yesterday...

Re: Convention for naming of packages

[Georg Bauhaus]

On 15.02.12 12:43, Georg Bauhaus wrote:

>> Font matters. We lack fonts with clear distinction between I and l as the ones
>> we already have with clear distinction between 0 and O.
> 
> Which one of the zeros is the empty set ∅, and which one
> is Danish ø? :-)

Darn, I forgot the diameter sign ⌀.

> Motto: Don't use characters as symbols.

Re: Convention for naming of packages

[Yannick Duchêne (Hibou57)]

Le Wed, 15 Feb 2012 13:33:08 +0100, Georg Bauhaus  
<rm.dash-bauhaus@futureapps.de> a écrit:

> On 15.02.12 12:43, Georg Bauhaus wrote:
>
>>> Font matters. We lack fonts with clear distinction between I and l as  
>>> the ones
>>> we already have with clear distinction between 0 and O.
>>
>> Which one of the zeros is the empty set ∅, and which one
>> is Danish ø? :-)
>
> Darn, I forgot the diameter sign ⌀.
>
>> Motto: Don't use characters as symbols.
Even symbols may be ambiguous. No one should be afraid of that. By the  
way, Unicode already provides some data on the different meanings of  
similar glyphs, and it does not suggest I vs l (or i vs j with some fonts)  
is the same as ∅ vs ø vs ⌀.

-- 
“Syntactic sugar causes cancer of the semi-colons.” [1]
“Structured Programming supports the law of the excluded muddle.” [1]
[1]: Epigrams on Programming — Alan J. — P. Yale University

Re: Convention for naming of packages

[Georg Bauhaus]

On 15.02.12 13:55, Yannick Duchêne (Hibou57) wrote:

>>> Motto: Don't use characters as symbols.
> Even symbols may be ambiguous. No one should be afraid of that.

If no one is afraid of ambiguity of identifiers, it will cause
errors sooner or later. Stupid errors. Pardon my French.

The readability of a program's source text obviously should not
depend on the choice of font if that font alone makes ambiguity
disappear. This kind of witchcraft is good for producing
nightmares for the programmers who need to fix the program.

> Unicode already provides some data on the different meanings of similar
> glyphs, and it does not suggest I vs l (or i vs j with some fonts) is the same
> as ∅ vs ø vs ⌀.

What do the Unicode data not not suggest? There is not three nots in
the preceding sentence.

Re: Convention for naming of packages

[Robert A Duff]

"J-P. Rosen" <rosen@adalog.fr> writes:

> Le 15/02/2012 05:09, Simon Wright a �crit :
>> I've adopted AdaCore's convention to use J instead of the (potentially
>> confusing) I in
>> 
>>    for J in Foo'Range loop
>
> Recently, I adopted the convention to use the first letter of the array
> (rather than the systematic I):
>
> for T in Tab'range...
> for A in Arr'range...

The issue of what to call the array index largely disappears
in Ada 2012, because you can loop through the array components,
rather than looping through the indices and then doing indexing.

- Bob

Re: Convention for naming of anything

[Yannick Duchêne (Hibou57)]

Le Thu, 09 Feb 2012 22:10:12 +0100, Yannick Duchêne (Hibou57)  
<yannick_duchene@yahoo.fr> a écrit:

> Hi people out there,

With functional representation in mind, when an object X' is a value  
derived from an object X in a recursive algorithm, which way do you name  
both X and X', as the Prime symbol is not allowed in Ada names?

  * X1 and X2 ?
  * X_1 and X_2 ?
  * X and X2 ?
  * X and X_2 ?
  * X and X_Prime ?
  * X and New_X ?
  * X and Derived_X ?

Note that the question may makes sense with loops too.

P.S. Changed thread's title into “Convention for naming of anything”.

-- 
“Syntactic sugar causes cancer of the semi-colons.” [1]
“Structured Programming supports the law of the excluded muddle.” [1]
[1]: Epigrams on Programming — Alan J. — P. Yale University

Re: Convention for naming of anything

[Yannick Duchêne (Hibou57)]

Le Thu, 16 Feb 2012 18:44:46 +0100, Yannick Duchêne (Hibou57)  
<yannick_duchene@yahoo.fr> a écrit:
> With functional representation in mind, when an object X' is a value  
> derived from an object X in a recursive algorithm, which way do you name  
> both X and X', as the Prime symbol is not allowed in Ada names?
>
>   * X1 and X2 ?
>   * X_1 and X_2 ?
>   * X and X2 ?
>   * X and X_2 ?
>   * X and X_Prime ?
>   * X and New_X ?
>   * X and Derived_X ?
>
> Note that the question may makes sense with loops too.

After some testing (writing then reading later), seems X and X2 is the  
best. Others looks too long compared to a Prime sign added to a name, and  
I feel X_2 looks ugly compared to X2. Two primes can then be written X3,  
three as X4 and so on.

That's personal feeling after dirty personal tests, comments about  
readability and understandability are still welcome (whether or not I  
agree with comments).


-- 
“Syntactic sugar causes cancer of the semi-colons.” [1]
“Structured Programming supports the law of the excluded muddle.” [1]
[1]: Epigrams on Programming — Alan J. — P. Yale University

Re: Convention for naming of anything

[Manuel Collado]

El 17/02/2012 20:46, Yannick Duchêne (Hibou57) escribió:
> Le Thu, 16 Feb 2012 18:44:46 +0100, Yannick Duchêne (Hibou57)
> <yannick_duchene@yahoo.fr> a écrit:
>> With functional representation in mind, when an object X' is a value
>> derived from an object X in a recursive algorithm, which way do you name
>> both X and X', as the Prime symbol is not allowed in Ada names?
>>
>> * X1 and X2 ?
>> * X_1 and X_2 ?
>> * X and X2 ?
>> * X and X_2 ?
>> * X and X_Prime ?
>> * X and New_X ?
>> * X and Derived_X ?
>>
>> Note that the question may makes sense with loops too.
>
> After some testing (writing then reading later), seems X and X2 is the
> best. Others looks too long compared to a Prime sign added to a name, and I
> feel X_2 looks ugly compared to X2. Two primes can then be written X3,
> three as X4 and so on.

At first glance, it seems more "natural":

X -> X
X' -> X1
X'' -> X2
etc.

>
> That's personal feeling after dirty personal tests, comments about
> readability and understandability are still welcome (whether or not I agree
> with comments).

-- 
Manuel Collado - http://lml.ls.fi.upm.es/~mcollado

Re: Convention for naming of anything

[Yannick Duchêne (Hibou57)]

Le Fri, 17 Feb 2012 22:53:49 +0100, Manuel Collado  
<m.collado@domain.invalid> a écrit:
> At first glance, it seems more "natural":
>
> X -> X
> X' -> X1
> X'' -> X2
> etc.

Good point indeed. While X2 may more clearly express this is a value of X  
derived from X, I agree this seems odd to have X' = X2, X'' = X3 and so on.

Will balance yours and mine. Thanks for the comment Manuel, will keep it  
in mind :-)

-- 
“Syntactic sugar causes cancer of the semi-colons.” [1]
“Structured Programming supports the law of the excluded muddle.” [1]
[1]: Epigrams on Programming — Alan J. — P. Yale University

Re: Convention for naming of anything

[Adam Beneschan]

On Feb 16, 9:44 am, Yannick Duchêne (Hibou57)
<yannick_duch...@yahoo.fr> wrote:
> Le Thu, 09 Feb 2012 22:10:12 +0100, Yannick Duchêne (Hibou57)
> <yannick_duch...@yahoo.fr> a écrit:
>
> > Hi people out there,
>
> With functional representation in mind, when an object X' is a value
> derived from an object X in a recursive algorithm, which way do you name
> both X and X', as the Prime symbol is not allowed in Ada names?
>
>   * X1 and X2 ?
>   * X_1 and X_2 ?
>   * X and X2 ?
>   * X and X_2 ?
>   * X and X_Prime ?
>   * X and New_X ?
>   * X and Derived_X ?

It looks like Unicode characters 02B9 and 02CA are both allowed in
identifiers.  Maybe you could one of those as your prime symbol?

                         -- Adam

Re: Convention for naming of anything

[Yannick Duchêne (Hibou57)]

Le Sat, 18 Feb 2012 00:52:41 +0100, Adam Beneschan <adam@irvine.com> a  
écrit:
> It looks like Unicode characters 02B9 and 02CA are both allowed in
> identifiers.  Maybe you could one of those as your prime symbol?

I've just checked, U+02CA is an accent, U+02B9 is a prime (as a modifier  
letter, not a standalone glyph). At least GNAT reject it. Will check the  
RM tomorrow (if ever GNAT is wrong).

Thanks for the point anyway, Adam.

-- 
“Syntactic sugar causes cancer of the semi-colons.” [1]
“Structured Programming supports the law of the excluded muddle.” [1]
[1]: Epigrams on Programming — Alan J. — P. Yale University

Re: Convention for naming of anything

[Yannick Duchêne (Hibou57)]

Le Sat, 18 Feb 2012 01:24:40 +0100, Yannick Duchêne (Hibou57)  
<yannick_duchene@yahoo.fr> a écrit:
> I've just checked, U+02CA is an accent, U+02B9 is a prime (as a modifier  
> letter, not a standalone glyph). At least GNAT reject it. Will check the  
> RM tomorrow (if ever GNAT is wrong).

No, GNAT is right, and I was wrong. Xʹ is OK and just requires to pass  
“-gnatiw -gnatW8” options to GNAT.

“-gnatiw”: allows character code out of ASCII in names.
“-gnatW8”: tell GNAT the source file is UTF-8 encoded.

“-gnatW8” works alone, but I feel its safer to use “-gnatiw -gnatW8”, to  
be more explicite.

Xʹ looks very similar to X' (attribute, type qualification), although the  
compiler will probably help to catch it. This depends on font too.

Xˊ is far less similar to X', but does not really stands for prime, it  
precisely is “Modifier Letter Acute Accent”. But don't bother, as the  
effective meaning is clear.


-- 
“Syntactic sugar causes cancer of the semi-colons.” [1]
“Structured Programming supports the law of the excluded muddle.” [1]
[1]: Epigrams on Programming — Alan J. — P. Yale University

Re: Convention for naming of anything

[Georg Bauhaus]

On 16.02.12 18:44, Yannick Duchêne (Hibou57) wrote:
> Le Thu, 09 Feb 2012 22:10:12 +0100, Yannick Duchêne (Hibou57) <yannick_duchene@yahoo.fr> a écrit:
>
>> Hi people out there,
>
> With functional representation in mind, when an object X' is a value derived from an object X in a recursive algorithm, which way do you name both X and X', as the Prime symbol is not allowed in Ada names?
>
> * X1 and X2 ?
> * X_1 and X_2 ?
> * X and X2 ?
> * X and X_2 ?
> * X and X_Prime ?
> * X and New_X ?
> * X and Derived_X ?

XX for x', XS for lists.

If both a letter with prime and a letter with plural s occur
in the same function, I'd choose a different prefix letter
for either.

Re: Convention for naming of anything

[Yannick Duchêne (Hibou57)]

Le Sat, 18 Feb 2012 12:32:40 +0100, Georg Bauhaus  
<rm.dash-bauhaus@futureapps.de> a écrit:

> On 16.02.12 18:44, Yannick Duchêne (Hibou57) wrote:
>> Le Thu, 09 Feb 2012 22:10:12 +0100, Yannick Duchêne (Hibou57)  
>> <yannick_duchene@yahoo.fr> a écrit:
>>
>>> Hi people out there,
>>
>> With functional representation in mind, when an object X' is a value  
>> derived from an object X in a recursive algorithm, which way do you  
>> name both X and X', as the Prime symbol is not allowed in Ada names?
>>
>> * X1 and X2 ?
>> * X_1 and X_2 ?
>> * X and X2 ?
>> * X and X_2 ?
>> * X and X_Prime ?
>> * X and New_X ?
>> * X and Derived_X ?
>
> XX for x', XS for lists.

XS seems Okay for lists, while it may conflict with package names if you  
use plural for these too.

XX seems Okay for X', except when X is a longer name.

> If both a letter with prime and a letter with plural s occur
> in the same function, I'd choose a different prefix letter
> for either.

Right, but then, there is typically something like Head and Tail in the  
place, which does not use the plural. So this does not may not necessarily  
be an issue.


-- 
“Syntactic sugar causes cancer of the semi-colons.” [1]
“Structured Programming supports the law of the excluded muddle.” [1]
[1]: Epigrams on Programming — Alan J. — P. Yale University

Re: Convention for naming of anything

[BrianG]

On 02/17/2012 07:50 PM, Yannick Duchêne (Hibou57) wrote:
> Le Sat, 18 Feb 2012 01:24:40 +0100, Yannick Duchêne (Hibou57)
> <yannick_duchene@yahoo.fr> a écrit:
>> I've just checked, U+02CA is an accent, U+02B9 is a prime (as a
>> modifier letter, not a standalone glyph). At least GNAT reject it.
>> Will check the RM tomorrow (if ever GNAT is wrong).
>
> No, GNAT is right, and I was wrong. Xʹ is OK and just requires to pass
> “-gnatiw -gnatW8” options to GNAT.
>
> “-gnatiw”: allows character code out of ASCII in names.
> “-gnatW8”: tell GNAT the source file is UTF-8 encoded.
>
> “-gnatW8” works alone, but I feel its safer to use “-gnatiw -gnatW8”, to
> be more explicite.
>
> Xʹ looks very similar to X' (attribute, type qualification), although
> the compiler will probably help to catch it. This depends on font too.
>
> Xˊ is far less similar to X', but does not really stands for prime, it
> precisely is “Modifier Letter Acute Accent”. But don't bother, as the
> effective meaning is clear.
>
>
Just don't use a name like XʹFirst :-)  What about Xʹs for plural?

-- 
---
BrianG
000
@[Google's email domain]
.com

Re: Convention for naming of anything

[Simon Wright]

BrianG <me@null.email> writes:

> What about Xʹs for plural?

No, no!

http://en.wikipedia.org/wiki/Apostrophe#Superfluous_apostrophes_.28.22greengrocers.27_apostrophes.22.29

Re: Convention for naming of anything

[Phil Clayton]

On Feb 16, 5:44 pm, Yannick Duchêne (Hibou57)
<yannick_duch...@yahoo.fr> wrote:
> With functional representation in mind, when an object X' is a value
> derived from an object X in a recursive algorithm, which way do you name
> both X and X', as the Prime symbol is not allowed in Ada names?

To refer to before and after values of a variable in e.g. a
postcondition, the convention of suffixing a subscript-zero to denote
the before value is fairly common in formal methods texts, e.g. the
classic "Programming from Specifications":
http://www.cs.ox.ac.uk/publications/books/PfS/
So, for example, the postcondition
  X = X₀ + 1
says that the value of X is increased by 1.  Perhaps an ASCII
equivalent would be
  X = X_0 + 1

I've come across exactly this conflict with primes in the past.  The
Ada verification tool, DAZ - built on ProofPower, see
http://www.lemma-one.com/ProofPower/index/
- would have ideally used a prime to denote an after value because
that is the convention of the Z notation, the language used to express
pre- and postconditions of Ada statements.  Instead it uses a
subscript-zero for the before value, like in Programming from
Specifications, on which it was based.

Phil

Re: Convention for naming of anything

[Yannick Duchêne (Hibou57)]

Le Sun, 19 Feb 2012 19:07:15 +0100, Phil Clayton  
<phil.clayton@lineone.net> a écrit:
> To refer to before and after values of a variable in e.g. a
> postcondition, the convention of suffixing a subscript-zero to denote
> the before value is fairly common in formal methods texts, e.g. the
> classic "Programming from Specifications":
> http://www.cs.ox.ac.uk/publications/books/PfS/
> So, for example, the postcondition
>   X = X₀ + 1
> says that the value of X is increased by 1.  Perhaps an ASCII
> equivalent would be
>   X = X_0 + 1

Prior side note: I’ve checked GNAT reject it, the ₀, with a message  
“invalid wide character in identifier”, and this time, that's not due to  
missing compiler options. Will really need to check the RM for these  
characters, so my comments may not not relevant.

X₀ or X_0 Could be an option if everything was formal in a given  
application. But when a specification is expected to be exposed with a  
classic look, this would imply giving subprograms argument names like X₀  
or X_0, as the “value before” is often from the subprogram parameters, and  
this wouldn't look as expected.

May be OK or not, depending on the overall style of an application.

But you gave me the idea X₁, X₂, X₃ could be alternatives to Xʹ or Xˊ,  
more distinctive, except it may make readers think they are list indexes  
or polynomial indexes…

Hint: ₀ is U+2080, ₁ is U+2081, and so on, up to ₉. Use of a character  
palette is probably recommended to help.


> http://www.cs.ox.ac.uk/publications/books/PfS/
> […]
> I've come across exactly this conflict with primes in the past.  The
> Ada verification tool, DAZ - built on ProofPower, see
> http://www.lemma-one.com/ProofPower/index/

Cool links, especially the former :-) Thanks

-- 
“Syntactic sugar causes cancer of the semi-colons.” [1]
“Structured Programming supports the law of the excluded muddle.” [1]
[1]: Epigrams on Programming — Alan J. — P. Yale University

Re: Convention for naming of anything

[Phil Clayton]

On Feb 19, 9:53 pm, Yannick Duchêne (Hibou57)
<yannick_duch...@yahoo.fr> wrote:
> Le Sun, 19 Feb 2012 19:07:15 +0100, Phil Clayton
> <phil.clay...@lineone.net> a écrit:
>
> > To refer to before and after values of a variable in e.g. a
> > postcondition, the convention of suffixing a subscript-zero to denote
> > the before value is fairly common in formal methods texts, e.g. the
> > classic "Programming from Specifications":
> >http://www.cs.ox.ac.uk/publications/books/PfS/
> > So, for example, the postcondition
> >   X = X₀ + 1
> > says that the value of X is increased by 1.  Perhaps an ASCII
> > equivalent would be
> >   X = X_0 + 1
>
> Prior side note: I’ve checked GNAT reject it, the ₀, with a message
> “invalid wide character in identifier”, and this time, that's not due to
> missing compiler options. Will really need to check the RM for these
> characters, so my comments may not not relevant.
>
> X₀ or X_0 Could be an option if everything was formal in a given
> application. But when a specification is expected to be exposed with a
> classic look, this would imply giving subprograms argument names like X₀
> or X_0, as the “value before” is often from the subprogram parameters, and
> this wouldn't look as expected.
>
> May be OK or not, depending on the overall style of an application.
>
> But you gave me the idea X₁, X₂, X₃ could be alternatives to Xʹ or Xˊ,
> more distinctive, except it may make readers think they are list indexes
> or polynomial indexes…
>
> Hint: ₀ is U+2080, ₁ is U+2081, and so on, up to ₉. Use of a character
> palette is probably recommended to help.

For before and after values, perhaps X_Old and X is worth considering
- then a postcondition e.g.
  X = X_Old + 1
would look more like it would for a program with a destructive update
of X:
  X = X'Old + 1


> >http://www.cs.ox.ac.uk/publications/books/PfS/
> > […]
> > I've come across exactly this conflict with primes in the past.  The
> > Ada verification tool, DAZ - built on ProofPower, see
> >http://www.lemma-one.com/ProofPower/index/
>
> Cool links, especially the former :-) Thanks

I don't know of anyone who actually derives programs for real as
described in PfS, but understanding the formal program development
methods helps one justify or explain a program - not necessarily a
formal argument but perhaps just better comments or more useful pre/
postconditions for run-time checking.

The DAZ tool checks PfS-style refinement arguments.  For example

    𝚫 X [ true, X = X₀ + 1 ]
  ⊑
    X := X + 1;

would produce a verification condition, which, if provable means that
the code is a valid implementation of the specification statement.  As
far as I know, DAZ was never used to develop programs (as described in
PfS) but to check already written programs against a specification by
'recovering' a refinement that gave provable verification conditions.
Then, verification conditions are shown to be provable by proving them
- the subject of theorem proving is yet another (fascinating) world.
Use of such tools tends to be limited to very critical systems.  In
fact, the analysis is very similar to compliance analysis with the
SPARK examiner, though the presentation is very different.

Phil

Re: Convention for naming of anything

[Randy Brukardt]

"Simon Wright" <simon@pushface.org> wrote in message 
news:m2r4xr13b2.fsf@pushface.org...
> BrianG <me@null.email> writes:
>
>> What about X's for plural?
>
> No, no!
>
> http://en.wikipedia.org/wiki/Apostrophe#Superfluous_apostrophes_.28.22greengrocers.27_apostrophes.22.29

Cool. I always thought that the 's plurals littering the comments in 
Janus/Ada (put there by others; I'm forever removing them) were illiteracy, 
but now I know that they are just archaic. Big difference. :-)

                                         Randy.