Re: Properties

Re: Properties

[Shark8]

On Dec 3, 1:16 am, Thomas Løcke <t...@ada-dk.org> wrote:
> It's of course less portable if you try to use it with the C shell.

C-shell -> irksome.
Having to migrate between C- and BASH-shells -> more irksome.
Sometimes using a different shell is not an option, as policy may
forbid such 'foreign'/non-approved software.

All shells must implement *-expansion, which means that it is close-to-
if-not-impossible to consistently/portability get the user's as-typed
command; granted that some shell or system may allow access to the as-
typed command but that would be making use of a feature not-portable
to other systems.

> If you don't like BASH, csh, zsh or Korn, then why not try
> something like BUSH:
>
> http://www.pegasoft.ca/bush.html
>
> It has a very Ada-like approach to shell scripting.

I'll have to give it a look.

>
> > The lack of types on files is another; old Macs had file-types down,
> > but *nix has nothing like that (nor does it have even the capability
> > for it, kernel-wise). {Windows has a [barely] workable file-extension/
> > association scheme -- analogous to an Ada map of (Key =>
> > File_Extention, Element =>  Application_Info).}
>
> The "file" command is your friend.
>
> It just works, and it doesn't depend on some shaky dot extension scheme.

Er, you missed my point that the "shaky dot extension scheme" is
barely workable.

Using a facility like the file command means that any file-type cannot
be determined w/o some sort of processing on the file itself [the
results may be saved/indexed for future use/performance]; the dot-
extension alleviates the need for this processing at the expense of
the unreliable extension (rather like a typecast in C); an actual
typed-file file-system has neither of these problems. Period.

>
> Simple file->program association is handled well in both KDE and Gnome.
> I suspect other desktop environments have similar systems in place. I
> don't think this is a job for the kernel.

Why not?
Isn't the job of the kernel to facilitate the use of the computer's
resources? If files are considered resources* then checking that they
are used properly cannot but be a part of the kernel's job.

*The *nix philosophy of "everything is a file" mandates that resources
(as a part of *everything*) are files.

> > One single hyphenated-word: man-pages.
> > The old DOS hypertext help was superior to man=pages, windows .HLP
> > file help was/is superior to man-pages, the OpenVMS help-system is
> > FAR, FAR more usable than man-pages.
>
> man rename
> man file
>
> What's wrong with that? It could not be any easier.
> It's easy, flexible and it works.

And here I thought the goal of the os was to make the machine usable
to human-users, not force them to act like machines.

The navigation system for man pages is, far far far subpar to any of
the help-systems I mentioned. In particular the DOS and VMS help
systems are both-text based and both can be easily navigated via
keyboard.

>
> > Error codes? In *nix programs may or may not use them... (some
> > programs return 0/success when errors were encountered) which makes
> > them less than useless.
>
> Hardly the fault of *nix, just as the abundance of horrible software
> for Windows cannot be blamed on Windows itself.

Actually it is the fault of unix, via C, which mandates that the main
subprogram return an error-code.

A better system would be one where programs are run and exceptions are
thrown on errors (the exception could be handled in-program or
propagated out). Something, conceptually similar to this:

-- In this system all program-entries have input and
-- output streams as parameters and a parameter which
-- contains the command as typed.
Type Program_Procedure is Access All Procedure(
    Input, Output : In Ada.Streams.Root_Stream_Type'Class;
    Command : String );

Procedure Run_Program( Program : in Program_Procedure;
                       Command : String ) is
 Input  : Access Ada.Streams.Root_Stream_Type'Class:=
         Get_Standard_Input;  -- Initializes to standard in.
 Output : Access Ada.Streams.Root_Stream_Type'Class:=
         Get_Standard_Output;  -- Initializes to standard out.
  -- Command is passed in from the command-interpreter.
begin

  Program.All( Input, Output, Command );

 exception
   --  handle 'normal' [predefined] exceptions...
  When Event: Others =>
   Ada.Text_IO.Put_line( '[' & Exception_Name(Event) & ']'
      & ':' & Character'Pos(9) & -- padding for the message
      Exception_Message(Event)
                       );
end Run_Program;

Since something in the vein of the above does not use error-codes
programmers cannot do something like:
int main()
{ get_list();
  operate_list(); // some error occurs here
  return SUCCESS;
}

The above undermines/invalidates the entire reasoning for requiring
main() to return an error-code, no?

Re: Properties

[Thomas Løcke]

On 2010-12-04 20:53, Shark8 wrote:
> C-shell ->  irksome.
> Having to migrate between C- and BASH-shells ->  more irksome.
> Sometimes using a different shell is not an option, as policy may
> forbid such 'foreign'/non-approved software.


My point was that one should not expect portability between shells, just
as one does not expect Java to compile using an Ada compiler.

Shells are mere tools. There are several to choose from. Users have
freedom to choose which of these they use, and which they ignore.

And if policy forbids using a specific shell, then that's no different
than a "no Ada" policy, which obviously makes it difficult to compile
an Ada program, but said policy does not detract from Ada as a 
programming language.

You can argue that you don't like the shells available to *nix, but that
is not the fault of *nix itself.


> Why not?
> Isn't the job of the kernel to facilitate the use of the computer's
> resources? If files are considered resources* then checking that they
> are used properly cannot but be a part of the kernel's job.
>
> *The *nix philosophy of "everything is a file" mandates that resources
> (as a part of *everything*) are files.


My view of a kernel is a piece of software that handles processes,
devices and memory. Systems calls are made available via an API of
sorts.

It does not include understanding what an .odf or .xsl file is. Such
associations belong, IMHO, in the chosen environment, be it KDE, BASH,
Fluxbox, XFCE, Gnome or what have you.

But then again, my understanding might be wrong. I will not claim to be
a kernel expert.


> And here I thought the goal of the os was to make the machine usable
> to human-users, not force them to act like machines.


There are excellent help facilities in KDE (and probably also in Gnome),
that extends beyond the man pages. These are easy to navigate using the
familiar point and click interface.

So the fact that there's a "raw" man system at the bottom of the ocean
does not mean that fancier interfaces does not exist closer to the
average computer user.

Personally I like the man system. Others may hate it with a passion, and
luckily they have something like the excellent KDE help system, which
encompasses the entire KDE environment (with pictures and everything)
_and_ a point and click interface to the man pages.

And everything is of course searchable using a simple and familiar
text field.

Also I do not feel like a machine when I'm using the man pages, just as
I don't feel like a machine when I'm using GPS. These are just tools
that help me get a job done, and as with every tool there's a certain
learning curve.


>>> Error codes? In *nix programs may or may not use them... (some
>>> programs return 0/success when errors were encountered) which makes
>>> them less than useless.
>>
>> Hardly the fault of *nix, just as the abundance of horrible software
>> for Windows cannot be blamed on Windows itself.
>
> Actually it is the fault of unix, via C, which mandates that the main
> subprogram return an error-code.


I agree with you that it's not a very good system, but it's still not
the fault of *nix that programmers make programs that return 0/success
when errors are encountered. That behavior is solely the responsibility
of the programmer(s).

No matter what you do, bad programmers will find ways to mess up a
system.


> A better system would be one where programs are run and exceptions are
> thrown on errors (the exception could be handled in-program or
> propagated out). Something, conceptually similar to this:


I agree. That would indeed be a better system.

-- 
Regards,
Thomas L�cke

Email: tl at ada-dk.org
Web: http:ada-dk.org
IRC nick: ThomasLocke

Properties

[Shark8]

I would like to submit a proposal for future Ada development; namely
"Properties." The purpose of this thread is to: 1) present the ideas
in general; 2) bounce ideas for the syntax off of fellow Ada users; 3)
work on presenting ideas to others; and  4) obtain the information to
submit the proposal.

1 -- Properties
Properties, as used here, are a typed member elements of either an
object or an interface displayed publicly which may be read-only,
write-only, or read-write and which may rename another member element
or a procedure/function.

In the case of interfaces they can greatly reduce the number of public
entities as all getters and setters may be hidden from the public view
and be 'collapsed' into reads and writes [respectively] to the
corresponding property.

2 -- Syntax Proposal
Part 1 -- Declaring a property
I propose reusing the SEPARATE keyword to mark properties.
Example:
Type Button is tagged record
  Text : Separate Access String;
end record;

Part 2 -- Specifying readability and writability
For declaring whether a property is read-only, write-only, or read-
write {The unreadable/unwritable state is useless and should be
excluded.} I propose using read-write as the default and specifying
read-only or write only via attributes "Readable" and/or "Writable".
Example:
For Property_Name'Writable Use False;
and
For Property_Name'Readable Use False;

If we default both Readable and Writable to true and allow only one to
be declared to be false then we achieve size-optimization in the code
for the common case of read-write and prohibit the unreadable/
unwritable properties.

Part 3 -- Specifying procedures or fields
I propose expanding/overloading the 'Read and 'Write attributes onto
the particular property of some type to specify its


Example:

Package Time is
SubType Hour is Natural Range 0..23;
SubType Minute is Natural 0..59;
Type Clock is tagged record
Internal_Time : record    ---  Some implementation/OS dependent time
                           Date : Integer;
                           M     : Minute; --- For some reason minutes
are stored separately on this os.
                       end record;
H : Separate Hour;
M : Separate Minute;
End record;

Private
 Function Get_Hour( Object : In Clock ) Return Hour;
 Function Get_Minute( Object : In Clock ) Return Minute;
 Procedure Set_Hour( Object : In Out Clock; Value : In Hour );
 Procedure Set_Minute( Object : In Out Clock; Value : In Minute );

For Clock.H'Read use Get_Hour;
For Clock.H'Write use Set_Hour;
For Clock.M'Read use Internal_Time.M;
For Clock.M'Write use Internal_Time.M;
End Time;


Part 4 -- Arrays
I propose that properties of an array-type should, when aliasing a
function or procedure, should require the forms of:
Function Get_Property_Value( Input : In Array_Type; Index_1 : in
Array_Index1_Type ) Return Array_Element_Type;
Procedure Set_Property_Value( Input : In Array_Type; Index_1 : in
Array_Index1_Type; Value In Array_Element_Type );

In the case of multidimensional arrays we would expand the parameter-
list accordingly, i.e. two dimensions, for getting, would yield a
function of the form:
Function Get_Property_Value( Input : In Array_Type; Index_1 : in
Array_Index1_Type; Index_2 : In Array_Index2_Type ) Return
Array_Element_Type;

Part 5 -- Public properties and private fields
Currently it is possible to hide the internals of a publicly used type
by forward-declaring the type in the public section of a specification
and completing the type in the private section.; in order to maintain
this ability, yet allow properties to be publicly accessed I propose
the use of the keywords SEPARATE & RECORD to allow the following:

Package GUIs is
Type Button is tagged separate record
  Top, Left, Height, Width : Separate Natural;  --- Only properties
are allowed to be declared here
end record;

Private
Type Button is Tagged record
 Caption : String;
 On_Click : Procedure( Item : In Out Button );
 -- ...
end record;

--...

End GUIs;

Re: Properties

[Dmitry A. Kazakov]

On Sat, 27 Nov 2010 19:21:55 -0800 (PST), Shark8 wrote:

> I would like to submit a proposal for future Ada development; namely
> "Properties."

Instead of properties I would prefer a full abstraction of record, array,
access, numeric types. E.g. you declare something as a record of certain
members and privately implement it as another record with other members or
as anything you like providing operations to read/write the publicly
declared members. I think it is a more simple and more natural to Ada model
than properties.

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

Re: Properties

[Shark8]

On Nov 28, 1:15 am, "Dmitry A. Kazakov" <mail...@dmitry-kazakov.de>
wrote:
> On Sat, 27 Nov 2010 19:21:55 -0800 (PST), Shark8 wrote:
> > I would like to submit a proposal for future Ada development; namely
> > "Properties."
>
> Instead of properties I would prefer a full abstraction of record, array,
> access, numeric types. E.g. you declare something as a record of certain
> members and privately implement it as another record with other members or
> as anything you like providing operations to read/write the publicly
> declared members. I think it is a more simple and more natural to Ada model
> than properties.
>
> --
> Regards,
> Dmitry A. Kazakovhttp://www.dmitry-kazakov.de

I'm not sure I see the difference between properties and your "full-
abstraction"; that is to say, aren't properties merely a way of
implementing that sort of abstraction (though with the additional
option of being read-only or write-only)?

Couldn't we have something similar to

Type Something is record
 S : String_Property;
end record;

--private or body

Default_State : Constant String:= "ANGRY KITTEN";
Stateful_Data : Not Null Access String:=
     New String'(Default_State);
For Something.S'Read Use Stateful_Data.All;

Procedure Set_Data( Input : In String ) is
begin
 if Input = "PLAYFUL KITTEN" OR Input = "RABID KITTEN" OR
    Input = "ANGRY KITTEN" OR Input = "DEAD KITTEN" then
   Stateful_Data := New String'( Input );
  end if;
end Set_Data;
For Something.S'Write use Set_Data;

Or am I completely misunderstanding your intent?
Also, do you have a possible syntax for these abstractions? {it may
help me fully-understand your position.}

Re: Properties

[Dmitry A. Kazakov]

On Sun, 28 Nov 2010 11:43:12 -0800 (PST), Shark8 wrote:

> On Nov 28, 1:15�am, "Dmitry A. Kazakov" <mail...@dmitry-kazakov.de>
> wrote:
>> On Sat, 27 Nov 2010 19:21:55 -0800 (PST), Shark8 wrote:
>>> I would like to submit a proposal for future Ada development; namely
>>> "Properties."
>>
>> Instead of properties I would prefer a full abstraction of record, array,
>> access, numeric types. E.g. you declare something as a record of certain
>> members and privately implement it as another record with other members or
>> as anything you like providing operations to read/write the publicly
>> declared members. I think it is a more simple and more natural to Ada model
>> than properties.
> 
> I'm not sure I see the difference between properties and your "full-
> abstraction"; that is to say, aren't properties merely a way of
> implementing that sort of abstraction (though with the additional
> option of being read-only or write-only)?

You want to expose something as a property, I want to hide the
implementation making the clients think of the thing in the terms I
defined.

> Couldn't we have something similar to
> 
> Type Something is record
>  S : String_Property;
> end record;

   type Something is private record
      S : String;
   end record;

or

   type Properly_Designed_Unbounded_String is
      private array (Positive range <>) of Character;

> Or am I completely misunderstanding your intent?
> Also, do you have a possible syntax for these abstractions? {it may
> help me fully-understand your position.}

I would use the word "private" to indicate that the implementation follows
in the private part, e.g.

   type Impossible_In_Ada is private array (Positive range <>) of T'Class;
private
   type Impossible_In_Ada is record
       ... -- The type is implemented as a record type
   end record;
   ... -- Overriding of the array interface operations required

Furthermore, I want record, array, access, number be interfaces. I.e. you
should be able to hang, for example, a record view on any type you wanted:

   type S is new T and record Foo : String end record with ...;

Note it is not an extension of S with a new member. It is adding an
interface making S appear to have the component Foo. The physical
implementation might ibe overriding the primitive operation ".Foo"
(getter/setter), or indeed an extension (implementation of a component by a
component).

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

Re: Properties

[Shark8]

On Nov 29, 1:34 am, "Dmitry A. Kazakov" <mail...@dmitry-kazakov.de>
wrote:
> On Sun, 28 Nov 2010 11:43:12 -0800 (PST), Shark8 wrote:
> > On Nov 28, 1:15 am, "Dmitry A. Kazakov" <mail...@dmitry-kazakov.de>
> > wrote:
> >> On Sat, 27 Nov 2010 19:21:55 -0800 (PST), Shark8 wrote:
> >>> I would like to submit a proposal for future Ada development; namely
> >>> "Properties."
>
> >> Instead of properties I would prefer a full abstraction of record, array,
> >> access, numeric types. E.g. you declare something as a record of certain
> >> members and privately implement it as another record with other members or
> >> as anything you like providing operations to read/write the publicly
> >> declared members. I think it is a more simple and more natural to Ada model
> >> than properties.
>
> > I'm not sure I see the difference between properties and your "full-
> > abstraction"; that is to say, aren't properties merely a way of
> > implementing that sort of abstraction (though with the additional
> > option of being read-only or write-only)?
>
> You want to expose something as a property, I want to hide the
> implementation making the clients think of the thing in the terms I
> defined.
>
> > Couldn't we have something similar to
>
> > Type Something is record
> >  S : String_Property;
> > end record;
>
>    type Something is private record
>       S : String;
>    end record;
>
> or
>
>    type Properly_Designed_Unbounded_String is
>       private array (Positive range <>) of Character;
>
> > Or am I completely misunderstanding your intent?
> > Also, do you have a possible syntax for these abstractions? {it may
> > help me fully-understand your position.}
>
> I would use the word "private" to indicate that the implementation follows
> in the private part, e.g.
>
>    type Impossible_In_Ada is private array (Positive range <>) of T'Class;
> private
>    type Impossible_In_Ada is record
>        ... -- The type is implemented as a record type
>    end record;
>    ... -- Overriding of the array interface operations required
>
> Furthermore, I want record, array, access, number be interfaces. I.e. you
> should be able to hang, for example, a record view on any type you wanted:
>
>    type S is new T and record Foo : String end record with ...;
>
> Note it is not an extension of S with a new member. It is adding an
> interface making S appear to have the component Foo. The physical
> implementation might ibe overriding the primitive operation ".Foo"
> (getter/setter), or indeed an extension (implementation of a component by a
> component).

[I think] I see! (I had to re-read it several times to get what you
are saying, and didn't want to post a reply until I did.)

It seems to me that your idea and mine are actually quite similar;
applying your proposal to internal components of a record virtually
yields my idea. (At least to a great degree.)

Re: Properties

[Georg Bauhaus]

On 11/28/10 4:21 AM, Shark8 wrote:
> I would like to submit a proposal for future Ada development; namely
> "Properties." The purpose of this thread is to: 1) present the ideas
> in general; 2) bounce ideas for the syntax off of fellow Ada users; 3)
> work on presenting ideas to others; and  4) obtain the information to
> submit the proposal.
>

Most of the suggestions seem to be about writing subprograms for
access to a single object component.
Just like @property in Objective-C is a shorthand for subprograms
generated by tools. (Or C#'s or Python's sugar equivalent.)

As such, an ASIS enabled Ada processor should be able to write
these without too much effort.

1 - What is the benefit other than not having to write subprograms?

Big win in standardized access to internal data of composite
types?  Or if that is: you can write additional code on assignment
to a component, yes, I can do that now, too, with not much
more effort.


2 - What if a property of an object needs to refer to two or more
of its components?

Say, a property's public view perhaps being much better presented
as a Point rather than as forcing two Coordinate properties (even
though Coordinates may have been chosen for internal representation
in a record).


3 - Is there anything in properties that helps with order of
component access?  (Just an idea.)


If Dmitry prefers giving the programmer control over basic
language features such as defining what record and array
should mean (within certain linguistic constraints), I'd prefer
the removal of get/set centric programming altogether: I'm always
the one to clean up after the practicalitists who just read and
assign record components all across landscapes of objects, using
get/set cotton candy.

As an alternative, I'd suggest an option to remove definitions
of full views of types from the specs.

Re: Properties

[Shark8]

On Nov 28, 5:37 am, Georg Bauhaus <rm-host.bauh...@maps.futureapps.de>
wrote:
> On 11/28/10 4:21 AM, Shark8 wrote:
>
> > I would like to submit a proposal for future Ada development; namely
> > "Properties." The purpose of this thread is to: 1) present the ideas
> > in general; 2) bounce ideas for the syntax off of fellow Ada users; 3)
> > work on presenting ideas to others; and  4) obtain the information to
> > submit the proposal.
>
> Most of the suggestions seem to be about writing subprograms for
> access to a single object component.
> Just like @property in Objective-C is a shorthand for subprograms
> generated by tools. (Or C#'s or Python's sugar equivalent.)
>
> As such, an ASIS enabled Ada processor should be able to write
> these without too much effort.

I've heard mention of ASIS somewhere, but was uninterested at the
time; perhaps I should take a look at it.

>
> 1 - What is the benefit other than not having to write subprograms?
>
> Big win in standardized access to internal data of composite
> types?  

I believe so. The example of a Clock {in C/C++} could include
validating the input (i.e. only executing the assignment when "((input
>= 0) || (input < 60))", though this is a poor example on an Ada forum
since we can just subtype out something with "Range 0..59")

The Delphi variant of Object Pascal allows the 'delegation' of
interface-implementation [or components thereof] to properties/fields
of some object. While not strictly necessary it does allow you to
avoid the clutter of writing numerous usually-one-line wrappers to
"redispatch" the incoming calls to that interface.

There was a problem I came across several months ago, while writing a
PostScript interpreter, where as per the PLRM PostScript's string-
objects didn't contain the string data themselves, but pointers to an
object that did. (Not just strings, but arrays/procedures as well,
this allows a subarray-object [say of the first to second-to-last
components] to be a more constricted view of the "superarray" & any
changes to its items impacts those of its parent.) I ended up using an
access to the 'data-object' in my array-objects which were, in turn,
referenced in the data object with the intention of having it so that
when the reference-list reached zero [in the data-object] the object
could "kill-itself." I don't remember if I got it to work absolutely
as intended, it was a side project that has been put on hold while I
finish my degree, though I do remember having to use 'Unchecked_Access
in the messy construct that I thought at the time may have been
alleviated with properties (esp array-properties). It probably would
have looked something like this:

Type String_Data_Object( String_Data : Access String ) is
         Limited Tagged; --Forward declared.

Type PS_String( Data_Object : Access String_Data_Object ) is
           New PostScript_Object with record
    Start, Stop : Positive; -- String'First/'Last equiv.
    The_String  : Separate String;
end record;
    For PS_String.The_String.Read Use
                 Data_Object.String_Data.All( Start..Stop );
    For PS_String.The_String.Write Use
                 Data_Object.String_Data.All( Start..Stop );

Type Reference_List is Array(Positive Range <>) of PS_String;
Type String_Data_Object( String_Data : Access String ) is
         Limited Tagged Record
   References : Access Reference_List;
end record;
Function Make_String( Input : String_Data_Object; Start_Index,
Stop_Index : Positive ) Return PS_String;
-- Creates the string and adds its ref to the ref list.

Hrm, maybe I didn't choose the design* as well as I could have, though
I was trying to follow the PLRM, but I think you can see what I was
trying for, no? *What's missing is a vector/list/map that holds
String_Data_Object objects and removes the entry when its reference
list reaches zero.

> 2 - What if a property of an object needs to refer to two or more
> of its components?
>
> Say, a property's public view perhaps being much better presented
> as a Point rather than as forcing two Coordinate properties (even
> though Coordinates may have been chosen for internal representation
> in a record).

That's kinda easy:
-- for referring to multiple fields.

Type Point is Record
 X, Y : Integer
End Record;

Type Point_3D is
 X, Y, Z : Integer;
 Parallel_Projected : Separate Point;
  For Parallel_Projected.X'Read Use X;
  For Parallel_Projected.Y'Read Use Y;
  For Parallel_Projected.X'Write Use X;
  For Parallel_Projected.Y'Write Use Y;
end record;

-- for referring to calculated fields
Package Geometry.Point is

Type Point is Record
 X, Y : Integer
End Record;

Type Angle Measure is mod 360; -- or some other appropriate
representation.

Type Point_3D is
 Radius : Positive;
 Theta, Phi : Angle_Measure;
 Parallel_Projected : Separate Point;
end record;

private
 Function Get_X( Input : Point_3D ) Return Integer;
 Procedure Set_X( Input : in out Point_3D; Value : Integer );
 --same getter/setter for y.
  For Parallel_Projected.X'Read Use Get_X;
  For Parallel_Projected.Y'Read Use Get_Y;
  For Parallel_Projected.X'Write Use Set_X;
  For Parallel_Projected.Y'Write Use Set_Y;

-- OR PERHAPS
 Function Get_XY( Input : Point_3D ) Return Point;
 Procedure Set_XY( Input : in out Point_3D; Value : Point );
 --same getter/setter for y.
  For Parallel_Projected'Read Use Get_XY;
  For Parallel_Projected'Write Use Set_XY;
end Geometry.Point;

> 3 - Is there anything in properties that helps with order of
> component access?  (Just an idea.)

I'm not sure I know what you mean by this... do you mean the order as
in how Ada automatically orders the internals of a record when piping
them to a stream?

> As an alternative, I'd suggest an option to remove definitions
> of full views of types from the specs.

Hm, I'm not sure I see what use that would be.
I see the usefulness of allowing additions to enumerations, supertypes
if you will, but I also see how horrible it would be to implement them
(especially while trying to maintain type safety).

Re: Properties

[Georg Bauhaus]

On 28.11.10 22:22, Shark8 wrote:
> It probably would
> have looked something like this:
> 
> Type String_Data_Object( String_Data : Access String ) is
>          Limited Tagged; --Forward declared.
> 
> Type PS_String( Data_Object : Access String_Data_Object ) is
>            New PostScript_Object with record
>     Start, Stop : Positive; -- String'First/'Last equiv.
>     The_String  : Separate String;
> end record;
>     For PS_String.The_String.Read Use
>                  Data_Object.String_Data.All( Start..Stop );
>     For PS_String.The_String.Write Use
>                  Data_Object.String_Data.All( Start..Stop );

To the extend I have understood the approach,
you can do this with current Ada. Just make
The_String aware of its surroundings (not sure
I got the String_Data_Object involved as should):

   type PS_String;

   type PostScript_String (Referred : access PS_String;
                           Capacity : Positive) is
      record
         Data : String (1 .. Capacity);
      end record;


   type PS_String( Data_Object : access String_Data_Object;
                   Capacity : Positive) is limited
        new PostScript_Object with record
           Start, Stop : Positive; -- String'First/'Last equiv.



           The_String  : PostScript_String (PS_String'Access, Capacity);
      end record;

Then you can define a user defined 'Write attribute
for PostScript_String that does use Start and Stop
from PS_String to select a range from the string's data:

  procedure Write_PostScript_String
     (Stream : access Ada.Streams.Root_Stream_Type'Class;
      Object : PostScript_String)
   is
      Link : PS_String renames Object.Referred.all; -- the surroundings
   begin
      String'Write(Stream, Object.Data (Link.Start .. Link.Stop));
   end Write_PostScript_String;



>> 2 - What if a property of an object needs to refer to two or more
>> of its components?
>>
>> Say, a property's public view perhaps being much better presented
>> as a Point rather than as forcing two Coordinate properties (even
>> though Coordinates may have been chosen for internal representation
>> in a record).
> 
> That's kinda easy:
> -- for referring to multiple fields.

I think I meant the other way around, as in the Get_XY
example:

> Type Point is Record
>  X, Y : Integer
> End Record;
> 
> Type Point_3D is
>  X, Y, Z : Integer;
>  Parallel_Projected : Separate Point;

   For Parallel_Projected'Read Use ???;

> end record;

Suppose clients of your private Point_3D should be able
to see a property whose computation (result is Point) involves
both components X and Y under the hood.  Call it the Shadow
property, maybe.

More generally, I might have

  type R is private;

  function Spatial_Needs (Item : R) return Area_N;

private
  type R is record
    X1, X2, ..., Xm : Distance;
    Y1, Y2, ..., Yn : Something;
    ...
  end record;

Spatial_Needs is computed from X1, X2, X5, X12, and
Z3 to Z6.  Will standardized properties help provide for this?



>> 3 - Is there anything in properties that helps with order of
>> component access?  (Just an idea.)
> 
> I'm not sure I know what you mean by this... do you mean the order as
> in how Ada automatically orders the internals of a record when piping
> them to a stream?

Something new, and probably not simple: the type's operations
can be called in a specific order only. For example, do not
call property p3 before both p1 and p2 have been set.


>> As an alternative, I'd suggest an option to remove definitions
>> of full views of types from the specs.
> 
> Hm, I'm not sure I see what use that would be.

Somewhat like the pointer-to-implementation approach.
The full type definition is in the body of a package
(or in some representation part of a package which
is separate from both the spec and the body), for example.
Every read/write of one or more components is done through
some primitive operation. A user of the type has no idea
what the component parts of an object might be.

Re: Properties

[Martin Krischik]

Am 28.11.2010, 13:37 Uhr, schrieb Georg Bauhaus  
<rm-host.bauhaus@maps.futureapps.de>:

> As such, an ASIS enabled Ada processor should be able to write
> these without too much effort.

Not from a readability point. The argument for properties is that they  
don't clutter your code. Imagine that when 'Image, 'Value etc. pp where  
purposed your solution was choosen and code generator would actually add  
the code for those functions into source. Would that not look hyper ugly.

On the other hand that "for Some_Type'Image use" was not added is a real  
shame.

Martin
-- 
Martin Krischik
mailto://krischik@users.sourceforge.net
https://sourceforge.net/users/krischik

Re: Properties

[Georg Bauhaus]

On 12/1/10 8:52 PM, Martin Krischik wrote:
> Am 28.11.2010, 13:37 Uhr, schrieb Georg Bauhaus <rm-host.bauhaus@maps.futureapps.de>:
>
>> As such, an ASIS enabled Ada processor should be able to write
>> these without too much effort.
>
> Not from a readability point. The argument for properties is that they don't clutter your code. Imagine that when 'Image, 'Value etc. pp where purposed your solution was choosen and code generator would actually add the code for those functions into source. Would that not look hyper ugly.

I don't see how "automatic" get/set subprograms offer
software engineering advantage, even when they are terse
and semi-implicit and purport to avoid repetitive clutter.
It's the desire for the structural clutter that get/set
style really is that I find worrisome.

I'd like to mention an alternative language design idea
by Jeffrey Kingston for contrast with get/set style for
record components.  Whenever you invoke an operation of
an object, you create a new object.


Observe the programs resulting from get/set style. If they
are working, aren't they typically hiding spaghetti coding,
and privacy intrusion?

There certainly are ways of justifying programs in spite
of these qualities.  One is the post hoc fallacy:

"The get/set feature works, since this program works.
Therefore, to choose the get/set approach was right."

If the post hoc fallacy helps you as a person to get
along, fine.
If the post hoc fallacy helps bring customers to Ada,
that's fine for the vendors, I'd say.
Is it fine, though, with those companies in industry
needing to maintain software in order to stay competitive?


There is an everyone-does-it argument in favor of get/set.
I list some use cases.  Which ones do I miss?

- array like access to data structures.

The low level style thinking shines through.
Sometimes just right.  Worth a language change?

- GUI field updates

Forms have not really become "smarter", though, after 30 years
of writing form input logic.  (Oh, I see!  If we did the
software engineering thing and use good algorithms instead of
record component assignments bridled by get/set, still à la FORTRAN 66,
we will not make any more money by writing the same programs
over and over. The old ones still work... O.K., that's a point.)

- data base objects

For building a layer on top of relational records, OK.
For quick and dirty database scripting it might be enough
to update some field in some view (or table) through some setter.
As a design guide, get/set let me understand the many reports about
data bases whose handling requires intimate knowledge of
the details of every program and of every table.

- ...

OK, I'm biased as I'm usually the one who cleans up after
those who think that getting and setting is the best software
design principle.

Anyway, one can always add get/set to Ada since that eases
the transition from the other languages who have added
get/set in very recent years, too.   And exclude get/set
from SPARK for the more critical programs.


~

Re: Properties

[Georg Bauhaus]

On 12/1/10 8:52 PM, Martin Krischik wrote:

> On the other hand that "for Some_Type'Image use" was not added is a real shame.

A type based 'Image is not enough.  Different contexts
will require different kinds of 'Image.  We need a way
to pass context to a user defined 'Image in order
to adapt the string to where it is shown.  A simple
procedure bound to the type doesn't seem a sufficiently
flexible  abstraction.

The image of an object is best created from information
about the object, not by the object, IMHO.

Re: Properties

[Randy Brukardt]

"Shark8" <onewingedshark@gmail.com> wrote in message 
news:3b84c8e7-1a51-4a7c-9646-119f1fc51478@s4g2000yql.googlegroups.com...
>I would like to submit a proposal for future Ada development; namely
> "Properties." The purpose of this thread is to: 1) present the ideas
> in general; 2) bounce ideas for the syntax off of fellow Ada users; 3)
> work on presenting ideas to others; and  4) obtain the information to
> submit the proposal.

My initial reaction is that you have a solution in search of a problem. That 
always happens when someone presents their whiz-bang new feature first 
instead of explaining in detail what the problem with current Ada is. (Don't 
worry, it's happened to all of us at some point or another.)

So, if you want this to be taken seriously, you need to explain the problem 
in detail and then show how your proposal fixes/improves the problem.

Note that the ARG in general is looking for problems that are occurring in 
real code, and much less for solutions to those problems -- we're plenty 
creative in that regard! We've occassionally talked about the need to have 
more flexibility for components (the missing "constant" components come up 
once in a while), but I think it would be helpful to have more compelling 
examples of problems with the current facilities.

                                             Randy.

Re: Properties

[Charmed Snark]

Randy Brukardt expounded in news:id1l6f$2v8$1@munin.nbi.dk:

..
> Note that the ARG in general is looking for problems that
> are occurring in real code, and much less for solutions to
> those problems -- we're plenty creative in that regard!
> We've occassionally talked about the need to have more
> flexibility for components (the missing "constant"
> components come up once in a while), but I think it would
> be helpful to have more compelling examples of problems
> with the current facilities. 
> 
>                                              Randy.

It always worries me a bit to see so many requests for new 
features. I am sure the ARG is doing a good job safe guarding 
against feature creep, but it always worries me to see so much 
pressure in that direction.  IMO, the language is complex 
enough without introducing new features.

My own personal preference is to simply perfect what Ada is 
now, rather than adding blocks of new functionality. Of 
course, that "line" between "feature" and "fix" is not always 
black and white.

Just my $0.02 worth Canadian.

Snark.

Re: Properties

[Dmitry A. Kazakov]

On Tue, 30 Nov 2010 16:58:03 +0000 (UTC), Charmed Snark wrote:

> It always worries me a bit to see so many requests for new 
> features. I am sure the ARG is doing a good job safe guarding 
> against feature creep, but it always worries me to see so much 
> pressure in that direction.

Yes, because there are serious problems with using Ada. The wider Ada use
is, more requests come.

> IMO, the language is complex 
> enough without introducing new features.

It became complex because wrong features were adopted without reviewing the
language core for real problems. Ada could be much more simpler if it
stopped its drift in a wrong direction (actually multiple wrong directions
at once).

The main problem is that ARG considers individual features having no
strategic plan of Ada evolution. Only Ada 95 had a recognizable plan behind
it.

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

Re: Properties

[Warren]

Dmitry A. Kazakov expounded in
news:vkz3nbgxubt1$.11vfo4rwuzegd.dlg@40tude.net: 

> On Tue, 30 Nov 2010 16:58:03 +0000 (UTC), Warren
> wrote: 

>> IMO, the language is complex 
>> enough without introducing new features.
> 
> It became complex because wrong features were adopted
> without reviewing the language core for real problems. 

In fairness to those who participated, it is not trivial to 
forsee all of those "real problems". There was no doubt, no 
total agreement either for each standard. 

> Ada
> could be much more simpler if it stopped its drift in a
> wrong direction (actually multiple wrong directions at
> once). 

That was my thinking with the "new features" (multiple new 
directions).  Many new features seem to be addressing 
conveniences or to include something from other languages, but 
in an Ada sense.

> The main problem is that ARG considers individual features
> having no strategic plan of Ada evolution. Only Ada 95 had
> a recognizable plan behind it.

That is probably not totally fair. It is very good that they 
continually evaluate for improvements, rather than just allow 
the language to become stale.  I just hope that they don't get 
too liberal in the new language features department.

Where I do like seeing "new features" is in the standard 
library support. Whatever you can leverage in std libraries, 
shortens your routine development time and testing. It also 
makes Ada more out-of-the-box friendly for routine 
applications.

Warren

Re: Properties

[Dmitry A. Kazakov]

On Tue, 30 Nov 2010 20:27:12 +0000 (UTC), Warren wrote:

> Dmitry A. Kazakov expounded in
> news:vkz3nbgxubt1$.11vfo4rwuzegd.dlg@40tude.net: 
> 
>> On Tue, 30 Nov 2010 16:58:03 +0000 (UTC), Warren
>> wrote: 
> 
>>> IMO, the language is complex 
>>> enough without introducing new features.
>> 
>> It became complex because wrong features were adopted
>> without reviewing the language core for real problems. 
> 
> In fairness to those who participated, it is not trivial to 
> forsee all of those "real problems". There was no doubt, no 
> total agreement either for each standard. 

Yes, but when faced a "real problem," people usually agree. Many features
introduced in recent times address rather virtual problems.

>> The main problem is that ARG considers individual features
>> having no strategic plan of Ada evolution. Only Ada 95 had
>> a recognizable plan behind it.
> 
> That is probably not totally fair. It is very good that they 
> continually evaluate for improvements, rather than just allow 
> the language to become stale.

I don't object that. The point is that the criterion for adopting a feature
should not have been "it is too difficult," or "nobody asked for this."
There should be a master plan of what language we want Ada to become.

Ada 95 had a clear idea of bringing in OO in a safe, properly typed way,
not compromising performance. That was a great success, IMO.

>  I just hope that they don't get 
> too liberal in the new language features department.

Absolutely. My dream were for them to review the existing features and
rework the language core in order to unify them, making the language more
regular.

> Where I do like seeing "new features" is in the standard 
> library support. Whatever you can leverage in std libraries, 
> shortens your routine development time and testing. It also 
> makes Ada more out-of-the-box friendly for routine 
> applications.

That is true, but there is a danger that the language deficiencies would
influence the library design. We have an awful string processing library
because there is no class of string types. The container library based on
generics does not support array views. We will never be able to create a
standard GUI library (on the Ada level of safety and usability, I mean),
because types, tasks, protected objects don't play good with each other,
etc.

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

Re: Properties

[Warren]

Dmitry A. Kazakov expounded in
news:4pnv7nl4cdui$.1n28i7lqk4mek$.dlg@40tude.net: 

> On Tue, 30 Nov 2010 20:27:12 +0000 (UTC), Warren wrote:

> We have an
> awful string processing library because there is no class
> of string types. 

I think I have to agree there. It just seems like a heavy 
interface with this emphasis on character maps. 

> The container library based on generics
> does not support array views. 

There are definitely some challenges there. Some perhaps worth 
pursuing more.

> We will never be able to
> create a standard GUI library (on the Ada level of safety
> and usability, I mean), because types, tasks, protected
> objects don't play good with each other, etc.

That would seem to be the acid test. I haven't looked at 
GtkAda in years, but my early version opinion of it was that 
it seemed too much like bending a C library into Ada terms. A 
library designed in Ada from the ground up, would be better.

Part of the difficulty is that something like a GUI takes so 
much effort to develop. To get one developed to a "standard 
level" would likely require some level of sponsorship. 
Especially if you want to also attempt to make it platform 
neutral.

Warren

Re: Properties

[Dmitry A. Kazakov]

On Wed, 1 Dec 2010 15:21:39 +0000 (UTC), Warren wrote:

> I haven't looked at 
> GtkAda in years, but my early version opinion of it was that 
> it seemed too much like bending a C library into Ada terms.

Yes it is.

> A library designed in Ada from the ground up, would be better.

But we cannot, think about a type- and task-safe notification mechanism. I
have no idea how to do it without tagged tasks and protected objects. And I
don't want to instantiate a generic each time I need an event handler. And
I do want the compiler to check that all events are handled.

> Part of the difficulty is that something like a GUI takes so 
> much effort to develop. To get one developed to a "standard 
> level" would likely require some level of sponsorship. 
> Especially if you want to also attempt to make it platform 
> neutral.

The main problem is the interface of such a library. There are multiple
parallel hierarchies need to be handled: a hierarchy of widget types, a
hierarchy of widget containers, a hierarchy of event handlers (events are
filtered, propagated, swallowed, re-generated). At least the first and the
third must be statically checked, if we really want it be Ada. Very likely
that some composite widgets (the second hierarchy) should also be static.
Then there is a fourth hierarchy of widget properties. Some of the
properties are inherited from parent types, some are from parent
containers.

All these hierarchies must play with each other. Ada's type system is not
mature for this.

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

Re: Properties

[Warren]

Dmitry A. Kazakov expounded in
news:1k7367gtebsgm$.18auo6u3nfg34.dlg@40tude.net: 

> On Wed, 1 Dec 2010 15:21:39 +0000 (UTC), Warren wrote:
>> A library designed in Ada from the ground up, would be
>> better. 
> 
> But we cannot, think about a type- and task-safe
> notification mechanism. I have no idea how to do it without
> tagged tasks and protected objects. 

Perhaps the scope you have in mind is too large. Is it really 
necessary to have the GUI operate outside of one task? Leave 
the task handling to the application designer.

> And I don't want to
> instantiate a generic each time I need an event handler.

Agreed, but I don't believe we're stuck with that solution. 
All you need is procedure'Access for the callback.

> And I do want the compiler to check that all events are
> handled. 

Hmmm, more of a scope problem, I think.  Your requirements may 
be part of the problem.

>> Part of the difficulty is that something like a GUI takes
>> so much effort to develop. To get one developed to a
>> "standard level" would likely require some level of
>> sponsorship. Especially if you want to also attempt to
>> make it platform neutral.
> 
> The main problem is the interface of such a library. There
> are multiple parallel hierarchies need to be handled: a
> hierarchy of widget types, a hierarchy of widget
> containers, 

There are some challenges there, but I don't believe the fact 
that you need widget containers is a show stopper.

> a hierarchy of event handlers (events are 
> filtered, propagated, swallowed, re-generated). 

Not a problem with the callback approach, AFAICS.

> At least
> the first and the third must be statically checked, if we
> really want it be Ada. 

Callbacks (events) are dynamic by nature. I think the best you 
can hope for is that your event handler is the correct kind 
(of callback) and that any parameters match are of the correct 
type. Both areas that Ada excells at.

Asking for more than that, is perhaps a requirements problem.

> Very likely that some composite
> widgets (the second hierarchy) should also be static. 

I think tagged records are going to be the only real solution 
here, which is going to forgo static analysis.

I think a tagged solution is at least as good as a C++ 
solution, but better due to Ada strengths.  I think many folks 
could live with the dynamic nature of an Ada GUI library.

> Then
> there is a fourth hierarchy of widget properties. Some of
> the properties are inherited from parent types, some are
> from parent containers.
> 
> All these hierarchies must play with each other. Ada's type
> system is not mature for this.

Perhaps not mature enough for your requirements. 

It really comes down to what is "good enough" for a standard 
GUI library. Your requirements are desirable, but with 
existing software technologies, it doesn't appear practical 
AFAICS.

Are there any GUI systems implemented that are fully static 
checked?

Warren

Re: Properties

[Dmitry A. Kazakov]

On Wed, 1 Dec 2010 16:20:44 +0000 (UTC), Warren wrote:

> Dmitry A. Kazakov expounded in
> news:1k7367gtebsgm$.18auo6u3nfg34.dlg@40tude.net: 
> 
>> On Wed, 1 Dec 2010 15:21:39 +0000 (UTC), Warren wrote:
>>> A library designed in Ada from the ground up, would be
>>> better. 
>> 
>> But we cannot, think about a type- and task-safe
>> notification mechanism. I have no idea how to do it without
>> tagged tasks and protected objects. 
> 
> Perhaps the scope you have in mind is too large. Is it really 
> necessary to have the GUI operate outside of one task?

Affirmative. Consider an oscilloscope widget indicating real-time data.
Consider a debug window showing log messages from different tasks. The
worst thing of GTK is that it is not task-safe.

> Leave the task handling to the application designer.

Obtrusive and inefficient. I did it for GtkAda. It is quite uncomfortable
to use, and if you forget to route GTK requests to the main task, you get
sporadic crashes difficult to trace down, quite nasty.

>> And I don't want to
>> instantiate a generic each time I need an event handler.
> 
> Agreed, but I don't believe we're stuck with that solution. 
> All you need is procedure'Access for the callback.

No, because events have parameters and those must be typed. The standard
solution is that you instantiate a generic (and there is one for each
number of parameters and the results). That is extremely boring.

>> And I do want the compiler to check that all events are
>> handled. 
> 
> Hmmm, more of a scope problem, I think.  Your requirements may 
> be part of the problem.

But otherwise you would have to frantically search for the handler that
caught the event you expected the widget to propagate, just to learn that
the widget does not propagate it at all. Even better if you create an
events generator that covers all desktop with multiplying pop-up windows. I
hate this stuff.

>> At least
>> the first and the third must be statically checked, if we
>> really want it be Ada. 
> 
> Callbacks (events) are dynamic by nature. I think the best you 
> can hope for is that your event handler is the correct kind 
> (of callback) and that any parameters match are of the correct 
> type. Both areas that Ada excells at.
> 
> Asking for more than that, is perhaps a requirements problem.

Maybe, but I expect excellence from a standard library.

>> Very likely that some composite
>> widgets (the second hierarchy) should also be static. 
> 
> I think tagged records are going to be the only real solution 
> here, which is going to forgo static analysis.

Yes, this is my impression too.

> I think a tagged solution is at least as good as a C++ 
> solution, but better due to Ada strengths.  I think many folks 
> could live with the dynamic nature of an Ada GUI library.

BTW, most likely multiple inheritance will be needed. There is a huge
resistance to MI in Ada. I have no idea why, nobody managed to articulate
anything but prejudices and urban legends.

> It really comes down to what is "good enough" for a standard 
> GUI library. Your requirements are desirable, but with 
> existing software technologies, it doesn't appear practical 
> AFAICS.

They are practical at least in pushing Ada into a right direction. (I
guess, the reason why I agree with Randy most of the time is because he
maintains CLAW and I do the GtkAda contributions. This keeps us on the same
page.)
 
> Are there any GUI systems implemented that are fully static 
> checked?

I guess no.

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

Re: Properties

[Shark8]

>> Agreed, but I don't believe we're stuck with that solution.
>> All you need is procedure'Access for the callback.
>
>No, because events have parameters and those must be typed.
>The standard solution is that you instantiate a generic (and
>there is one for each number of parameters and the results).
>That is extremely boring.

Er, why not use OO/tagged-records for the events themselves and let
the base-handler have that as a parameter?

i.e. the handler would be an access to something like this:
Procedure On_Event( Object : in out : GUI_Object; --'Class?
                    Event  : In Base_Event'Class );

The Root for GUI-objects can say "On_Event(...) is null*" and allow
overriding for the components that DO use it. *A Null-body, not null-
access.

Further some mouse-event can extend the base-record with items such as
the position of the mouse.

Or is there something I'm missing?

Re: Properties

[Dmitry A. Kazakov]

On Wed, 1 Dec 2010 11:36:57 -0800 (PST), Shark8 wrote:

>>> Agreed, but I don't believe we're stuck with that solution.
>>> All you need is procedure'Access for the callback.
>>
>>No, because events have parameters and those must be typed.
>>The standard solution is that you instantiate a generic (and
>>there is one for each number of parameters and the results).
>>That is extremely boring.
> 
> Er, why not use OO/tagged-records for the events themselves and let
> the base-handler have that as a parameter?
> 
> i.e. the handler would be an access to something like this:
> Procedure On_Event( Object : in out : GUI_Object; --'Class?
>                     Event  : In Base_Event'Class );

Yes, event handlers are naturally doubly dispatching, this is why you were
not sure if On_Event should be a primitive operation of GUI_Object. It
should and it also should be one of the Base_Event. Unless you downcast in
the handler body.

Another issue with the above is that you will have to derive from
Base_Event somewhere this might be actually forbidden. On_Event is a
closure, which is tend to be a subprogram rather than a primitive
operation.

Event parameters usually marshaled, which might be difficult.

Yet another issue. Handlers actually connect the GUI object and the context
of the handler. The context, if not of a closure, then another GUI object.
E.g. normally one object catches events of another. In a GUI objects are
usually collected. So you need a mechanism which disconnects the handler if
any of the objects get destroyed. In any case it is probably triply
dispatching:

procedure On_Event
   (Emitter, Observer : in out : GUI_Object; Event  : In Base_Event);

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

Re: Properties

[Maciej Sobczak]

On Dec 1, 7:22 pm, "Dmitry A. Kazakov" <mail...@dmitry-kazakov.de>
wrote:

> > Perhaps the scope you have in mind is too large. Is it really
> > necessary to have the GUI operate outside of one task?
>
> Affirmative. Consider an oscilloscope widget indicating real-time data.
> Consider a debug window showing log messages from different tasks.

And how is this any different from, say, printing exactly the same log
messages on standard output? You do not expect different tasks to spit
their stuff directly to Ada.Text_IO and have it working properly,
right?
How do you solve this problem with Ada.Text_IO? Why the same solution
cannot apply to GUI?

I don't see any problem with single-threaded GUI, as long as there are
ways to communicate with it. It is the communication part that has to
be task-safe, not the GUI as a whole.

> > Leave the task handling to the application designer.
>
> Obtrusive and inefficient. I did it for GtkAda. It is quite uncomfortable
> to use, and if you forget to route GTK requests to the main task, you get
> sporadic crashes difficult to trace down, quite nasty.

I thought that Ada has enough tools to support arbitrary visibility
and access strategies. If you can "forget to route GTK requests to the
main task", then there is some package/typing problem in the code. Is
GUI to be blamed for this?

--
Maciej Sobczak * http://www.inspirel.com

Re: Properties

[Dmitry A. Kazakov]

On Wed, 1 Dec 2010 13:35:32 -0800 (PST), Maciej Sobczak wrote:

> On Dec 1, 7:22�pm, "Dmitry A. Kazakov" <mail...@dmitry-kazakov.de>
> wrote:
> 
>>> Perhaps the scope you have in mind is too large. Is it really
>>> necessary to have the GUI operate outside of one task?
>>
>> Affirmative. Consider an oscilloscope widget indicating real-time data.
>> Consider a debug window showing log messages from different tasks.
> 
> And how is this any different from, say, printing exactly the same log
> messages on standard output?

It is just same. You can safely call Put_Line from any task. But if you do
Set_Text in GTK, that will crash your program.

> How do you solve this problem with Ada.Text_IO? Why the same solution
> cannot apply to GUI?

I would like to have a similar solution, i.e. GUI things working without
switching the contexts.

>>> Leave the task handling to the application designer.
>>
>> Obtrusive and inefficient. I did it for GtkAda. It is quite uncomfortable
>> to use, and if you forget to route GTK requests to the main task, you get
>> sporadic crashes difficult to trace down, quite nasty.
> 
> I thought that Ada has enough tools to support arbitrary visibility
> and access strategies. If you can "forget to route GTK requests to the
> main task", then there is some package/typing problem in the code. Is
> GUI to be blamed for this?

On the context of the main GTK task you just call Set_Text. From an alien
task you need to instantiate a generic, or pass a closure, or override a
primitive operation of a query object and from the callback call to
Set_Text. The router calls the callback on the context of the main task.
You would not do this for each graphic operations. Instead you have a sort
of transactions, sets of operations executed in a group. This makes the
code look very different. As I said it is obtrusive.

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

Re: Properties

[Maciej Sobczak]

On Dec 1, 10:45 pm, "Dmitry A. Kazakov" <mail...@dmitry-kazakov.de>
wrote:

> > And how is this any different from, say, printing exactly the same log
> > messages on standard output?
>
> It is just same. You can safely call Put_Line from any task.

Wrong (AARM Annex A, 3.a):

"simultaneous calls to Text_IO.Put will work properly, so long as they
are going to two different files. On the other hand, simultaneous
output to the same file constitutes erroneous use of shared
variables."

You might argue that by analogy two tasks should be able to modify the
content of two distinct widgets, but that would be stretching
definitions, as the agreement of what is "distinct" in GUI is quite
arbitrary (ultimately, everything is a "child" of some uber-container,
like a display and shares, so nothing is really distinct).

> But if you do
> Set_Text in GTK, that will crash your program.

You mean - that will lead to erroneous execution? So it is exactly the
same as with printing on standard output.

Why do you expect to get better guarantees from GUI than from stdout?

> > How do you solve this problem with Ada.Text_IO? Why the same solution
> > cannot apply to GUI?
>
> I would like to have a similar solution, i.e. GUI things working without
> switching the contexts.

"Switching the contexts" is a technical term that relates to some
platform implementation details. I don't see why this is relevant to
GUIs, certainly not for performance reasons.

And again, this is the same as with standard output.

> On the context of the main GTK task you just call Set_Text. From an alien
> task you need to instantiate a generic, or pass a closure, or override a
> primitive operation of a query object and from the callback call to
> Set_Text. The router calls the callback on the context of the main task.
> You would not do this for each graphic operations. Instead you have a sort
> of transactions, sets of operations executed in a group. This makes the
> code look very different. As I said it is obtrusive.

Is this a GUI problem or a general language problem?
And is this really a proper design?

I have implemented a GUI application recently. Not in Ada, but the
general concepts are transferrable, as the tasking constraints were
the same.
The design involved a separate encapsulating "gui" package that
exposed subprograms for *logical* (ie. domain-level) manipulations of
the displayed content. The actual domain-oriented tasks of the
application were not concerned with "setting a new text value of some
widget", but rather with updating the domain-level information,
whatever it was. By doing this, I have achieved not only the physical
encapsulation of the display part and loose coupling between
functional modules (heck, I could change that to a web service without
touching anything else), which solved the tasking constraints, but
also raised the level of operation for the rest of the program. And I
don't consider it to be "obtrusive".

With this experience in mind, if you insist on GUI to be task-safe, I
think it is because you want the GUI library to support poor design
practices. Having arbitrary application tasks calling Set_Text
directly on some widget sounds like spaghetti.
And that's why I'm not convinced.

--
Maciej Sobczak * http://www.inspirel.com

Re: Properties

[Dmitry A. Kazakov]

On Thu, 2 Dec 2010 01:57:49 -0800 (PST), Maciej Sobczak wrote:

> On Dec 1, 10:45�pm, "Dmitry A. Kazakov" <mail...@dmitry-kazakov.de>
> wrote:
> 
>>> And how is this any different from, say, printing exactly the same log
>>> messages on standard output?
>>
>> It is just same. You can safely call Put_Line from any task.
> 
> Wrong (AARM Annex A, 3.a):
> 
> "simultaneous calls to Text_IO.Put will work properly, so long as they
> are going to two different files. On the other hand, simultaneous
> output to the same file constitutes erroneous use of shared
> variables."

OK, I let us consider only "reasonable" implementations of Put.

>> But if you do
>> Set_Text in GTK, that will crash your program.
> 
> You mean - that will lead to erroneous execution? So it is exactly the
> same as with printing on standard output.

I don't know if there is an Ada implementation working this way.

> Why do you expect to get better guarantees from GUI than from stdout?

Because in all Ada compilers I used so far this was safe.

>>> How do you solve this problem with Ada.Text_IO? Why the same solution
>>> cannot apply to GUI?
>>
>> I would like to have a similar solution, i.e. GUI things working without
>> switching the contexts.
> 
> "Switching the contexts" is a technical term that relates to some
> platform implementation details. I don't see why this is relevant to
> GUIs, certainly not for performance reasons.

A "reasonable" implementation of Text_IO queues I/O requests to some
internal or external task/driver. I want same sort of design for graphical
requests.

>> On the context of the main GTK task you just call Set_Text. From an alien
>> task you need to instantiate a generic, or pass a closure, or override a
>> primitive operation of a query object and from the callback call to
>> Set_Text. The router calls the callback on the context of the main task.
>> You would not do this for each graphic operations. Instead you have a sort
>> of transactions, sets of operations executed in a group. This makes the
>> code look very different. As I said it is obtrusive.
> 
> Is this a GUI problem or a general language problem?

It is a problem of the GTK library design.

> And is this really a proper design?

No.
 
> With this experience in mind, if you insist on GUI to be task-safe, I
> think it is because you want the GUI library to support poor design
> practices.

No, single thread GUI is bad design practice, that is when you block the
GUI when your dialog has a progress bar. A good design practice is that the
application does nothing functional on the context of the message loop. Any
action on this context must be a subject of design rules similar to ones
for the protected actions: non-blocking, atomic, short, semantically
instant.

> Having arbitrary application tasks calling Set_Text
> directly on some widget sounds like spaghetti.

On the contrary, spaghetti is poor man's multitasking implemented by
callbacks from timer messages on the context of the messages loop.

GUI is natively multitasking:

1. actions invoked by its controls are not instant: progress bar
2. some controls are active objects: animation widgets, visual effects,
tooltips, hovering etc
3. indication of asynchronous events and data: oscilloscope

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

Re: Properties

[Maciej Sobczak]

On Dec 2, 11:26 am, "Dmitry A. Kazakov" <mail...@dmitry-kazakov.de>
wrote:

> > Why do you expect to get better guarantees from GUI than from stdout?
>
> Because in all Ada compilers I used so far this was safe.

Safe? What is the benefit of safe if at the same time it's pointless?

Put ("My ");
Put ("name ");
Put ("is ");
Put_Line ("Maciej");

I have multiple tasks doing it. What is safe for you? For me "safe"
means "not corrupting the information" and the above sequence produces
a single piece of information.

There is no point in Text_IO to be internally synchronized, because
the granularity of synchronization can be defined only at the
application level. And once this is done, it is also sufficient and
then any internal synchronization is a waste.

Similar reasoning applies to GUIs. Imagine a graphical display of
multi-line log messages. There is no point for such GUI to be task
safe, because GUI has no understanding of the logical granularity of
what is being displayed.

> A "reasonable" implementation of Text_IO queues I/O requests to some
> internal or external task/driver. I want same sort of design for graphical
> requests.

Not necessarily. And there are lots of data structures that have to be
acted upon until you come close to the driver. These data structures
are vulnerable to corruption.

> GUI is natively multitasking:
>
> 1. actions invoked by its controls are not instant: progress bar
> 2. some controls are active objects: animation widgets, visual effects,
> tooltips, hovering etc
> 3. indication of asynchronous events and data: oscilloscope

How is that any different from standard output?
How is your oscilloscope any different from the "top" utility that
displays the state of many processes on the text terminal? It is not
different and therefore does not need any additional guarantees.

--
Maciej Sobczak * http://www.inspirel.com

Re: Properties

[Dmitry A. Kazakov]

On Thu, 2 Dec 2010 07:25:20 -0800 (PST), Maciej Sobczak wrote:

> On Dec 2, 11:26�am, "Dmitry A. Kazakov" <mail...@dmitry-kazakov.de>
> wrote:
> 
>>> Why do you expect to get better guarantees from GUI than from stdout?
>>
>> Because in all Ada compilers I used so far this was safe.
> 
> Safe? What is the benefit of safe if at the same time it's pointless?
> 
> Put ("My ");
> Put ("name ");
> Put ("is ");
> Put_Line ("Maciej");
> 
> I have multiple tasks doing it. What is safe for you?

1. It does not crash, the effect is defined
2. Put is atomic

> Imagine a graphical display of
> multi-line log messages. There is no point for such GUI to be task
> safe, because GUI has no understanding of the logical granularity of
> what is being displayed.

The point is that tasks putting messages into the trace widget should have
an ability to do this atomically independently on each other and the
interface should be a procedure call.

This is how the trace dialog window is implemented in the GtkAda
contributions. Its interface procedure Trace can be called from any Ada
task.

>> A "reasonable" implementation of Text_IO queues I/O requests to some
>> internal or external task/driver. I want same sort of design for graphical
>> requests.
> 
> Not necessarily. And there are lots of data structures that have to be
> acted upon until you come close to the driver. These data structures
> are vulnerable to corruption.

Only if designed poorly. The requirement to be task-safe means that
internally managed structures do not get corrupt when public interfaces are
used.

>> GUI is natively multitasking:
>>
>> 1. actions invoked by its controls are not instant: progress bar
>> 2. some controls are active objects: animation widgets, visual effects,
>> tooltips, hovering etc
>> 3. indication of asynchronous events and data: oscilloscope
> 
> How is that any different from standard output?

What is different/same from what?

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

Re: Properties

[Maciej Sobczak]

On Dec 2, 4:46 pm, "Dmitry A. Kazakov" <mail...@dmitry-kazakov.de>
wrote:

> > Safe? What is the benefit of safe if at the same time it's pointless?
>
> > Put ("My ");
> > Put ("name ");
> > Put ("is ");
> > Put_Line ("Maciej");
>
> > I have multiple tasks doing it. What is safe for you?
>
> 1. It does not crash, the effect is defined
> 2. Put is atomic

These are very weak requirements. The information was scrambled - the
mail packages arrived at the wrong address, the missile attacked the
wrong country and the doctor removed the liver of the wrong patient.
But nothing crashed. :-)

The reasons why it's pointless to internally synchronize GUI (or
Text_IO) are exactly the same as why it's pointless to synchronize
standard containers. It's the wrong level of granularity. You might
steer away from erroneous execution, but that does not in itself make
the program correct.

> >> GUI is natively multitasking:
>
> >> 1. actions invoked by its controls are not instant: progress bar
> >> 2. some controls are active objects: animation widgets, visual effects,
> >> tooltips, hovering etc
> >> 3. indication of asynchronous events and data: oscilloscope
>
> > How is that any different from standard output?
>
> What is different/same from what?

GUI from Text_IO.

I will try to answer myself: the difference is that Text_IO, as an
abstract stream, "feels" sequential by nature, whereas GUI, with its
2D layout (+ time dimension for content changes), makes concurrency
more appealing. Still, good design principles call for decoupling of
application logic and display (maybe with some intermediate "data
model" module?) and this decoupling blurs that distinction
significantly.

I'm not convinced that GUI should be task-safe. Supporting bad
application designs would be a wrong justification.

--
Maciej Sobczak * http://www.inspirel.com

Re: Properties

[Dmitry A. Kazakov]

On Thu, 2 Dec 2010 13:11:58 -0800 (PST), Maciej Sobczak wrote:

> I'm not convinced that GUI should be task-safe. Supporting bad
> application designs would be a wrong justification.

Well, if enjoy design a UI from single thread, that is your choice. But
count me out.

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

Re: Properties

[Randy Brukardt]

"Maciej Sobczak" <see.my.homepage@gmail.com> wrote in message 
news:2a3219cb-5793-4e5b-97aa-036da124ccba@y31g2000vbt.googlegroups.com...
...
>Still, good design principles call for decoupling of
>application logic and display (maybe with some intermediate "data
>model" module?) and this decoupling blurs that distinction
>significantly.

When it comes to GUI programming, this supposedly "good design principle" 
often doesn't make any sense.

For example, consider the series of SLED (Simple Little EDitor) examples in 
Claw. These show how a Notepad-like editor could be constructed using Claw. 
In this case, the "application logic" is editing of text (that is, handling 
insertions, deletions, cut, paste, etc.) If you strictly decouple that from 
the GUI, you then cannot use the prexisting controls that automatically 
provide that editing functionality. Several of the SLED versions show how 
that can be done, but the versions using the Rich_Edit control are a lot 
shorter and also a lot more powerful.

You will have that problem with any GUI program that manages text. And there 
are lots of other similar sorts of examples out there as well.

The problem, of course is that there is no such thing as a clear boundary 
between "application logic" and "display". The application logic has a 
strong effect on what can be displayed and how; similarly, what the user 
does with the GUI has a strong effect on what application logic is invoked. 
They can't be completely independent.

                                   Randy.

Re: Properties

[Maciej Sobczak]

On Dec 3, 5:43 am, "Randy Brukardt" <ra...@rrsoftware.com> wrote:

> When it comes to GUI programming, this supposedly "good design principle"
> often doesn't make any sense.
>
> For example, consider the series of SLED (Simple Little EDitor) examples in
> Claw. These show how a Notepad-like editor could be constructed using Claw.

Yes. There are two points, however:

1. Text editors (in particular text widgets) are both sources and
destinations of data. That is, they not only display something, they
also control the content by allowing the user to interact with it and
modify it. Thanks to this coupling of functionality (content control
and rendering) it makes sense to delegate the data structure
management to the same component as well. In this regard text widgets
are self-contained.
Unfortunately this reasoning has no applicability in a real-time
oscilloscope display, where such coupling does not occur - data source
is definitely separate from the rendering component so there is no
justification for coupling data model with widgets. On the contrary,
it makes perfect sense to decouple them - for starters, did I mention
several displays showing the same signal, but with different filtering
settings?

2. Your text-editing example has little relation to multitasking as a
general GUI feature. Of course one can imagine, for example, a
background spellchecker task or something in this area, but this is so
particular to the text editing domain that is hardly a justification
for requiring that the whole GUI framework must be task-safe.

--
Maciej Sobczak * http://www.inspirel.com

Re: Properties

[Randy Brukardt]

"Maciej Sobczak" <see.my.homepage@gmail.com> wrote in message 
news:0c899bff-c580-4b9f-9c94-b9226c089cde@j29g2000yqm.googlegroups.com...
On Dec 3, 5:43 am, "Randy Brukardt" <ra...@rrsoftware.com> wrote:

>> When it comes to GUI programming, this supposedly "good design principle"
>> often doesn't make any sense.
>>
>> For example, consider the series of SLED (Simple Little EDitor) examples 
>> in
>> Claw. These show how a Notepad-like editor could be constructed using 
>> Claw.
>
>Yes. There are two points, however:
>
>1. Text editors (in particular text widgets) are both sources and
>destinations of data. That is, they not only display something, they
>also control the content by allowing the user to interact with it and
>modify it. Thanks to this coupling of functionality (content control
>and rendering) it makes sense to delegate the data structure
>management to the same component as well. In this regard text widgets
>are self-contained.

Right. My point is that is the quite natural to have widgets like that. Text 
processing surely is not the only example.

>Unfortunately this reasoning has no applicability in a real-time
>oscilloscope display, where such coupling does not occur - data source
>is definitely separate from the rendering component so there is no
>justification for coupling data model with widgets. On the contrary,
>it makes perfect sense to decouple them - for starters, did I mention
>several displays showing the same signal, but with different filtering
>settings?

Possibly, but irrelevant. My point was that the "good design principle" is 
nowhere near absolute when it comes to GUIs. It makes just as much sense for 
some applications to have a control (widget) that does everything. I never 
claimed that you should *never* separate these things, only that claiming 
that a design that does not do so is somehow wrong is simplistic.

>2. Your text-editing example has little relation to multitasking as a
>general GUI feature. Of course one can imagine, for example, a
>background spellchecker task or something in this area, but this is so
>particular to the text editing domain that is hardly a justification
>for requiring that the whole GUI framework must be task-safe.

I don't believe that a general-purpose library should be telling people how 
to design their software. (This is very similar to the issue of almost never 
using access types in the interface -- the library should not be telling 
people how to do memory management.)

Indeed, I think that *any* library intended for general Ada usage ought to 
be task-safe to the extent that Ada.Text_IO and Ada.Containers are (access 
to different objects of the library by different tasks always work). That 
surely includes GUI libraries. That's all that Claw guarantees (that two 
tasks can access different controls/windows without interference). Libraries 
that don't meet those basic Ada requirements are very constraining, lead to 
the sort of problems that Dmitry mentioned (accidental use from the wrong 
task causes crashes and no clear indication of the mistake). Sometimes you 
have to use such things, but they then require wrapping in the Ada 
environment (unless you like debugging!).

                                    Randy.

Re: Properties

[Maciej Sobczak]

On Dec 3, 10:32 pm, "Randy Brukardt" <ra...@rrsoftware.com> wrote:

> Indeed, I think that *any* library intended for general Ada usage ought to
> be task-safe to the extent that Ada.Text_IO and Ada.Containers are (access
> to different objects of the library by different tasks always work).

What are different objects?

Certainly, AARM does not allow several tasks to access distinct
elements of the same container - because, well, even though the
elements are different, they belong to the same container.

> That
> surely includes GUI libraries.

...where almost everything is a child of some bigger container.

I understand what you try to convey (and to a large extent I agree
with it), but the analogy with containers does not work. By that
analogy it should be forbidden to access two controls of the same
window from different tasks without additional synchronization.

> That's all that Claw guarantees

I can imagine that it was very expensive to achieve.

--
Maciej Sobczak * http://www.inspirel.com

Re: Properties

[Shark8]

On Dec 4, 3:13 pm, Maciej Sobczak <see.my.homep...@gmail.com> wrote:
> ...where almost everything is a child of some bigger container.
>
> I understand what you try to convey (and to a large extent I agree
> with it), but the analogy with containers does not work. By that
> analogy it should be forbidden to access two controls of the same
> window from different tasks without additional synchronization.


Hm, wouldn't that be achievable by having each program/application
have its own Task for its GUI-handling? (Then, conceptually, all the
GUI components are owned by the single-container that is owned-by/
contained-within the Task, no?)

Re: Properties

[Randy Brukardt]

"Maciej Sobczak" <see.my.homepage@gmail.com> wrote in message 
news:acc754a9-4861-401a-a904-5f22efe852ac@z26g2000prf.googlegroups.com...
>On Dec 3, 10:32 pm, "Randy Brukardt" <ra...@rrsoftware.com> wrote:
>
>> Indeed, I think that *any* library intended for general Ada usage ought 
>> to
>> be task-safe to the extent that Ada.Text_IO and Ada.Containers are 
>> (access
>> to different objects of the library by different tasks always work).
>
>What are different objects?

The definition I use is the RM one: "non-overlapping" objects. Informally, 
these occur anytime you have parameters that are all distinct (none denoting 
parts of any of the others, taking into account renames and components, but 
generally not access values).

Practically, if the implementation is a bunch of objects interconnected by 
access types, the individual objects should be task-safe; if the objects are 
components of a larger object, then task safety is probably a mistake. But 
that's too implementation-oriented a definition to use.

There really can't a formal definition, unfortunately, because of the need 
to support portions of objects that aren't components but are managed as if 
they were. So we could argue about the exact definition all day.

> Certainly, AARM does not allow several tasks to access distinct
> elements of the same container - because, well, even though the
> elements are different, they belong to the same container.

In this case, the container is implicitly part of the cursor parameters. 
Note that I believe this is a design bug in the Ada.Containers; the 
container parameter ought to be explicit in all of these operations, 
including the reading ones. As they are defined currently, you would expect 
tasking to work on reading of different elements (and like Text_IO, it 
probably will work in practice).

>> That
>> surely includes GUI libraries.
>
>...where almost everything is a child of some bigger container.

Here I disagree. A GUI is a bunch of cooperating objects; the organization 
is a loosely coupled. Just because a button has a parent window doesn't mean 
that the button isn't an independent object (it could be moved to a 
different parent, for instance).

>I understand what you try to convey (and to a large extent I agree
>with it), but the analogy with containers does not work. By that
>analogy it should be forbidden to access two controls of the same
>window from different tasks without additional synchronization.

The problem here is that the containers specification is incorrect -- it 
doesn't properly expose the relationship with the container objects. Thus 
you are making the wrong analogy. (Given the specification given for reading 
container objects, task safety ought to be required. We didn't do that 
because we really meant it to work as if the container was explicitly given. 
This is also a problem in defining the behavior of the operations formally, 
and it prevents using prefix notation with these calls.)

If your hypothetical GUI never allowed accessing the controls of a window 
without mentioning the name of the parent window, then I would in fact agree 
with your implementation. But I'd still want task-safety between windows.

>> That's all that Claw guarantees

>I can imagine that it was very expensive to achieve.

It's not that hard to achieve, the problem is avoiding deadlock (since you 
have to be able to do operations in action routines). We would have had to 
do it in any case, given that we set up a separate task to handle messages. 
And, as noted above, the problems only really show up when you modify the 
"shape" of the GUI, adding or removing windows/controls. (Just directly 
reading or writing a control is not a problem.)

                                         Randy.

Re: Properties

[Simon Wright]

"Dmitry A. Kazakov" <mailbox@dmitry-kazakov.de> writes:

> On Thu, 2 Dec 2010 01:57:49 -0800 (PST), Maciej Sobczak wrote:
>
>> On Dec 1, 10:45 pm, "Dmitry A. Kazakov" <mail...@dmitry-kazakov.de>
>> wrote:
>> 
>>>> And how is this any different from, say, printing exactly the same log
>>>> messages on standard output?
>>>
>>> It is just same. You can safely call Put_Line from any task.
>> 
>> Wrong (AARM Annex A, 3.a):
>> 
>> "simultaneous calls to Text_IO.Put will work properly, so long as they
>> are going to two different files. On the other hand, simultaneous
>> output to the same file constitutes erroneous use of shared
>> variables."
>
> OK, I let us consider only "reasonable" implementations of Put.
>
>>> But if you do
>>> Set_Text in GTK, that will crash your program.
>> 
>> You mean - that will lead to erroneous execution? So it is exactly the
>> same as with printing on standard output.
>
> I don't know if there is an Ada implementation working this way.
>
>> Why do you expect to get better guarantees from GUI than from stdout?
>
> Because in all Ada compilers I used so far this was safe.

Then I don't think you can have used GNAT on VxWorks!

Re: Properties

[Dmitry A. Kazakov]

On Sat, 04 Dec 2010 17:43:30 +0000, Simon Wright wrote:

> "Dmitry A. Kazakov" <mailbox@dmitry-kazakov.de> writes:
> 
>> Because in all Ada compilers I used so far this was safe.
> 
> Then I don't think you can have used GNAT on VxWorks!

Hmm, I did and do GNAT Pro under VxWorks and noticed no problems.

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

Re: Properties

[Simon Wright]

"Dmitry A. Kazakov" <mailbox@dmitry-kazakov.de> writes:

> On Sat, 04 Dec 2010 17:43:30 +0000, Simon Wright wrote:
>
>> "Dmitry A. Kazakov" <mailbox@dmitry-kazakov.de> writes:
>> 
>>> Because in all Ada compilers I used so far this was safe.
>> 
>> Then I don't think you can have used GNAT on VxWorks!
>
> Hmm, I did and do GNAT Pro under VxWorks and noticed no problems.

Perhaps it's that we were using serial output?

We typically saw, with two tasks one outputting "aaaaaaa" and the other
"bbbbbbb" aaabababababbbaa ... etc

Simple enough to fix, of course.

Re: Properties

[Vinzent Hoefler]

Simon Wright wrote:

> "Dmitry A. Kazakov" <mailbox@dmitry-kazakov.de> writes:
>
>> On Sat, 04 Dec 2010 17:43:30 +0000, Simon Wright wrote:
>>
>>> "Dmitry A. Kazakov" <mailbox@dmitry-kazakov.de> writes:
>>>
>>>> Because in all Ada compilers I used so far this was safe.
>>>
>>> Then I don't think you can have used GNAT on VxWorks!
>>
>> Hmm, I did and do GNAT Pro under VxWorks and noticed no problems.
>
> Perhaps it's that we were using serial output?

Yes. That's it. :)


Vinzent.

-- 
Beaten by the odds since 1974.

Re: Properties

[Randy Brukardt]

"Maciej Sobczak" <see.my.homepage@gmail.com> wrote in message 
news:18768dde-5817-40b9-aaa1-03c620ad7187@i32g2000pri.googlegroups.com...
...
>You might argue that by analogy two tasks should be able to modify the
>content of two distinct widgets, but that would be stretching
>definitions, as the agreement of what is "distinct" in GUI is quite
>arbitrary (ultimately, everything is a "child" of some uber-container,
>like a display and shares, so nothing is really distinct).

I wouldn't *argue* that, I'd say it ought to be a fact. And it is in Claw...

I'd also suggest that the Standard screwed up with Text_IO. It should have 
some guarantee of sanity for writing to Standard_Output (no erroneous 
execution, but no requirements of ordering, either). In practice, this is 
the case; I'm not aware of any Windows hosted compiler that really does 
anything weird with these Put_Lines.

Robert Dewar has noted in the past that there are two kinds of erroreous 
execution: those where truely bad things will happen, and those that are 
erroneous in name, but in practice will work fine. Put_Line is a clear case 
of the latter. (Almost every Ada program is full of such cases, at least in 
the runtime.)
...
>I have implemented a GUI application recently. Not in Ada, but the
>general concepts are transferrable, as the tasking constraints were
>the same.
>The design involved a separate encapsulating "gui" package that
>exposed subprograms for *logical* (ie. domain-level) manipulations of
>the displayed content. The actual domain-oriented tasks of the
>application were not concerned with "setting a new text value of some
>widget", but rather with updating the domain-level information,
>whatever it was. By doing this, I have achieved not only the physical
>encapsulation of the display part and loose coupling between
>functional modules (heck, I could change that to a web service without
>touching anything else), which solved the tasking constraints, but
>also raised the level of operation for the rest of the program. And I
>don't consider it to be "obtrusive".

It's not "obtrusive", but what it is is serializing. Essentially, all of 
your tasks have to line up to get their data updated. Depending on how much 
data they need to display, that can effectively block them from getting 
anything significant done. (I've had problems like this with logging 
facilities in our web server.)

The result is that gauges don't update when input is being solicited, and 
sometimes the tasks themselves have to be blocked. It's usually better to 
push the serialization to the lowest level (with the shortest execution 
times), and that is deep within the GUI, not at the top level.

Now, I agree that most GUIs simply don't work with tasking; to get Claw to 
work with it requires lots of locks internally, since Windows doesn't like 
multiple threads doing I/O.

> With this experience in mind, if you insist on GUI to be task-safe, I
> think it is because you want the GUI library to support poor design
> practices. Having arbitrary application tasks calling Set_Text
> directly on some widget sounds like spaghetti.
> And that's why I'm not convinced.

Fair enough, although I don't really agree. First off all, all GUI code is 
spaghetti (it's the nature of event-driven programming); it doesn't really 
matter how you do it. (If there was a better alternative to using 
event-driven systems, I'd suggest using it, but it doesn't exist so far as I 
can tell.) Second of all, one design does not fit all. Sometimes you can use 
a central data repository as you previously suggested, but it doesn't work 
very well if there is a lot of data (because of the need to provide mutual 
exclusion on the data, along with the need to give the GUI priority access 
to that data) or if the processing time is short compared to the time to 
display the data.

I prefer that my GUI framework allow *any* reasonable design, rather than 
forcing one into abstractions that may very well just bloat up the code. In 
Claw, the usual approach for simple widgets is to put all of the 
functionality directly into the widget itself (including any tasking 
needed), rather than artifically separating the data creation from the 
display. (Most of the GUI programs I've worked on have had very little data 
processing associated with them; indeed, most of them have had completely 
separate GUI management programs from the actual server simply because 
automatically running programs have to run headless.)

In any case, tasking is a critical functionality for Ada, and one of the 
most important differences between it and most other languages. Deciding to 
prevent the use of that functionality for one sort of programming is like 
cutting off a foot...

                              Randy.


                        Randy.

Re: Properties

[Shark8]

On Dec 2, 2:57 am, Maciej Sobczak <see.my.homep...@gmail.com> wrote:
>
>Wrong (AARM Annex A, 3.a):
>
>"simultaneous calls to Text_IO.Put will work properly, so long
>as they are going to two different files. On the other hand,
>simultaneous output to the same file constitutes erroneous use
>of shared variables."
> --
> Maciej Sobczak *http://www.inspirel.com

Er, then does that mean that the following is wrong?

   Procedure Top is
      F : Ada.Text_IO.File_Type;
      I : Integer:= Positive'First;

      Task Type Writer(ID : Integer) is
      end Writer;

      Task Body Writer is
      begin -- Write the ID to the file.
         Ada.Text_IO.Put( Integer'Image(ID) );
      end Writer;

      Function Make_Task Return Writer is
      begin -- Make unique ID tasks.
         Return Result : Writer(ID => I) do
            I:= I + 1;
         end return;
      end Make_Task;

      Type Task_Array is Array (1..20) of Access Writer;
      Tasks : Task_Array:= ( 1..20 => New Writer'(Make_Task) );
   begin
      Null;      -- Everything happens by MAGIC!
   end top;

Re: Properties

[Randy Brukardt]

"Shark8" <onewingedshark@gmail.com> wrote in message 
news:18f98563-340c-4bc2-83e5-8d1187f92165@j19g2000prh.googlegroups.com...
On Dec 2, 2:57 am, Maciej Sobczak <see.my.homep...@gmail.com> wrote:
>>
>>Wrong (AARM Annex A, 3.a):
>>
>>"simultaneous calls to Text_IO.Put will work properly, so long
>>as they are going to two different files. On the other hand,
>>simultaneous output to the same file constitutes erroneous use
>>of shared variables."

>Er, then does that mean that the following is wrong?

Formally, yes. Practically, no. The underlying OS does not have problems 
with this sort of construct, nor do any Ada implementations that I am aware 
of. But of course there is no guarantee as to how the output will be 
presented.

                          Randy.

Re: Properties

[Jeffrey Carter]

On 12/02/2010 10:00 PM, Shark8 wrote:
>
>        Type Task_Array is Array (1..20) of Access Writer;
>        Tasks : Task_Array:= ( 1..20 =>  New Writer'(Make_Task) );

Access is not needed here. You can (and probably should) do something like

type Writer_List is array (Positive range <>) of Writer;

Writers : constant Writer_List := (1 .. 20 => Make_Writer);

-- 
Jeff Carter
"Gentlemen, you can't fight in here. This is the War Room!"
Dr. Strangelove
30

Re: Properties

[Brad Moore]

On 03/12/2010 4:34 PM, Jeffrey Carter wrote:
> On 12/02/2010 10:00 PM, Shark8 wrote:
>>
>> Type Task_Array is Array (1..20) of Access Writer;
>> Tasks : Task_Array:= ( 1..20 => New Writer'(Make_Task) );
>
> Access is not needed here. You can (and probably should) do something like
>
> type Writer_List is array (Positive range <>) of Writer;
>
> Writers : constant Writer_List := (1 .. 20 => Make_Writer);
>

Note that for this to compile, you end up needing to make the task 
discriminant mutable, since the task type in the array type declaration 
need to be constrained.

Sonmething like;

    task type Writer (ID : Integer := 0) is
    end Writer;

Re: Properties

[Shark8]

On Dec 5, 11:02 pm, Brad Moore <brad.mo...@shaw.ca> wrote:
> On 03/12/2010 4:34 PM, Jeffrey Carter wrote:
>
> > On 12/02/2010 10:00 PM, Shark8 wrote:
>
> >> Type Task_Array is Array (1..20) of Access Writer;
> >> Tasks : Task_Array:= ( 1..20 => New Writer'(Make_Task) );
>
> > Access is not needed here. You can (and probably should) do something like
>
> > type Writer_List is array (Positive range <>) of Writer;
>
> > Writers : constant Writer_List := (1 .. 20 => Make_Writer);
>
> Note that for this to compile, you end up needing to make the task
> discriminant mutable, since the task type in the array type declaration
> need to be constrained.
>
> Sonmething like;
>
>     task type Writer (ID : Integer := 0) is
>     end Writer;

Ah, Thanks!

Re: Properties

[Randy Brukardt]

"Warren" <ve3wwg@gmail.com> wrote in message 
news:Xns9E417369AD1F4WarrensBlatherings@81.169.183.62...
> Dmitry A. Kazakov expounded in
> news:1k7367gtebsgm$.18auo6u3nfg34.dlg@40tude.net:
>
>> On Wed, 1 Dec 2010 15:21:39 +0000 (UTC), Warren wrote:
>>> A library designed in Ada from the ground up, would be
>>> better.
>>
>> But we cannot, think about a type- and task-safe
>> notification mechanism. I have no idea how to do it without
>> tagged tasks and protected objects.
>
> Perhaps the scope you have in mind is too large. Is it really
> necessary to have the GUI operate outside of one task? Leave
> the task handling to the application designer.

We did this with Claw (Dmitry's argument that it is impossible doesn't hold 
water, since we tried to do all of the things that he suggests with Claw. 
Perhaps not in the way that he would like...)

There definitely are problems where supporting tasking in the GUI is a 
significant help. For instance, a background task can update part of a 
window (say for a speed gauge); the main interface does not need to concern 
itself with keeping "background" information current.

OTOH, supporting tasking in the GUI constrains what can be done in an event 
handler (Claw calls them "When_" routines), as it is quite easy to deadlock 
the system by having a handler do something that requires a lock that some 
other task is holding. It's not hard to avoid such situations, but we 
couldn't find any way to statically or dynamically check that the "rules" 
aren't violated.

>> And I don't want to
>> instantiate a generic each time I need an event handler.
>
> Agreed, but I don't believe we're stuck with that solution.
> All you need is procedure'Access for the callback.

Claw solely uses OOP to support event handlers. There are no explicit 
callbacks, and there are no generics to instantiate. (But instantiating a 
generic probably involves less typing than deriving an OOP type). IMHO, 
events cannot and should not be separated from the associated objects.

>> And I do want the compiler to check that all events are handled.
>
> Hmmm, more of a scope problem, I think.  Your requirements may
> be part of the problem.

This is not a problem in Claw, as all relevant events are always handled by 
every object. It's only necessary to write new handlers if you need 
additional actions on an event, and that could never be checked statically 
(or even dynamically), as it is specific to the problem being solved.

>>> Part of the difficulty is that something like a GUI takes
>>> so much effort to develop. To get one developed to a
>>> "standard level" would likely require some level of
>>> sponsorship. Especially if you want to also attempt to
>>> make it platform neutral.
>>
>> The main problem is the interface of such a library. There
>> are multiple parallel hierarchies need to be handled: a
>> hierarchy of widget types, a hierarchy of widget
>> containers,
>
> There are some challenges there, but I don't believe the fact
> that you need widget containers is a show stopper.

I don't see it as a problem at all. The standard Ada containers will handle 
Claw objects just fine (that's one of the reasons that I was very interested 
in the indefinite containers). [Note: Almost all Claw objects -- including 
all types of windows -- are non-limited with cloning semantics.]

>> a hierarchy of event handlers (events are
>> filtered, propagated, swallowed, re-generated).
>
> Not a problem with the callback approach, AFAICS.

Callbacks are unstructured and lead to unmanagable spaggeti code.

The same is true in any case if events are separated from the associated 
objects; so none of the things Dmitry talks about make sense for sane event 
handling. It's the objects that cooperate, not the events.

...
> It really comes down to what is "good enough" for a standard
> GUI library. Your requirements are desirable, but with
> existing software technologies, it doesn't appear practical
> AFAICS.
>
> Are there any GUI systems implemented that are fully static
> checked?

I don't think that even makes sense. The overriding property of a GUI is 
that objects are being created and destroyed under control of the user of 
the application, *not* under the control of the application or its 
programmer. We treated the user of the application as a "virtual" task, with 
the application itself being a different task that cooperates with the 
first. There is little there that can be determined statically (even if we 
hadn't used dispatching to deliver events to objects).

                                       Randy.

Re: Properties

[Warren]

Randy Brukardt expounded in news:id68q7$d66$1@munin.nbi.dk:

> "Warren" <ve3wwg@gmail.com> wrote in message 
> news:Xns9E417369AD1F4WarrensBlatherings@81.169.183.62...
>> Dmitry A. Kazakov expounded in
>> news:1k7367gtebsgm$.18auo6u3nfg34.dlg@40tude.net:
>>
>>> On Wed, 1 Dec 2010 15:21:39 +0000 (UTC), Warren wrote:
>>>> A library designed in Ada from the ground up, would be
>>>> better.
..
>>> And I don't want to
>>> instantiate a generic each time I need an event handler.
>>
>> Agreed, but I don't believe we're stuck with that
>> solution. All you need is procedure'Access for the
>> callback. 
> 
> Claw solely uses OOP to support event handlers. There are
> no explicit callbacks, and there are no generics to
> instantiate. (But instantiating a generic probably involves
> less typing than deriving an OOP type). IMHO, events cannot
> and should not be separated from the associated objects. 
..
>                                        Randy.

Ya, that seems to be a sensible approach. It's hard for me to 
forget a lifetime of C-based brainwashing. ;-)

Warren

Re: Properties

[Shark8]

> Ya, that seems to be a sensible approach. It's hard for me to
> forget a lifetime of C-based brainwashing. ;-)
>
> Warren

The Unix-hater's Handbook has a nice chapter on C-based programming...
I found the explanation of what C's "arrays" are to be most helpful in
a [required] C class I took later.
It's freely downloadable here: http://simson.net/ref/ugh.pdf

Re: Properties

[Warren]

Shark8 expounded in
news:618677c8-a44f-443e-9052-a94fb48c999a@s4g2000yql.googlegro
ups.com: 

>> Ya, that seems to be a sensible approach. It's hard for me
>> to forget a lifetime of C-based brainwashing. ;-)
>>
>> Warren
> 
> The Unix-hater's Handbook has a nice chapter on C-based
> programming... I found the explanation of what C's "arrays"
> are to be most helpful in a [required] C class I took
> later. It's freely downloadable here:
> http://simson.net/ref/ugh.pdf 

I am actually a fan of Unix/Linux. And C arrays/pointers must 
be groked early, if you want to survive the art of any serious 
C programming!

But the text looks like an amusing read, so I'll read it on my 
commute home. It'll be interesting to see what some folks find 
to hate about Unix. The only detracting thing I find about it, 
is simply the fact that it is well steeped in C.

But then, prior to Unix, O/S's were usually steeped in 
assembler language (like OS/2 for a modern example).  C has 
been a big improvement in that regard.

Warren

Re: Properties

[Dmitry A. Kazakov]

On Thu, 2 Dec 2010 16:45:16 +0000 (UTC), Warren wrote:

> It'll be interesting to see what some folks find 
> to hate about Unix.

Everything! I cannot figure out anything I didn't hate there. Hmm, maybe
Open Look? Which is dead anyway.

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

Re: Properties

[Warren]

Dmitry A. Kazakov expounded in
news:kr1k3b117xny$.1f3qb64m5z824$.dlg@40tude.net: 

> On Thu, 2 Dec 2010 16:45:16 +0000 (UTC), Warren wrote:
> 
>> It'll be interesting to see what some folks find 
>> to hate about Unix.
> 
> Everything! I cannot figure out anything I didn't hate
> there. Hmm, maybe Open Look? Which is dead anyway.

In my own experience, those who hate Unix generally are 
usually those from a non-Unix background who are in too big of 
a hurry to know it.

It's like the pianist who hates guitar- now instead of playing 
a certain pitched G note in one place on the keyboard, he 
hates the fact that there is now multiple choice on the 
guitar. But those who've taken the time to learn guitar, see 
this as a feature.

Warren

Re: Properties

[Adam Beneschan]

On Dec 2, 12:45 pm, Warren <ve3...@gmail.com> wrote:

> It's like the pianist who hates guitar- now instead of playing
> a certain pitched G note in one place on the keyboard, he
> hates the fact that there is now multiple choice on the
> guitar. But those who've taken the time to learn guitar, see
> this as a feature.

I understand what you're trying to get at, but the analogy seems
really strained.  As someone who started on piano and then took up
cello later, I don't think that the "problem" you describe is really a
problem at all.  When you first learn, they just don't teach you that
there is more than one way to play a note.  There's one way to play a
low G, and that's the open G string.  By the time you're taught that
you can also play it on the C string, you have enough experience that
you know how to make use of the information.  I'm sure it's pretty
much the same way on guitar.  It would strike me as odd for a pianist
to "hate" guitar because of that, and it would be really bizarre for a
beginning teacher to tell his students "There are two ways to play a
G, and you have to guess which one whenever you see it".  Now, the
fact that the note you're actually playing is an octave lower than
what you see on the page---*that's* a reason to hate it.  :)

                                           -- Adam

Re: Properties

[Warren]

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

Adam Beneschan expounded in
news:a66255f6-d39b-4017-b89a-5bbc901649ec@m20g2000prc.googlegr
oups.com: 

> On Dec 2, 12:45�pm, Warren <ve3...@gmail.com> wrote:
> 
>> It's like the pianist who hates guitar- now instead of
>> playing a certain pitched G note in one place on the
>> keyboard, he hates the fact that there is now multiple
>> choice on the guitar. But those who've taken the time to
>> learn guitar, see this as a feature.
> 
> I understand what you're trying to get at, but the analogy
> seems really strained.  As someone who started on piano and
> then took up cello later, 

The cello is a somewhat different. You're not playing more 
than one or two strings at a time. On a 6-string, you may be 
playing all 6, though 3-4 are often enough for many chords.

> ...  I'm sure it's pretty much the same way on
> guitar.  It would strike me as odd for a pianist to "hate"
> guitar because of that, 

It's not when you're playing guitar from "standard notation" 
(aka "piano notation"). The particular fret and string you 
choose for that higher G, depends a lot on the context of what 
is currently being played and where on the neck your hand is.

On a keyboard, that G note (of a particular) pitch is only 
played from one key, ever.  This is much simpler than the 
split second thinking about (as you play):

- Is that string I normally play it on, already fretted for 
another simultaneous note? 

- Is that alternative practical for the fretting hand given 
the other notes that must be fretted (i.e. can I reach it)?

Sure, with experience it starts to become second nature, but 
this is one of the main reasons that guitarists hate "standard 
notation". Many (most?), never learn to play from it (they use 
TAB instead).

TAB is another matter entirely-- it is the compiled machine 
language to guitar performance by comparison. The fretting has 
already been worked out for you in TAB. TAB is to guitar, what 
standard notation is to keyboards.

Agreed, the analogy is perhaps strained. 

The thrust of my point is simply that under Unix, it is often 
said that there are "several ways to skin a cat".

-- No offense to cat lovers, which include my wife.

A plethora of choice, complicates.

Warren

Re: Properties

[Shark8]

On Dec 2, 1:45 pm, Warren <ve3...@gmail.com> wrote:
> Dmitry A. Kazakov expounded innews:kr1k3b117xny$.1f3qb64m5z824$.dlg@40tude.net:
>
> > On Thu, 2 Dec 2010 16:45:16 +0000 (UTC), Warren wrote:
>
> >> It'll be interesting to see what some folks find
> >> to hate about Unix.
>
> > Everything! I cannot figure out anything I didn't hate
> > there. Hmm, maybe Open Look? Which is dead anyway.
>
> In my own experience, those who hate Unix generally are
> usually those from a non-Unix background who are in too big of
> a hurry to know it.

Perhaps this is true in some degree; there are, however, some rather
serious design flaws and deficiencies. One deficiency is/was the
absence of a 'rename' command for files & directories; renaming is a
VERY common procedure for anyone managing their files; instead of
'rename' one is to use 'move' to achieve similar effect... there is
one HUGE problem with using move [because * expansion is required in
all *nix shells] you cannot rename groups of files.

ex:
DOS -> Ren *.p *.pas    -- Renaming all .p files to .pas
*nix -> mv *.p *.pas    -- becomes expanded...
     -> mv 1.p 2.p 3.p test.pas    -- test.pas from the dir

In my experience *nix OSes make doing something harder, not easier...
somewhat like that person on your team who dragged their feet every
step of the way. That is to say, the OS is not helpful in providing
access to the resources of the computer.

Shell-scripting is loads of fun* too. {*And by 'fun' I mean
irritating, irregular, and surprisingly non-portable between different
'flavors'.} The following two-line script shows the POWER of *nix
shell-scripts:
#/bin/sh
$0 &

> It's like the pianist who hates guitar- now instead of playing
> a certain pitched G note in one place on the keyboard, he
> hates the fact that there is now multiple choice on the
> guitar. But those who've taken the time to learn guitar, see
> this as a feature.

I beg to differ.
There are plenty of reasons that *nix is horrid. {And I'm not saying
this because "windows is better" or anything, windows has a hell-of-a-
lot of faults...}

The shell-scripting is one reason; why in the name of Chaos would
someone want to use them [CSH or KSH or BASH]? In terms of power/
flexibility a LISP-based shell would be TONS more useful/managable...
though, admitidly it would require that one thinks in recursion.

The lack of types on files is another; old Macs had file-types down,
but *nix has nothing like that (nor does it have even the capability
for it, kernel-wise). {Windows has a [barely] workable file-extension/
association scheme -- analogous to an Ada map of (Key =>
File_Extention, Element => Application_Info).}

Lack of file versioning.* {Unix, Mac, and Win => Lose. VMS => Win.}
*File-versioning could save the arses of 90% of the lost/corrupted
file problems that I've encountered with MS Word users. i.e. the "my
kid selected the first twelve pages of my document and replaced it
with 'gsosdpofij' and I saved over it!" instantly becomes recoverable.

The FS as a "big bag-o-bytes" and the "EVERYTHING *IS* a file"
mentalities of *nix are, in a single word, wrong. My display is NOT a
file, nor should it be treated as such! {No, I would *not* like to
"rm" my display!}

One single hyphenated-word: man-pages.
The old DOS hypertext help was superior to man=pages, windows .HLP
file help was/is superior to man-pages, the OpenVMS help-system is
FAR, FAR more usable than man-pages.

Error codes? In *nix programs may or may not use them... (some
programs return 0/success when errors were encountered) which makes
them less than useless.

Re: Properties

[Thomas Løcke]

On 2010-12-03 04:34, Shark8 wrote:
> Perhaps this is true in some degree; there are, however, some rather
> serious design flaws and deficiencies. One deficiency is/was the
> absence of a 'rename' command for files&  directories; renaming is a
> VERY common procedure for anyone managing their files; instead of
> 'rename' one is to use 'move' to achieve similar effect... there is
> one HUGE problem with using move [because * expansion is required in
> all *nix shells] you cannot rename groups of files.
>
> ex:
> DOS ->  Ren *.p *.pas    -- Renaming all .p files to .pas
> *nix ->  mv *.p *.pas    -- becomes expanded...
>       ->  mv 1.p 2.p 3.p test.pas    -- test.pas from the dir


Or you can use rename:

$ rename .bak .txt *.bak

That renames all your .bak files to .txt.

The rename command has been part of the standard Linux tools for many
years. It's also readily available for FreeBSD and I suspect other
*BSD's as well. You're not forced to use mv to rename files.



> Shell-scripting is loads of fun* too. {*And by 'fun' I mean
> irritating, irregular, and surprisingly non-portable between different
> 'flavors'.} The following two-line script shows the POWER of *nix
> shell-scripts:
> #/bin/sh
> $0&



A /bin/sh script is perfectly portable, if you intend to use it with the
Bourne Shell.

It's of course less portable if you try to use it with the C shell.



> The shell-scripting is one reason; why in the name of Chaos would
> someone want to use them [CSH or KSH or BASH]? In terms of power/
> flexibility a LISP-based shell would be TONS more useful/managable...
> though, admitidly it would require that one thinks in recursion.



If you don't like BASH, csh, zsh or Korn, then why not try
something like BUSH:

http://www.pegasoft.ca/bush.html

It has a very Ada-like approach to shell scripting.



> The lack of types on files is another; old Macs had file-types down,
> but *nix has nothing like that (nor does it have even the capability
> for it, kernel-wise). {Windows has a [barely] workable file-extension/
> association scheme -- analogous to an Ada map of (Key =>
> File_Extention, Element =>  Application_Info).}


The "file" command is your friend.

It just works, and it doesn't depend on some shaky dot extension scheme.

Simple file->program association is handled well in both KDE and Gnome.
I suspect other desktop environments have similar systems in place. I
don't think this is a job for the kernel.


> Lack of file versioning.* {Unix, Mac, and Win =>  Lose. VMS =>  Win.}
> *File-versioning could save the arses of 90% of the lost/corrupted
> file problems that I've encountered with MS Word users. i.e. the "my
> kid selected the first twelve pages of my document and replaced it
> with 'gsosdpofij' and I saved over it!" instantly becomes recoverable.


Hardly the fault of *nix, but of the file system you're using.

Or you could just use a VCS to track the directories and files that
needs versioning.


> One single hyphenated-word: man-pages.
> The old DOS hypertext help was superior to man=pages, windows .HLP
> file help was/is superior to man-pages, the OpenVMS help-system is
> FAR, FAR more usable than man-pages.


man rename
man file

What's wrong with that? It could not be any easier.

Do you want to search for a specific word?

man -K word

or a phrase?

man -K "my phrase"

Or using apropos:

man -k "determine file type"

and you get:

file []              (1)  - determine file type

It's easy, flexible and it works.


> Error codes? In *nix programs may or may not use them... (some
> programs return 0/success when errors were encountered) which makes
> them less than useless.


Hardly the fault of *nix, just as the abundance of horrible software
for Windows cannot be blamed on Windows itself.

-- 
Regards,
Thomas L�cke

Email: tl at ada-dk.org
Web: http:ada-dk.org
IRC nick: ThomasLocke

Re: Properties

[Pascal Obry]

Le 02/12/2010 18:32, Dmitry A. Kazakov a �crit :
> Everything! I cannot figure out anything I didn't hate there. Hmm, maybe
> Open Look? Which is dead anyway.

You are missing something then. Too bad!

-- 

--|------------------------------------------------------
--| 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: Properties

[Adam Beneschan]

On Dec 2, 8:45 am, Warren <ve3...@gmail.com> wrote:
> Shark8 expounded innews:618677c8-a44f-443e-9052-a94fb48c999a@s4g2000yql.googlegro
> ups.com:
>
> >> Ya, that seems to be a sensible approach. It's hard for me
> >> to forget a lifetime of C-based brainwashing. ;-)
>
> >> Warren
>
> > The Unix-hater's Handbook has a nice chapter on C-based
> > programming... I found the explanation of what C's "arrays"
> > are to be most helpful in a [required] C class I took
> > later. It's freely downloadable here:
> >http://simson.net/ref/ugh.pdf
>
> I am actually a fan of Unix/Linux. And C arrays/pointers must
> be groked early, if you want to survive the art of any serious
> C programming!
>
> But the text looks like an amusing read, so I'll read it on my
> commute home. It'll be interesting to see what some folks find
> to hate about Unix. The only detracting thing I find about it,
> is simply the fact that it is well steeped in C.

I couldn't actually find the part about arrays that Shark8 alluded to
(although I didn't look very hard).  However, I did find the section
"Creators Admit C, Unix Were Hoax".

> But then, prior to Unix, O/S's were usually steeped in
> assembler language (like OS/2 for a modern example).  C has
> been a big improvement in that regard.

Yes, the big disadvantage that assembler had over C was that, despite
the fact that its mnemonics can be cryptic, they are actually based on
English words and use real letters, which meant that there was a real
possibility that the rookie programmer in the next cubicle might
actually be able to understand and fix your program, leading to loss
of job security.  I think that was one of the problems C was designed
to address.

:) :) :) Just kidding!

                                 -- Adam

Re: Properties

[Warren]

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

Adam Beneschan expounded in
news:4287748c-0962-4cd2-a36b-9dd7113267a6@21g2000prv.googlegro
ups.com: 

> On Dec 2, 8:45�am, Warren <ve3...@gmail.com> wrote:
>> Shark8 expounded
>> But then, prior to Unix, O/S's were usually steeped in
>> assembler language (like OS/2 for a modern example). �C
>> has been a big improvement in that regard.
> 
> Yes, the big disadvantage that assembler had over C was
> that, despite the fact that its mnemonics can be cryptic,
> they are actually based on English words and use real
> letters, which meant that there was a real possibility that
> the rookie programmer in the next cubicle might actually be
> able to understand and fix your program, leading to loss 
> of job security.  I think that was one of the problems C
> was designed to address.
> 
>:) :) :) Just kidding!
> 
>                                  -- Adam

Joking aside, C allowed the compiler to work on behalf of a 
programmer's higher level intentions, without making assembler 
level errors.

Ada could be said that it allows the [Ada] compiler to work on 
behalf of the programmer's higher level intentions, without 
making C level errors.

Warren

Re: Properties

[Jeffrey Carter]

Shark8 wrote:
>
> But then, prior to Unix, O/S's were usually steeped in
> assembler language (like OS/2 for a modern example).  C
> has been a big improvement in that regard.

OS/2 "prior to Unix"? Unix dates from ~1970, OS/2 the 1980s.

What I find funny is that the alternatives to Windows are all versions of Unix. 
Unix is hardly perfect; you'd think we'd have come up with something better by now.

-- 
Jeff Carter
"Well, a gala day is enough for me. I don't think
I can handle any more."
Duck Soup
93

Re: Properties

[Warren]

Jeffrey Carter expounded in
news:id93pc$qf9$1@tornado.tornevall.net: 

> Shark8 wrote:
>>
>> But then, prior to Unix, O/S's were usually steeped in
>> assembler language (like OS/2 for a modern example).  C
>> has been a big improvement in that regard.
> 
> OS/2 "prior to Unix"? Unix dates from ~1970, OS/2 the
> 1980s. 

Yes. I never said _anything_ about OS/2 predating Unix. 

What I did say was that OS/2 was as a modern example of an asm 
version of an O/S.  Sheesh.  Didn't you read the word 
"modern"?

> What I find funny is that the alternatives to Windows are
> all versions of Unix. Unix is hardly perfect; you'd think
> we'd have come up with something better by now. 

Agreed that Unix has imprefections but at least it was 
"designed" with some peer review.  

MS stuff just gets "marketing review" and pushed out the door 
with a "look what we can do?" approach.  Everyone told them 
ActiveX over the internet was a bad idea. It tooks years for 
that lesson to sink in.

It would be interesting to know more about what NT was 
designed like, before MS bastardized it, to make it compatible 
with prior Windows APIs.

I've never worked with VMS, but folks that have seem to have 
really liked it.

More recently, I've personally liked the idea of an Ada mach 
kernel myself, and even did some work on one once (RTMK I 
think it was).  But I'm too old to follow through on something 
that huge.  That is a Linux type of project in need of a young 
university grad with energy and enthusiasm.

Warren

Re: Properties

[Anonymous]

> Jeff Carter

You're someone worth listening to so I was surprised to read your comment.

What's wrong with UNIX for PC use?

Re: Properties

[Shark8]

On Dec 2, 12:46 pm, Adam Beneschan <a...@irvine.com> wrote:
> On Dec 2, 8:45 am, Warren <ve3...@gmail.com> wrote:
>
>
>
> > Shark8 expounded innews:618677c8-a44f-443e-9052-a94fb48c999a@s4g2000yql.googlegro
> > ups.com:
>
> > >> Ya, that seems to be a sensible approach. It's hard for me
> > >> to forget a lifetime of C-based brainwashing. ;-)
>
> > >> Warren
>
> > > The Unix-hater's Handbook has a nice chapter on C-based
> > > programming... I found the explanation of what C's "arrays"
> > > are to be most helpful in a [required] C class I took
> > > later. It's freely downloadable here:
> > >http://simson.net/ref/ugh.pdf
>
> > I am actually a fan of Unix/Linux. And C arrays/pointers must
> > be groked early, if you want to survive the art of any serious
> > C programming!
>
> > But the text looks like an amusing read, so I'll read it on my
> > commute home. It'll be interesting to see what some folks find
> > to hate about Unix. The only detracting thing I find about it,
> > is simply the fact that it is well steeped in C.
>
> I couldn't actually find the part about arrays that Shark8 alluded to
> (although I didn't look very hard).  However, I did find the section
> "Creators Admit C, Unix Were Hoax".
>
> > But then, prior to Unix, O/S's were usually steeped in
> > assembler language (like OS/2 for a modern example).  C has
> > been a big improvement in that regard.
>
> Yes, the big disadvantage that assembler had over C was that, despite
> the fact that its mnemonics can be cryptic, they are actually based on
> English words and use real letters, which meant that there was a real
> possibility that the rookie programmer in the next cubicle might
> actually be able to understand and fix your program, leading to loss
> of job security.  I think that was one of the problems C was designed
> to address.
>
> :) :) :) Just kidding!
>
>                                  -- Adam

Interesting you should mention that; I got into a discussion elsewhere
about OSes and the influence of the programming languages they're
developed in. One of the people in the discussion did an analysis/
recommendation for Microsoft right after windows came out... their
recommendation was to re-encoded in Ada.

...and on the note of 'job security,' on that same discussion was
posted this link:
http://www-users.cs.york.ac.uk/~susan/joke/cpp.htm

Re: Properties

[Robert A Duff]

Warren <ve3wwg@gmail.com> writes:

> But the text looks like an amusing read, so I'll read it on my 
> commute home.

It is amusing, both the parts I agree with and the parts
I disagree with.

>...It'll be interesting to see what some folks find 
> to hate about Unix.

There's lots to hate about Unix.  There's lots to hate
about other operating systems, too.  I switch back&forth
between Linux and Windows all the time, and I definitely
prefer Linux.  But I still hate it.

>...The only detracting thing I find about it, 
> is simply the fact that it is well steeped in C.

Well, that's sort of like saying "The only thing to
dislike about the Atlantic Ocean is that it's got
seawater in it".  ;-)  I don't think C would have
gone anywhere without riding on the back of Unix.

An operating system shouldn't be heavily biased toward
writing user-mode programs in the same language as the OS.
Unix is.  Some others are better in that regard.
VMS, for example.  (But there's a lot about VMS
I don't like.)

I mean, defining system call interfaces as .h files
is just a bad way to do things.  VMS is better in that regard.

- Bob

Re: Properties

[Warren]

Robert A Duff expounded in
news:wccvd3bu37w.fsf@shell01.TheWorld.com: 

> Warren <ve3wwg@gmail.com> writes:
> 
>> But the text looks like an amusing read, so I'll read it
>> on my commute home.
> 
> It is amusing, both the parts I agree with and the parts
> I disagree with.

It was an amusing walk down memory lane. I remember many of 
the struggles mentioned there.

> There's lots to hate about Unix.  There's lots to hate
> about other operating systems, too.  I switch back&forth
> between Linux and Windows all the time, and I definitely
> prefer Linux.  But I still hate it.

I guess I hate Windows so much, that I love Unix by 
comparison. 

I really hate MS software design.  Every API item is shoe 
horned into a WORD, DWORD or some basterized pointer to some 
such.  Why couldn't they take the time to put some real C++ 
types (if they're going to use C++) around these things?  
Cheeze Louise!  And drop that Hungarian notation, for crying 
out loud.

> Well, that's sort of like saying "The only thing to
> dislike about the Atlantic Ocean is that it's got
> seawater in it".  ;-)  

Sharks. If only if it didn't have Sharks. ;-)

> I mean, defining system call interfaces as .h files
> is just a bad way to do things.  VMS is better in that
> regard. 
> 
> - Bob

I really like the Ada package approach. I was never really 
fond of that whole .h shuffle, and cpp macros.  I was ok with 
my own macros but working with other ppl's macros isn't so 
fun.

Warren

Re: Properties

[Shark8]

On Dec 3, 8:49 am, Warren <ve3...@gmail.com> wrote:
> Robert A Duff expounded innews:wccvd3bu37w.fsf@shell01.TheWorld.com:
>
> I really hate MS software design.  Every API item is shoe
> horned into a WORD, DWORD or some basterized pointer to some
> such.  Why couldn't they take the time to put some real C++
> types (if they're going to use C++) around these things?  
> Cheeze Louise!  And drop that Hungarian notation, for crying
> out loud.
>
> Warren

I defiantly agree with the Hungarian notation.
The argument could be made that if they were going to spend the time/
energy to use "real C++ types" they would have been better off doing
it in Ada where the strong typing would help; IMO, C++ encourages the
disuse/misuse of types.

I agree with you about the WORD, DWORD, pointer thing. It would be
better to have actual types with actual parameters/fields... but then
the same could be said about the 'typless' FSes for *nix and windows;
instead of treating every file as a bag-o-bytes it would be better to
have the files-themselves store that information -- yes, the latter
method makes it 'harder' for you to open that midi file with notepad
so you can do a quick "hex"-edit... but it also means that users can't
screw up your system by forgetting the extension in a rename [win] or
forcing the OS to run some file-checker on the file to determine its
type.

Re: Properties

[Warren]

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

Shark8 expounded in
news:066181c0-9b80-4c17-a7b4-7ef28a297ea4@e16g2000pri.googlegr
oups.com: 

> On Dec 3, 8:49�am, Warren <ve3...@gmail.com> wrote:
>> I really hate MS software design. �Every API item is shoe
>> horned into a WORD, DWORD or some basterized pointer to
>> some such. �Why couldn't they take the time to put some
>> real C++ types (if they're going to use C++) around these
>> things? � Cheeze Louise! �And drop that Hungarian
>> notation, for crying out loud.
>>
>> Warren
> 
> I defiantly agree with the Hungarian notation.

<tossed cookies> followed by <dry heaves>

The type declaration carrys the type information. It does NOT 
belong in the name (of the variable).  It creates a  
maintenance nightmare also -- change the type and all 
instances of the name must be changed.  

BLECH.

> The argument could be made that if they were going to spend
> the time/ energy to use "real C++ types" they would have
> been better off doing it in Ada where the strong typing
> would help; 

That's academic- but they did use C++.

> IMO, C++ encourages the disuse/misuse of types.

If you're going to use C++, then don't dumb it down to 
dumbest unspecified types.  That's like taking a sports car
and using those dumb little spare tires that limp you home.

> I agree with you about the WORD, DWORD, pointer thing. It
> would be better to have actual types with actual
> parameters/fields... 

Yes. Every event and API is usually specific enough for real 
type definitions. 

> but then the same could be said about
> the 'typless' FSes for *nix and windows

That is something different. A "file" is a perfectly generic 
container of information. Do you want to allow your software 
to decide the format? Or would you prefer the OS to do it 
instead?  Something must decide.

Prior to Unix, everything was a unit record of some sort. It 
still is on the non-UNIX (non-hierarchical) parts of a 
mainframe:

//DATAOUT DD DSN=M0DXYZ.DATA,                      
//           DISP=(NEW,CATLG,DELETE),                 
//           SPACE=(TRK,(10,10),RLSE),                
//           DCB=(RECFM=FB,LRECL=23,BUFNO=10,OPTCD=C) 

Do you want to go back to specifying all these file 
attributes? RECFM=? LRECL=? BLKSIZE=? bLECH. Not to 
mention it complicates ftp transfers etc. :

LOCSITE LRECL=80 RECFM=FB BLOCKSIZE=320 CYLINDERS \
  PRIMARY=2 SECONDARY=2

Blexhch.

One of the best things about Unix is that it finally tossed 
aside all of these silly hinderances.  Everything since has 
copied this thinking.

Warren

Re: Properties

[Shark8]

> > I defiantly agree with the Hungarian notation.
>
> <tossed cookies> followed by <dry heaves>
>
> The type declaration carrys the type information. It does NOT
> belong in the name (of the variable).  It creates a  
> maintenance nightmare also -- change the type and all
> instances of the name must be changed.  
>
> BLECH.

Eh, my mistake, I meant to say "I defiantly agree with you on the
Hungarian notation."
> > I agree with you about the WORD, DWORD, pointer thing. It
> > would be better to have actual types with actual
> > parameters/fields...
>
> Yes. Every event and API is usually specific enough for real
> type definitions.
>
> > but then the same could be said about
> > the 'typless' FSes for *nix and windows
>
> That is something different. A "file" is a perfectly generic
> container of information. Do you want to allow your software
> to decide the format? Or would you prefer the OS to do it
> instead?  Something must decide.

Er, I think you misunderstand what I mean by "typed files" very often
"the software" does NOT & should NOT decide the format; if that were
the case then "the software" could say "my HTML file writer doesn't
need ending tags!" or "I don't need to write the header for an .ICO
file!" which misses the whole point of having a specified standard.

IOW, the type of a file, having some definition, SHOULD ensure that
the file has the correct layout... like Access ensures that our
"pointer" *IS* to a variable of the specified type.

> Prior to Unix, everything was a unit record of some sort. It
> still is on the non-UNIX (non-hierarchical) parts of a
> mainframe:
>
> //DATAOUT DD DSN=M0DXYZ.DATA,                      
> //           DISP=(NEW,CATLG,DELETE),                
> //           SPACE=(TRK,(10,10),RLSE),                
> //           DCB=(RECFM=FB,LRECL=23,BUFNO=10,OPTCD=C)
>
> Do you want to go back to specifying all these file
> attributes? RECFM=? LRECL=? BLKSIZE=? bLECH. Not to
> mention it complicates ftp transfers etc. :
>
> LOCSITE LRECL=80 RECFM=FB BLOCKSIZE=320 CYLINDERS \
>   PRIMARY=2 SECONDARY=2
>
> Blexhch.

It actually makes a lot of sense to be able to have some sort of "unit
record" in files, especially if you are dealing with databases and, in
that case, units should be able to be individually locked.

As for specifying all the little attributes of some file, why not
treat it the same way I do in Ada: unless there is some specific
reason to do otherwise [like hardware interfacing] let the compiler
choose the attributes of the type like 'Size, 'Bit_Order?

>
> One of the best things about Unix is that it finally tossed
> aside all of these silly hinderances.  Everything since has
> copied this thinking.

Just because everything copies the thinking neither means that the
thinking is correct or useful. (Though it doesn't mean that it's wrong
or useless either.)

Re: Properties

[Warren]

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

Shark8 expounded in
news:923f0664-890d-4ca9-9b34-2da64067b068@21g2000prv.googlegro
ups.com: 

>> > I defiantly agree with the Hungarian notation.
>>
>> <tossed cookies> followed by <dry heaves>
>>
>> The type declaration carrys the type information. It does
>> NOT belong in the name (of the variable). �It creates a �
>> maintenance nightmare also -- change the type and all
>> instances of the name must be changed. �
>>
>> BLECH.
> 
> Eh, my mistake, I meant to say "I defiantly agree with you
> on the Hungarian notation."

Ah, ok... you're forgiven. ;-)

>> That is something different. A "file" is a perfectly
>> generic container of information. Do you want to allow
>> your software to decide the format? Or would you prefer
>> the OS to do it instead? �Something must decide.
> 
> Er, I think you misunderstand what I mean by "typed files"
> very often "the software" does NOT & should NOT decide the
> format; if that were the case then "the software" could say
> "my HTML file writer doesn't need ending tags!" or "I don't
> need to write the header for an .ICO file!" which misses
> the whole point of having a specified standard. 
> 
> IOW, the type of a file, having some definition, SHOULD
> ensure that the file has the correct layout... like Access
> ensures that our "pointer" *IS* to a variable of the
> specified type. 

I guess, I don't understand your point. The software creating 
the "content" is doing it in a format, which often varies 
record by record, even in binary (yours is a text example).

> Just because everything copies the thinking neither means
> that the thinking is correct or useful. (Though it doesn't
> mean that it's wrong or useless either.)

Agreed, but you have ask why this is "successful". Usually, 
there are good reasons for it.  Then again, C/C++ is a bad 
counter example. ;-)

Warren

Re: Properties

[Simon Wright]

Shark8 <onewingedshark@gmail.com> writes:

> Eh, my mistake, I meant to say "I defiantly agree with you on the
> Hungarian notation."

Do you actually mean 'defiantly'? or perhaps 'definitely'?

Re: Properties

[Shark8]

On Dec 8, 2:13 pm, Simon Wright <si...@pushface.org> wrote:
> Shark8 <onewingedsh...@gmail.com> writes:
> > Eh, my mistake, I meant to say "I defiantly agree with you on the
> > Hungarian notation."
>
> Do you actually mean 'defiantly'? or perhaps 'definitely'?

The latter.
{Spell-checker is not always your friend.}

;)

Re: Properties

[Randy Brukardt]

"Warren" <ve3wwg@gmail.com> wrote in message 
news:Xns9E46A316BB94AWarrensBlatherings@81.169.183.62...
> Shark8 expounded in
> news:066181c0-9b80-4c17-a7b4-7ef28a297ea4@e16g2000pri.googlegr
> oups.com:
...
>> The argument could be made that if they were going to spend
>> the time/ energy to use "real C++ types" they would have
>> been better off doing it in Ada where the strong typing
>> would help;
>
> That's academic- but they did use C++.

So far as I know, Win32 is written in C. I'm pretty sure about that, since 
Claw interfaces only using C (Stdcall) interfaces. There are a few recent 
parts of Win32 that have C++ counterparts, but the majority of it was 
designed before there was any such thing as C++ (most of it is a copy of 
Win16, after all). Thus the bizarre notations.

                                            Randy.

Re: Properties

[Jeffrey Carter]

On 12/06/2010 04:43 PM, Randy Brukardt wrote:
>
> So far as I know, Win32 is written in C. I'm pretty sure about that, since
> Claw interfaces only using C (Stdcall) interfaces. There are a few recent
> parts of Win32 that have C++ counterparts, but the majority of it was
> designed before there was any such thing as C++ (most of it is a copy of
> Win16, after all). Thus the bizarre notations.

I'm not sure you can make that claim ("the majority of it was designed before 
there was any such thing as C++"). C++ dates from 1982; Windows came later.

-- 
Jeff Carter
"This scene's supposed to be in a saloon, but
the censor cut it out. It'll play just as well
this way." [in a soda fountain]
Never Give a Sucker an Even Break
113

Re: Properties

[Maciej Sobczak]

On Dec 7, 12:43 am, "Randy Brukardt" <ra...@rrsoftware.com> wrote:

> > That's academic- but they did use C++.
>
> So far as I know, Win32 is written in C. I'm pretty sure about that, since
> Claw interfaces only using C (Stdcall) interfaces.

That doesn't mean anything. It might as well be written in Ada and
pragma Export everything to meet the "lowest denominator" at the C
level. It might as well be written in assembler. And so on.

As a demonstration that this can be a reasonable approach, the YAMI4
core library was written in C++ (to benefit from namespaces,
encapsulation, and access control), but exports its interface in terms
of extern "C". This interface is used as a basis for the Ada part.
Technically, exactly the same approach might have been used in the
Win32-Claw stack. Without you knowing about it. ;-)

I don't claim that this is actually the case, but this is a)
demonstrably possible and b) it even makes perfect sense from the
engineering perspective.

And in fact, the following might be an answer:

http://www2.research.att.com/~bs/applications.html

(scroll down to the bullet devoted to Microsoft)

--
Maciej Sobczak * http://www.inspirel.com

Re: Properties

[Georg Bauhaus]

On 07.12.10 12:23, Maciej Sobczak wrote:

> As a demonstration that this can be a reasonable approach, the YAMI4
> core library was written in C++ (to benefit from namespaces,
> encapsulation, and access control), but exports its interface in terms
> of extern "C". This interface is used as a basis for the Ada part.
> Technically, exactly the same approach might have been used in the
> Win32-Claw stack. Without you knowing about it. ;-)
> 
> I don't claim that this is actually the case, but this is a)
> demonstrably possible and b) it even makes perfect sense from the
> engineering perspective.

I'm curious about the engineering perspective, the
one that prefers a "lowest denominator" in the
style of extern "C".

To me this seems like the prime example of effective
software management:  Attract more people by requiring
a seemingly minimal programming approach.
Will it help them, in the long run, to become attracted
to more modern concepts like explicit modules (packages,
classes, ADTs)?

Re: Properties

[Maciej Sobczak]

On Dec 7, 12:51 pm, Georg Bauhaus <rm.dash-bauh...@futureapps.de>
wrote:

> > I don't claim that this is actually the case, but this is a)
> > demonstrably possible and b) it even makes perfect sense from the
> > engineering perspective.
>
> I'm curious about the engineering perspective, the
> one that prefers a "lowest denominator" in the
> style of extern "C".

The "lowest denominator" is not just preferred, it is actually imposed
by market forces.
Imagine, for example, that Win32 exposed its interfaces as C++. Or C#.
Would you be able to use it from Ada? No. Would you be able to use it
from Java? No.

The other way round: imagine a general-purpose operating system
written in Ada that did not bother to export its interfaces as C.
Would it become an attractive and popular development platform? No.

These are the forces that make the "lowest denominator" not just
preferred, but obligatory. Ignore this fact and you will be...
ignored.

> To me this seems like the prime example of effective
> software management:  Attract more people by requiring
> a seemingly minimal programming approach.

I don't claim that this "lowest denominator" is good.
I only claim that there is no alternative.

The only improvement that I'm aware of involves traveling back in time
and reinventing the IT industry.

--
Maciej Sobczak * http://www.inspirel.com

Re: Properties

[Georg Bauhaus]

On 07.12.10 16:35, Maciej Sobczak wrote:
> I don't claim that this "lowest denominator" is good.
> I only claim that there is no alternative.
> 
> The only improvement that I'm aware of involves traveling back in time
> and reinventing the IT industry.

I see; yet Microsoft seems to have moved its software towards
objects. If .NET is a sign of objects and if .NET, Java and
iOS shape future programmers, maybe IT can travel forwards.

There is a gap between modeling tools' presentation of the
world (using objects' interfaces) and the way they appear in extern
"C" style programs (implicit, mostly).  This is contradictory,
I think, but then contradictions impose no strain on a programmer's
mind when he can switch world views by switching tools.
Odd it is, though.

Re: Properties

[Warren]

Randy Brukardt expounded in news:idjsen$hg9$1@munin.nbi.dk:

> "Warren" <ve3wwg@gmail.com> wrote in message 
> news:Xns9E46A316BB94AWarrensBlatherings@81.169.183.62...
>> Shark8 expounded in
>> news:066181c0-9b80-4c17-a7b4-7ef28a297ea4@e16g2000pri.googl
>> egr oups.com:
> ...
>>> The argument could be made that if they were going to
>>> spend the time/ energy to use "real C++ types" they would
>>> have been better off doing it in Ada where the strong
>>> typing would help;
>>
>> That's academic- but they did use C++.
> 
> So far as I know, Win32 is written in C. I'm pretty sure
> about that, since Claw interfaces only using C (Stdcall)
> interfaces. There are a few recent parts of Win32 that have
> C++ counterparts, but the majority of it was designed
> before there was any such thing as C++ (most of it is a
> copy of Win16, after all). Thus the bizarre notations.
> 
>                                             Randy.

I was thinking about the MFC classes, which are C++. IIRC, 
there were still WORD and DWORD components within that. But 
its been years since I've looked. 

Warren

Re: Properties

[Warren]

Warren expounded in
news:Xns9E4277935FF91WarrensBlatherings@85.214.73.210: 

> Shark8 expounded in
> news:618677c8-a44f-443e-9052-a94fb48c999a@s4g2000yql.googleg
> ro ups.com: 
..
>> The Unix-hater's Handbook has a nice chapter on C-based
>> programming... I found the explanation of what C's
>> "arrays" are to be most helpful in a [required] C class I
>> took later. It's freely downloadable here:
>> http://simson.net/ref/ugh.pdf 
> 
> I am actually a fan of Unix/Linux. And C arrays/pointers
> must be groked early, if you want to survive the art of any
> serious C programming!
> 
> But the text looks like an amusing read, so I'll read it on
> my commute home. ...

I got through about half of it last night. It took me down 
memory lane with some snickers. Ya, there are some justifiable 
rants about warts etc. 

But Unix still appears king of the hill. At least until 
something better comes along. 

Warren

Re: Properties

[Shark8]

On Dec 3, 8:40 am, Warren <ve3...@gmail.com> wrote:
> Warren expounded innews:Xns9E4277935FF91WarrensBlatherings@85.214.73.210:
>
> But Unix still appears king of the hill. At least until
> something better comes along.
>
> Warren

And I'd love to be able to produce that "something better"... bonus
"satisfaction points" if it uses Ada exclusively (partially to show up
the CS dept of my university where everyone seems to think "You can't
make a [good] OS without C/C++").

;)

Re: Properties

[Warren]

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

Shark8 expounded in
news:f2d78fc4-9918-4df3-8771-45e7f7fd8f67@p11g2000vbn.googlegr
oups.com: 

> On Dec 3, 8:40�am, Warren <ve3...@gmail.com> wrote:
>> Warren expounded
>> innews:Xns9E4277935FF91WarrensBlatherings@85.214.73.210: 
>>
>> But Unix still appears king of the hill. At least until
>> something better comes along.
>>
>> Warren
> 
> And I'd love to be able to produce that "something
> better"... bonus "satisfaction points" if it uses Ada
> exclusively (partially to show up the CS dept of my
> university where everyone seems to think "You can't make a
> [good] OS without C/C++"). 
> 
> ;)

Start on your proof of concept, get a following of loyal "I 
can't wait to contribute to your OS" volunteers, get some sort 
of industry buy in and then Bob's your uncle.

But the challenge this time around is that there are not 
enough people who are hungry for a free O/S, since Linux is 
already there and "good enough".  Then they need to use Ada, 
and then you need OS specific device drivers etc.....  

That it why it needs someone with a LOT of energy and drive! 
And someone young enough to endure it all.

Warren

Re: Properties

[Shark8]

On Dec 1, 8:59 am, "Dmitry A. Kazakov" <mail...@dmitry-kazakov.de>
wrote:
>The main problem is the interface of such a library. There are
>multiple parallel hierarchies need to be handled: a hierarchy
>of widget types, a hierarchy of widget containers, a hierarchy
>of event handlers (events are filtered, propagated, swallowed,
>re-generated).
>
> --
> Regards,
> Dmitry A. Kazakovhttp://www.dmitry-kazakov.de

Why not have an INTERFACE hierarchy in addition to the GUI_Object
hierarchy? This would allow for an easy way for foreign-language
objects to be incorporated, to some extent, into applications which
use this hypothetical library.... with only the added encumberment of
forcing more up-front design. (Usu. a good thing.)

Additionally, it could help with keeping the GUI_Object hierarchy
smaller as there are many GUI items which are themselves composed of
other GUI items. A scroll-bar, for example, has two distinct
interfaces: the Button[s] and the slider-bar.

The event-handler hierarchy seems to be the most 'interesting', not
because of the events themselves, but because of the problem of how
best to hook them; as you said they can be consumed, passed-through,
emitted, and so-forth. They should, therefore be lightweight (as we
don't want to transmit unnecessary information), quick in construction
(this will impact the GUIs responsiveness) and clean in destruction
(no memory leaks, please).

By "widget containers" do you mean something like
Ada.Containers.Vectors initialized to the classwide-type of the root
of the GUI_Object hierarchy, OR do you mean some component which
contains other components (like a panel, perhaps)? {I'm inclined to
believe you meant the latter.}

Finally, I've been quite impressed with Delphi's Visual Component
Library (VCL). Microsoft's MFC and Java's JFC seem to have been
'inspired' [or copied] from the VCL, but neither presents itself as
uniform & usable/mature [if you will] as the VCL. While the VCL
doesn't use interfaces it does make nice use of properties; event
handlers are get/set w/ properties and handlers are not required to be
installed for every object like they are in Java; I believe that
internally Delphi uses something like this:
If Assigned(Handler) Then Handler^(Sender); {Assigned tests for null.}

Re: Properties

[Dmitry A. Kazakov]

On Thu, 2 Dec 2010 21:53:13 -0800 (PST), Shark8 wrote:

> On Dec 1, 8:59�am, "Dmitry A. Kazakov" <mail...@dmitry-kazakov.de>
> wrote:
>>The main problem is the interface of such a library. There are
>>multiple parallel hierarchies need to be handled: a hierarchy
>>of widget types, a hierarchy of widget containers, a hierarchy
>>of event handlers (events are filtered, propagated, swallowed,
>>re-generated).
>>
> Why not have an INTERFACE hierarchy in addition to the GUI_Object
> hierarchy?

Hmm, isn't it same? To me interface = abstract type.

> Additionally, it could help with keeping the GUI_Object hierarchy
> smaller as there are many GUI items which are themselves composed of
> other GUI items. A scroll-bar, for example, has two distinct
> interfaces: the Button[s] and the slider-bar.

Ada should have had proper multiple inheritance 15 years ago.
 
> By "widget containers" do you mean something like
> Ada.Containers.Vectors initialized to the classwide-type of the root
> of the GUI_Object hierarchy, OR do you mean some component which
> contains other components (like a panel, perhaps)? {I'm inclined to
> believe you meant the latter.}

Yes, the latter, but the former is also required, you frequently need lists
of widgets (of referential semantics). This raises another question. Ada
does not support abstract access types. You want a reference to the widget
be a fat pointer transparent to all widget operations with automatic
collection of widget objects. This almost works in Ada, but it is extremely
boring to do. The scheme is as follows:

1. You declare a separate interface type for each widget
2. You implement the interface by the widget object
3. You implement the interface by the handle to the widget (a controlled
type).

It is nightmare to do, I know it. I did so in one project (not for the
widgets), and I don't want this adventure anymore.

The bottom line, interfaces must be removed from Ada. Instead of that an
interface must be made inheritable from any concrete type. This is the same
idea as with abstract record, array etc types. Any type has interface,
which is inheritable without the implementation:

   type Widget_Handle is private Widget; -- Like the widget, but isn't
private
   type Widget_Handle is new Ada.Limited_Controlled with record
       Ptr : access Widget;
   end record;

For access types there must be delegation support, which should eliminate
need in wrappers. There are other issues as well, like that "access Widget"
is purposely not "access Widget'Class."

> Finally, I've been quite impressed with Delphi's Visual Component
> Library (VCL).

That's interesting, because we are using the VCL quite heavily. One of our
customers explicitly ordered that. Now, my impression is opposite to yours:
it is safer, *quicker*, cleaner, an far more maintainable to develop GUI in
*raw* Windows API than in VCL. As a bonus, you can get rid of that awful
Borland C++, use VC++ or gcc instead.

> Microsoft's MFC and Java's JFC seem to have been
> 'inspired' [or copied] from the VCL, but neither presents itself as
> uniform & usable/mature [if you will] as the VCL.

We dropped MFC long ago and never returned to it. We didn't use JFC, so I
cannot say anything about it.

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

Re: Properties

[Shark8]

On Dec 3, 2:05 am, "Dmitry A. Kazakov" <mail...@dmitry-kazakov.de>
wrote:
> > Why not have an INTERFACE hierarchy in addition to the GUI_Object
> > hierarchy?
>
> Hmm, isn't it same? To me interface = abstract type.

Usually they are interchangeable, but INTERFACES are the only way in
Ada to do something akin to multiple inheritance: i.e. it is the only
way that we can synthesize a spin-box {an increase value button, a
decrease value button, and a numeric-value edit-box} from the leaves
of our elemental-GUI-component hierarchy w/o encapsulating the items
within an otherwise useless 'container' object.

   Type GUI_Base is interface;
   Procedure On_Basic_Event(Object : In Out GUI_Base'Class;
                            Event : In Basic_Event'Class
                           );

   Type Button is interface and GUI_base;
   Procedure On_Click( Object : In Out Button'Class;
                       Click  : In Click_Event'Class
                     );

   Type Edit_Box is interface and GUI_Base;
   Procedure On_Change( Object : In Out Edit_Box'Class;
                        Change : In Change_Event'Class
                      );

   -- ...

   Type Spin_Box_Object is New GUI_Base_Object and Button and Edit_box
with
      record
         --...
      end record;



> > Additionally, it could help with keeping the GUI_Object hierarchy
> > smaller as there are many GUI items which are themselves composed of
> > other GUI items. A scroll-bar, for example, has two distinct
> > interfaces: the Button[s] and the slider-bar.
>
> Ada should have had proper multiple inheritance 15 years ago.

Mayhaps; but that would be irrelevant to actual task. (i.e.  where
someone plops down and says to your boss "We're using Ada 2005 and we
want a GUI library fully and seamlessly portable across X, Y, and Z
OSes." who then turns to you and me and says "Make it!")

> > By "widget containers" do you mean something like
> > Ada.Containers.Vectors initialized to the classwide-type of the root
> > of the GUI_Object hierarchy, OR do you mean some component which
> > contains other components (like a panel, perhaps)? {I'm inclined to
> > believe you meant the latter.}
>
> Yes, the latter, but the former is also required, you frequently need lists
> of widgets (of referential semantics).

It is somewhat irritating that you cannot initialize element to
GUI_Base'Class directly.

Attempting the following
   Package GUI_Vector is New Ada.Containers.Vectors
	( Element_Type => GUI_Base'Class, Index_Type => Positive );
yields
instantiation error at a-convec.ads:321
"unconstrained element type in array declaration actual for
"Element_Type" must be a definite subtype"

What's wrong with say initializing Ada.Containers.Vector with Positive
=> Index and Element => Access_GUI_Base_Class*?

*Type Access_GUI_Base_Class is Access GUI_Base'Class;

It would be nice to throw a "Not null" in because storing a 'pointer'
to "not an object" is pretty dumb... but that gives this error-set:
warning: in instantiation at a-convec.adb:1196
warning: (Ada 2005) null-excluding objects must be initialized
warning: "Constraint_Error" will be raised at run time
warning: in instantiation at a-convec.adb:1209
warning: (Ada 2005) null-excluding objects must be initialized
warning: "Constraint_Error" will be raised at run time

It's almost as if it's saying that we couldn't ever use the container
exclusively like this:

Vector : GUI_Vector.Vector:= GUI_Vector.Empty_Vector;
Component_1 : Aliased GUI_Base'Class:= Make_Component( ... );
--...
Component_n : Aliased GUI_Base'Class:= Make_Component( ... );
begin
 Vector.Add( Component_1'Access );
--...
 Vector.Add( Component_n'Access );
--the work
end;

>This raises another question. Ada
> does not support abstract access types. You want a reference to the widget
> be a fat pointer transparent to all widget operations with automatic
> collection of widget objects. This almost works in Ada, but it is extremely
> boring to do.

[snip]
> The bottom line, interfaces must be removed from Ada.
> Instead of that an interface must be made inheritable
> from any concrete type. This is the same idea as with
> abstract record, array etc types.

Wouldn't this be alleviated by two things:
Allowing INTERFACE [keyword] objects to have fields (properties as
I've described, or somesuch)?
Allowing objects some sort of self/this/me attribute where the result
is a Not Null Access to its classwide-type*? (Or am I misunderstanding
what you mean by the need for "a fat pointer transparent to all widget
operations"?)

*Or is this the equivalent of requiring all such variables to be
Aliased?

>
>    type Widget_Handle is private Widget; -- Like the widget, but isn't
> private
>    type Widget_Handle is new Ada.Limited_Controlled with record
>        Ptr : access Widget;
>    end record;
>
> For access types there must be delegation support, which should eliminate
> need in wrappers. There are other issues as well, like that "access Widget"
> is purposely not "access Widget'Class."
>
> > Finally, I've been quite impressed with Delphi's Visual Component
> > Library (VCL).
>
> That's interesting, because we are using the VCL quite heavily. One of our
> customers explicitly ordered that. Now, my impression is opposite to yours:
> it is safer, *quicker*, cleaner, an far more maintainable to develop GUI in
> *raw* Windows API than in VCL. As a bonus, you can get rid of that awful
> Borland C++, use VC++ or gcc instead.

Oh, right, the VCL *WAS* ported-over-to/interfaced-with Borland's C
Builder. I'm utterly unfamiliar with that incarnation of the VCL as my
experience with it has been on the Delphi (Object Pascal) side.

But the problem is that wrapping the API calls, and management of the
returned references, in objects yields something similar-in-structure
to the VCL, no?

I'm not saying that things couldn't have been done better; they could
have. But for being a useful object-oriented GUI library tied to a
singular API (Windows) I think it's done pretty well.

The idea we've been kicking around about a truly portable GUI library
with attention to type-safety and [hopefully] prevention of Bad Things
(insofar as they can be prevented, thus your desire for a statically-
checked GUI library) is an order of magnitude more complex. -- Though
I myself would like to see just such a portable GUI library done in
Ada.

>
> > Microsoft's MFC and Java's JFC seem to have been
> > 'inspired' [or copied] from the VCL, but neither presents itself as
> > uniform & usable/mature [if you will] as the VCL.
>
> We dropped MFC long ago and never returned to it. We didn't use JFC, so I  cannot say anything about it.

Imagine the VCL, then take away all the inherited handling of events
and make them all purely java-interfaces (so in order to handle events
you have to create some class which implements the interface; this is
usually cone in-line/via-anonymous-class), and you basically have
something similar to the JFC.

Re: Properties

[Randy Brukardt]

"Shark8" <onewingedshark@gmail.com> wrote in message 
news:75475874-cd6c-4e75-8a2f-7675ecf0864a@f20g2000vbc.googlegroups.com...
...
>It is somewhat irritating that you cannot initialize element to
>GUI_Base'Class directly.

You can do this with the Ada containers.

>Attempting the following
>   Package GUI_Vector is New Ada.Containers.Vectors
>( Element_Type => GUI_Base'Class, Index_Type => Positive );
>yields
>instantiation error at a-convec.ads:321
>"unconstrained element type in array declaration actual for
>"Element_Type" must be a definite subtype"

Right, but you are using the wrong container for this. Try the indefinite 
containers (designed specifically for this purpose):

Package GUI_Vector is New Ada.Containers.Indefinite_Vectors
   ( Element_Type => GUI_Base'Class, Index_Type => Positive );

This will work fine.

                              Randy.



What's wrong with say initializing Ada.Containers.Vector with Positive
=> Index and Element => Access_GUI_Base_Class*?

*Type Access_GUI_Base_Class is Access GUI_Base'Class;

It would be nice to throw a "Not null" in because storing a 'pointer'
to "not an object" is pretty dumb... but that gives this error-set:
warning: in instantiation at a-convec.adb:1196
warning: (Ada 2005) null-excluding objects must be initialized
warning: "Constraint_Error" will be raised at run time
warning: in instantiation at a-convec.adb:1209
warning: (Ada 2005) null-excluding objects must be initialized
warning: "Constraint_Error" will be raised at run time

It's almost as if it's saying that we couldn't ever use the container
exclusively like this:

Vector : GUI_Vector.Vector:= GUI_Vector.Empty_Vector;
Component_1 : Aliased GUI_Base'Class:= Make_Component( ... );
--...
Component_n : Aliased GUI_Base'Class:= Make_Component( ... );
begin
 Vector.Add( Component_1'Access );
--...
 Vector.Add( Component_n'Access );
--the work
end;

>This raises another question. Ada
> does not support abstract access types. You want a reference to the widget
> be a fat pointer transparent to all widget operations with automatic
> collection of widget objects. This almost works in Ada, but it is 
> extremely
> boring to do.

[snip]
> The bottom line, interfaces must be removed from Ada.
> Instead of that an interface must be made inheritable
> from any concrete type. This is the same idea as with
> abstract record, array etc types.

Wouldn't this be alleviated by two things:
Allowing INTERFACE [keyword] objects to have fields (properties as
I've described, or somesuch)?
Allowing objects some sort of self/this/me attribute where the result
is a Not Null Access to its classwide-type*? (Or am I misunderstanding
what you mean by the need for "a fat pointer transparent to all widget
operations"?)

*Or is this the equivalent of requiring all such variables to be
Aliased?

>
> type Widget_Handle is private Widget; -- Like the widget, but isn't
> private
> type Widget_Handle is new Ada.Limited_Controlled with record
> Ptr : access Widget;
> end record;
>
> For access types there must be delegation support, which should eliminate
> need in wrappers. There are other issues as well, like that "access 
> Widget"
> is purposely not "access Widget'Class."
>
> > Finally, I've been quite impressed with Delphi's Visual Component
> > Library (VCL).
>
> That's interesting, because we are using the VCL quite heavily. One of our
> customers explicitly ordered that. Now, my impression is opposite to 
> yours:
> it is safer, *quicker*, cleaner, an far more maintainable to develop GUI 
> in
> *raw* Windows API than in VCL. As a bonus, you can get rid of that awful
> Borland C++, use VC++ or gcc instead.

Oh, right, the VCL *WAS* ported-over-to/interfaced-with Borland's C
Builder. I'm utterly unfamiliar with that incarnation of the VCL as my
experience with it has been on the Delphi (Object Pascal) side.

But the problem is that wrapping the API calls, and management of the
returned references, in objects yields something similar-in-structure
to the VCL, no?

I'm not saying that things couldn't have been done better; they could
have. But for being a useful object-oriented GUI library tied to a
singular API (Windows) I think it's done pretty well.

The idea we've been kicking around about a truly portable GUI library
with attention to type-safety and [hopefully] prevention of Bad Things
(insofar as they can be prevented, thus your desire for a statically-
checked GUI library) is an order of magnitude more complex. -- Though
I myself would like to see just such a portable GUI library done in
Ada.

>
> > Microsoft's MFC and Java's JFC seem to have been
> > 'inspired' [or copied] from the VCL, but neither presents itself as
> > uniform & usable/mature [if you will] as the VCL.
>
> We dropped MFC long ago and never returned to it. We didn't use JFC, so I 
> cannot say anything about it.

Imagine the VCL, then take away all the inherited handling of events
and make them all purely java-interfaces (so in order to handle events
you have to create some class which implements the interface; this is
usually cone in-line/via-anonymous-class), and you basically have
something similar to the JFC. 

Re: Properties

[Shark8]

On Dec 3, 2:14 pm, "Randy Brukardt" <ra...@rrsoftware.com> wrote:
> Right, but you are using the wrong container for this.
> Try the  indefinite containers (designed specifically for
> this purpose):
>
> Package GUI_Vector is New Ada.Containers.Indefinite_Vectors
>   ( Element_Type => GUI_Base'Class, Index_Type => Positive );
>
> This will work fine.
>
>                              Randy.

Oh wow! / Nice... As I've admitted I'm a newcomer to Ada, so there's a
lot to [still] learn.

I kept thinking "there's GOT to be some reason that it won't let me do
that... maybe I'm just not understanding something here..."

Just a quick question, but why was it necessary to have two sets of
containers, one for the indefinates and one for the definites?

Re: Properties

[Peter C. Chapin]

On 2010-12-04 00:35, Shark8 wrote:

> Just a quick question, but why was it necessary to have two sets of
> containers, one for the indefinates and one for the definites?

Each instance of an indefinite type can have different sizes. For example

procedure Example is
   S1 : String(1 .. 10);
   S2 : String(1 .. 100);
begin
  null;
end Example;

S1 and S2 occupy different amounts of memory. The indefinite containers
deal with this by using access values internally. That is an indefinite
vector of strings actually stores String access values (pointers) and
manages that extra indirection internally so you aren't exposed to it.
This allows strings of different sizes to be stored in the vector in a
uniform way. The price is extra overhead and slightly less efficiency.

Class wide types are also indefinite because an instance of a class wide
type can be one of several different types in the class (all with
potentially different sizes).

Peter

Re: Properties

[Shark8]

On Dec 4, 7:23 am, "Peter C. Chapin" <PCha...@vtc.vsc.edu> wrote:
> On 2010-12-04 00:35, Shark8 wrote:
>
> > Just a quick question, but why was it necessary to have two sets of
> > containers, one for the indefinates and one for the definites?
>
> Each instance of an indefinite type can have different sizes. For example
>
> procedure Example is
>    S1 : String(1 .. 10);
>    S2 : String(1 .. 100);
> begin
>   null;
> end Example;
>
> S1 and S2 occupy different amounts of memory. The indefinite containers
> deal with this by using access values internally. That is an indefinite
> vector of strings actually stores String access values (pointers) and
> manages that extra indirection internally so you aren't exposed to it.
> This allows strings of different sizes to be stored in the vector in a
> uniform way. The price is extra overhead and slightly less efficiency.
>
> Class wide types are also indefinite because an instance of a class wide
> type can be one of several different types in the class (all with
> potentially different sizes).
>
> Peter

Ok, I suspected this was the answer but wanted to make sure.
Thank you for verifying it.

Re: Properties

[Brian Drummond]

On Fri, 3 Dec 2010 15:14:09 -0600, "Randy Brukardt" <randy@rrsoftware.com>
wrote:

>"Shark8" <onewingedshark@gmail.com> wrote in message 
>news:75475874-cd6c-4e75-8a2f-7675ecf0864a@f20g2000vbc.googlegroups.com...
>...
>>It is somewhat irritating that you cannot initialize element to
>>GUI_Base'Class directly.
...
>>instantiation error at a-convec.ads:321
>>"unconstrained element type in array declaration actual for
>>"Element_Type" must be a definite subtype"
>
>Right, but you are using the wrong container for this. Try the indefinite 
>containers (designed specifically for this purpose):
>
>Package GUI_Vector is New Ada.Containers.Indefinite_Vectors
>   ( Element_Type => GUI_Base'Class, Index_Type => Positive );
>
>This will work fine.

Excellent! 
But perhaps the error message could be improved to suggest this, e.g.

>>"unconstrained element type in array declaration actual for
>>"Element_Type" must be a definite subtype, or container must be indefinite"

- Brian

Re: Properties

[Dmitry A. Kazakov]

On Fri, 3 Dec 2010 11:52:22 -0800 (PST), Shark8 wrote:

> On Dec 3, 2:05�am, "Dmitry A. Kazakov" <mail...@dmitry-kazakov.de>
> wrote:
>> The bottom line, interfaces must be removed from Ada.
>> Instead of that an interface must be made inheritable
>> from any concrete type. This is the same idea as with
>> abstract record, array etc types.
> 
> Wouldn't this be alleviated by two things:
> Allowing INTERFACE [keyword] objects to have fields (properties as
> I've described, or somesuch)?

These are different problems:

1. Record interface, this is in effect what you proposed:

   type Members is interface record
       A : Integer; -- Not a physical member only an interface "Object.A"
   end record;

[I want other interfaces too, like array interface, access interface etc.]

2. Interface inheritance. Let you have some type:

   type T is tagged ...
   procedure Foo (X : T);

You have to replace it to

   type Interface_of_T is interface;
   procedure Foo (X : Interface_T) is abstract;

   type T is ... and Interface_of_T ...
   overriding procedure Foo (X : T);

In order to be able to say:

   type S is ... and Interface_of_T ...
   overriding procedure Foo (X : S);

It is boring. Each type obviously has an interface, which must be
inheritable from.

> Allowing objects some sort of self/this/me attribute where the result
> is a Not Null Access to its classwide-type*? (Or am I misunderstanding
> what you mean by the need for "a fat pointer transparent to all widget
> operations"?)

I mean this:

   -- Anything you can do with a widget
   type Widget_Interface is limited interface;
   procedure Draw (Object : in out Widget_Interface) is abstract;
   ...

   -- Implementation of a widget
   type Widget_Object is new Widget_Interface with ...;
   overriding procedure Draw (Object : in out Widget_Object);

   type Widget_Object_Ptr is access all Widget_Object;

   -- Public interface of a widget, a reference
   type Widget is new Ada.Finalization.Controlled and Widget_Interface with
   record
      Ptr : Widget_Object_Ptr;
   end record;
   overriding procedure Draw (Object : in out Widget);

   procedure Draw (Object : in out Widget) is
   begin
      Draw (Object.Ptr.all);
   end Draw;

Widget_Object is private, publicly accessible is its fat pointer/handle
Widget. Both implement the same interface Widget_Interface.

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

Re: Properties

[Shark8]

On Dec 3, 3:38 pm, "Dmitry A. Kazakov" <mail...@dmitry-kazakov.de>
wrote:
> On Fri, 3 Dec 2010 11:52:22 -0800 (PST), Shark8 wrote:
> > On Dec 3, 2:05 am, "Dmitry A. Kazakov" <mail...@dmitry-kazakov.de>
> > wrote:
> >> The bottom line, interfaces must be removed from Ada.
> >> Instead of that an interface must be made inheritable
> >> from any concrete type. This is the same idea as with
> >> abstract record, array etc types.
>
> > Wouldn't this be alleviated by two things:
> > Allowing INTERFACE [keyword] objects to have fields (properties as
> > I've described, or somesuch)?
>
> These are different problems:
>
> 1. Record interface, this is in effect what you proposed:
>
>    type Members is interface record
>        A : Integer; -- Not a physical member only an interface "Object.A"
>    end record;
>
> [I want other interfaces too, like array interface, access interface etc.]
>
> 2. Interface inheritance. Let you have some type:
>
>    type T is tagged ...
>    procedure Foo (X : T);
>
> You have to replace it to
>
>    type Interface_of_T is interface;
>    procedure Foo (X : Interface_T) is abstract;
>
>    type T is ... and Interface_of_T ...
>    overriding procedure Foo (X : T);
>
> In order to be able to say:
>
>    type S is ... and Interface_of_T ...
>    overriding procedure Foo (X : S);
>
> It is boring. Each type obviously has an interface, which must be
> inheritable from.
>
> > Allowing objects some sort of self/this/me attribute where the result
> > is a Not Null Access to its classwide-type*? (Or am I misunderstanding
> > what you mean by the need for "a fat pointer transparent to all widget
> > operations"?)
>
> I mean this:
>
>    -- Anything you can do with a widget
>    type Widget_Interface is limited interface;
>    procedure Draw (Object : in out Widget_Interface) is abstract;
>    ...
>
>    -- Implementation of a widget
>    type Widget_Object is new Widget_Interface with ...;
>    overriding procedure Draw (Object : in out Widget_Object);
>
>    type Widget_Object_Ptr is access all Widget_Object;
>
>    -- Public interface of a widget, a reference
>    type Widget is new Ada.Finalization.Controlled and Widget_Interface with
>    record
>       Ptr : Widget_Object_Ptr;
>    end record;
>    overriding procedure Draw (Object : in out Widget);
>
>    procedure Draw (Object : in out Widget) is
>    begin
>       Draw (Object.Ptr.all);
>    end Draw;
>
> Widget_Object is private, publicly accessible is its fat pointer/handle
> Widget. Both implement the same interface Widget_Interface.
>
> --
> Regards,
> Dmitry A. Kazakovhttp://www.dmitry-kazakov.de

Ah, I see!
Delphi has the nice ability to delegate the implementation for an
interface... so the analog to your type widget would be:

Type
  {TObject is the root-object in Delphi}
  TWidget = Class( TObject, Widget_Interface )
   public
     Object : ^Widget_Object implements Widget_Interface;
  end; {Class TWidget}

And then all calls to objects of TWidget via Widget_Interface are
automatically routed to the Object field.

Re: Properties

[Georg Bauhaus]

On 12/3/10 8:52 PM, Shark8 wrote:
> On Dec 3, 2:05 am, "Dmitry A. Kazakov"<mail...@dmitry-kazakov.de>
> wrote:
>>> Why not have an INTERFACE hierarchy in addition to the GUI_Object
>>> hierarchy?
>>
>> Hmm, isn't it same? To me interface = abstract type.
>
> Usually they are interchangeable, but INTERFACES are the only way in
> Ada to do something akin to multiple inheritance:

One of the three ways to do something akin
to multiple inheritance is mixin generics.