Structured exception information

Structured exception information

[Maciej Sobczak]

Hi,

Consider an object created by a constructor function:

X : My_Type := My_Constructor(Some_Parameters);

My_Type is Controlled_Limited to ensure control over initialization and 
finalization. The idea of constructor function is to prevent the 
existence of objects that are not yet initialized, half-baked, in a bad 
state, etc. If the object exists, it's ready for use.

If there are problems during the execution of the constructor function, 
the exception is raised, so that there is no X object in a bad state.
How can I pass some error information from the constructor function out, 
so that it's used when the exception is handled?
Obviously, some message can be attached to the exception occurence, but 
it doesn't scale well - I might want to pass some more data, possibly 
structured (some error code, some reason code, some timestamp, some 
whatever else, ...).

Yes, I'm asking for "throwing objects", in the C++ parlance.

How to do this in Ada?
If I cannot - how to solve this design problem?

BTW - How can I ensure in a general way that the constructor function 
must be used to initialize the object, otherwise compile-time error is 
reported?
If I make My_Type a discriminated type (so that the discriminant value 
is used in the default initialization), does it limit anything, like 
constructor parameter types?

-- 
Maciej Sobczak : http://www.msobczak.com/
Programming    : http://www.msobczak.com/prog/

Re: Structured exception information

[claude.simon]

[-- Warning: decoded text below may be mangled, UTF-8 assumed --]
[-- Attachment #1: Type: text/plain; charset="us-ascii", Size: 1747 bytes --]

when My_Type is an indefinite subtype.

type My_type (<>) is ... for example

Then, when you declare an object of that type you must provide an
initialization expression (a constructor call !).

Maciej Sobczak a écrit :
> Hi,
>
> Consider an object created by a constructor function:
>
> X : My_Type := My_Constructor(Some_Parameters);
>
> My_Type is Controlled_Limited to ensure control over initialization and
> finalization. The idea of constructor function is to prevent the
> existence of objects that are not yet initialized, half-baked, in a bad
> state, etc. If the object exists, it's ready for use.
>
> If there are problems during the execution of the constructor function,
> the exception is raised, so that there is no X object in a bad state.
> How can I pass some error information from the constructor function out,
> so that it's used when the exception is handled?
> Obviously, some message can be attached to the exception occurence, but
> it doesn't scale well - I might want to pass some more data, possibly
> structured (some error code, some reason code, some timestamp, some
> whatever else, ...).
>
> Yes, I'm asking for "throwing objects", in the C++ parlance.
>
> How to do this in Ada?
> If I cannot - how to solve this design problem?
>
> BTW - How can I ensure in a general way that the constructor function
> must be used to initialize the object, otherwise compile-time error is
> reported?
> If I make My_Type a discriminated type (so that the discriminant value
> is used in the default initialization), does it limit anything, like
> constructor parameter types?
>
> --
> Maciej Sobczak : http://www.msobczak.com/
> Programming    : http://www.msobczak.com/prog/

Re: Structured exception information

[Maciej Sobczak]

claude.simon@equipement.gouv.fr wrote:

> when My_Type is an indefinite subtype.
> 
> type My_type (<>) is ... for example
> 
> Then, when you declare an object of that type you must provide an
> initialization expression (a constructor call !).

If I understand correctly:

procedure Hello is

    package P is
       type T(<>) is private;
       function Constructor(S : String) return T;
    private
       type T(I : Integer) is
          record
             null;
          end record;
    end P;

    package body P is
       function Constructor(S : String) return T is
       begin
          return (I => 0);
       end Constructor;
    end P;

    X : P.T := P.Constructor("some params");

begin
    null;
end Hello;

(of course, package is nested for presentation only)

I have initially thought that discriminated types limit me in terms of 
what parameter types can be used for constructing them, but actually 
there is no such limitation - constructor function can have whatever 
parameter types it wants and the discriminant is irrelevant.

It does not feel like a genuine part of the object model (you know, in 
C++ it is much simpler, more readable, maintainable, etc. ;-) ), but 
seems to work.


OK, so putting aside the fact that my compiler can not swallow it, is it 
possible to make T Limited_Controlled as well?

This is my guess:

-- file p.ads
with Ada.Finalization;
package P is
    type T(<>) is limited private;
    function Constructor(S : String) return T;
private
    type T(I : Integer) is new Ada.Finalization.Limited_Controlled with
       record
          null;
       end record;
end P;

-- file p.adb
package body P is
    function Constructor(S : String) return T is
    begin
       return (I => 0);  -- NOTE
    end Constructor;
end P;

-- file hello.adb
with P;
procedure Hello is
    X : P.T := P.Constructor("some params");
begin
    null;
end Hello;

It should be impossible to create X in any other way - this is the exact 
effect that I want to achieve.

My compiler does not like it (but it's not really Ada2005), so I cannot 
verify it. Is the code above correct?

BTW - in the line marked as NOTE the compiler says that aggregate type 
cannot be limited. Is it true for Ada2005?

-- 
Maciej Sobczak : http://www.msobczak.com/
Programming    : http://www.msobczak.com/prog/

Re: Structured exception information

[Randy Brukardt]

"Maciej Sobczak" <no.spam@no.spam.com> wrote in message
news:eoi4fg$to8$1@cernne03.cern.ch...
> claude.simon@equipement.gouv.fr wrote:
...
> It should be impossible to create X in any other way - this is the exact
> effect that I want to achieve.
>
> My compiler does not like it (but it's not really Ada2005), so I cannot
> verify it. Is the code above correct?

I think so, but since I don't have a new compiler to try it on, either, I
can't say for absolutely certain.

> BTW - in the line marked as NOTE the compiler says that aggregate type
> cannot be limited. Is it true for Ada2005?

No, aggregates can be defined for limited types, just like functions can be
defined for limited types. That's all new.

                       Randy.

Re: Structured exception information

[Robert A Duff]

Maciej Sobczak <no.spam@no.spam.com> writes:

> If there are problems during the execution of the constructor function,
> the exception is raised, so that there is no X object in a bad state.
> How can I pass some error information from the constructor function out,
> so that it's used when the exception is handled?

There is no good way to do this in Ada.  You can attach any information
you like to an exception, if you are willing to encode it as a String --
but then you lose static type checking.  You can put the info in a
global variable, but that's bad for several reasons (not task safe,
can be accessed outside of any handler, ...).  You can put the info in a
Task_Attribute, but that's rather a pain -- verbose and inefficient.

- Bob

Re: Structured exception information

[Georg Bauhaus]

On Mon, 2007-01-15 at 12:28 -0500, Robert A Duff wrote:
> Maciej Sobczak <no.spam@no.spam.com> writes:
> 
> > If there are problems during the execution of the constructor function,
> > the exception is raised, so that there is no X object in a bad state.
> > How can I pass some error information from the constructor function out,
> > so that it's used when the exception is handled?
> 
> There is no good way to do this in Ada.  You can attach any information
> you like to an exception, if you are willing to encode it as a String --
> but then you lose static type checking.  You can put the info in a
> global variable, but that's bad for several reasons (not task safe,
> can be accessed outside of any handler, ...).  You can put the info in a
> Task_Attribute, but that's rather a pain -- verbose and inefficient.

I'm still wondering whether or not an Ada compiler could provide
a special kind of closure for this case? We do already get stack
traces. (I don't know compilers so this is just a guess...)

package Handling is
   
   --
   -- info to be attached to an exception occurence
   --
   
   type State is tagged record
      info: Integer;
   end record;
   
end Handling;


with Handling;  use Handling;
procedure foo is
   
   x: Integer;
   
   function Env return State'class is
   begin
      return State'(info => x);
   end Env;
   
begin
   if 1 > 1 then
      raise Constraint_Error with Env'access;
   end if;
end foo;

Re: Structured exception information

[Dmitry A. Kazakov]

On Mon, 15 Jan 2007 19:29:31 +0100, Georg Bauhaus wrote:

> On Mon, 2007-01-15 at 12:28 -0500, Robert A Duff wrote:
>> Maciej Sobczak <no.spam@no.spam.com> writes:
>> 
>>> If there are problems during the execution of the constructor function,
>>> the exception is raised, so that there is no X object in a bad state.
>>> How can I pass some error information from the constructor function out,
>>> so that it's used when the exception is handled?
>> 
>> There is no good way to do this in Ada.  You can attach any information
>> you like to an exception, if you are willing to encode it as a String --
>> but then you lose static type checking.  You can put the info in a
>> global variable, but that's bad for several reasons (not task safe,
>> can be accessed outside of any handler, ...).  You can put the info in a
>> Task_Attribute, but that's rather a pain -- verbose and inefficient.
> 
> I'm still wondering whether or not an Ada compiler could provide
> a special kind of closure for this case?

When closures should be supported then they should not be any special...

> We do already get stack
> traces. (I don't know compilers so this is just a guess...)
> 
> package Handling is
>    
>    --
>    -- info to be attached to an exception occurence
>    --
>    
>    type State is tagged record
>       info: Integer;
>    end record;
>    
> end Handling;
> 
> 
> with Handling;  use Handling;
> procedure foo is
>    
>    x: Integer;
>    
>    function Env return State'class is
>    begin
>       return State'(info => x);
>    end Env;
>    
> begin
>    if 1 > 1 then
>       raise Constraint_Error with Env'access;
>    end if;
> end foo;

Ada 2005 will allow non-library-level extensions. So? What if Env were
declared within Foo?

Exceptions are usually considered as non-local jumps. But there is also
another mental model possible. One could consider them as a kind of
rendezvous with the handler.

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

Re: Structured exception information

[Georg Bauhaus]

On Mon, 2007-01-15 at 20:44 +0100, Dmitry A. Kazakov wrote:
> On Mon, 15 Jan 2007 19:29:31 +0100, Georg Bauhaus wrote:
>  (I don't know compilers so this is just a guess...)
> > 
> > package Handling is
> >    
> >    --
> >    -- info to be attached to an exception occurence
> >    --
> >    
> >    type State is tagged record
> >       info: Integer;
> >    end record;
> >    
> > end Handling;
> > 
> > 
> > with Handling;  use Handling;
> > procedure foo is
> >    
> >    x: Integer;
> >    
> >    function Env return State'class is
> >    begin
> >       return State'(info => x);
> >    end Env;
> >    
> > begin
> >    if 1 > 1 then
> >       raise Constraint_Error with Env'access;
> >    end if;
> > end foo;
> 
> Ada 2005 will allow non-library-level extensions. So? What if Env were
> declared within Foo?

(I assume you mean some type that extends State within foo.)
Yes, perhaps
(a) the nesting level of the handler, together with
(b) which ancestor is visible there,
would have to "influence" access to the components of an
extension of State.  (Another wild guess.)

Re: Structured exception information

[Randy Brukardt]

"Georg Bauhaus" <bauhaus@arcor.de> wrote in message
news:1168891576.30643.39.camel@localhost...
> On Mon, 2007-01-15 at 20:44 +0100, Dmitry A. Kazakov wrote:
> > On Mon, 15 Jan 2007 19:29:31 +0100, Georg Bauhaus wrote:
> >  (I don't know compilers so this is just a guess...)
> > >
> > > package Handling is
> > >
> > >    --
> > >    -- info to be attached to an exception occurence
> > >    --
> > >
> > >    type State is tagged record
> > >       info: Integer;
> > >    end record;
> > >
> > > end Handling;
> > >
> > >
> > > with Handling;  use Handling;
> > > procedure foo is
> > >
> > >    x: Integer;
> > >
> > >    function Env return State'class is
> > >    begin
> > >       return State'(info => x);
> > >    end Env;
> > >
> > > begin
> > >    if 1 > 1 then
> > >       raise Constraint_Error with Env'access;
> > >    end if;
> > > end foo;
> >
> > Ada 2005 will allow non-library-level extensions. So? What if Env were
> > declared within Foo?
>
> (I assume you mean some type that extends State within foo.)
> Yes, perhaps
> (a) the nesting level of the handler, together with
> (b) which ancestor is visible there,
> would have to "influence" access to the components of an
> extension of State.  (Another wild guess.)

Yuck. One of the invariants of Ada is that an object of a type can never
outlive its type. Probably the way to handle this would be the same as
streaming is handled. After all, the state is should be an extension of some
predefined type (so that resolution will work properly).
The effect would be that:

      raise Constraint_Error with Env'access;

would raise Program_Error for a failed accessibility check.

We did look at this issue when working on the Amendment. The "obvious"
answers seem to have issues with visibility and compatibility with existing
Ada.Exceptions mechanisms. We sent the proposal back to the author, and
never got an improved proposal. Thus, it got dropped (no reflection on
importance; can't do anything without a proposal). In hindsight, it probably
should have been assigned to someone else, but it wasn't.

                                             Randy.

Re: Structured exception information

[Robert A Duff]

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

> We did look at this issue when working on the Amendment. The "obvious"
> answers seem to have issues with visibility and compatibility with existing
> Ada.Exceptions mechanisms.

If we had done it right in Ada 95, we wouldn't have had the
Ada.Exceptions kludge in the first place, so no need to be complatible
with it.

I don't know what the visibility issues were, so I can't comment on
that.  Do you happen to know which AI this was?

Rant:

The attitude about this feature during Ada 9X seemed to be:

    1. Folks should not overuse exceptions.  (I agree.)

    2. Therefore, we should make exceptions painful to use.  (Sorry,
       that does not follow.)

The problem with (2) is: what about the cases where exceptions ARE
appropriate?  Pushing people in the direction of encoding information
un-type-safely as Strings, or using global variables, or whatever is not
helpful.  It's like removing the guard rail from a dangerous curve in
order to make drivers slow down.

The language designer should alway assume that programmers are competent
-- in this case, that they can decide whether exceptions are appropriate
in any given case -- and not try to prevent people from doing bad
things.  (Preventing people from doing bad things by accident, however,
is Good Language Design.)

- Bob

Re: Structured exception information

[Ray Blaak]

Robert A Duff <bobduff@shell01.TheWorld.com> writes:
> "Randy Brukardt" <randy@rrsoftware.com> writes:
> 
> > We did look at this issue when working on the Amendment. The "obvious"
> > answers seem to have issues with visibility and compatibility with existing
> > Ada.Exceptions mechanisms.
> 
> If we had done it right in Ada 95, we wouldn't have had the
> Ada.Exceptions kludge in the first place, so no need to be complatible
> with it.
> 
> I don't know what the visibility issues were, so I can't comment on
> that.  Do you happen to know which AI this was?

It is things like this that make Ada no longer be my favourite language.

Ada's whole approach to OO, while powerful, makes it inconvenient to express
things that are easily done in other languages. At least Ada 2005 is improving
things.

With regard to structured exceptions, other languages have done it, and the
problems preventing from being done well in Ada seem artificial. Why can't it
just work conveniently for the programmer?

C# is now my new favourite language, and I find it is more or less as typesafe
as it needs to be, with "good enough" features for programming in the large.

And it has garbage collection!

-- 
Cheers,                                        The Rhythm is around me,
                                               The Rhythm has control.
Ray Blaak                                      The Rhythm is inside me,
rAYblaaK@STRIPCAPStelus.net                    The Rhythm has my soul.

C# versus Ada (was: Structured exception information)

[Georg Bauhaus]

On Tue, 2007-01-16 at 18:36 +0000, Ray Blaak wrote:

> C# is now my new favourite language, and I find it is more or less as typesafe
> as it needs to be, with "good enough" features for programming in the large.

Are you using C#/.NET threads? What do you think about the "ease" of
having Windows threads communicate, and share data, compared to
Ada's tasks and protected objects?

> And it has garbage collection!

Garbage collection is a property of all language implementations
targeting .NET or the JVM, so it's rather a property of the
implementation not the language. You could use A#, too,
or AppletMagic, etc. :-)


 -- Georg 

Re: C# versus Ada

[Markus E Leypold]

Georg Bauhaus <bauhaus@arcor.de> writes:

> On Tue, 2007-01-16 at 18:36 +0000, Ray Blaak wrote:

>
>> And it has garbage collection!
>
> Garbage collection is a property of all language implementations
> targeting .NET or the JVM, so it's rather a property of the
> implementation not the language. You could use A#, too,
> or AppletMagic, etc. :-)

I don't know. The requirement of garbage collection stems from the run
time, so the languages had to be modified. It's still a property of
the language definition.

Regards -- Markus

Re: C# versus Ada

[Dmitry A. Kazakov]

On Wed, 17 Jan 2007 00:29:02 +0100, Markus E Leypold wrote:

> Georg Bauhaus <bauhaus@arcor.de> writes:
> 
>> On Tue, 2007-01-16 at 18:36 +0000, Ray Blaak wrote:
>>
>>> And it has garbage collection!
>>
>> Garbage collection is a property of all language implementations
>> targeting .NET or the JVM, so it's rather a property of the
>> implementation not the language. You could use A#, too,
>> or AppletMagic, etc. :-)
> 
> I don't know. The requirement of garbage collection stems from the run
> time, so the languages had to be modified. It's still a property of
> the language definition.

Yes. I a well-defined language there should be almost no need in GC. Ada is
close to that.

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

Re: C# versus Ada (was: Structured exception information)

[Ray Blaak]

Georg Bauhaus <bauhaus@arcor.de> writes:
> On Tue, 2007-01-16 at 18:36 +0000, Ray Blaak wrote:
> > C# is now my new favourite language, and I find it is more or less as typesafe
> > as it needs to be, with "good enough" features for programming in the large.
> 
> Are you using C#/.NET threads? What do you think about the "ease" of
> having Windows threads communicate, and share data, compared to
> Ada's tasks and protected objects?

Well, it's a trade off. In general I prefer the C# model, since is is easier
to set up threads and have them freely talk to each other.

One probably does have to worry about deadlocks more, but I am prepared for
that, and tend to reason about these interactions very carefully, lock things
into critical sections, etc. It seems easier to have shared objects to use at
will.

I have not done as much Ada tasking, but from what I recall, setting up the
rendevous sections seems to require a lot more planning. Protected objects I
am less familiar with.

I suppose I prefer the greater freedom in C# (and in Java for that matter).
Also, the mental model of a thread being just another kind of good old Object
fits my intuition better. With Ada one requires 2 or 3 distinct language
mechanisms (tasks, protected objects, tagged types) to all work together.

I won't dispute Ada's model as being more careful and correct, with finer
controls useful for systems and embedded programming, but it seems more
complex to use properly in the common cases.

> 
> > And it has garbage collection!
> 
> Garbage collection is a property of all language implementations
> targeting .NET or the JVM, so it's rather a property of the
> implementation not the language. You could use A#, too,
> or AppletMagic, etc. :-)

Good point.

Still, in Java and C#, it's in the language itself. All implementations have it.

It should be that way in Ada too, so that "compiled" executables can have it
as well.

-- 
Cheers,                                        The Rhythm is around me,
                                               The Rhythm has control.
Ray Blaak                                      The Rhythm is inside me,
rAYblaaK@STRIPCAPStelus.net                    The Rhythm has my soul.

Re: Structured exception information

[Markus E Leypold]

> It is things like this that make Ada no longer be my favourite language.
>
> Ada's whole approach to OO, while powerful, makes it inconvenient to express
> things that are easily done in other languages. 

Unfortunately that applies to all languages that where subtyping
polymorphism is coupled to implementation inheritance. That's why
"factory patterns" had to be invented and they don't really work. 

If you want to have a look at a language where implementation
inheritance and subtyping polymorphism are completely decoupled, have
a look at i.e. OCaml. Together with type parameters that makes for
real powerful OO.

Regards -- Markus

Re: Structured exception information

[Martin Krischik]

Ray Blaak schrieb:

> With regard to structured exceptions, other languages have done it, and the
> problems preventing from being done well in Ada seem artificial. Why can't it
> just work conveniently for the programmer?

You forgot: Other languages don't have task types or ANNEX E.

Recently did a Weblogic course and to my surprise learned that if the 
server applications raises an exception A that the client will receive 
exception B with B being either ...UserException or ...SystemException 
(can't recall the exact names) and all extra informations lost.

I found that very restricting and not a solution I which for in Ada.

But as Randy pointed out: With external streaming it might be possible. 
Maybe next time round.


Martin

Re: Structured exception information

[Randy Brukardt]

"Robert A Duff" <bobduff@shell01.TheWorld.com> wrote in message
news:wcc64b7or96.fsf@shell01.TheWorld.com...
> "Randy Brukardt" <randy@rrsoftware.com> writes:
>
> > We did look at this issue when working on the Amendment. The "obvious"
> > answers seem to have issues with visibility and compatibility with
existing
> > Ada.Exceptions mechanisms.
>
> If we had done it right in Ada 95, we wouldn't have had the
> Ada.Exceptions kludge in the first place, so no need to be complatible
> with it.

Well, don't look at me on that one... ;-)

> I don't know what the visibility issues were, so I can't comment on
> that.  Do you happen to know which AI this was?

Not off-hand, but it only takes a minute to look up...

It was AI-264, "Exceptions as types". The title alone suggests trouble: the
main issue is to provide type-safe data along with exceptions. The minor
issue is a better way to deal with sets of exceptions. Neither of those
necessarily require making exceptions into types.

My personal feeling is that we solved a lot of the problems that we had with
the exception proposal when we dealt with all of the issues that nested
tagged types brought up. When we considered AI-264, we hadn't yet gone
through that exercise, and the entire thing looked impossible. Having solved
some of the related issues, it would be easier to deal with now. It would be
even easier if we had a mechanism for user-defined 'Image (which would allow
automatic converting to strings to keep the existing Ada.Exceptions routines
working).

                                      Randy.

Re: Structured exception information

[Bob Spooner]

"Randy Brukardt" <randy@rrsoftware.com> wrote in message 
news:J_udnYhOH7i4zjDYnZ2dnUVZ_r2onZ2d@megapath.net...
> ...
> My personal feeling is that we solved a lot of the problems that we had 
> with
> the exception proposal when we dealt with all of the issues that nested
> tagged types brought up. When we considered AI-264, we hadn't yet gone
> through that exercise, and the entire thing looked impossible. Having 
> solved
> some of the related issues, it would be easier to deal with now. It would 
> be
> even easier if we had a mechanism for user-defined 'Image (which would 
> allow
> automatic converting to strings to keep the existing Ada.Exceptions 
> routines
> working).
Would a possible mechanism for user-defined 'Image be to allow the default 
to be overridden the way 'Read and 'Write attributes can be overridden? For 
the case of something with no 'Image attribute, one would be defined by the 
"override."
    Bob
>
>                                      Randy.
>
>
> 

Re: Structured exception information

[Randy Brukardt]

"Bob Spooner" <rls19@psu.edu> wrote in message
news:eolhua$1fnm$1@f04n12.cac.psu.edu...
> "Randy Brukardt" <randy@rrsoftware.com> wrote in message
> news:J_udnYhOH7i4zjDYnZ2dnUVZ_r2onZ2d@megapath.net...
...
> > It would be
> > even easier if we had a mechanism for user-defined 'Image (which would
allow
> > automatic converting to strings to keep the existing Ada.Exceptions
routines
> > working).

> Would a possible mechanism for user-defined 'Image be to allow the default
> to be overridden the way 'Read and 'Write attributes can be overridden?
For
> the case of something with no 'Image attribute, one would be defined by
the
> "override."

I was thinking of something like that. But that is a completely unbaked idea
at the moment; there's probably some ugly problem that I haven't thought of.

                             Randy.

Re: Structured exception information

[Dmitry A. Kazakov]

On Mon, 15 Jan 2007 15:56:14 -0600, Randy Brukardt wrote:

> Yuck. One of the invariants of Ada is that an object of a type can never
> outlive its type. Probably the way to handle this would be the same as
> streaming is handled. After all, the state is should be an extension of some
> predefined type (so that resolution will work properly).
> The effect would be that:
> 
>       raise Constraint_Error with Env'access;
> 
> would raise Program_Error for a failed accessibility check.
> 
> We did look at this issue when working on the Amendment. The "obvious"
> answers seem to have issues with visibility and compatibility with existing
> Ada.Exceptions mechanisms. We sent the proposal back to the author, and
> never got an improved proposal. Thus, it got dropped (no reflection on
> importance; can't do anything without a proposal). In hindsight, it probably
> should have been assigned to someone else, but it wasn't.

I think that a more "obvious" answer to me would be a contracted model of
exceptions a-la Java. Then we would have in Georg's case (the syntax is
imaginary):

   procedure Foo raises Foo_Error; -- Compile error!

   procedure Foo is
      type Foo_Error is exception with ...;
   begin
      ...
      raise Foo_Error'(...);
      ...

The contract of Foo should refer to all exception types it can propagate,
this would automatically exclude any local types.

When Foo would not have any explicit exception contract, then raise
Foo_Error should again give compilation error, because the standard implied
contract would contain only the legacy exceptions of Ada 83.

One problem with above is that 

   procedure Foo raises Some_Error'Class;

should be illegal. Well, this issue should be handled anyway in "when"
clauses, to make them statically checkable:

exception  -- Things like this cannot be legal!!
   when E : Some_Error'Class =>
   when E : Some_Error  =>
   ...

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

Re: Structured exception information

[Maciej Sobczak]

Dmitry A. Kazakov wrote:

> I think that a more "obvious" answer to me would be a contracted model of
> exceptions a-la Java. Then we would have in Georg's case (the syntax is
> imaginary):
> 
>    procedure Foo raises Foo_Error; -- Compile error!
> 
>    procedure Foo is
>       type Foo_Error is exception with ...;
>    begin
>       ...
>       raise Foo_Error'(...);
>       ...

or maybe:

         raise Foo_Error with (A => X; B => Y; C => Z);

as a natural extension for raise with message.

> One problem with above is that 
> 
>    procedure Foo raises Some_Error'Class;
> 
> should be illegal.

Why? You would need to allow it at least in those subprograms that 
accept class-wide parameters, otherwise the open-close principle of OO 
would not hold (it would not be possible to extend the given hierarchy 
without messing with *all* the subprograms that operate on existing 
class-wide types).


-- 
Maciej Sobczak : http://www.msobczak.com/
Programming    : http://www.msobczak.com/prog/

Re: Structured exception information

[Dmitry A. Kazakov]

On Tue, 16 Jan 2007 11:45:54 +0100, Maciej Sobczak wrote:

> Dmitry A. Kazakov wrote:
> 
>> I think that a more "obvious" answer to me would be a contracted model of
>> exceptions a-la Java. Then we would have in Georg's case (the syntax is
>> imaginary):
>> 
>>    procedure Foo raises Foo_Error; -- Compile error!
>> 
>>    procedure Foo is
>>       type Foo_Error is exception with ...;
>>    begin
>>       ...
>>       raise Foo_Error'(...);
>>       ...
> 
> or maybe:
> 
>          raise Foo_Error with (A => X; B => Y; C => Z);

No, Foo_Error /= "Foo_Error with anything." The whole idea is that the
contract requires Foo_Error alone. Nothing else, even if from the
Foo_Error'Class, is accepted.

If Foo_Error were derived from some Base_Error, you could use an extension
aggregate:

   raise (Base_Error with A => X, B => Y, C => Z);

The result were Foo_Error again.

> as a natural extension for raise with message.
> 
>> One problem with above is that 
>> 
>>    procedure Foo raises Some_Error'Class;
>> 
>> should be illegal.
> 
> Why?

Because otherwise you could raise a type from the class, of which scope is
narrower than one of the handler. So the problem would reappear. OK, there
could be other means, like freezing Some_Error'Class after the declaration
point of Foo for anybody who can directly or indirectly see Foo. I don't
know if that could be a way. As I said, it is a problem to deal with,
including the example:

   when E : Some_Error'Class =>
   when E : Some_Error  =>

We definitely do not want whens to become ordered. Even less, to have
contracts which cannot be checked.

> You would need to allow it at least in those subprograms that 
> accept class-wide parameters, otherwise the open-close principle of OO 
> would not hold (it would not be possible to extend the given hierarchy 
> without messing with *all* the subprograms that operate on existing 
> class-wide types).

An exception hander and raise can be considered as a "caller" and "callee."
The exception propagated is the contract for both. Clearly you cannot have
the contract more nested than its parties. Except that you didn't want to
introduce upward closures with garbage-collected types and classes of. This
is doable, but I doubt it would be much usable for a universal purpose
language like Ada!

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

Re: Structured exception information

[Maciej Sobczak]

Dmitry A. Kazakov wrote:

>>>    procedure Foo raises Some_Error'Class;
>>>
>>> should be illegal.
>> Why?
> 
> Because otherwise you could raise a type from the class, of which scope is
> narrower than one of the handler.

Then I would expect slicing to the type that the handler sees.
Which brings another point - the handler has to *see* the type it wants 
to handle, which means that the type in question cannot have narrower 
scope anyway and even if it has, the handler will not be able to misuse it.

>    when E : Some_Error'Class =>
>    when E : Some_Error  =>
> 
> We definitely do not want whens to become ordered.

You have them ordered already, just not in a sequence, but across all 
enclosing scopes (handlers are searched from "inside" to "outside", so 
they might as well be traversed from top to down in addition). I don't 
see much difference.

> Even less, to have
> contracts which cannot be checked.

You can check it. Java guys did it, so there is a prior art. :-)


-- 
Maciej Sobczak : http://www.msobczak.com/
Programming    : http://www.msobczak.com/prog/

Re: Structured exception information

[Dmitry A. Kazakov]

On Tue, 16 Jan 2007 15:44:43 +0100, Maciej Sobczak wrote:

> Dmitry A. Kazakov wrote:
> 
>>>>    procedure Foo raises Some_Error'Class;
>>>>
>>>> should be illegal.
>>> Why?
>> 
>> Because otherwise you could raise a type from the class, of which scope is
>> narrower than one of the handler.
> 
> Then I would expect slicing to the type that the handler sees.

That does not work because slicing could yield an abstract type. This would
not be a view change, because exceptions are rather "marshaled," for many
reasons. Consider:

   type Local_Type is ...
   type Local_Exception is ... with record
      X : Local_Type;  -- This must be finalized upon leaving the scope
   end record;

I.e. you have to create a truly new sliced object. An abstract one cannot
be, and it would be a quite overhead.

> Which brings another point - the handler has to *see* the type it wants 
> to handle, which means that the type in question cannot have narrower 
> scope anyway and even if it has, the handler will not be able to misuse it.

Right. This is why contracts is potentially *the* answer.

>>    when E : Some_Error'Class =>
>>    when E : Some_Error  =>
>> 
>> We definitely do not want whens to become ordered.
> 
> You have them ordered already, just not in a sequence, but across all 
> enclosing scopes (handlers are searched from "inside" to "outside", so 
> they might as well be traversed from top to down in addition). I don't 
> see much difference.

"when" in exception has the meaning of exclusive or, same as in case.
Otherwise it would be "elsif."

>> Even less, to have
>> contracts which cannot be checked.
> 
> You can check it. Java guys did it, so there is a prior art. :-)

Did they anything right? (:-))

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

Re: Structured exception information

[Jeffrey Carter]

Dmitry A. Kazakov wrote:
> 
>    procedure Foo raises Foo_Error; -- Compile error!

Generally, subprograms should raise exceptions because of precondition 
violations. If the preconditions are met, the subprogram should not 
raise an exception (barring things that are beyond the developer's 
control, such as running out of memory). So it would be better to 
associate a subprogram with a list of preconditions with the exception 
raised if each is violated:

function Arccoth (Coth : Real) return Real
when abs Coth < 1.0 raise Invalid_Coth;

procedure Time_Limited (X : in Integer)
when X = 0 raise Zero_X and
when Ada.Calendar.Clock >=
      Ada.Calendar.Time_Of (Year    => 2010,
                            Month   => 1,
                            Day     => 1,
                            Seconds => 0.0)
raise Too_Late;

Re: Structured exception information

[Dmitry A. Kazakov]

On Tue, 16 Jan 2007 17:50:46 GMT, Jeffrey Carter wrote:

> Dmitry A. Kazakov wrote:
>> 
>>    procedure Foo raises Foo_Error; -- Compile error!
> 
> Generally, subprograms should raise exceptions because of precondition 
> violations. If the preconditions are met, the subprogram should not 
> raise an exception (barring things that are beyond the developer's 
> control, such as running out of memory). So it would be better to 
> associate a subprogram with a list of preconditions with the exception 
> raised if each is violated:
> 
> function Arccoth (Coth : Real) return Real
> when abs Coth < 1.0 raise Invalid_Coth;
> 
> procedure Time_Limited (X : in Integer)
> when X = 0 raise Zero_X and
> when Ada.Calendar.Clock >=
>       Ada.Calendar.Time_Of (Year    => 2010,
>                             Month   => 1,
>                             Day     => 1,
>                             Seconds => 0.0)
> raise Too_Late;

Totally disagree.

A precondition violation is not an exceptional state, it is a bug. Bugs
fundamentally cannot be handled within the same program. This "exception"
should propagate in the visual debugger and further into the head of the
code maintainer, If you want.

The difference becomes obvious if you consider that there might well be
valid program states corresponding to the end of a file. But there cannot
be any valid and consistent state in which there would exist x such that
cosh(x)<1.

Therefore their handling strategies are quite different as well. Bugs
propagating exceptions is the worst debugging nightmare. A precondition
violation shall stop immediately to prevent further harm and to make a
inspection possible. Exceptions are just a method of flow control.

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

Re: Structured exception information

[Randy Brukardt]

"Dmitry A. Kazakov" <mailbox@dmitry-kazakov.de> wrote in message
news:s0prxwrhxfj1.1r5zzccgpzy2.dlg@40tude.net...
> On Tue, 16 Jan 2007 17:50:46 GMT, Jeffrey Carter wrote:
>
> > Dmitry A. Kazakov wrote:
> >>
> >>    procedure Foo raises Foo_Error; -- Compile error!
> >
> > Generally, subprograms should raise exceptions because of precondition
> > violations. If the preconditions are met, the subprogram should not
> > raise an exception (barring things that are beyond the developer's
> > control, such as running out of memory). So it would be better to
> > associate a subprogram with a list of preconditions with the exception
> > raised if each is violated:
> >
...
> Totally disagree.
>
> A precondition violation is not an exceptional state, it is a bug. Bugs
> fundamentally cannot be handled within the same program. This "exception"
> should propagate in the visual debugger and further into the head of the
> code maintainer, If you want.
>
> The difference becomes obvious if you consider that there might well be
> valid program states corresponding to the end of a file. But there cannot
> be any valid and consistent state in which there would exist x such that
> cosh(x)<1.
>
> Therefore their handling strategies are quite different as well. Bugs
> propagating exceptions is the worst debugging nightmare. A precondition
> violation shall stop immediately to prevent further harm and to make a
> inspection possible. Exceptions are just a method of flow control.

Yikes. If a precondition failure can be detected statically (i.e. at compile
time), then surely you are right.

But most of them cannot. And I have a lot of software that shouldn't stop
just because it has a bug. For example, my mail server shouldn't stop
handling mail just because a bug was encountered (and it certainly has had a
few bugs, especially in the spam filter): I want to write the failure into a
special log, save the offending message if possible, reinitialize the task
to a starting state, and continue. Anything else would stop the flow of
mail.

Surely there are systems where the best response to a bug is a full stop,
but there are many for which that would be silly. If the airplane or rocket
software shuts down because a bug, at best you'll have vehicle loss (and at
worst, loss of life).

In any case, you can't draw a hard line between what is a bug and what is
some other sort of error: it can even depend on intended use. A Find routine
that doesn't find anything could be an error or could be expected -- and we
don't have different otherwise identical routines for this purpose.

                                         Randy.

Re: Structured exception information

[Dmitry A. Kazakov]

On Tue, 16 Jan 2007 16:52:31 -0600, Randy Brukardt wrote:

> "Dmitry A. Kazakov" <mailbox@dmitry-kazakov.de> wrote in message
> news:s0prxwrhxfj1.1r5zzccgpzy2.dlg@40tude.net...
>> On Tue, 16 Jan 2007 17:50:46 GMT, Jeffrey Carter wrote:
>>
>>> Generally, subprograms should raise exceptions because of precondition
>>> violations. If the preconditions are met, the subprogram should not
>>> raise an exception (barring things that are beyond the developer's
>>> control, such as running out of memory). So it would be better to
>>> associate a subprogram with a list of preconditions with the exception
>>> raised if each is violated:
> ...
>> Totally disagree.
>>
>> A precondition violation is not an exceptional state, it is a bug. Bugs
>> fundamentally cannot be handled within the same program. This "exception"
>> should propagate in the visual debugger and further into the head of the
>> code maintainer, If you want.
>>
>> The difference becomes obvious if you consider that there might well be
>> valid program states corresponding to the end of a file. But there cannot
>> be any valid and consistent state in which there would exist x such that
>> cosh(x)<1.
>>
>> Therefore their handling strategies are quite different as well. Bugs
>> propagating exceptions is the worst debugging nightmare. A precondition
>> violation shall stop immediately to prevent further harm and to make a
>> inspection possible. Exceptions are just a method of flow control.
> 
> Yikes. If a precondition failure can be detected statically (i.e. at compile
> time), then surely you are right.

I doubt that others could or should be called preconditions.

> But most of them cannot. And I have a lot of software that shouldn't stop
> just because it has a bug. For example, my mail server shouldn't stop
> handling mail just because a bug was encountered (and it certainly has had a
> few bugs, especially in the spam filter): I want to write the failure into a
> special log, save the offending message if possible, reinitialize the task
> to a starting state, and continue. Anything else would stop the flow of
> mail.

How could you be sure that it would write log and not destroy your address
database? A vivid example is MS-Word which corrupts the document being
edited upon crash. BTW, in my view, writing log is still a valid program
state, it is a defined behavior. As long as you can continue, no matter
how, it is not yet a bug within the scope where you continue.

If cosh(-1) raises an exception, then that is the defined behavior of cosh
on -1. If so, then the precondition of cosh cannot exclude -1, because it
is a valid argument of. But x /= elephant, for example, is still in the
precondition. However, somebody could also define cosh(elephant), which
would automatically change the precondition.

The point is that violated preconditions are non-states and cannot be
handled at all. Provided, that one understands precondition as a method of
proving program correctness. Otherwise, it is something else.

> Surely there are systems where the best response to a bug is a full stop,
> but there are many for which that would be silly. If the airplane or rocket
> software shuts down because a bug, at best you'll have vehicle loss (and at
> worst, loss of life).

It would be a bad design to have a single monolithic software component to
control an airplane. The thing should be redundant to provide failover. No
malfunctioning component may continue its work (=malfunction!). For
example, a CAN bus field controller stops sending anything, when it detects
a bus problem. This is the first thing it does.

> In any case, you can't draw a hard line between what is a bug and what is
> some other sort of error: it can even depend on intended use. A Find routine
> that doesn't find anything could be an error or could be expected -- and we
> don't have different otherwise identical routines for this purpose.

Yes. The semantic of a program is defined by its developer. The same
program can be wrong and right.

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

Re: Structured exception information

[Jeffrey Carter]

Dmitry A. Kazakov wrote:
> 
> I doubt that others could or should be called preconditions.

> The point is that violated preconditions are non-states and cannot be
> handled at all. Provided, that one understands precondition as a method of
> proving program correctness. Otherwise, it is something else.

It's clear that you're locked into the concept of a precondition as part 
of correctness proofs. In that context, yes, you statically prove that 
preconditions are met, and do not need to dynamically test them. This is 
the case with SPARK, for example.

In general, though, preconditions are a useful tool for documenting SW, 
especially SW that will be used by people other than the developer. It's 
a useful way of communicating to the client what he needs to ensure in 
order for the SW to function normally (this condition must be true), and 
the consequences of failing to do so (this exception is raised).

Ideally, you'd use the same syntax for both uses of preconditions. Then 
SW that's written for general use could be used in SW that does 
correctness proofs without changes; without correctness proofs the 
compiler would automatically generate the tests, and with proofs, the 
tests would not be generated.

In retrospect, the syntax I thought up on the spur of the moment in my 
previous post is not very good, since, for a precondition P, what you 
write is not P. That would not be very useful for correctness proofs.

Re: Structured exception information

[Randy Brukardt]

"Jeffrey Carter" <spam.jrcarter.not@spam.acm.not.org> wrote in message
news:x2urh.309672$FQ1.158886@attbi_s71...
> Dmitry A. Kazakov wrote:
> >
> > I doubt that others could or should be called preconditions.
>
> > The point is that violated preconditions are non-states and cannot be
> > handled at all. Provided, that one understands precondition as a method
of
> > proving program correctness. Otherwise, it is something else.
>
> It's clear that you're locked into the concept of a precondition as part
> of correctness proofs. In that context, yes, you statically prove that
> preconditions are met, and do not need to dynamically test them. This is
> the case with SPARK, for example.

Right. The problem is that you can't write much of anything interesting that
is statically provable for the full Ada language. (If your willing to work
only in a subset of Ada, that's of course different.) Thus, I tend to think
mainly about dynamic preconditions, tested either as explicit tests or as
assertions. Those raise an exception if they fail. And part of the contract
of the operation is that an exception will be raised if the (dynamic)
preconditions fail.

...
> Ideally, you'd use the same syntax for both uses of preconditions. Then
> SW that's written for general use could be used in SW that does
> correctness proofs without changes; without correctness proofs the
> compiler would automatically generate the tests, and with proofs, the
> tests would not be generated.

When we looked at this during the Amendment work, the static analysis people
thought that the requirements for static preconditions and dynamic ones were
too different to use the same syntax/semantics for both. While I'm not sure
I believe that, it's never a good idea to dispute people who have more
experience in an area than you do.

Anyway, preconditions and postconditions start getting messy once you try to
figure out how they inherit, how to access previous values, and the like.
And there's ugly visibility issues if you want to write them on the
specification. So, eventually we gave up in part because there wasn't much
existing practice for dynamic preconditions/postconditions, so we couldn't
be sure what we were doing was even useful.

                          Randy.

Re: Structured exception information

[Robert A Duff]

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

> "Jeffrey Carter" <spam.jrcarter.not@spam.acm.not.org> wrote in message
> news:x2urh.309672$FQ1.158886@attbi_s71...
>> Dmitry A. Kazakov wrote:
>> >
>> > I doubt that others could or should be called preconditions.
>>
>> > The point is that violated preconditions are non-states and cannot be
>> > handled at all. Provided, that one understands precondition as a method
> of
>> > proving program correctness. Otherwise, it is something else.
>>
>> It's clear that you're locked into the concept of a precondition as part
>> of correctness proofs. In that context, yes, you statically prove that
>> preconditions are met, and do not need to dynamically test them. This is
>> the case with SPARK, for example.
>
> Right. The problem is that you can't write much of anything interesting that
> is statically provable for the full Ada language.
     ^^^^^^^^^^^^^^^^^^^

But note that "statically provable" is a moving target.  It depends on how
smart the prover is.  My brain can prove a few things that SPARK can't.
And vice-versa, of course.

>... (If your willing to work
> only in a subset of Ada, that's of course different.) Thus, I tend to think
> mainly about dynamic preconditions, tested either as explicit tests or as
> assertions. Those raise an exception if they fail. And part of the contract
> of the operation is that an exception will be raised if the (dynamic)
> preconditions fail.

That seems like a reasonable point of view.  And then if somebody hands
you a tool that can prove many of those assertions true statically, you're
happy.

>... So, eventually we gave up in part because there wasn't much
> existing practice for dynamic preconditions/postconditions, so we couldn't
> be sure what we were doing was even useful.

There's existing practice in Eiffel.  It's a good start, but doesn't
entirely solve the problem.

- Bob

Re: Structured exception information

[Jeffrey Carter]

Randy Brukardt wrote:
> 
> When we looked at this during the Amendment work, the static analysis people
> thought that the requirements for static preconditions and dynamic ones were
> too different to use the same syntax/semantics for both. While I'm not sure
> I believe that, it's never a good idea to dispute people who have more
> experience in an area than you do.
> 
> Anyway, preconditions and postconditions start getting messy once you try to
> figure out how they inherit, how to access previous values, and the like.
> And there's ugly visibility issues if you want to write them on the
> specification. So, eventually we gave up in part because there wasn't much
> existing practice for dynamic preconditions/postconditions, so we couldn't
> be sure what we were doing was even useful.

Preconditions are pretty straightforward, in my experience: I can almost 
always express them as a Boolean expression (not X.Empty). Couple a 
Boolean expression with an exception and I'll be happy. Where that fails 
is mostly "for all" and "there exists" conditions, and I can live 
without that.

Postconditions are a different matter. I often want to write things like 
(using SPARK notation)

Size (X) = Size (X~) + 1

[would that be X~.Size in Object.Operation notation?]

where X is an in out parameter of a limited type. In the most general 
case this involves storing the in value of X, which you're not supposed 
to be able to do. Maybe you could arrange to store Size (X) on input, as 
well as the values of all the other functions on in out parameters 
mentioned in the postcondition(s).

They're still useful for documenting the behavior of an operation.

Re: Structured exception information

[Randy Brukardt]

"Jeffrey Carter" <spam.jrcarter.not@spam.acm.not.org> wrote in message
news:%xErh.228837$aJ.94458@attbi_s21...
> Randy Brukardt wrote:
...
> > Anyway, preconditions and postconditions start getting messy once you
try to
> > figure out how they inherit, how to access previous values, and the
like.
> > And there's ugly visibility issues if you want to write them on the
> > specification. So, eventually we gave up in part because there wasn't
much
> > existing practice for dynamic preconditions/postconditions, so we
couldn't
> > be sure what we were doing was even useful.
>
> Preconditions are pretty straightforward, in my experience: I can almost
> always express them as a Boolean expression (not X.Empty). Couple a
> Boolean expression with an exception and I'll be happy. Where that fails
> is mostly "for all" and "there exists" conditions, and I can live
> without that.

Right, but there still are the issues of what is and is not visible in the
precondition. You're not inside the subprogram, yet you have access to the
parameters. And what about side-effects?

The other issue was what to do with preconditions for inherited routines.
They ought to compose somehow, but that got ugly in a hurry.

> Postconditions are a different matter. I often want to write things like
> (using SPARK notation)
>
> Size (X) = Size (X~) + 1
>
> [would that be X~.Size in Object.Operation notation?]
>
> where X is an in out parameter of a limited type. In the most general
> case this involves storing the in value of X, which you're not supposed
> to be able to do. Maybe you could arrange to store Size (X) on input, as
> well as the values of all the other functions on in out parameters
> mentioned in the postcondition(s).

The proposal we were working on had a way to get the original value of a
scalar parameter. Which meant they all had to copied on entrance - causing
extra overhead. And the inheritance, visibility, and side-effect issues are
still around.

                          Randy.

Re: Structured exception information

[Dmitry A. Kazakov]

On Fri, 19 Jan 2007 01:34:35 -0600, Randy Brukardt wrote:

> The other issue was what to do with preconditions for inherited routines.
> They ought to compose somehow, but that got ugly in a hurry.
[...]
> The proposal we were working on had a way to get the original value of a
> scalar parameter. Which meant they all had to copied on entrance - causing
> extra overhead. And the inheritance, visibility, and side-effect issues are
> still around.

Inherited subprograms should take them as-is. When overridden,
preconditions are weakened, postoconditions are strengthened. An override
should add its precondition as a disjunctive term to the precondition of
the subprogram being overridden one, and its postcondition as a conjunctive
term.

There shall be no side-effects for the same reasons why there shall be no
exceptions. (:-)) For the same reason visibility is not an issue,
everything is visible...

OK, what about an alternative. Let's forget about preconditions, let's call
it *constraint*. This is what Ada has since its beginning. What about
allowing more generous constraint expressions put on the subtypes? It could
have the desired effect, IMO. The "precondition" could be a constraint on
the subtype of an in-parameter. The "postcondition" could be one on the
subtype of an out-parameter. We could allow ad-hoc subtypes in subprogram
signatures, for lazy guys...

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

Re: Structured exception information

[Jeffrey Carter]

Dmitry A. Kazakov wrote:
> 
> OK, what about an alternative. Let's forget about preconditions, let's call
> it *constraint*. This is what Ada has since its beginning. What about
> allowing more generous constraint expressions put on the subtypes? It could
> have the desired effect, IMO. The "precondition" could be a constraint on
> the subtype of an in-parameter. The "postcondition" could be one on the
> subtype of an out-parameter. We could allow ad-hoc subtypes in subprogram
> signatures, for lazy guys...

This is a good point. Ada's subtypes have always been a form of dynamic 
precondition. I've always thought it better to write

Length : in Natural

than

Length : in Integer

--#pre Length >= 0

So it would be nice if this concept could be extended to essentially 
handle dynamic preconditions. Any suggestions how to apply this to, say

(DS : in out Data_Structure; Index : in Positive)

--#pre Index in 1 .. Size (DS);

?

Re: Structured exception information

[Robert A Duff]

Jeffrey Carter <spam.jrcarter.not@spam.acm.not.org> writes:

> This is a good point. Ada's subtypes have always been a form of dynamic
> precondition.

And postcondition.  I.e. an invariant.

>... I've always thought it better to write
>
> Length : in Natural
>
> than
>
> Length : in Integer
>
> --#pre Length >= 0

Agreed.

> So it would be nice if this concept could be extended to essentially
> handle dynamic preconditions. Any suggestions how to apply this to, say
>
> (DS : in out Data_Structure; Index : in Positive)
>
> --#pre Index in 1 .. Size (DS);

Well I suppose one could come up with rules that make sense of:

(DS : in out Data_Structure; Index : in Positive range 1..Size(DS))

but that's a huge change to Ada.

- Bob

Re: Structured exception information

[Jeffrey Carter]

Robert A Duff wrote:
> 
> (DS : in out Data_Structure; Index : in Positive range 1..Size(DS))
> 
> but that's a huge change to Ada.

Interesting. Not Ada, but interesting.

Re: Structured exception information

[Dmitry A. Kazakov]

On Wed, 17 Jan 2007 18:38:21 GMT, Jeffrey Carter wrote:

> Dmitry A. Kazakov wrote:
>> 
>> I doubt that others could or should be called preconditions.
> 
>> The point is that violated preconditions are non-states and cannot be
>> handled at all. Provided, that one understands precondition as a method of
>> proving program correctness. Otherwise, it is something else.
> 
> It's clear that you're locked into the concept of a precondition as part 
> of correctness proofs. In that context, yes, you statically prove that 
> preconditions are met, and do not need to dynamically test them. This is 
> the case with SPARK, for example.

I think that stress on compile-time checks is to some extent misleading. In
my view, the issue is not "when", but "who" performs the checks.
Correctness checks cannot be performed by the same program. In the case of
static checks, it is just so that the compiler program P2 checks my program
P1. If I wished to check my program at run-time, I should have a run-time
checker P3. For that matter, it could well be a part of Ada run-time
library, provided it were good insulated from my P1. But in all cases, when
P2 or P3 detects that P1 is incorrect (not Ada), then P1 cannot be
continued. The checker is free to start some third (Ada) program, though.

For this reason exception propagation in P1 were fundamentally flawed. We
cannot pretend that P1 has any scope which wasn't spoiled by the bug.

> In general, though, preconditions are a useful tool for documenting SW, 
> especially SW that will be used by people other than the developer. It's 
> a useful way of communicating to the client what he needs to ensure in 
> order for the SW to function normally (this condition must be true), and 
> the consequences of failing to do so (this exception is raised).

To me this is a contract: x/y yields a mathematically correct result or
else it propagates an exception when, for example, y=0. I.e. it is legal to
write 1/0 and the precondition is True.

If the precondition were y/=0, then 1/0 would be illegal and nothing could
be done about it.

> Ideally, you'd use the same syntax for both uses of preconditions. 

I think is a difficult question. The languages of P1 (my program) and of P2
(a checker of) could be sufficiently different, by necessity. On the other
hand, Ada compilers are written in Ada... In any case there should be a
clear visual distinction between the contracts and the things checking the
contracts. The latter are optional (=have the semantics outside P1) the
former are not (=have the semantics of P1). 

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

Re: Structured exception information

[Jeffrey Carter]

Dmitry A. Kazakov wrote:
> 
> To me this is a contract: x/y yields a mathematically correct result or
> else it propagates an exception when, for example, y=0. I.e. it is legal to
> write 1/0 and the precondition is True.
> 
> If the precondition were y/=0, then 1/0 would be illegal and nothing could
> be done about it.

I think what many of us (Brukardt and I, at least) are calling (dynamic) 
preconditions, you're calling exceptional states. I can see that, but 
these are undesirable exceptional states that the developer cannot 
ensure will not happen (consider reusable components). Neither the 
client nor the service provider want an exceptional state. The idea is, 
in the contract, to assist the caller in knowing what the exceptional 
states are and how to avoid them. That's similar to a precondition in 
the correctness-proof sense: something which prevents the program from 
functioning. In the case of correctness proofs, the program doesn't 
function at all; in the case of dynamic preconditions or exceptional 
states, the program doesn't function as desired.

Re: Structured exception information

[Randy Brukardt]

"Dmitry A. Kazakov" <mailbox@dmitry-kazakov.de> wrote in message
news:1lpy2h06scx34.1i2k4dlbg0nfy.dlg@40tude.net...
> On Tue, 16 Jan 2007 16:52:31 -0600, Randy Brukardt wrote:
>
...
> > But most of them cannot. And I have a lot of software that shouldn't
stop
> > just because it has a bug. For example, my mail server shouldn't stop
> > handling mail just because a bug was encountered (and it certainly has
had a
> > few bugs, especially in the spam filter): I want to write the failure
into a
> > special log, save the offending message if possible, reinitialize the
task
> > to a starting state, and continue. Anything else would stop the flow of
> > mail.
>
> How could you be sure that it would write log and not destroy your address
> database? A vivid example is MS-Word which corrupts the document being
> edited upon crash.

Sure? You can never be completely sure; you have to mitigate risks. But in
my case, I trust my compiler not to destroy anything before generating
checks (given that I wrote most of the compiler, I have a lot of knowledge
of what it will and will not do). I also build components to be resilient to
failure: most everything is controlled, and will reset itself to a correct
state if the objects are prematurely finalized. The main remaining risk is
using dangling pointers (and I try to avoid pointers as much as possible,
and use a special storage pool to try to detect that when I cannot avoid
it). An implementation that corrupted something on a failure is just not
acceptable.

But even with the logging, you still have to be able to deal with crashes.
For instance, these programs run on Windows; and it's been known to die
occassionally. So the mail server has to guard against that, too. Since,
because mail should never, ever be lost, most everything in memory is also
mirrored on disk: a mail message is written to disk before a successful
receipt is acknowledged, and it stays there until a successful receipt by
the destination is acknowledged. So, there is a tiny chance that mail might
be sent twice, but virtually none that it would be sent never.

At least in this case, the program can be restarted with little negative
impact. The main problem is that if it fails when no one is around, it could
be a long time before anyone is able to restart it. I think there are a lot
of programs in that category - that is, very important, but not loss-of-life
crticial.

> BTW, in my view, writing log is still a valid program
> state, it is a defined behavior. As long as you can continue, no matter
> how, it is not yet a bug within the scope where you continue.

Well, then there are no bugs in my mail and web servers. I'm happy to hear
that. ;-)

That doesn't match my definition of bug. There's not much to talk about if
we don't agree on the meaning of basic terms.

                    Randy.

Re: Structured exception information

[Dmitry A. Kazakov]

On Wed, 17 Jan 2007 17:36:41 -0600, Randy Brukardt wrote:

> "Dmitry A. Kazakov" <mailbox@dmitry-kazakov.de> wrote in message
> news:1lpy2h06scx34.1i2k4dlbg0nfy.dlg@40tude.net...
>>
>> How could you be sure that it would write log and not destroy your address
>> database? A vivid example is MS-Word which corrupts the document being
>> edited upon crash.
> 
> Sure? You can never be completely sure; you have to mitigate risks. But in
> my case, I trust my compiler not to destroy anything before generating
> checks (given that I wrote most of the compiler, I have a lot of knowledge
> of what it will and will not do). I also build components to be resilient to
> failure: most everything is controlled, and will reset itself to a correct
> state if the objects are prematurely finalized. The main remaining risk is
> using dangling pointers (and I try to avoid pointers as much as possible,
> and use a special storage pool to try to detect that when I cannot avoid
> it). An implementation that corrupted something on a failure is just not
> acceptable.

Consider a failure defined as "corrupting something." Now what an
implementation should do if it notices that it just has corrupted something
(=failed)? (:-))

> But even with the logging, you still have to be able to deal with crashes.
> For instance, these programs run on Windows; and it's been known to die
> occassionally.

Right. This is exactly the point. When MS-Word crashes it is not a crash of
Windows. Thus the program Windows can continue, the file system can, HDD
can, the powerplant supplying the computer can etc, but MS-Word cannot. In
other words, for Windows it is a normal state when MS-Word crashes... (:-))

>> BTW, in my view, writing log is still a valid program
>> state, it is a defined behavior. As long as you can continue, no matter
>> how, it is not yet a bug within the scope where you continue.
> 
> Well, then there are no bugs in my mail and web servers. I'm happy to hear
> that. ;-)

An undesired behavior is still one... Otherwise we would considered
anything we don't like as bugs.

> That doesn't match my definition of bug. There's not much to talk about if
> we don't agree on the meaning of basic terms.

Yes. I think one should clearly distinguish:

1. states
2. undesired (exceptional) states 
3. non-states (bugs)

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

Re: Structured exception information

[Robert A Duff]

Georg Bauhaus <bauhaus@arcor.de> writes:

> I'm still wondering whether or not an Ada compiler could provide
> a special kind of closure for this case? We do already get stack
> traces. (I don't know compilers so this is just a guess...)
>
> package Handling is
>    
>    --
>    -- info to be attached to an exception occurence
>    --
>    
>    type State is tagged record
>       info: Integer;
>    end record;
>    
> end Handling;
>
>
> with Handling;  use Handling;
> procedure foo is
>    
>    x: Integer;
>    
>    function Env return State'class is
>    begin
>       return State'(info => x);
>    end Env;
>    
> begin
>    if 1 > 1 then
>       raise Constraint_Error with Env'access;
>    end if;
> end foo;

I'm not sure exactly what you mean by the above.  Is Handling supposed
to be provided by the Ada implementation?  Is Env'Access pointing to a
function or the result of calling the function (allocated where?)?

Anyway, I think the goal is (should be) that when you attach information
to an exception, there's a contract.  That is, when you declare the
exception, you declare the type of that information, and the "raise"
statement and the handler both obey that contract.

In this view, it makes no sense to attach miscellaneous info to
Constraint_Error.  How is a "when Constraint_Error" supposed to know the
type of that info?

Another goal, of course, is to allow the handler to do fine-grained or
coarse-grained handling, without having to make that decision when you
declare the exception.  See Posix Ada-binding "errno" fiasco.

Numerous languages have accomplished all of the above in a simple and
elegant manner.  It's not that hard.

- Bob

Re: Structured exception information

[Georg Bauhaus]

On Mon, 2007-01-15 at 17:19 -0500, Robert A Duff wrote:
> Georg Bauhaus <bauhaus@arcor.de> writes:
> 
...
> >    type State is tagged record
> >       info: Integer;
> >    end record;

> >
> > with Handling;  use Handling;
> > procedure foo is
> >    
> >    x: Integer;
> >    
> >    function Env return State'class is
> >    begin
> >       return State'(info => x);
> >    end Env;
> >    
> > begin
> >    if 1 > 1 then
> >       raise Constraint_Error with Env'access;
> >    end if;
> > end foo;
> 
> I'm not sure exactly what you mean by the above.  Is Handling supposed
> to be provided by the Ada implementation?

Yes, I had imagined a type somewhat like (Limited_)Controlled.
Randy has clarified IIUC.

>   Is Env'Access pointing to a
> function or the result of calling the function (allocated where?)?

More or less Env'Access should designate a "pure parameterless
projection function" e.g. from an activation record into a special
memory area used by exception handlers.
When Env'Access occurs after "with" and an exception is raised,
the projection is performed, that is, the necessary copying of
fields is performed in an implementation specific way.
The storage of the projection is typed, and access is granted in
handlers only.
Env is associated with the exception occurence (Ex_Obj'Environment?).
A call will then return a read only tagged object of the special
kind mentioned above. (Uhm, this reminds me of the composed
type in Tom Moran's example, and of stream attributes :-)

As a simpler approach, and a variation of what Maciej Sobczak has
suggested, what if
 
  raise Constraint_Error with
    (Derived_from_Exception_Controlled with A => X, ...)

will restrict X to be a name of a local object? Or more generally,
a name of an object that has already been computed?
(The type of A will have to be as visible as
Derived_from_Exception_Controlled I guess.)

Re: Structured exception information

[Adam Beneschan]

Maciej Sobczak wrote:
> Hi,
>
> Consider an object created by a constructor function:
>
> X : My_Type := My_Constructor(Some_Parameters);
>
> My_Type is Controlled_Limited to ensure control over initialization and
> finalization. The idea of constructor function is to prevent the
> existence of objects that are not yet initialized, half-baked, in a bad
> state, etc. If the object exists, it's ready for use.
>
> If there are problems during the execution of the constructor function,
> the exception is raised, so that there is no X object in a bad state.
> How can I pass some error information from the constructor function out,
> so that it's used when the exception is handled?
> Obviously, some message can be attached to the exception occurence, but
> it doesn't scale well - I might want to pass some more data, possibly
> structured (some error code, some reason code, some timestamp, some
> whatever else, ...).
>
> Yes, I'm asking for "throwing objects", in the C++ parlance.
>
> How to do this in Ada?
> If I cannot - how to solve this design problem?

Hmmm ... I almost thought this could be done by writing your own
package that provides its own Raise routine, something like

   type Extra_Info is ...

   procedure My_Own_Raise (E : in Ada.Exceptions.Exception_ID;
                           Info : Extra_Info;
                           Message : in String := "");

The implementation of this routine would call
Ada.Exceptions.Raise_Exception(E,Message), and at the same time attach
"Info" to the exception occurrence, so that another routine in this
package could retrieve the information from the exception occurrence.
(Is this the sort of design you had in mind?)

Unfortunately, you don't know what the Exception_Occurrence is before
you call Raise_Exception.  Maybe if you implemented it something like
this:

   procedure My_Own_Raise (E : in Ada.Exceptions.Exception_ID;
                           Info : Extra_Info;
                           Message : in String := "") is
   begin
       Ada.Exceptions.Raise_Exception (E, Message);
   exception
       when Occ : Others =>
           ... do something that associates Occ with Info, that another
           ... subprogram in the package could then retrieve
           Ada.Exceptions.Reraise_Occurrence (Occ);
   end My_Own_Raise;

But since Exception_Occurrence is a limited private type that doesn't
have its own "handle" (there's no Exception_Occurrence_Id in
Ada.Exceptions), I still don't see how this could be done.

Anyone else have any ideas?  Or did I totally misunderstand the
problem?

                            -- Adam

Re: Structured exception information

[Robert A Duff]

"Adam Beneschan" <adam@irvine.com> writes:

>    procedure My_Own_Raise (E : in Ada.Exceptions.Exception_ID;
>                            Info : Extra_Info;
>                            Message : in String := "");
>
> The implementation of this routine would call
> Ada.Exceptions.Raise_Exception(E,Message), and at the same time attach
> "Info" to the exception occurrence, so that another routine in this
> package could retrieve the information from the exception occurrence.
> (Is this the sort of design you had in mind?)

You could have:

    procedure My_Own_Raise (E : in Ada.Exceptions.Exception_ID;
                            Info : Extra_Info);

and the implementation could encode Info as a String, and use that as
the Message passed to Raise_Excpetion.  The handler then decodes the
String.  The stream attributes could be used for encoding/decoding.
Maybe wrapping this mess in some generics could make it more type safe.

Yuck.

- Bob

Re: Structured exception information

[tmoran]

> You could have:
>
>     procedure My_Own_Raise (E : in Ada.Exceptions.Exception_ID;
>                             Info : Extra_Info);
>
> and the implementation could encode Info as a String, and use that as
> the Message passed to Raise_Excpetion.  The handler then decodes the
> String.  The stream attributes could be used for encoding/decoding.
> Maybe wrapping this mess in some generics could make it more type safe.
>
> Yuck.

   You could make it type safe with an extended tagged record.  Make
   a key handler that saves a pointer to the classwide record, returning
   a "safe deposit key" whose (short) 'image constitutes the message.
   Risking posting untried pseudo code, how about:

package exception_info is

  exception_with_info : exception;

  type base_type is abstract tagged record
    actual_occurrence : ada.exceptions.exception_occurrence_access;
  end record;

  procedure handle(x : in out base_type);
  -- Called by handler for descendant of base type.  Does a Free
  -- on x.actual_occurrence

  type p_exception_info_type is access base_type'class;

  procedure raise_with_info(p : in p_exception_info_type);
  -- Trades the pointer to the information for a unique key from a
  -- (protected) key handler, then raises Exception_With_Info
  -- with key_type'image(key) as the message string.

  function fetch_info(egad : ada.exceptions.exception_occurrence)
  return p_exception_info_type;
  -- Extracts the key_type'value from the message, gives it to
  -- the protected key handler, and returns the saved pointer.


and to use declare
  ...
    type speeding_ticket_type is new exception_info.base_type with record
      time : ada.calendar.time;
      speed : positive;
    end record;

    procedure handle(ticket : in out speeding_ticket_type) is
    begin
      ada.text_io.put_line(integer'image(ticket.speed) & " mph."
        & ada.exceptions.exception_information(ticket.actual_occurrence.all));
      handle(exception_info.base_type(ticket));
    end handle;

    ...

when there's an exception that needs to pass speeding ticket info do
    when oops:constraint_error =>
      declare
        p : exception_info.p_exception_info_type
          := new speeding_ticket_type(
                actual_occurrence=>ada.exceptions.save_occurrence(oops),
                time=>ada.calendar.clock,
                speed=>speedometer_value);
      begin
        exception_info.raise_with_info(p);
      end;

and the catcher is
    when aha:exception_info.exception_with_info =>
      declare
        p : exception_info.p_exception_info_type
          := exception_info.fetch(aha);
      begin
        handle(p.all'class);
        free(p);
      end;

Re: Structured exception information

[Stephen Leake]

Maciej Sobczak <no.spam@no.spam.com> writes:

> X : My_Type := My_Constructor(Some_Parameters);
>
> If there are problems during the execution of the constructor
> function, the exception is raised, so that there is no X object in a
> bad state.
> How can I pass some error information from the constructor function
> out, so that it's used when the exception is handled?

Why do you want to? Generally, all you can do is report the error to
the user.

Can you give a detailed example of passing more complex information
that is actually used?

-- 
-- Stephe

Re: Structured exception information

[Maciej Sobczak]

Stephen Leake wrote:

>> How can I pass some error information from the constructor function
>> out, so that it's used when the exception is handled?
> 
> Why do you want to?

So that the handler has more information about the error?

> Generally, all you can do is report the error to
> the user.

That's what I want to do.

> Can you give a detailed example of passing more complex information
> that is actually used?

Imagine a constructor function that calls a database or a script engine 
with the query/script provided as a parameter. Some error can result and 
I want to raise an exception. The handler might benefit (even if for the 
purpose of presenting a nice error pop-up message) from:

- error code
- error message
- line number
- character position
- hint from the engine
- timestamp from within the engine
- ...

Another example - imagine that your compiler just prints 
"COMPILER_ERROR" instead of everything that it actually prints.
That wouldn't be very funny!

-- 
Maciej Sobczak : http://www.msobczak.com/
Programming    : http://www.msobczak.com/prog/

Re: Structured exception information

[Georg Bauhaus]

On Tue, 2007-01-16 at 15:33 +0100, Maciej Sobczak wrote:

> Imagine a constructor function that calls a database or a script engine 
> with the query/script provided as a parameter. Some error can result and 
> I want to raise an exception. The handler might benefit (even if for the 
> purpose of presenting a nice error pop-up message) from:
> 
> - error code
> - error message
> - line number
> - character position
> - hint from the engine
> - timestamp from within the engine
> - ...

This looks like a rich and controlled message passing to me.
Maybe an alternative design will handle the DB exceptions
locally, and then have two task rendevouz: a DB_Service
task, and a UI task. The latter will accept
and entry called "throw" with a parameter of a type
that reflects the list above. :-)

Re: Structured exception information

[Jeffrey Carter]

Maciej Sobczak wrote:
> 
> Another example - imagine that your compiler just prints 
> "COMPILER_ERROR" instead of everything that it actually prints.
> That wouldn't be very funny!

Since Compiler_Error would be an error with the compiler, not with the 
source code it was compiling, this would apparently be a compiler that 
couldn't compile anything. Now a compiler that just said "Compilation 
error" for any errors in the source would be irritating. Might be a good 
learning tool, though.

Re: Structured exception information

[Randy Brukardt]

"Jeffrey Carter" <spam.jrcarter.not@spam.acm.not.org> wrote in message
news:Ij8rh.226765$aJ.8694@attbi_s21...
> Maciej Sobczak wrote:
> >
> > Another example - imagine that your compiler just prints
> > "COMPILER_ERROR" instead of everything that it actually prints.
> > That wouldn't be very funny!
>
> Since Compiler_Error would be an error with the compiler, not with the
> source code it was compiling, this would apparently be a compiler that
> couldn't compile anything. Now a compiler that just said "Compilation
> error" for any errors in the source would be irritating. Might be a good
> learning tool, though.

The error handling of early Ada compilers, especially for resolution errors,
was essentially this. You still see it once in a while with complex
expressions where the compiler cannot figure out what it is that you're
doing.

                           Randy.

Re: Structured exception information

[Stephen Leake]

Maciej Sobczak <no.spam@no.spam.com> writes:

> Stephen Leake wrote:
>
>>> How can I pass some error information from the constructor function
>>> out, so that it's used when the exception is handled?
>> Why do you want to?
>
> So that the handler has more information about the error?
>
>> Generally, all you can do is report the error to
>> the user.
>
> That's what I want to do.

Then what's wrong with a string?

>> Can you give a detailed example of passing more complex information
>> that is actually used?
>
> Imagine a constructor function that calls a database or a script
> engine with the query/script provided as a parameter. Some error can
> result and I want to raise an exception. The handler might benefit
> (even if for the purpose of presenting a nice error pop-up message)
> from:
>
> - error code
> - error message
> - line number
> - character position
> - hint from the engine
> - timestamp from within the engine
> - ...

All of this can be put into the string by the routine raising the
exception:

raise Database_Error with 
   "Error " & Error_Code_Type'image (Error_Code) & 
   ": " & Time_Type'image (Timestamp) & 
   ": " & file_name & ":" & Integer'image (Line_Number) &
   ":" & Integer'image (Character_Position) & 
   ": " & Message & 
   ": " & Hint;

If you want a GUI pop-up, and it would be wrong to have the routine
raising the exception do the pop-up (which is reasonable), the
pop-up can just display this string. That's what Windex did.

I suppose if you want to put the different pieces of information into
different widgets in the "nice error pop-up", then you now have to
parse the string. With the structure I've shown, that's not hard; it's
colon-delimited. But I'll grant that is a case where more structure
than a string is desired.

As a general matter of user-interface design, I would find that
annoying. As a user of a system, the only thing I want from an error
message is either "how do I fix this myself" or "how do I report this
to the maintenance team".

In the first case, if the error is in a source file, displaying the
source file and line number, in a format that my IDE can understand,
is the best solution. That's a string on standard_output, not a GUI
pop-up.

In the second case, writing the string to a log file, and
displaying a pop-up with the full path name of the log file is a
_much_ better user interface. Make sure you can copy the file name, so
it can be pasted into an email message.

As a maintainer, I want the same thing. I hate conversations like
"what does the pop-up say in the third widget"? "no, the third widget
right to left, not top to bottom". Much better to say "send me the log
file".

> Another example - imagine that your compiler just prints
> "COMPILER_ERROR" instead of everything that it actually prints.
> That wouldn't be very funny!

The compiler prints a string! I have a script interpreter that does
exactly that. The string is formatted at the lowest level, where the
details of the error are known. Sometimes a higher level exception
handler prepends another string with source file information:

exception 
when E : Input_Error  => 
   raise Script_Error with File_Line_Column (current_script) & 
    Ada.Exceptions.Exception_Message (E);
end;

In building this system, I have never wished for more complex info
from an exception. Sometimes the string length limit is a problem, but
that's an implementation detail, not a fundamental design issue.

-- 
-- Stephe

Re: Structured exception information

[Maciej Sobczak]

Stephen Leake wrote:

>>> Generally, all you can do is report the error to
>>> the user.
>> That's what I want to do.
> 
> Then what's wrong with a string?

Doesn't feel as type-safe as advertised.

>> - error code
>> - error message
>> - line number
>> - character position
>> - hint from the engine
>> - timestamp from within the engine
>> - ...
> 
> All of this can be put into the string by the routine raising the
> exception:
[...]

Sure. That's why there are more JavaScript programmers than Ada programmers.

> raise Database_Error with 
>    "Error " & Error_Code_Type'image (Error_Code) & 
>    ": " & Time_Type'image (Timestamp) & 
>    ": " & file_name & ":" & Integer'image (Line_Number) &
>    ":" & Integer'image (Character_Position) & 
>    ": " & Message & 
>    ": " & Hint;

Of course, with similar routine for dismantling all this in the handler.

Still, that's not what I expect from Ada.

> As a general matter of user-interface design, I would find that
> annoying. As a user of a system, the only thing I want from an error
> message is either "how do I fix this myself" or "how do I report this
> to the maintenance team".

That is a reasonable approach and will work fine most of the time, but 
it does not explain the lack of a language feature that is taken for 
granted in other languages - and coming from another language, I find 
the lack of structured exception information as a defect, even though I 
realize that I can easily work around it.
The point is that I should not be forced to work around anything.

-- 
Maciej Sobczak : http://www.msobczak.com/
Programming    : http://www.msobczak.com/prog/

Re: Structured exception information

[Stephen Leake]

Maciej Sobczak <no.spam@no.spam.com> writes:

>>>> Generally, all you can do is report the error to
>>>> the user.
>>> That's what I want to do.
>> Then what's wrong with a string?
>
> Doesn't feel as type-safe as advertised.

But you have not given an actual example where a string is not
a type-safe solution to the actual problem at hand.

The only example you have given is "present the error to the user". In
that case, a string is precisely the correct type.

>>> - error code
>>> - error message
>>> - line number
>>> - character position
>>> - hint from the engine
>>> - timestamp from within the engine
>>> - ...
>> All of this can be put into the string by the routine raising the
>> exception:
> [...]
>
> Sure. That's why there are more JavaScript programmers than Ada programmers.

I don't follow. Strings are perfectly valid Ada constructs. Why does
the code to build the string not feel like Ada to you?

>> raise Database_Error with    "Error " & Error_Code_Type'image
>> (Error_Code) &    ": " & Time_Type'image (Timestamp) &    ": " &
>> file_name & ":" & Integer'image (Line_Number) &
>>    ":" & Integer'image (Character_Position) &    ": " & Message &
>> ": " & Hint;
>
> Of course, with similar routine for dismantling all this in the
> handler.

You have not said _why_ you need to dismantle this information in the
handler. What, _exactly_, will the handler do with the separate bits?

> Still, that's not what I expect from Ada.

Lots of people expect lots of things. Sometimes, those expectations
are unreasonable, and should be changed. That's what I'm trying to
explore here; I think expecting anything other than a string for
exception data is unreasonable. 

So far, you have presented no case to show I am wrong.

>> As a general matter of user-interface design, I would find that
>> annoying. As a user of a system, the only thing I want from an error
>> message is either "how do I fix this myself" or "how do I report this
>> to the maintenance team".
>
> That is a reasonable approach and will work fine most of the time, 

When will it not work? I have never encountered such a case.

> but it does not explain the lack of a language feature that is taken
> for granted in other languages - and coming from another language, I
> find the lack of structured exception information as a defect, even
> though I realize that I can easily work around it. The point is that
> I should not be forced to work around anything.

If you look into the details of "structured exception handling" in
other languages and implementations, they have bugs, and fundamental
flaws in design. That is why Ada did not go that way. Ada is _much_
more careful about getting the core design right, allowing fully
robust and safe implementations of _all_ features, especially in
multi-tasking and multi-processing environments.

So if you find yourself fighting Ada to do something, you need to step
back and think more carefully about _why_ you are doing it that way.
Ada is telling you it is inherently unsafe.

-- 
-- Stephe

Re: Structured exception information

[Dmitry A. Kazakov]

On Fri, 19 Jan 2007 04:47:28 -0500, Stephen Leake wrote:

> Maciej Sobczak <no.spam@no.spam.com> writes:
> 
>> Doesn't feel as type-safe as advertised.
> 
> But you have not given an actual example where a string is not
> a type-safe solution to the actual problem at hand.
> 
> The only example you have given is "present the error to the user". In
> that case, a string is precisely the correct type.

What about presenting an information necessary for handling the exception
to the handler?

Normally, exceptions are used when the situation cannot be dealt at the
point of raising. It cannot be handled because of lack of information. For
instance, Read has no idea what to do on EOF. But the handler of End_Error
knows it. Fine.

Now consider, a more complex picture. Let the client knows something. It is
still not enough, but it is a necessary piece of the puzzle, and what is
more important, is that the handler does not have this information and
cannot reconstruct it. In this scenario you would like to pass it as a
parameter to the handler, in an type-safe way, an Ada way.

As a practical example, consider mail non-delivery. A returned mail plus
traceback is the information to you, the handler from the exception point.

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

Re: Structured exception information

[Stephen Leake]

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

> On Fri, 19 Jan 2007 04:47:28 -0500, Stephen Leake wrote:
>
>> Maciej Sobczak <no.spam@no.spam.com> writes:
>> 
>>> Doesn't feel as type-safe as advertised.
>> 
>> But you have not given an actual example where a string is not
>> a type-safe solution to the actual problem at hand.
>> 
>> The only example you have given is "present the error to the user". In
>> that case, a string is precisely the correct type.
>
> What about presenting an information necessary for handling the exception
> to the handler?

Ok, I would still like to see a precise example, not all this hand-waving.

> As a practical example, consider mail non-delivery. A returned mail plus
> traceback is the information to you, the handler from the exception point.

To me, bounced emails are _not_ "exceptional" events in mail handling
systems; they are expected, even "normal". As for the failed
temperature sensor in another thread, out-of-band status information
is a cleaner way to handle this.

Can you show some example Ada code for this? And explain why
exceptions are better than status for this case?

-- 
-- Stephe

Re: Structured exception information

[Dmitry A. Kazakov]

On Sat, 20 Jan 2007 10:04:07 -0500, Stephen Leake wrote:

> "Dmitry A. Kazakov" <mailbox@dmitry-kazakov.de> writes:
> 
>> On Fri, 19 Jan 2007 04:47:28 -0500, Stephen Leake wrote:
>>
>>> Maciej Sobczak <no.spam@no.spam.com> writes:
>>> 
>>>> Doesn't feel as type-safe as advertised.
>>> 
>>> But you have not given an actual example where a string is not
>>> a type-safe solution to the actual problem at hand.
>>> 
>>> The only example you have given is "present the error to the user". In
>>> that case, a string is precisely the correct type.
>>
>> What about presenting an information necessary for handling the exception
>> to the handler?
> 
> Ok, I would still like to see a precise example, not all this hand-waving.

I wished to stay at the level of vagueness of "present the error to the
user." (:-))

>> As a practical example, consider mail non-delivery. A returned mail plus
>> traceback is the information to you, the handler from the exception point.
> 
> To me, bounced emails are _not_ "exceptional" events in mail handling
> systems; they are expected, even "normal".

We agree on that. But that is not the problem we are discussing. Which
simplified is whether an API procedure Send_Mail should add a non-string
information to the Delivery_Error exception, or else pack it in a String. I
prefer the former.

> As for the failed
> temperature sensor in another thread, out-of-band status information
> is a cleaner way to handle this.

I don't think so, that would make interfaces very clumsy. Further it is a
bad design, because it eludes to face the problem by putting all the
responsibility to deal with on the user's shoulders. The user of API must
check the status later. This is a distributed overhead contaminating the
code and violating the principle "here and now."

Note, even if we considered a middleware layer, in which the sensor
variable would indeed have a status field and a lot of other fields to make
the internals working, even in this design, the argument would still hold.
Because then, when accessing such variable object, one would again need an
exception and an information about the status in it. Otherwise one would
have quite nasty race condition issues when accessing such variables - you
check the status, get preempted and then read a rubbish value.

The point is, you have just moved the problem, you didn't solve it.

And last but not least, it is an argument against exceptions in general and
thus irrelevant here.

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

Re: Structured exception information

[Stephen Leake]

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

>>> As a practical example, consider mail non-delivery. A returned mail plus
>>> traceback is the information to you, the handler from the exception point.
>> 
>> To me, bounced emails are _not_ "exceptional" events in mail handling
>> systems; they are expected, even "normal".
>
> We agree on that. 

Good.

> But that is not the problem we are discussing. Which simplified is
> whether an API procedure Send_Mail should add a non-string
> information to the Delivery_Error exception, or else pack it in a
> String. I prefer the former.

Ah. Apparently you don't agree with me, or you missed my point.

Since bounced emails are not exceptional events, they should not be
handled by exceptions. Send_Mail should return status information, as
much as it wants to, for bounced emails; it should _not_ raise an
exception in this case.

>> As for the failed
>> temperature sensor in another thread, out-of-band status information
>> is a cleaner way to handle this.
>
> I don't think so, that would make interfaces very clumsy. 

Well, I'd need to see an actual interface, as part of a real system,
to judge that.

If you are talking about the sensor system, then I _have_ seen real
examples of that, and it is not clumsy; it solves the problem of
possibly failed sensors quite nicely.

Basically, the result of any sensor read is a record:

type Sensor_Result_Type is record
    Quality : Quality_Type;
    Value   : Value_Type;
end record;

Any algorithm that deals with the sensor must be prepared for Quality
to be Bad.

Note that the algorithm is not just skipped; it probably uses an
estimate based on past values. Only when the sensor is Bad for some
finite time is it declared Permanently_Bad; then the system will
switch to the backup sensor, or an algorithm that does not use that
sensor.

> Further it is a bad design, because it eludes to face the problem by
> putting all the responsibility to deal with on the user's shoulders.

Say what?

Whether the status information is passed in an 'out' parameter, or as
part of a structured exception, or packed into an exception string,
the user still has to deal with it.

We are only discussing the parameter passing mechanism, not who is
going to deal with the information.

The same argument applies to the sensor system.

> The user of API must check the status later. 

Why "later"? Since bouncing is expected, that status must be checked
immediately; that's the point.

For the sensor, the quality is packaged with the value, they are
always examined together.

> This is a distributed overhead contaminating the code and violating
> the principle "here and now."

I'm not familiar with that principle of code design. As a lifestyle,
I've heard of it.

> Note, even if we considered a middleware layer, in which the sensor
> variable would indeed have a status field and a lot of other fields to make
> the internals working, even in this design, the argument would still
> hold.

I'm lost; which argument?

> Because then, when accessing such variable object, one would again need an
> exception and an information about the status in it. Otherwise one would
> have quite nasty race condition issues when accessing such variables - you
> check the status, get preempted and then read a rubbish value.

Say what? Once the sensor has been read, all of the information is in
an object of Result_Type; there is no race condition in reading the
components of Result_Type.

> The point is, you have just moved the problem, you didn't solve it.

What "problem" are you trying to solve?

> And last but not least, it is an argument against exceptions in general and
> thus irrelevant here.

I am arguing that exceptions should not be used when 'out' parameters
are more appropriate.

I am suggesting that in general, if you _need_ structured information
as the result of a subprogram, passing it in an 'out' parameter is
better than attaching it to an exception.

But others have posted convincing cases where that is not true. And it
appears the state of the art in exception mechanisms has improved, so
it's not such a large problem as I thought it was.

-- 
-- Stephe

Re: Structured exception information

[Dmitry A. Kazakov]

On Tue, 23 Jan 2007 02:28:12 -0500, Stephen Leake wrote:

> "Dmitry A. Kazakov" <mailbox@dmitry-kazakov.de> writes:
> 
>>>> As a practical example, consider mail non-delivery. A returned mail plus
>>>> traceback is the information to you, the handler from the exception point.
>>> 
>>> To me, bounced emails are _not_ "exceptional" events in mail handling
>>> systems; they are expected, even "normal".
>>
>> We agree on that. 
> 
> Good.
> 
>> But that is not the problem we are discussing. Which simplified is
>> whether an API procedure Send_Mail should add a non-string
>> information to the Delivery_Error exception, or else pack it in a
>> String. I prefer the former.
> 
> Ah. Apparently you don't agree with me, or you missed my point.
> 
> Since bounced emails are not exceptional events, they should not be
> handled by exceptions. Send_Mail should return status information, as
> much as it wants to, for bounced emails; it should _not_ raise an
> exception in this case.

Oops, then you reject use of exceptions here. That would be a different
discussion then.

> If you are talking about the sensor system, then I _have_ seen real
> examples of that, and it is not clumsy; it solves the problem of
> possibly failed sensors quite nicely.

Good, let's drop that E-mail stuff, because sensors seem to be closer to
both of us.

> Basically, the result of any sensor read is a record:
> 
> type Sensor_Result_Type is record
>     Quality : Quality_Type;
>     Value   : Value_Type;
> end record;
> 
> Any algorithm that deals with the sensor must be prepared for Quality
> to be Bad.

I don't think so. From a system-wide perspective, yes, sure, but locally I
have a problem with that. Let's consider:

   function "+" (X, Y : Sensor_Result_Type) return Value_Type;

We have to discard this on the same reasons (if we had accepted them (:-))
and replace it with:

   function "+" (X, Y : Sensor_Result_Type) return Sensor_Result_Type;

Now, before we would rush into developing a home-brewed IEEE arithmetic.
May I ask you, how Quality_Type compose under "+"? I know what 1+2 is, but
what is (1, Try_Again) + (2, Change_Battery)?

(2, First_Change_Then_Try)? (:-))

> Note that the algorithm is not just skipped; it probably uses an
> estimate based on past values.

Yes, these are not exceptional states, they are parts of some composite
value. Nobody would implement that using exceptions. It would be like file
Read raising exception on each read character and returning EOF if there
were no one. (:-)) Let's don't consider measurement errors and concentrate
on hardware faults.

> Only when the sensor is Bad for some
> finite time is it declared Permanently_Bad; then the system will
> switch to the backup sensor, or an algorithm that does not use that
> sensor.

OK, this is a third case. Timeouts are handled in a similar way. Before an
exceptional state is entered one ignores the data/service quality assuming
that everything is alright, because no reasonable estimation could be made
anyway before the timeout expires.

>> Further it is a bad design, because it eludes to face the problem by
>> putting all the responsibility to deal with on the user's shoulders.
> 
> Say what?
> 
> Whether the status information is passed in an 'out' parameter, or as
> part of a structured exception, or packed into an exception string,
> the user still has to deal with it.
> 
> We are only discussing the parameter passing mechanism, not who is
> going to deal with the information.

Full agreement.

But the mechanism of passing is very different. In case of exceptions it is
fully transparent for the layers where the exception is being propagated
unhandled. A big difference.

>> The user of API must check the status later. 
> 
> Why "later"? Since bouncing is expected, that status must be checked
> immediately; that's the point.
> 
> For the sensor, the quality is packaged with the value, they are
> always examined together.

See the example with "+".

>> Note, even if we considered a middleware layer, in which the sensor
>> variable would indeed have a status field and a lot of other fields to make
>> the internals working, even in this design, the argument would still
>> hold.
> 
> I'm lost; which argument?

Actually your Sensor_Result_Type is exactly what I had in mind.

>> Because then, when accessing such variable object, one would again need an
>> exception and an information about the status in it. Otherwise one would
>> have quite nasty race condition issues when accessing such variables - you
>> check the status, get preempted and then read a rubbish value.
> 
> Say what? Once the sensor has been read, all of the information is in
> an object of Result_Type; there is no race condition in reading the
> components of Result_Type.

Consider it a protected object, with Get_Quality and Get_Value functions.
(a middleware is a kind of bunch of such objects)

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

Re: Structured exception information

[Stephen Leake]

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

>> Basically, the result of any sensor read is a record:
>> 
>> type Sensor_Result_Type is record
>>     Quality : Quality_Type;
>>     Value   : Value_Type;
>> end record;
>> 
>> Any algorithm that deals with the sensor must be prepared for Quality
>> to be Bad.
>
> I don't think so. From a system-wide perspective, yes, sure, but locally I
> have a problem with that. Let's consider:
>
>    function "+" (X, Y : Sensor_Result_Type) return Value_Type;
>
> We have to discard this on the same reasons (if we had accepted them (:-))
> and replace it with:
>
>    function "+" (X, Y : Sensor_Result_Type) return Sensor_Result_Type;
>
> Now, before we would rush into developing a home-brewed IEEE arithmetic.
> May I ask you, how Quality_Type compose under "+"? I know what 1+2 is, but
> what is (1, Try_Again) + (2, Change_Battery)?
>
> (2, First_Change_Then_Try)? (:-))

Obviously, a system that is prepared to deal with failing sensors has
to define what to do in this situation.

It is not typical to define "+" for a sensor quality like this, which
has only a few values. The quality would be considered at the top
level, with a case statement.

On the other hand, some sensors (for example star trackers) have a
floating point quality, which can be used in a Kalman filter to arrive
at a correctly balanced result. In that case, defining "+" probably
makes sense.

-- 
-- Stephe

Re: Structured exception information

[Maciej Sobczak]

Stephen Leake wrote:

>>> Then what's wrong with a string?
>> Doesn't feel as type-safe as advertised.
> 
> But you have not given an actual example where a string is not
> a type-safe solution to the actual problem at hand.

Going this path a bit further, I find it difficult to convince myself 
that Ada is any better than, say, Perl. :-)

>> Sure. That's why there are more JavaScript programmers than Ada programmers.
> 
> I don't follow. Strings are perfectly valid Ada constructs. Why does
> the code to build the string not feel like Ada to you?

Again - going down this route, what's wrong with having only strings in 
the language? Tcl is a powerful language that is quite successful with 
only strings.

> You have not said _why_ you need to dismantle this information in the
> handler. What, _exactly_, will the handler do with the separate bits?

Looking up the localized error message in the dictionary based on the 
*type-safe* error code that it got from the exception object, probably?

>> Still, that's not what I expect from Ada.
> 
> Lots of people expect lots of things.

And lots of them find these things in other languages.

> Sometimes, those expectations
> are unreasonable, and should be changed.

Sometimes, yes.

> That's what I'm trying to
> explore here; I think expecting anything other than a string for
> exception data is unreasonable.

I expect *type-safe* error code which I can look up in the dictionary.

> So far, you have presented no case to show I am wrong.

I'm looking forward to see a convincing solution for error code and the 
dictionary.

>>> As a general matter of user-interface design, I would find that
>>> annoying. As a user of a system, the only thing I want from an error
>>> message is either "how do I fix this myself" or "how do I report this
>>> to the maintenance team".
>> That is a reasonable approach and will work fine most of the time, 
> 
> When will it not work? I have never encountered such a case.

It will not work in those cases where the handler might attempt to "fix 
things" and retry the operation that failed instaed of displaying the 
"sorry" message.
Consider for example a compuational algorithm that failed to allocate 
some memory that was needed for computations. Exception is raised and 
goes up to the handler that as a first attempt tries to flush some 
in-memory caches or other transient buffers and restarts the computation 
with the hope that it can now succeed with more memory available in the 
system. There is no need to display anything to the user and string 
format has no use here. Even for this simple case I can imagine that the 
code in question can include in the exception object the size of the 
allocation that failed, so that the handler can make more optimal 
decisions as to what should be flushed. In such a case, I'd expect the 
size information to retain the type safety that should be there from the 
very beginning.

> If you look into the details of "structured exception handling" in
> other languages and implementations, they have bugs, and fundamental
> flaws in design.

Ada does not have this, because it *might* be difficult for 
implementers? Is it better if programmers find it more difficult to 
write final programs instead?

> That is why Ada did not go that way. Ada is _much_
> more careful about getting the core design right

It failed in this aspect.

> allowing fully
> robust and safe implementations of _all_ features

Is there anything in Java or C++ or Python or whatever exception 
handling that makes it fundamentally impossible to implement correctly?

> especially in
> multi-tasking and multi-processing environments.

Why should I care about multi-tasking and multi-processing environments 
when writing single-tasking programs? Should I be constrained in my work 
just because some feature might be difficult to implement elsewhere?
I'd say no, but just in case I propose an easy solution for everybody: 
just forbid structured exceptions in multitasking and distributed 
environments and allow them where they will naturally work.
BTW - somehow Java exceptions work fine in a distributed environment, so 
there is a proof that such thing is possible.

> So if you find yourself fighting Ada to do something, you need to step
> back and think more carefully about _why_ you are doing it that way.
> Ada is telling you it is inherently unsafe.

Sorry, I don't buy this. I stepped back, thought more carefully and I 
haven't seen any solution for looking up error code in a dictionary or 
for transmitting size information so that the handler can make optimal 
decisions before retrying memory-expensive computations.

-- 
Maciej Sobczak : http://www.msobczak.com/
Programming    : http://www.msobczak.com/prog/

Re: Structured exception information

[Stephen Leake]

Maciej Sobczak <no.spam@no.spam.com> writes:

> Again - going down this route, what's wrong with having only strings
> in the language? Tcl is a powerful language that is quite successful
> with only strings.

That's absurd.

I said "Strings are the correct type for presenting information to the
user".

My full system uses strings for that purpose. It uses many other
types for other purposes; quaternions for orientation, unbounded
arrays for dynamic lists, binary trees for sorted symbol tables, hash
tables for fast lookup of symobls, a class hierarchy with abstract
operations for models, records with bit-level representation clauses
for hardware registers. Etc. 

>> You have not said _why_ you need to dismantle this information in the
>> handler. What, _exactly_, will the handler do with the separate bits?
>
> Looking up the localized error message in the dictionary based on the
> *type-safe* error code that it got from the exception object,
> probably?

Why would it do that? The original problem was "present this
information to the user".

Again, I'm asking for a _detailed_, _real_ example!

> I expect *type-safe* error code which I can look up in the dictionary.

Well, ok, that's a fairly clear requirement. And yes, Ada exceptions
cannot include a type-safe error code.

But I don't understand _why_ you want to do that in the exception
handler. Why didn't the callee look up the error code, and put the
string in the exception message?

What will the exception handler do with the result of the lookup?

> I'm looking forward to see a convincing solution for error code and
> the dictionary.

You have not defined "dictionary" here. If I assume it just contains
strings, and the handler will simply output that string to
Standard_Error, then having the callee do the lookup is a perfectly
reasonable solution.

>>>> As a general matter of user-interface design, I would find that
>>>> annoying. As a user of a system, the only thing I want from an error
>>>> message is either "how do I fix this myself" or "how do I report this
>>>> to the maintenance team".
>>> That is a reasonable approach and will work fine most of the time,
>> When will it not work? I have never encountered such a case.
>
> It will not work in those cases where the handler might attempt to
> "fix things" and retry the operation that failed instaed of displaying
> the "sorry" message.
> Consider for example a compuational algorithm that failed to allocate
> some memory that was needed for computations. Exception 
> is raised and goes up to the handler that as a first attempt tries
> to flush some in-memory caches or other transient buffers and
> restarts the computation with the hope that it can now succeed with
> more memory available in the system. There is no need to display
> anything to the user and string format has no use here. Even for
> this simple case I can imagine that the code in question can include
> in the exception object the size of the allocation that failed, so
> that the handler can make more optimal decisions as to what should
> be flushed. In such a case, I'd expect the size information to
> retain the type safety that should be there from the very beginning.

Ok, that's a concrete example. Thank you.

>> If you look into the details of "structured exception handling" in
>> other languages and implementations, they have bugs, and fundamental
>> flaws in design.
>
> Ada does not have this, because it *might* be difficult for
> implementers? 

Not "might be difficult", but "is impossible to get truly right in
_all_ cases required by the language". Hmm. "impossible" may be too
strong. "we know of no way to do it" is probably closer. As Randy has
been saying, now that the rest of Ada has evolved, it may be that we
now _could_ find a way to have structured exceptions in the next
version of Ada.



> Is it better if programmers find it more difficult to write final
> programs instead?

Yes! 

Let's be clear. Here are the choices:

1) Define structured exceptions in Ada. We _know_ that _all_ compilers
will not meet the standard in some way, and each in different ways.

2) Define only strings for exceptions. Let the programmers use other
methods to solve particular problems.


In case 1), I will never be able to rely on the exception information,
so I will only use strings anyway.

>> That is why Ada did not go that way. Ada is _much_
>> more careful about getting the core design right
>
> It failed in this aspect.

Well, you are interpreting "right" to mean "has everything I want"; I
meant "is internally consistent, has no unexpected behaviors, has a
reasonable implementation approach".

>> allowing fully
>> robust and safe implementations of _all_ features
>
> Is there anything in Java or C++ or Python or whatever exception
> handling that makes it fundamentally impossible to implement correctly?

Yes, which is why none of those implementations fully meets the
standard, and each implementation differs from the others, sometimes
in subtle ways.

>> especially in
>> multi-tasking and multi-processing environments.
>
> Why should I care about multi-tasking and multi-processing
> environments when writing single-tasking programs? 

Well, that is a reasonable point. Ada made the choice to make
multi-tasking work right, as part of the language. So you may want to
choose another language, if this particular choice make Ada unsuitable
for you. 

> Should I be constrained in my work just because some feature might
> be difficult to implement elsewhere? I'd say no, but just in case I
> propose an easy solution for everybody: just forbid structured
> exceptions in multitasking and distributed environments and allow
> them where they will naturally work. BTW - somehow Java exceptions
> work fine 

By "fine" do you mean "i've never had a problem with them" or do you
mean "everyone who has studied these issues in depth agrees that the
Java implementation will _never_ have a problem"?

Those are two very different statements. I prefer a language that uses
the second approach.

The Java class libraries have lots of deprecated procedures, that
"worked fine" when they were first released, but had problems of one
sort or another when people tried to use them in unanticipated but
clearly reasonable ways. Ada tries very hard to avoid that sort of
thing, especially in the core language.

>> So if you find yourself fighting Ada to do something, you need to step
>> back and think more carefully about _why_ you are doing it that way.
>> Ada is telling you it is inherently unsafe.
>
> Sorry, I don't buy this. I stepped back, thought more carefully and I
> haven't seen any solution for looking up error code in a dictionary or
> for transmitting size information so that the handler can make optimal
> decisions before retrying memory-expensive computations.

In Ada, you need to pass back an error code of some type, or the size,
not use an exception. That is a valid solution. Using exceptions for
this is inherently unsafe.

-- 
-- Stephe

Re: Structured exception information

[Robert A Duff]

Stephen Leake <stephen_leake@stephe-leake.org> writes:

> But I don't understand _why_ you want to do that in the exception
> handler. Why didn't the callee look up the error code, and put the
> string in the exception message?

The same reason the callee doesn't print the string out and/or terminate
the program.  "Separation of concerns" is the appropriate buzzword.

> 1) Define structured exceptions in Ada. We _know_ that _all_ compilers
> will not meet the standard in some way, and each in different ways.

I'm confused by that statement.  Are you merely saying that "compilers
have bugs"?  It's (sadly) true, but that's not a valid criticism of this
particular feature.  Or are you saying there's something specific about
the "exceptions as objects" feature we're discussing that makes it hard
(impossible?!) to implement, and therefore buggy?

I (think I) know how to implement this feature.  What are the
implementation difficulties you perceive?  I've heard some vague talk
about tasks and distributed systems -- but I still don't see the
problem(s).

It's certainly more difficult to implement data attached to
exceptions, compared to the Ada 83 feature, where an exception can be
represented as a fixed-size (one word) compile- or link-time-known
quantity.  Managing variable sized things is definitely harder.
But I fail to see how exceptions with Strings attached (he he)
is easier to implement than exceptions with arbitrary (typed) data
attached.

- Bob

Re: Structured exception information

[Stephen Leake]

Robert A Duff <bobduff@shell01.TheWorld.com> writes:

> Stephen Leake <stephen_leake@stephe-leake.org> writes:
>
>> 1) Define structured exceptions in Ada. We _know_ that _all_ compilers
>> will not meet the standard in some way, and each in different ways.
>
> I'm confused by that statement.  Are you merely saying that "compilers
> have bugs"?  It's (sadly) true, but that's not a valid criticism of this
> particular feature.  Or are you saying there's something specific about
> the "exceptions as objects" feature we're discussing that makes it hard
> (impossible?!) to implement, and therefore buggy?

The latter. But apparently I'm wrong, given the current state of the art.

> It's certainly more difficult to implement data attached to
> exceptions, compared to the Ada 83 feature, where an exception can be
> represented as a fixed-size (one word) compile- or link-time-known
> quantity.  Managing variable sized things is definitely harder.
> But I fail to see how exceptions with Strings attached (he he)
> is easier to implement than exceptions with arbitrary (typed) data
> attached.

This is related to an issue that you raised earlier; in Ada 2005 there
is a limit of 200 characters on the string. I believe that is because
exceptions with Strings must work even when the exception is
Storage_Error due to either heap exhaustion or stack overflow.

You can't allocate space for the attached data at the point of the
exception; you have to allocate a 200 byte buffer somewhere (in
per-task space?) ahead of time, in case an exception is raised.

(a side note: 200 is arbitary; we need a pragma Exception_Data_Size,
which would default to 200.)

It's much better to trucate a String to 200 bytes than some
user-defined type. I supposed fixed-size user-defined types that are
smaller than 200 bytes could work. But I don't see how to allow
dynamically sized data.

-- 
-- Stephe

Re: Structured exception information

[Robert A Duff]

Stephen Leake <stephen_leake@stephe-leake.org> writes:

> Robert A Duff <bobduff@shell01.TheWorld.com> writes:
>> It's certainly more difficult to implement data attached to
>> exceptions, compared to the Ada 83 feature, where an exception can be
>> represented as a fixed-size (one word) compile- or link-time-known
>> quantity.  Managing variable sized things is definitely harder.
>> But I fail to see how exceptions with Strings attached (he he)
>> is easier to implement than exceptions with arbitrary (typed) data
>> attached.
>
> This is related to an issue that you raised earlier;

Sorry, which issue did I raise, and when? -- I guess I've forgotten...

>... in Ada 2005 there
> is a limit of 200 characters on the string. I believe that is because
> exceptions with Strings must work even when the exception is
> Storage_Error due to either heap exhaustion or stack overflow.

I don't think that's the issue.  If you raise an exception with a String
attached (whether that's S_E or not), and there's no stack space to
allocate that String, then the run-time system needs to be prepared to
raise a "plain old" Storage_Error.  That's just a special case: if ANY
operation runs out of stack, the run-time system needs to be able to
raise S_E.  That's no big deal -- just reserve enough extra space on
every task's stack, so that raising S_E is always possible.  And that
"extra stack space" is a fixed small number of bytes.

I think the 200-char limit was based on concerns about managing the
memory.  (Misguided concerns, IMHO.)  The exception occurrence is
allocated on the stack at the point of the raise, and it somehow needs
to appear at the point of the handler.  That's tricky, but doable (after
all, Ada allows "return String", which is pretty much the same idea).
Heap allocation may be necessary in some cases (as Stroustrup points out
in one of his books on C++).  That's OK -- embedded systems might want
to avoid those cases.

> It's much better to trucate a String to 200 bytes than some
> user-defined type.

Indeed.  If a limit is needed (I don't think so), then truncation is
tolerable for Strings, but not for misc data types.

- Bob

Re: Structured exception information

[Maciej Sobczak]

Robert A Duff wrote:

>> It's much better to trucate a String to 200 bytes than some
>> user-defined type.
> 
> Indeed.  If a limit is needed (I don't think so), then truncation is
> tolerable for Strings

It is not tolerable if the message contains anything more than a prose. 
If the programmer needs to build the string message out of other 
components (what was suggested in this thread), then truncating the 
message is about the same good idea as truncating the amount in bank 
account or rounding coordinates for a spaceship. That's the problem.

-- 
Maciej Sobczak : http://www.msobczak.com/
Programming    : http://www.msobczak.com/prog/

Re: Structured exception information

[Stephen Leake]

Robert A Duff <bobduff@shell01.TheWorld.com> writes:

>>... in Ada 2005 there
>> is a limit of 200 characters on the string. I believe that is because
>> exceptions with Strings must work even when the exception is
>> Storage_Error due to either heap exhaustion or stack overflow.
>
> I don't think that's the issue.  If you raise an exception with a String
> attached (whether that's S_E or not), and there's no stack space to
> allocate that String, then the run-time system needs to be prepared to
> raise a "plain old" Storage_Error.  That's just a special case: if ANY
> operation runs out of stack, the run-time system needs to be able to
> raise S_E.  That's no big deal -- just reserve enough extra space on
> every task's stack, so that raising S_E is always possible.  And that
> "extra stack space" is a fixed small number of bytes.

So you are saying:

raise My_Exception with <any construct>;

is allowed to become (in effect);

raise Storage_Error;

I guess that makes sense, and is true now. I hadn't quite realized that.

> I think the 200-char limit was based on concerns about managing the
> memory.  (Misguided concerns, IMHO.)  The exception occurrence is
> allocated on the stack at the point of the raise, and it somehow needs
> to appear at the point of the handler.  That's tricky, but doable (after
> all, Ada allows "return String", which is pretty much the same idea).
> Heap allocation may be necessary in some cases (as Stroustrup points out
> in one of his books on C++).  That's OK -- embedded systems might want
> to avoid those cases.

Yes, I agree, in the absense of Storage_Error, dynamic exceptions
should be no harder than dynamic function results. 

-- 
-- Stephe

Re: Structured exception information

[Robert A Duff]

Stephen Leake <stephen_leake@stephe-leake.org> writes:

> So you are saying:
>
> raise My_Exception with <any construct>;
>
> is allowed to become (in effect);
>
> raise Storage_Error;

Yes, precisely.

This is just a special case of the fact that:

<any construct>

is allowed to become (in effect);

raise Storage_Error;

!

> I guess that makes sense, and is true now. I hadn't quite realized that.

Yeah, it pretty much has to be that way, given that we don't know (at the
language level) how much memory is available, nor how much memory is
used up by any given construct.  We don't even really know what "memory"
means -- the implementation could split memory up into stacks, secondary
stacks, heap(s), stacks could be discontiguous, stacks could be
growable -- and the language designer doesn't want to deal with all
that.

Even something as simple as "X := 1;" can, in theory, raise
Storage_Error.  For that matter, I suppose even "null;" can raise
Storage_Error!

- Bob

Re: Structured exception information

[Maciej Sobczak]

Robert A Duff wrote:

> For that matter, I suppose even "null;" can raise
> Storage_Error!

AARM 5.1/13:

"The execution of a null_statement has no effect."

-- 
Maciej Sobczak : http://www.msobczak.com/
Programming    : http://www.msobczak.com/prog/

Re: Structured exception information

[Robert A Duff]

Maciej Sobczak <no.spam@no.spam.com> writes:

> Robert A Duff wrote:
>
>> For that matter, I suppose even "null;" can raise
>> Storage_Error!
>
> AARM 5.1/13:
>
> "The execution of a null_statement has no effect."

But 11.1(6) (which says anything can raise Storage_Error) trumps that.
It also trumps whatever paragraphs explain the semantics of "X := 1;".

- Bob

Re: Structured exception information

[Randy Brukardt]

Someone wrote: (I've lost track of the original author)

> >>... in Ada 2005 there
> >> is a limit of 200 characters on the string. I believe that is because
> >> exceptions with Strings must work even when the exception is
> >> Storage_Error due to either heap exhaustion or stack overflow.

Sorry, that's FUD. That limit only applies in very limited circumstances
(Save_Exception, Reraise_Occurrence, reraise statement). The only one of
those that you even have a realistic chance of running into is reraise
statement, and if you really are worried about that limit, you can avoid the
limit be avoiding any of those constructs. So it shouldn't prevent the use
of (admittedly suboptimal) coding/decoding mechanisms.

An implementation that truncates messages for regular raise statements is
just plain wrong (go read 11.4.1(18) again if you don't believe me).

Because that's the case, it's hardly possible for it to be valuable to an
implementation to actually do that truncation. (You've got to already have a
mechanism for handling the unknown sized objects in an occurrence.) Users
need to push vendors into not using 11.4.1(18) [it's surely not a
requirement!]

                              Randy.

Re: Structured exception information

[Maciej Sobczak]

Stephen Leake wrote:

>> Looking up the localized error message in the dictionary based on the
>> *type-safe* error code that it got from the exception object,
>> probably?
> 
> Why would it do that? The original problem was "present this
> information to the user".

Separation of concerns was already presented by Robert, but that's not 
the whole story. The raising site might not even know where the 
dictionary is and making it aware would mean reversing the dependency 
that usual systems have between (G)UI and lower layers.
In the extreme case, the team developing the algorithmic part need not 
be aware that their component will be used in the environment with a 
dictionary, so even this reversing of dependencies would not be possible 
in general.

> Again, I'm asking for a _detailed_, _real_ example!

A real example is a HTTP component that reports error code with value 
404 and the GUI leyer that looks up the dictionary of messages for 
currently selected language to resolve it to whatever is appropriate for 
display. The HTTP network component should not be aware about the 
multilanguage abilities of the browser. Dictionary (in the sense of the 
map that associates error codes with human readable messages) makes it 
possible.

> What will the exception handler do with the result of the lookup?

Display it. The point is that the HTTP component has no idea where the 
display is, not to mention the current language - these are managed by 
higher levels of the software.

You can argue that return code instead of exception might do the job and 
that's true - but then we are back to the discussion of return codes vs. 
exceptions, which is a paradigm issue - which should be independent on 
the technical abilities of each solution. Exceptions should not be any 
less capable than return values are, otherwise designers cannot make 
free paradigm choices.


-- 
Maciej Sobczak : http://www.msobczak.com/
Programming    : http://www.msobczak.com/prog/

Re: Structured exception information

[Stephen Leake]

Maciej Sobczak <no.spam@no.spam.com> writes:

> A real example is a HTTP component that reports error code with value
> 404 and the GUI leyer that looks up the dictionary of messages for
> currently selected language to resolve it to whatever is appropriate
> for display. 

I don't buy it. Any HTTP component that I build will provide the
dictionary of HTTP error messages. Those error messages are defined in
the HTTP standard, not by the application! 

This business of passing back an error code instead of a string is all
heritage from C. C _can't_ pass back a string, let alone an exception,
so it relies on the horrible kludge of 'errno' and 'perror'. Ada can,
and should, do better.

> The HTTP network component should not be aware about the
> multilanguage abilities of the browser. 

Ah, internationalization of error messages. Again, I think the HTTP
component itself needs to be internationalized to make that work
properly, so it is simpler for the HTTP component to put the error
message string in the exception. That way, it can be used in a program
that is not otherwize internationalized.

Hmm. I guess an HTTP component that did not want to be bothered with
internationalization could just return error codes, and let the client
deal with internationalization. But I think that is a poor component,
compared to one that includes internationalization.

>> What will the exception handler do with the result of the lookup?
>
> Display it. The point is that the HTTP component has no idea where the
> display is, not to mention the current language - these are managed by
> higher levels of the software.

I don't see how proper internationalization can be done if low-level
components must be unaware of it. As I understand it, there is an OS
call to get the locale; any component that does HTTP is making other
OS calls, so why can't it make that one?

> You can argue that return code instead of exception might do the job
> and that's true - but then we are back to the discussion of return
> codes vs. exceptions, which is a paradigm issue 

Yes, exactly.

> - which should be independent on the technical abilities of each
> solution. Exceptions should not be any less capable than return
> values are, 

Well, that's a very strong statement. It is certainly a plausible
request of language designers, but we are arguing about whether it is
truly worth the cost, so you can't take that as a starting point.

Apparently it could be done with relatively little cost in Ada
2015, so we should push for it.

> otherwise designers cannot make free paradigm choices.

In general that is a Good Thing.

-- 
-- Stephe

Re: Structured exception information

[Maciej Sobczak]

Stephen Leake wrote:

>> A real example is a HTTP component that reports error code with value
>> 404 and the GUI leyer that looks up the dictionary of messages for
>> currently selected language to resolve it to whatever is appropriate
>> for display. 
> 
> I don't buy it. Any HTTP component that I build will provide the
> dictionary of HTTP error messages.

Surely it will also contain Polish versions of these messages, right?

> Those error messages are defined in
> the HTTP standard, not by the application! 

HTTP standard defines the *meaning* of errors, not their literal text. 
Localized browsers display messages in local language.

> This business of passing back an error code instead of a string is all
> heritage from C.

Yes.

> C _can't_ pass back a string

Sure it can.

> let alone an exception,
> so it relies on the horrible kludge of 'errno' and 'perror'.

errno and perror is a kludge, but not inherent for C. There are lots of 
interfaces (POSIX threads, for example) designed for C that work without 
global errno.

> Ada can,
> and should, do better.

Yes. Ada should allow structured exception information, as any other 
high-level language does.

>> The HTTP network component should not be aware about the
>> multilanguage abilities of the browser. 
> 
> Ah, internationalization of error messages. Again, I think the HTTP
> component itself needs to be internationalized to make that work
> properly, so it is simpler for the HTTP component to put the error
> message string in the exception.

No. I've been involved in an application for the Belgian market, where 
there is more than one official language. It was an application for the 
call center, where operators needed a possibility to switch the display 
language at *run time*, depending on the preferences of the client 
calling them, so that the operator need not be a simultaneous 
translator. This means dynamic dictionary switching. Can your HTTP 
component do this? I mean - have you *foreseen* an appropriate API for 
switching the dictionary between French and Flemish? I guess no.

Low-level components should *never* be involved in user-interface tasks 
like message composition. They should provide *information*, but not 
*messages*. Ada got it wrong by focusing on the latter in exception 
handling.

> Hmm. I guess an HTTP component that did not want to be bothered with
> internationalization could just return error codes, and let the client
> deal with internationalization.

Bingo.

> But I think that is a poor component,
> compared to one that includes internationalization.

No, it's a perfect component that can be reused in the environment that 
you didn't even think of when developing it. Separation of concerns.

> I don't see how proper internationalization can be done if low-level
> components must be unaware of it. As I understand it, there is an OS
> call to get the locale; any component that does HTTP is making other
> OS calls, so why can't it make that one?

Why doesn't it display the message? Why stop at message composition?

>> Exceptions should not be any less capable than return
>> values are, 
> 
> Well, that's a very strong statement. It is certainly a plausible
> request of language designers, but we are arguing about whether it is
> truly worth the cost, so you can't take that as a starting point.

Nobody in this discussion explained why the cost would be prohibitive. 
On the contrary, examples of languages that do this abound.

> Apparently it could be done with relatively little cost in Ada
> 2015, so we should push for it.

What about Ada's competitiveness till that time? ;-)

>> otherwise designers cannot make free paradigm choices.
> 
> In general that is a Good Thing.

I don't agree. Not in general. By "free paradigm choice" I mean the 
choice that is not imposed by implementation constraints. In particular, 
the choice between exception and return code should not be based on 
their different type-safety abilities.

-- 
Maciej Sobczak : http://www.msobczak.com/
Programming    : http://www.msobczak.com/prog/

Re: Structured exception information

[Stephen Leake]

Maciej Sobczak <no.spam@no.spam.com> writes:

>> Ah, internationalization of error messages. Again, I think the HTTP
>> component itself needs to be internationalized to make that work
>> properly, so it is simpler for the HTTP component to put the error
>> message string in the exception.
>
> No. I've been involved in an application for the Belgian market, where
> there is more than one official language. It was an application for
> the call center, where operators needed a possibility to switch the
> display language at *run time*, depending on the preferences of the
> client calling them, so that the operator need not be a simultaneous
> translator. This means dynamic dictionary switching. Can your HTTP
> component do this? I mean - have you *foreseen* an appropriate API for
> switching the dictionary between French and Flemish? I guess no.

Then you "guess" wrong. Of course you should be able to switch
languages at run time; that's an obvious requirement. On the other
hand, I've never actually written an internationalized program. Maybe
the current tools are not as good as they should be.

> Low-level components should *never* be involved in user-interface
> tasks like message composition. They should provide *information*, but
> not *messages*. Ada got it wrong by focusing on the latter in
> exception handling.

Well, I guess I don't know enough about internationalization.

In my main project at work, it is much easier to format the messages
at the level where the relevant information is available.

>>> otherwise designers cannot make free paradigm choices.
>> In general that is a Good Thing.
>
> I don't agree. Not in general. By "free paradigm choice" I mean the
> choice that is not imposed by implementation constraints. In
> particular, the choice between exception and return code should not be
> based on their different type-safety abilities.

Actually, I was trying to say "free paradigm choice is a good thing".
Obviously what I actually wrote can be taken to mean the opposite :(.

-- 
-- Stephe

Re: Structured exception information

[Maciej Sobczak]

Stephen Leake wrote:

> In my main project at work, it is much easier to format the messages
> at the level where the relevant information is available.

I prefer to have the relevant information available at the level where 
the messages are formatted.

Looks like this is exactly the difference in our approaches. :-)

-- 
Maciej Sobczak : http://www.msobczak.com/
Programming    : http://www.msobczak.com/prog/

Re: Structured exception information

[Stephen Leake]

Maciej Sobczak <no.spam@no.spam.com> writes:

> Stephen Leake wrote:
>
>> In my main project at work, it is much easier to format the messages
>> at the level where the relevant information is available.
>
> I prefer to have the relevant information available at the level where
> the messages are formatted.

As do I; that's what I said :).

> Looks like this is exactly the difference in our approaches. :-)

You have not explained _why_ you format the messages at a higher
level than necessary.

Here's an actual example from my current system (simplified). We have
an analog output module, that accepts user input and writes it to a
hardware register. There is a maximum voltage that the hardware
supports; if the user inputs a voltage higher than that, we want a
nice warning message.

So the code in the analog module looks something like:

procedure Write_Output
   (Module : in Module_Type; 
    Symbol : in Symbol_Access_Type)
is
   User_Volts : in Real_Type := Reals.Get (Symbol);
begin
   if User_Volts > Max_Volts then
      raise User_Error with 
        Real_Type'image (User_Volts) & 
        " greater than " & 
        Real_Type'image (Max_Volts);
   else
      Write_Hardware (Module.Hardware_Device, To_Counts (User_Volts));
   end if;

end Write_Output;
  

This code is called from the user command parser (I'm using
OpenToken). There we have something like:

procedure Synthesize_Set
is
begin
    ...
    Set (Symbol, Token); --  Sets Symbol to user value
    Write_Output (Module, Symbol); -- dispatches to above
end Synthesize_Set;

One level up, in the main parsing loop, we have:

begin
   loop
      ...
      Parse; -- dispatches to Synthesize_*
   end loop;   
exception
when E : User_Error => 
    Put_Line (Ada.Exceptions.Get_Exception_Message (E));
end;

What would you change about this, and why?

You seem to be saying "pass User_Volts and Max_Volts up to the parser
loop, and let it format the message". But now the parser loop has to
understand the required information for _all_ possible errors in the
_entire_ system! For example, the digital potentiometer module has
_different_ limits that might be violated. That is _not_ information
hiding.

The way it's built now, the parser loop only has to deal with strings;
that's easy, and natural for a parser.

-- 
-- Stephe

Re: Structured exception information

[Markus E Leypold]

Stephen Leake <stephen_leake@stephe-leake.org> writes:

> Maciej Sobczak <no.spam@no.spam.com> writes:
>
>> Stephen Leake wrote:
>>
>>> In my main project at work, it is much easier to format the messages
>>> at the level where the relevant information is available.
>>
>> I prefer to have the relevant information available at the level where
>> the messages are formatted.
>
> As do I; that's what I said :).
>
>> Looks like this is exactly the difference in our approaches. :-)
>
> You have not explained _why_ you format the messages at a higher
> level than necessary.

I think one can support both approaches. Just have the exceaption text
in a specfic format, like

   "E-1234-DISK-FULL Disk full during database write"

The message identifier should be unique and can be used to
translate/reformat the message at higher layers to whatever one
wants. On the other side the message as it is is not meaningless and a
side benefit provides a unique identification when communicating to
the user

(I hope I'm not missing the topic here, since I didn't follow the
thread very closely).

Regards -- Markus

Re: Structured exception information

[Georg Bauhaus]

On Fri, 2007-01-26 at 04:35 -0500, Stephen Leake wrote:

> So the code in the analog module looks something like:
> 
...
>    if User_Volts > Max_Volts then
>       raise User_Error with 
>         Real_Type'image (User_Volts) & 
>         " greater than " & 
>         Real_Type'image (Max_Volts);
>    else
>       Write_Hardware (Module.Hardware_Device, To_Counts (User_Volts));
>    end if;

I'd prefer something like

procedure Write_Output
   (Module : in Module_Type;
    Symbol : in Symbol_Access_Type)
is
   User_Volts : constant Real_Type := Reals.Get (Symbol);
begin
   if User_Volts > Max_Volts then
      View.Set_Error((Off_Error with
                          Condition => Greater_Than,
                          Required => Max_Volts,
                          Given => User_Volts));
      raise User_Error;
   else
      Write_Hardware (Module.Hardware_Device, To_Counts (User_Volts));
   end if;

end Write_Output;

And then

exception
  when E : User_Error => 
    View.Show_Error;
      -- Uses the interface of the progenitors of Off_Error,
      -- for the object entered using View.Set_Error.
      -- If we had exception types, this could be
      -- much simpler, just View.Show_Error(E).
    View.Print(Ada.Exceptions.Get_Exception_Message (E));
end;


> What would you change about this, and why?

Absent exception types, making exception info propagation
explicit will add some advantages, in addition to not being
implicit as in exception strings:

- message information isn't dependent on arbitrary strings in the
  implementation of Write_Output. You'd need to recompile a
  *validation* procedure when the *message* should change even
  though the validation didn't change. From this viewpoint
  Write_Output mixes two separate concerns: input checking
  and UI message construction.

- Off_Error is derived from an abstract data type describing
  failure information. A user of this type can choose a
  suitable message constructed from the information.
  This is both *MVC* and also *decoupling*: The procedure Write_Output
  can be used unchanged even when error messages are to be
  displayed using Wide_String, a pair of LEDs or a Spanish
  character set.
  The construction of a message that meets the UI criteria (the
  parser loop with prompt in this case) becomes the job of the
  a View package that matches the display.

- the program points the reader to the software types and
  modules involved in propagating error information by
  naming the package and type at both ends (View in this case).
  A change in the implementation of View won't necessitate
  a recompilation of Write_Output, unlike using
  raise ... with ... for message construction.

- Any useful information that compilers add for an exception
  occurrence will not be touched.

Re: Structured exception information

[Stephen Leake]

Georg Bauhaus <bauhaus@futureapps.de> writes:

> On Fri, 2007-01-26 at 04:35 -0500, Stephen Leake wrote:
>
> I'd prefer something like
>
> procedure Write_Output
>    (Module : in Module_Type;
>     Symbol : in Symbol_Access_Type)
> is
>    User_Volts : constant Real_Type := Reals.Get (Symbol);
> begin
>    if User_Volts > Max_Volts then
>       View.Set_Error((Off_Error with
>                           Condition => Greater_Than,
>                           Required => Max_Volts,
>                           Given => User_Volts));
>       raise User_Error;
>    else
>       Write_Hardware (Module.Hardware_Device, To_Counts (User_Volts));
>    end if;
>
> end Write_Output;
>
> And then
>
> exception
>   when E : User_Error => 
>     View.Show_Error;
>       -- Uses the interface of the progenitors of Off_Error,
>       -- for the object entered using View.Set_Error.
>       -- If we had exception types, this could be
>       -- much simpler, just View.Show_Error(E).
>     View.Print(Ada.Exceptions.Get_Exception_Message (E));
> end;
>

Obviously that would work, but _why_ is it "better"? In my opinion,
it's worse, for libraries you want to distribute; you now have this
non-standard "View" library to distribute with your application.

I guess View.Show_Error might do something other than write a string
to an error log. It might put up a structured dialog box, with widgets
for each different field of the exception type. But that's a huge
amount of work, and no application I've ever seen does that.

What do you think Show_Error does here?

In addition, you have ignored the problem that each version of
Write_Output for different hardware will need need a corresponding
version of the exception type; more work.

Hmm. With the choice of names you used in Set_Error, you seem to be
implying that there is a "general error description language", that
Set_Error can enforce. I don't think that's true.

Here is a small sample of actual error messages from my application:

raise Hardware_Error with 
 "digital pot card did not respond to serial number request";

raise Hardware_Error with
  "digital pot card responded with wrong byte count to serial number" &
  request (got" & Stream_Element_Offset'Image (Data_Last) & ")";

raise Parameter_Error with
  "motor" & Integer'Image (Module.Ramp_Motor_Index) & 
  " Disable_Encoder_Model not set";

raise Device_Error with
  "can't open device " & C_Name (1 .. C_Name'Last - 1) & " : " &
  Error_Type'Image (To_Error (GNAT.OS_Lib.Errno));

(There are many, many more, of course).

Here are a couple of other 'validation' procedures that raise
exceptions:

      procedure Check_Size (Max : in Integer)
      is begin
         if Integer (Bit) + Integer (Bit_Size) > Max then
            Ada.Exceptions.Raise_Exception
              (Config_File_Error'Identity,
               File_Line_Column & " bit, bit_size overflow register");
         end if;
      end Check_Size;

      procedure Check_Direction (Port : in Port_Type)
      is begin
         if Direction /= Mode (Port) then
            Ada.Exceptions.Raise_Exception
              (Config_File_Error'Identity,
               File_Line_Column & " conflicting directions");
         end if;
      end Check_Direction;


I suppose it might be _possible_ to come up with a generic set of
exception type components that would cover all of the messages in my
application, but that's a lot of extra design work, when 'raise ...
with <string>" give the same end result much more simply.

> Absent exception types, making exception info propagation
> explicit will add some advantages, in addition to not being
> implicit as in exception strings:
>
> - message information isn't dependent on arbitrary strings in the
>   implementation of Write_Output. You'd need to recompile a
>   *validation* procedure 

I guess by "validation" you mean the check "user_volts > Max_volts",
and the Check_* procedures I quoted above.

> when the *message* should change even though the validation didn't
> change. From this viewpoint Write_Output mixes two separate
> concerns: input checking and UI message construction.

People keep saying those should be separate concerns, but I don't
accept that. Why is it _better_ that they be separate?

As far as I can tell, the _primary_ purpose of a validation procedure
is to report a problem to the user. Formatting a string is the best
way to do that.

> - Off_Error is derived from an abstract data type describing
>   failure information. A user of this type can choose a
>   suitable message constructed from the information.
>   This is both *MVC* and also *decoupling*: The procedure Write_Output
>   can be used unchanged even when error messages are to be
>   displayed using Wide_String, 

Converting String to Wide_String is trivial. 

> a pair of LEDs 

No, there is nowhere near enough expressive power in LEDs to cover all
possible error messages. This is not a viable option. 

That's like saying "I can browse the web on my cell phone". You may
have a cell phone that understands http and can format HTML, but you
can actually _use_ only the very small fraction of the web sites that
have been reworked to support small displays. This is an excellent
analogy; the _provider_ of the information has to understand the
limits of the _display_.

Yes, I am assuming something about the ultimate error display
mechanism; I'm assuming it can display String. But no-one has
presented an actual alternative that isn't equivalent to String!

> or a Spanish character set. 

I think that is a valid objection; other parts of this thread have
talked around it. My application has no (current :) requirement for
this, so I can ignore it.

But let me present what I might do if this became a real requirement.
I would try to use the Gnu gettext library. I believe (I have _not_
studied this in detail) that library allows you to define
"message_ids" that are then looked up in a message database; there are
different instances of the database for each language. In addition, I
think you can include C printf escapes in the strings.

So two of the messages above would become:

raise Hardware_Error with MESSAGE_ID_1234;

where the English version of MESSAGE_ID_1234 is
 "digital pot card did not respond to serial number request"

raise Device_Error with
  GetText (MESSAGE_ID_5678, 
     C_Name (1 .. C_Name'Last - 1),
     Error_Type'Image (To_Error (GNAT.OS_Lib.Errno));

The English version of MESSAGE_ID_5678 would be:
  "can't open device %s : %s";

Note that a language that requires different noun/verb ordering can
use this approach quite nicely.

That seems to be a reasonable approach, and my current application
could be incrementally changed to accomodate it.

Anyone that wants to port my application to Spanish then just has to
translate the provided English strings to Spanish.

Ah; it might be that the new language _requires_ a 16 bit character
set (Chinese, for example). Then we have to assume UTF-8 encoding. It
might be simpler if 'raise' supported Wide_String (or
Wide_Wide_String?) directly, but it's not an insurmountable problem.
Perhaps Ada 2015 will allow Wide_Wide_String for exceptions.

> The construction of a message that meets the UI criteria (the parser
> loop with prompt in this case) becomes the job of the a View package
> that matches the display.

The _primary_ role of a parser is to accept user input and provide
feedback on errors. Why is it _better_ to move part of that job over
into the View package?

> - the program points the reader to the software types and
>   modules involved in propagating error information by
>   naming the package and type at both ends (View in this case).
>   A change in the implementation of View won't necessitate
>   a recompilation of Write_Output, unlike using
>   raise ... with ... for message construction.

Anticipating a change in implementation is a good reason for
separating out packages. 

However, I have yet to see an _actual_ implemention of View that is
not equivalent to "write this string to a device". So I do _not_
anticipate changing that implementation.

-- 
-- Stephe

Re: Structured exception information

[Simon Wright]

Stephen Leake <stephen_leake@stephe-leake.org> writes:

> raise Hardware_Error with 
>  "digital pot card did not respond to serial number request";
>
> raise Hardware_Error with
>   "digital pot card responded with wrong byte count to serial number" &
>   request (got" & Stream_Element_Offset'Image (Data_Last) & ")";
>
> raise Parameter_Error with
>   "motor" & Integer'Image (Module.Ramp_Motor_Index) & 
>   " Disable_Encoder_Model not set";
>
> raise Device_Error with
>   "can't open device " & C_Name (1 .. C_Name'Last - 1) & " : " &
>   Error_Type'Image (To_Error (GNAT.OS_Lib.Errno));

Our project (which has no HCI for the end users, just for the
maintenance engineer) might categorise these as

(a) and (b) possible hardware error, run BIT, get maintainer to
replace card if won't come good

(c) design error, reboot and report fault to support

(d) possible connection failure, run BIT, get maintainer to check
cabling

and in none of these is the original (English) text likely to help
front-line maintenance, though it will clearly help us to diagnose (c)
back at base.


It all depends who's going to be reading the error text.

Re: Structured exception information

[Simon Wright]

Stephen Leake <stephen_leake@stephe-leake.org> writes:

> In addition, you have ignored the problem that each version of
> Write_Output for different hardware will need need a corresponding
> version of the exception type; more work.

I suppose the model of Ada.IO_Exceptions might help.

Re: Structured exception information

[Stephen Leake]

Stephen Leake <stephen_leake@stephe-leake.org> writes:

> However, I have yet to see an _actual_ implemention of View that is
> not equivalent to "write this string to a device". So I do _not_
> anticipate changing that implementation.

I have to take this back, partly. Ray Blaak posted an example where
View would do:

Write Short_Description to immediate display device
Write Detailed_Description to log device

So View would take two strings, rather than one.

But the data is still strings, so the rest of my post stands.

-- 
-- Stephe

Re: Structured exception information

[Georg Bauhaus]

On Sun, 2007-01-28 at 08:18 -0500, Stephen Leake wrote:
> Stephen Leake <stephen_leake@stephe-leake.org> writes:
> 
> > However, I have yet to see an _actual_ implemention of View that is
> > not equivalent to "write this string to a device". So I do _not_
> > anticipate changing that implementation.
> 
> I have to take this back, partly. Ray Blaak posted an example where
> View would do:
> 
> Write Short_Description to immediate display device

Our office printer has four LEDs, two in green, two in
red. In addition, there are some defined blinking
sequences. On top of the chassis, there is a label with
a legend explaining a number of these combinations.

So the "exception strings" are external to the program
supposedly running inside the printer. I agree that there
are no natural language strings that can usefully be sent
to the 4 LEDs. But in this example we have a reporting
facility that is easily modified by replacing the label
with explanatory text in Spanish, say. Now,

> Write Detailed_Description to log device

if there was an occurrence of Paper_Jam, and
if there is a way to communicate with this printer
using same cable connection, the handler can also construct
information more useful to service personnel, or to service
machinery using a communications protocol.
 The point is that all of these views will use the
same information (ID of the device part that reports failure,
kind of failure, ...). Depending on what View is being used,
what reporting language, what communications channel,
etc., typed exception information could be used to construct
a suitable object depending on the display.

Re: Structured exception information

[Ray Blaak]

Stephen Leake <stephen_leake@stephe-leake.org> writes:

> Stephen Leake <stephen_leake@stephe-leake.org> writes:
> 
> > However, I have yet to see an _actual_ implemention of View that is
> > not equivalent to "write this string to a device". So I do _not_
> > anticipate changing that implementation.
> 
> I have to take this back, partly. Ray Blaak posted an example where
> View would do:
> 
> Write Short_Description to immediate display device
> Write Detailed_Description to log device
> 
> So View would take two strings, rather than one.
> 
> But the data is still strings, so the rest of my post stands.

Another twist on this that I have actually used is in the case of handling
parse errors when implementing editors in an IDE.

The exception certainly contained strings (since errors fundamentally have to
be shown to a human at some point), but also contained source locations
(line/col and absolute offsets) as integer fields, so that one not need to
parse them out.

The source location would be used such that the error message would appear in
some sort of log window, and double clicking on the error would auto-navigate
to the offending snippet of code where the error occurred in the source or
input file.

So, certainly the data is fundamentally strings, but can readily contain
auxiliary information that allows further processing to occur.

-- 
Cheers,                                        The Rhythm is around me,
                                               The Rhythm has control.
Ray Blaak                                      The Rhythm is inside me,
rAYblaaK@STRIPCAPStelus.net                    The Rhythm has my soul.

Re: Structured exception information

[Georg Bauhaus]

On Sat, 2007-01-27 at 13:17 -0500, Stephen Leake wrote:


> In addition, you have ignored the problem that each version of
> Write_Output for different hardware will need need a corresponding
> version of the exception type; more work.

Versions of Write_Output for different hardware might also
need a different string passed with the exception? For example
in order to clearly indicate which hardware is reporting.
I'm not so sure a different type is needed for every
variation in hardware. A serial number component might do,
if the hardware is sufficiently similar.

It _is_ more work to write good state/error reporting
modules. But there are some things in Ada that support
"message management" quite well, from a project point
of view I think. One of these is the case coverage rules.
(Exception types would make this even more integrated.)
If a message has an ID of some enumeration subtype,
it is unique per program or library.

Once you have the message types, starting e.g. with

   type Diagnosis is
      (Hardware,
       Parameters,
       Connection,
       ...);

you can construct aggregates of messages. A simple case is when
the messages are indeed string literals, possibly in different
languages. (This setup can be extended to include typed
information from the exception origin, formatting, and more.)

   type List_Of_Messages is array(Diagnosis) of String_Ptr;

   type I18N_Messages(language: ISO_639) is
      record
         texts: List_of_Message;
      end record;

   Japanese_Messages: constant I18N_Messages(Language => JP) :=
      (texts =>
       (Hardware => new String'("..."),
        Parameters => new String'("..."),
        ...);

You can now easily construct translations that are type checked:
Write a simple program that shapes the strings of a
List_of_Messages for Qt linguist XML, or Excel, or GNU gettext etc..
(IIRC, http://www.mckae.com/xia.html has a module for
transforming Ada objects to XML.)
Have someone translate the messages using for example the
Qt linguist tool, output will be XML again.
Then use a simple XSL program to create another
Ada declaration from the XML, for the tranlated messages.
(You won't need to link Qt to your program; you just use
the very comfortable tool - or your favorite XML editor,
and then run the XSL program. Or write the message translations
using Ada directly.)

The Ada compiler checks coverage. The translations should
therefore have one string for each value of the Diagnosis type.

For this procedure to work, you won't even need most of your
program because the strings are collected in one place. They are
not the result of scanning the entire program for possible
message strings.

If you use the linguist program, this points to a possible way
of including additional information like the device name
or errno using %1, %2, ... message forms similar to sprintf
format strings, and similar but not equal to GNU gettext:
Suppose there is an exception type hierarchy.

   type Device_Error(What_Happened: Diagnosis) is
      new Predefined_Exception_Type with
      record
         Device_Name: String(1 .. 12);
         errno: C.int;
      end record;

Then,

   The_Messages: constant List_of_Messages_Ptr :=
      Japanese_Messages'access;

For a command line tool,

   procedure Show_Error(Issue: Device_Error'class) is
      Text: String_Ptr renames
         The_Messages.texts(Issue.What_Happened);
      -- say, "can't open device %1 : %2"
   begin
      Fill_In(Text, Issue);
             -- %1 is filled using Issue.Device_Name
             -- %2 is filled using Issue.errno
      Output_Device.Show(Text);
   end Show_Error;

or, ignoring the text messages entirely,

   procedure Show_Error(Issue: Device_Error'class) is
      Alarm: Sound;
   begin
      Interpret(Issue, Result => Alarm);
      Midi.Play(Alarm);
   end Show_Error;

That is, messages are not frozen where the exception
is raised, but where they are displayed, played, read,
where they turn the red lights on, and the sirens too etc..


> Hmm. With the choice of names you used in Set_Error, you seem to be
> implying that there is a "general error description language", that
> Set_Error can enforce. I don't think that's true.

I think every application has a few classes of errors.
For every class, have a small tree of parameterized
exception information types, as outlined above.


> I guess by "validation" you mean the check "user_volts > Max_volts",
> and the Check_* procedures I quoted above.

Yes.

> > when the *message* should change even though the validation didn't
> > change. From this viewpoint Write_Output mixes two separate
> > concerns: input checking and UI message construction.
> 
> People keep saying those should be separate concerns, but I don't
> accept that. Why is it _better_ that they be separate?

Depending on the type of program, using MVC and corresponding
typed objects might be too complex, unnecessary work, etc.
But once you have a package of reporting routines, it's not
that much work. Typed exception information will help in
creating variants of these.

>  Formatting a string is the best
> way to do that.

Right, a string that explains the issue to the user. But
the string need not be produced by the program, as I've shown
in another post about LEDs with a legend.

Why is it better to have this setup that seems more complicated?
(Isn't it strange to hear an Ada programmer ask why it is
better to not just lump information into a string? :-) :-)
Now who best writes the messages (1), what should be included (2),
and where in the program should they be formatted(3)?

(1) Programmers tend to leave out necessary context information
judging by the brief shouts of command line tools that have
caused so much anger and Google searches for explanations.
Natural language experts aren't usually available during
development, so it seems an advantage to add another level of
indirection, just provide the information, and delegate the
formulation of messages to the domain experts.

(2) How can a programmer anticipate how the information
"raised" from his/her module is best used elsewhere?
E.g., MS recommends not to show stack traces from failing
ASPx programs to end users. Perhaps show a nice page with
some error code and an invitation to report or come back
later.  But what can an Ada exception handler do here
if all exception information is already frozen inside
a string? Parse it?

(3) As you have explained, SPO sentence construction rules are
not universal. The usual approach is therefore to use sprintf-
like procedure calls for message construction. Yet, whatever the
grammar rules of a natural language might require, the
information available *for* message construction is unchanged
by the fact that it can be turned into a sentence. So why not
create or extend a type for the information and pass objects
of the type, not formatted strings?


A related example. I find it quite helpful to see how two
different compilers analyze my programs, hence how different
groups of people create messages. When one of the compilers says,

foo.ada: ... P(x) is not appropriate

The other might say

foo.ada: ... P(x) can only be used if Q(x)

Granted these are messages from different compilers and not
really exception messages. Still, chances are that some Q*(x) is
available to the first compiler, too, because it reports
an error for the same input, without informing about Q*(x).
It's just a Not.
This shows the importance of messages: Good messages can create
huge savings, by reducing the time consuming and frustrating work
of finding out *why* P(x) is not appropriate in the first
error message. Avoids anger, too. 
Suppose now that you had a compiler where you could augment error
messages yourself, without touching the compiler. Example:

foo.adb:18: invalid prefix in selected component "FOO"

where FOO does _not_ denote the component. Suppose further that
this error message had a unique ID, e.g. i_p_s_c_2.
The compiler user can now associate hints with the message
by writing a corresponding statement such as

   for Message_Hints use
       I_P_S_C_2 := "The identifier shown could be the prefix";
   end;

In summary, then, I would prefer the separation of typed exception
data and exception message strings. The first is far more flexible
and accessible for anyone but the lazy programmer who writes
the exception message strings after "with" ;-)


> > or a Spanish character set. 
> 
> I think that is a valid objection; other parts of this thread have
> talked around it. My application has no (current :) requirement for
> this, so I can ignore it.

That's common practice I guess.
For many programs I wouldn't waste time on more sophisticated
reporting, too. But this luxury fails once the assumptions
change, or the requirements ask for more :-)

Re: Structured exception information

[Stephen Leake]

Georg Bauhaus <bauhaus@futureapps.de> writes:

> On Sat, 2007-01-27 at 13:17 -0500, Stephen Leake wrote:
>
>> In addition, you have ignored the problem that each version of
>> Write_Output for different hardware will need need a corresponding
>> version of the exception type; more work.
>
> Versions of Write_Output for different hardware might also
> need a different string passed with the exception? 

There is one Write_Output for each hardware type, so that's what
happens now.

> For example in order to clearly indicate which hardware is
> reporting. I'm not so sure a different type is needed for every
> variation in hardware. A serial number component might do, if the
> hardware is sufficiently similar.

Yes, if there are 5 Analog_Output cards in the system, each one has a
name or number, and that is included in the exception string.

> Why is it better to have this setup that seems more complicated?
> (Isn't it strange to hear an Ada programmer ask why it is
> better to not just lump information into a string? :-) :-)
> Now who best writes the messages (1), what should be included (2),
> and where in the program should they be formatted(3)?
>
> (1) Programmers tend to leave out necessary context information
> judging by the brief shouts of command line tools that have
> caused so much anger and Google searches for explanations.
> Natural language experts aren't usually available during
> development, so it seems an advantage to add another level of
> indirection, just provide the information, and delegate the
> formulation of messages to the domain experts.

Hmm. I agree that some members of my team have not yet learned how to
write good error messages. The solution is to educate them :). Or to
have someone who is good at it review and fix the messages.

Based on other examples of whole manuals written by someone other than
the programmers, I don't think that approach will produce good error
messages. 

Have you worked on a real system where this approach was used, and was
in fact better than having the programmers write the error messages?

> (2) How can a programmer anticipate how the information
> "raised" from his/her module is best used elsewhere?

Because there is a system design. Without a system design, you cannot
do error messages correctly. 

> E.g., MS recommends not to show stack traces from failing
> ASPx programs to end users. 

Good advice. I have the same policy.

> Perhaps show a nice page with some error code and an invitation to
> report or come back later. But what can an Ada exception handler do
> here if all exception information is already frozen inside a string?
> Parse it?

There are no stack traces in the messages I've shown. 

The system design says exception handlers only have to add
information, never subtract it.

If all programmers follow the system design, there will never be
inappropriate information in an exception message. 

If some programmer doesn't follow the system design, educate them!

> (3) As you have explained, SPO sentence construction rules are
> not universal. The usual approach is therefore to use sprintf-
> like procedure calls for message construction. Yet, whatever the
> grammar rules of a natural language might require, the
> information available *for* message construction is unchanged
> by the fact that it can be turned into a sentence. So why not
> create or extend a type for the information and pass objects
> of the type, not formatted strings?

"Why not"? Because it's easier not to! That is the topic of this
thread. 

> In summary, then, I would prefer the separation of typed exception
> data and exception message strings. The first is far more flexible

It is far _less_ flexible! that is the point. Any pre-defined type
structure is (by definition!) less flexible than a string. I can put
_anything_ in a string; I can only put the pre-conceived classes of
information in a structure. So when I write the Write_Output for my
wizzy new piece of hardware, I will _also_ have to extend the
exception class; not worth it.

> and accessible for anyone but the lazy programmer who writes the
> exception message strings after "with" ;-)

"accessible" meaning "easy to change some details of the
presentation", yes. But I remain unconvinced that small gain is worth
the cost. Except for internationalization support, which can be done
with strings as well.

-- 
-- Stephe

Re: Structured exception information

[Georg Bauhaus]

On Mon, 2007-01-29 at 21:15 -0500, Stephen Leake wrote:
> Georg Bauhaus <bauhaus@futureapps.de> writes:

> Based on other examples of whole manuals written by someone other than
> the programmers, I don't think that approach will produce good error
> messages. 

Yes, I should have said that I meant the set of all people
involved in exception raising and exception handling in the
broadest sense of the term.

> Have you worked on a real system where this approach was used, and was
> in fact better than having the programmers write the error messages?

I worked on a system involving 3 companies where one style of
exception handling was to be silent about them (empty handlers).
Another style was to write a few words that could be understood
by the programmer who wrote the handler because he knew the
context. These were (are, I think the programs are still up and
running) communicating programs, no source code was exchanged.

But when the exceptions were reported as strings into some log
some of us on all sides were out of luck. Strings are too easy
to write. People didn't give them enough attention, and they
didn't create exception types either even when this was possible
(in Java). And you don't ask for education across company borders
if there is a hierarchy. Let alone speak of education!



> The system design says exception handlers only have to add
> information, never subtract it.

Adding information is good, and the advice also needs to mention
that exceptions raised *do* have to provide some information :-)


>  So why not
> > create or extend a type for the information and pass objects
> > of the type, not formatted strings?
> 
> "Why not"? Because it's easier not to! That is the topic of this
> thread. 

I'm not so sure what is easier to do, write a good exception
message or build up an exception object containing the necessary
information about what happened. It seems easier to just write an
exception message string. Easy programming. But once it is written,
the information is as inflexibly coded as can be: You need parsing
if you have to extract it. I need to extract it if and when I
cannot change what a 3rd party library is reporting. There just
is no "education" or telling them what they should write in
exception messages.

> > In summary, then, I would prefer the separation of typed exception
> > data and exception message strings. The first is far more flexible
> 
> It is far _less_ flexible! that is the point. Any pre-defined type
> structure is (by definition!) less flexible than a string. I can put
> _anything_ in a string;

Certainly _you_ can place anything inside an exception message string.
(To say a few absurd things, for example a Tcl program. No problem.
I could even suggest that we use Storage_Element_Array instead of
String for the message as this helps preserving memory layouts... :)
 As a user of your exception message I get something that is carved in,
well, a String. As a user of an exception object of an exception type,
I'll have the necessary information at my disposal (hopefully).
For me then this is more flexible and easier than parsing message
strings.


>  Except for internationalization support, which can be done
> with strings as well.

Uhhhm. Anything can be done with strings, as Tcl is demonstrating,
but why do we use Ada where is can be done better using object of
type. A type for internationalized messages is easy to spot in a
program and can be arranged for Ada coverage rules. So you get
builtin language checks. If you use just strings, it will work, but
you have to use another language processor for scanning message
strings reliably. This may work in practice, with proper discipline
and heavy scanning, but I think it works around a better solution,
one that makes use of the Ada type system.

Re: Structured exception information

[Stephen Leake]

Georg Bauhaus <bauhaus@arcor.de> writes:

> On Mon, 2007-01-29 at 21:15 -0500, Stephen Leake wrote:
>
>> Have you worked on a real system where this approach was used, and was
>> in fact better than having the programmers write the error messages?
>
> I worked on a system involving 3 companies where one style of
> exception handling was to be silent about them (empty handlers).
> Another style was to write a few words that could be understood
> by the programmer who wrote the handler because he knew the
> context. These were (are, I think the programs are still up and
> running) communicating programs, no source code was exchanged.
>
> But when the exceptions were reported as strings into some log
> some of us on all sides were out of luck. Strings are too easy
> to write. People didn't give them enough attention, and they
> didn't create exception types either even when this was possible
> (in Java). And you don't ask for education across company borders
> if there is a hierarchy. Let alone speak of education!

Ok, so the answer to my question is "no".

There certainly was a problem, but it appears that structured
exceptions were not accepted as a solution. On the other hand, neither
was programmer education, so apparently we are both wrong :).

>>  So why not
>> > create or extend a type for the information and pass objects
>> > of the type, not formatted strings?
>> 
>> "Why not"? Because it's easier not to! That is the topic of this
>> thread. 
>
> I'm not so sure what is easier to do, write a good exception
> message or build up an exception object containing the necessary
> information about what happened. It seems easier to just write an
> exception message string. Easy programming. But once it is written,
> the information is as inflexibly coded as can be: You need parsing
> if you have to extract it. I need to extract it if and when I
> cannot change what a 3rd party library is reporting. There just
> is no "education" or telling them what they should write in
> exception messages.

Yes, I have said that designing exceptions for libraries intended to
be used in a wide variety of systems is hard. In that case, it might
be useful for the library to define a structured exception type. But
it might be even better to provide status instead of exceptions.

>> > In summary, then, I would prefer the separation of typed exception
>> > data and exception message strings. The first is far more flexible
>> 
>> It is far _less_ flexible! that is the point. Any pre-defined type
>> structure is (by definition!) less flexible than a string. I can put
>> _anything_ in a string;
>
> Certainly _you_ can place anything inside an exception message string.
> (To say a few absurd things, for example a Tcl program. No problem.
> I could even suggest that we use Storage_Element_Array instead of
> String for the message as this helps preserving memory layouts... :)
>  As a user of your exception message I get something that is carved in,
> well, a String. As a user of an exception object of an exception type,
> I'll have the necessary information at my disposal (hopefully).
> For me then this is more flexible and easier than parsing message
> strings.

So I'm talking about having control over the _entire_ system, and you
are talking about third party libraries. That is different.

-- 
-- Stephe

Re: Structured exception information

[Georg Bauhaus]

On Thu, 2007-02-01 at 07:20 -0500, Stephen Leake wrote:
> Georg Bauhaus <bauhaus@arcor.de> writes:
> 
> > On Mon, 2007-01-29 at 21:15 -0500, Stephen Leake wrote:
> >
> >> Have you worked on a real system where this approach was used, and was
> >> in fact better than having the programmers write the error messages?
> >
> > I worked ...
> >
> > [Some] people didn't ...
> 
> Ok, so the answer to my question is "no".

Well, actually, there have been at least two programmers who did try
to write meaningful exception messages and who have derived an exception
type. The objects were used in handlers further out in the call chain.

Changing the software to have better error handling had made us
find out about a few obscure behaviors of the software, of course.
The original developer had left, so we couldn't ask
him about the whys and whens of the silent handlers.


> So I'm talking about having control over the _entire_ system, and you
> are talking about third party libraries. That is different.

OK, but talking about third party Ada libraries makes sense when
discussing exception types as they will be additions to Ada,
a language for large distributed systems?

Re: Structured exception information

[Randy Brukardt]

"Stephen Leake" <stephen_leake@stephe-leake.org> wrote in message
news:usldzbzu4.fsf@stephe-leake.org...
...
> In my main project at work, it is much easier to format the messages
> at the level where the relevant information is available.

Internationalization is all about taking stuff that should be easy and
making it much harder. ;-)

Seriously, the only practical way to Internationalize a component library is
to remove all messages from it. One could argue that Ada fails miserably
here, because the strings that get attached to exceptions are probably in
English. (Look at the Gnat runtime for an obvious example of the problem.)
OTOH, its somewhat of a bogus argument, as no application should be
presenting messages from the Ada runtime to users in the first place. (Or,
at least, only as a last resort when all else has failed.)

                         Randy.

Re: Structured exception information

[Randy Brukardt]

"Stephen Leake" <stephen_leake@stephe-leake.org> wrote in message
news:u3b62dqj5.fsf@stephe-leake.org...
...
> > The HTTP network component should not be aware about the
> > multilanguage abilities of the browser.
>
> Ah, internationalization of error messages. Again, I think the HTTP
> component itself needs to be internationalized to make that work
> properly, so it is simpler for the HTTP component to put the error
> message string in the exception. That way, it can be used in a program
> that is not otherwize internationalized.

Umm, even I (who think internationalization is a total waste of effort)
realize that's completely impossible. Who could possibility write an HTTP
component that could put its error messages into the literally hundreds of
different languages that are in use out there. It would be, at best,
unnecessary coupling: I surely don't want the overhead of Italian and
Russian support, for example in my programs that are likely to only be used
by English-speaking people.

If Internationalization is a requirement, you pretty much have to remove all
natural language from your lower-level components. Then at least you can let
the UI be filled in by people with the appropriate local skills.

                 Randy.

Wasteful internationalization (Was: Structured exception information)

[Alex R. Mosteo]

Randy Brukardt wrote:

> Umm, even I (who think internationalization is a total waste of effort)

I'm curious about this, could you elaborate a bit? Surely
internationalization is a reality; in what sense you consider it a total
waste?

Alex.

Re: Wasteful internationalization (Was: Structured exception information)

[Dmitry A. Kazakov]

On Wed, 24 Jan 2007 15:17:59 +0100, Alex R. Mosteo wrote:

> Randy Brukardt wrote:
> 
>> Umm, even I (who think internationalization is a total waste of effort)
> 
> I'm curious about this, could you elaborate a bit? Surely
> internationalization is a reality; in what sense you consider it a total
> waste?

Much of reality is a total waste.

As for renaming buttons and translating compiler messages, it is so obvious
that there is no any need to explain why this idea is evil.

Even in entertainment industry, it is sometimes quite problematic. I
remember some quest games, virtually impossible to go through in localized
versions. Translated songs in a musical film, presented by local third-rate
interpreters, this can ruin any masterpiece.

It is always amusing to read Russian manuals written outside Russia.
Unfortunately due to universality of this argument (about wastefulness), I
cannot present any examples a non-Russian reader could understand... (:-))

BTW, it is not that funny in some cases. I saw many safety devices, people
of good intentions tried to localize...with almost life threatening
effect...

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

Re: Wasteful internationalization

[Björn Persson]

Dmitry A. Kazakov wrote:

> As for renaming buttons and translating compiler messages, it is so
> obvious that there is no any need to explain why this idea is evil.

It's not obvious. I could of course try guessing what bad experiences you've
had with button texts and compiler messages, but I don't think I should.

> Even in entertainment industry, it is sometimes quite problematic. I
> remember some quest games, virtually impossible to go through in localized
> versions. Translated songs in a musical film, presented by local
> third-rate interpreters, this can ruin any masterpiece.
> 
> It is always amusing to read Russian manuals written outside Russia.
> Unfortunately due to universality of this argument (about wastefulness), I
> cannot present any examples a non-Russian reader could understand... (:-))

You're saying translation as such is a bad idea because the translated texts
are of poor quality. That's an incorrect conclusion. If translations are
bad it's because the translators aren't good enough at what they do. I
don't know about Russian translators but good Swedish translators do exist.
Of course there are examples of bad translations, particularly user manuals
for electronic consumer devices, but there are plenty of very good
translations too.

> BTW, it is not that funny in some cases. I saw many safety devices, people
> of good intentions tried to localize...with almost life threatening
> effect...

For safety devices it is vital that the users understand the instructions.
They'll understand best if the instructions are in their own language. Of
course the translation must be correct, which means the translator must be
competent. Letting some random bloke from the street do the job is just as
bad as hiring some random bloke from the street to write safety-critical
software.

-- 
Bj�rn Persson                              PGP key A88682FD
                   omb jor ers @sv ge.
                   r o.b n.p son eri nu

Re: Wasteful internationalization

[Markus E Leypold]

Bj�rn Persson <spam-away@nowhere.nil> writes:

> Dmitry A. Kazakov wrote:
>
>> As for renaming buttons and translating compiler messages, it is so
>> obvious that there is no any need to explain why this idea is evil.
>
> It's not obvious. I could of course try guessing what bad experiences you've
> had with button texts and compiler messages, but I don't think I should.
>
>> Even in entertainment industry, it is sometimes quite problematic. I
>> remember some quest games, virtually impossible to go through in localized
>> versions. Translated songs in a musical film, presented by local
>> third-rate interpreters, this can ruin any masterpiece.
>> 
>> It is always amusing to read Russian manuals written outside Russia.
>> Unfortunately due to universality of this argument (about wastefulness), I
>> cannot present any examples a non-Russian reader could understand... (:-))
>
> You're saying translation as such is a bad idea because the translated texts
> are of poor quality. That's an incorrect conclusion. If translations are
> bad it's because the translators aren't good enough at what they do. I

Or translation is done as an obligatory exercise ("must have i18n and
XYZ manuals to be able to sell in XYZ"), but not really seen as part
of the development. So it's done on the cheap, as an afterthought, not
as an integral part of design and development. 

> don't know about Russian translators but good Swedish translators do exist.

Yes. But do they work for nothing :-). I've seen companies giving the
translation of their otherwise relatively good manual to the cheapest
bidder. Of course they were not really satisfied
afterwards. Surprise. Not.

Regards -- Markus

Re: Wasteful internationalization (Was: Structured exception information)

[Randy Brukardt]

"Alex R. Mosteo" <devnull@mailinator.com> wrote in message
news:51p83bF1k9di7U1@mid.individual.net...
> Randy Brukardt wrote:
>
> > Umm, even I (who think internationalization is a total waste of effort)
>
> I'm curious about this, could you elaborate a bit? Surely
> internationalization is a reality; in what sense you consider it a total
> waste?

Dmitry answered this better than I could: just because it is "reality"
doesn't make it right. There are many such examples: you could start with
the current US president. ;-)

It depends on the application, of course, but for many things (like compiler
error messages), attempts to localize just make things more confusing. Most
important stuff in the world is in English these days -- that's the reality,
and forcing localization of that is counterproductive.

There clearly are exceptions: if you want to sell a word processor in Japan,
it probably has to handle their funny character set. Which is why I said IF
Internationalization is a requirement (hopefully it is not, but you don't
always get what you want).

                          Randy.

Re: Wasteful internationalization (Was: Structured exception information)

[Alex R. Mosteo]

Randy Brukardt wrote:

> "Alex R. Mosteo" <devnull@mailinator.com> wrote in message
> news:51p83bF1k9di7U1@mid.individual.net...
>> Randy Brukardt wrote:
>>
>> > Umm, even I (who think internationalization is a total waste of effort)
>>
>> I'm curious about this, could you elaborate a bit? Surely
>> internationalization is a reality; in what sense you consider it a total
>> waste?
> 
> Dmitry answered this better than I could: just because it is "reality"
> doesn't make it right. 

Until some global language gets truly prevalent, I'm afraid i18n will not be
a waste. It's a need, perhaps expensive and difficult to get right, even if
enjoying original works is much better for the fortunate that can do that.
I agree with Bj�rn that we shouldn't equate the fault of bad translators
with total waste.

(I see this is a matter of perspective, I suppose, and how you value proper
translations).

> There are many such examples: you could start with 
> the current US president. ;-)

> It depends on the application, of course, but for many things (like
> compiler error messages), attempts to localize just make things more
> confusing. Most important stuff in the world is in English these days --
> that's the reality, and forcing localization of that is counterproductive.

Ah, forced localization... I live very near of Catalonia... Yes, I'd like
nobody needed translations. But I'm not disagreeing with the issue of
unneeded but imposed translations.

It's difficult not to agree with the compiler example. Compiler errors are
certainly bothersome for me in Spanish, but because they're badly
translated and they difficult searches in google. An even worse example is
Excel, whose formulae are translated in Spanish versions! So you have
both "IF(;;)" and "SI(;;)" and so on, and both are accepted by the formula
engine. This is just mental.

> There clearly are exceptions: if you want to sell a word processor in
> Japan, it probably has to handle their funny character set. Which is why I
> said IF Internationalization is a requirement (hopefully it is not, but
> you don't always get what you want).

I reckon the problem lies more in the infrastructure needed for multiple
translations being supported than in the character sets per se. Unicode has
eased this pain very much. Curiously, one could argue that having to remove
the actual strings from the places where they're needed is a good isolation
practice. I'm not sure what's your opinion on this; for me certainly is a
lost battle to laziness. But then, I don't do i18n in my programs.

Re: Wasteful internationalization

[Björn Persson]

Alex R. Mosteo wrote:

> It's difficult not to agree with the compiler example. Compiler errors are
> certainly bothersome for me in Spanish, but because they're badly
> translated and they difficult searches in google.

I see you post with Knode, so obviously you have a Unixy OS. Getting at the
English version of a message from GCC is easy. Just put "LANG=C" in front
of the command. That's what I do when I post compilation examples here in
comp.lang.ada. Like this:

LANG=C gnatmake something.adb

-- 
Bj�rn Persson                              PGP key A88682FD
                   omb jor ers @sv ge.
                   r o.b n.p son eri nu

Re: Wasteful internationalization (Was: Structured exception information)

[Randy Brukardt]

"Alex R. Mosteo" <devnull@mailinator.com> wrote in message
news:51rhs3F1m1jliU1@mid.individual.net...
> Randy Brukardt wrote:
...
> It's difficult not to agree with the compiler example. Compiler errors are
> certainly bothersome for me in Spanish, but because they're badly
> translated and they difficult searches in google. An even worse example is
> Excel, whose formulae are translated in Spanish versions! So you have
> both "IF(;;)" and "SI(;;)" and so on, and both are accepted by the formula
> engine. This is just mental.

This gave me a vision of a fully internationalized Ada program written in
Cyrillic (or Chinese or Thai or ...). Just a mass of funny looking
characters. Just imagine the portability!

                         Randy.

Re: Wasteful internationalization (Was: Structured exception information)

[Dmitry A. Kazakov]

On Thu, 25 Jan 2007 15:57:29 -0600, Randy Brukardt wrote:

> "Alex R. Mosteo" <devnull@mailinator.com> wrote in message
> news:51rhs3F1m1jliU1@mid.individual.net...
>> Randy Brukardt wrote:
> ...
>> It's difficult not to agree with the compiler example. Compiler errors are
>> certainly bothersome for me in Spanish, but because they're badly
>> translated and they difficult searches in google. An even worse example is
>> Excel, whose formulae are translated in Spanish versions! So you have
>> both "IF(;;)" and "SI(;;)" and so on, and both are accepted by the formula
>> engine. This is just mental.
> 
> This gave me a vision of a fully internationalized Ada program written in
> Cyrillic (or Chinese or Thai or ...). Just a mass of funny looking
> characters. Just imagine the portability!

Oh, Ada could become much "better" here!

German Excel (and I believe Russian as well) uses "," instead of "." in all
numbers. What a refreshing idea!

Following that path we could consider Maya and old Slavic numerals
(http://en.wikipedia.org/wiki/Slavic_numerals) for integer literals in Ada
programs. Should we? (:-)) 

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

Re: Wasteful internationalization (Was: Structured exception information)

[Georg Bauhaus]

On Fri, 2007-01-26 at 10:13 +0100, Dmitry A. Kazakov wrote:
> On Thu, 25 Jan 2007 15:57:29 -0600, Randy Brukardt wrote:

> > This gave me a vision of a fully internationalized Ada program written in
> > Cyrillic (or Chinese or Thai or ...). Just a mass of funny looking
> > characters. Just imagine the portability!
> 
> Oh, Ada could become much "better" here!
> 
> German Excel (and I believe Russian as well) uses "," instead of "." in all
> numbers. What a refreshing idea!

For about half a year it was my daily job to extract numbers
from handwritten Excel sheets for processing, without access to
MS programming tools. An added challenge has been that their format
changed every other week, and even in the same column of the
same week.

OTOH, Excel numbers aren't usually produced by programmers
for programmers, so they are somewhat "human".
And this is right, because it helps efficient human
communication where this form of communication dominates.
For another refreshing insight, have a look at the separators
for groups of 10**3 in Switzerland, or consider calender date
formats. But OTOH most programmers' *refuse* to add type to
the most useless

  date: Pattern :=
   Digit & Digit & Sep & Digit & Digit & Sep & Digit & Digit;

Why is that? They could, for example, use ISO dates,
or grammar based date formats for disambiguation:

 <date y="2007"
       m="5"
       d="6"   />

Hm. Maybe this is an opportunity to create a few instances
of the new 2007 standard generic function

  Ada.Tags.Generic_Dispatching_Constructor

 -- georg

Re: Wasteful internationalization (Was: Structured exception information)

[Randy Brukardt]

"Dmitry A. Kazakov" <mailbox@dmitry-kazakov.de> wrote in message
news:1v3kaogkz3p05.krktib9iodz6$.dlg@40tude.net...
...
> German Excel (and I believe Russian as well) uses "," instead of "." in
all
> numbers. What a refreshing idea!

Shhh. The ISO standard for drafting of standards (which I had the misfortune
of having to reread this week) requires that the decimal points in numbers
be represented by commans. Luckily, programming language standards have
ignored that requirement. Other, we'd be presented with nonsense like:

The numeric literal has the value given. For example, "3.14" has the value
3,14.

                  Randy.

Re: Wasteful internationalization

[Stephen Leake]

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

> "Alex R. Mosteo" <devnull@mailinator.com> wrote in message
> news:51rhs3F1m1jliU1@mid.individual.net...
>> Randy Brukardt wrote:
> ...
>> It's difficult not to agree with the compiler example. Compiler errors are
>> certainly bothersome for me in Spanish, but because they're badly
>> translated and they difficult searches in google. An even worse example is
>> Excel, whose formulae are translated in Spanish versions! So you have
>> both "IF(;;)" and "SI(;;)" and so on, and both are accepted by the formula
>> engine. This is just mental.
>
> This gave me a vision of a fully internationalized Ada program written in
> Cyrillic (or Chinese or Thai or ...). Just a mass of funny looking
> characters. Just imagine the portability!

I must object to the characterization of non-English characters as
"funny". 

To people who grew up with Chinese as their native tongue, this entire
thread is just a stream of "funny characters", and a compiler that
worked with Chinese as nicely as GNAT does with English would be a
very productive tool.

While I believe it is true that English is spoken by more people than
any other language (if we count people for whom English is a second
language), there are still billions of people who do not speak
English. We should not dismiss them so lightly.

-- 
-- Stephe

Re: Wasteful internationalization

[Markus E Leypold]

Stephen Leake <stephen_leake@stephe-leake.org> writes:

> "Randy Brukardt" <randy@rrsoftware.com> writes:
>
>> "Alex R. Mosteo" <devnull@mailinator.com> wrote in message
>> news:51rhs3F1m1jliU1@mid.individual.net...
>>> Randy Brukardt wrote:
>> ...
>>> It's difficult not to agree with the compiler example. Compiler errors are
>>> certainly bothersome for me in Spanish, but because they're badly
>>> translated and they difficult searches in google. An even worse example is
>>> Excel, whose formulae are translated in Spanish versions! So you have
>>> both "IF(;;)" and "SI(;;)" and so on, and both are accepted by the formula
>>> engine. This is just mental.
>>
>> This gave me a vision of a fully internationalized Ada program written in
>> Cyrillic (or Chinese or Thai or ...). Just a mass of funny looking
>> characters. Just imagine the portability!
>
> I must object to the characterization of non-English characters as
> "funny". 
>
> To people who grew up with Chinese as their native tongue, this entire
> thread is just a stream of "funny characters", and a compiler that
> worked with Chinese as nicely as GNAT does with English would be a
> very productive tool.

Identifiers in Ada are actually Latin-1, arent't they? At least in
GNAT writing '�berschuss' instead of 'Ueberschuss' works. And I
appreciate that. So, a compiler taking complete unicode source with
identifiers in the respective alphabets would be really useful.


>
> While I believe it is true that English is spoken by more people
> than any other language (if we count people for whom English is a
> second language), 

Hm. I'd even be tempted to deny this. 

> there are still billions of people who do not
> speak English. We should not dismiss them so lightly.

ACK.

Regards -- Markus

Re: Wasteful internationalization

[Björn Persson]

Markus E Leypold wrote:

> Identifiers in Ada are actually Latin-1, arent't they? At least in
> GNAT writing '�berschuss' instead of 'Ueberschuss' works.

In Ada 95, yes. In Ada 2005, the full Unicode character set is allowed. The
constant ? is defined. Unfortunately there's a big showstopper: There's no
standard way to tell the compiler which character encoding each source file
is encoded in.

> And I 
> appreciate that. So, a compiler taking complete unicode source with
> identifiers in the respective alphabets would be really useful.

In theory Gnat is supposed to do that, as it has command line switches for
UTF-8 support. In practice this feature won't be very useful, because it
requires *all* code to be in the same encoding. Even worse, it assumes that
the same encoding is used in every locale where the program will be
executed.

-- 
Bj�rn Persson                              PGP key A88682FD
                   omb jor ers @sv ge.
                   r o.b n.p son eri nu

Re: Wasteful internationalization

[Björn Persson]

Björn Persson wrote:

> The constant ? is defined.

Bah! That was supposed to be a π. (Obviously Knode, my Usenet client, is
also less than stellar when it comes to handling character encodings.)

-- 
Björn Persson                              PGP key A88682FD
                   omb jor ers @sv ge.
                   r o.b n.p son eri nu

Re: Wasteful internationalization

[Markus E Leypold]

Björn Persson <spam-away@nowhere.nil> writes:

> Björn Persson wrote:
>
>> The constant ? is defined.
>
> Bah! That was supposed to be a π. (Obviously Knode, my Usenet client, is

Was that supposed to be rendered as a box? Or does _my_ client not get it right?

Regards -- Markus

Re: Wasteful internationalization

[Larry Kilgallen]

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

In article <r07iv7gort.fsf@hod.lan.m-e-leypold.de>, Markus E Leypold writes:
> 
> Björn Persson <spam-away@nowhere.nil> writes:
> 
>> Björn Persson wrote:
>>
>>> The constant ? is defined.
>>
>> Bah! That was supposed to be a π. (Obviously Knode, my Usenet client, is
> 
> Was that supposed to be rendered as a box? Or does _my_ client not get it right?

I get the following characters < I " > [ 8 0 ] in the editor, with a funny
different character in place of the first 4 in the mail program.

Re: Wasteful internationalization

[Björn Persson]

Larry Kilgallen wrote:

> I get the following characters < I " > [ 8 0 ] in the editor, with a funny
> different character in place of the first 4 in the mail program.

Your client doesn't seem to handle MIME at all, so in effect it assumes that
the whole world is using the same character encoding as you. If you care
about having all characters displayed right, then I'm afraid you'll need a
better Usenet client.

-- 
Bj�rn Persson                              PGP key A88682FD
                   omb jor ers @sv ge.
                   r o.b n.p son eri nu

Re: Wasteful internationalization

[Larry Kilgallen]

In article <_wrvh.30646$E02.12547@newsb.telia.net>, =?ISO-8859-1?Q?Bj=F6rn?= Persson <spam-away@nowhere.nil> writes:
> Larry Kilgallen wrote:
> 
>> I get the following characters < I " > [ 8 0 ] in the editor, with a funny
>> different character in place of the first 4 in the mail program.
> 
> Your client doesn't seem to handle MIME at all, so in effect it assumes that
> the whole world is using the same character encoding as you. If you care
> about having all characters displayed right, then I'm afraid you'll need a
> better Usenet client.

And what client on my VMS system would display those characters on my
VT102 (emulator) ?

It seems to me that people in newsgroups should stick to ASCII.

Re: Wasteful internationalization

[Simon Wright]

Kilgallen@SpamCop.net (Larry Kilgallen) writes:

> In article <_wrvh.30646$E02.12547@newsb.telia.net>, =?ISO-8859-1?Q?Bj=F6rn?= Persson <spam-away@nowhere.nil> writes:
>> Larry Kilgallen wrote:
>> 
>>> I get the following characters < I " > [ 8 0 ] in the editor, with
>>> a funny different character in place of the first 4 in the mail
>>> program.
>> 
>> Your client doesn't seem to handle MIME at all, so in effect it
>> assumes that the whole world is using the same character encoding
>> as you. If you care about having all characters displayed right,
>> then I'm afraid you'll need a better Usenet client.
>
> And what client on my VMS system would display those characters on
> my VT102 (emulator) ?
>
> It seems to me that people in newsgroups should stick to ASCII.

I suppose Bj�rn could gave said 'lowercase Greek pi' but I think it
would have destroyed his point! (BTW, this is Carbon Emacs on
Powerbook G4).

Re: Wasteful internationalization

[Björn Persson]

Larry Kilgallen wrote:

> And what client on my VMS system would display those characters on my
> VT102 (emulator) ?

I don't know VMS. comp.os.vms might be a better place to ask about that.

> It seems to me that people in newsgroups should stick to ASCII.

So, you want the entire world to use the American Standard Code? I suppose
we should all drop our un-American, nonstandard languages and only speak
and write American Standard English, right? Maybe we should give up all
un-American, nonstandard culture and watch nothing but American Standard
Hollywood movies? Perhaps you also want all countries to join the Holy
American Empire and let the American Standard President reign for ever and
ever?

Look, nobody is forcing you to use a MIME-aware newsreader. It may be that
there is none that runs on VMS. In that case you have a choice: Use VMS and
not see all characters right, or see the characters but not on VMS. Decide
what's more important to you. I don't care what you choose, but I do take
offence when you try to force an outdated and hopelessly insufficient
standard on *me* just because *your* software is limited.

Usenet is international. Deal with it.

-- 
Björn Persson                              PGP key A88682FD
                   omb jor ers @sv ge.
                   r o.b n.p son eri nu

Re: Wasteful internationalization

[Adam Beneschan]

On Feb 2, 4:48 pm, Björn Persson <spam-a...@nowhere.nil> wrote:
> Larry Kilgallen wrote:
> > And what client on my VMS system would display those characters on my
> > VT102 (emulator) ?
>
> I don't know VMS. comp.os.vms might be a better place to ask about that.
>
> > It seems to me that people in newsgroups should stick to ASCII.
>
> So, you want the entire world to use the American Standard Code? I suppose
> we should all drop our un-American, nonstandard languages and only speak
> and write American Standard English, right?

No way.  You Scandinavians already speak better English than most of
us Americans do.  So it's perfectly fine for you to go on speaking
English Standard English.  :) :) :) :)

But Larry, I think you hit a nerve when you made your comment to a
person who has an o-umlaut in his name.  I can understand why he may
have gotten a bit peeved---you're practically asking him not to use
his own name on the Internet.

                          -- Adam

Re: Wasteful internationalization

[Larry Kilgallen]

In article <1170464671.166414.311980@q2g2000cwa.googlegroups.com>, "Adam Beneschan" <adam@irvine.com> writes:
> On Feb 2, 4:48 pm, Bj=F6rn Persson <spam-a...@nowhere.nil> wrote:
>> Larry Kilgallen wrote:
>> > And what client on my VMS system would display those characters on my
>> > VT102 (emulator) ?
>>
>> I don't know VMS. comp.os.vms might be a better place to ask about that.
>>
>> > It seems to me that people in newsgroups should stick to ASCII.
>>
>> So, you want the entire world to use the American Standard Code? I suppose
>> we should all drop our un-American, nonstandard languages and only speak
>> and write American Standard English, right?
> 
> No way.  You Scandinavians already speak better English than most of
> us Americans do.  So it's perfectly fine for you to go on speaking
> English Standard English.  :) :) :) :)
> 
> But Larry, I think you hit a nerve when you made your comment to a
> person who has an o-umlaut in his name.  I can understand why he may
> have gotten a bit peeved---you're practically asking him not to use
> his own name on the Internet.

I try not to object to characters in names, since I do not read names
for content.

Re: Wasteful internationalization

[Markus E Leypold]

Bj�rn Persson <spam-away@nowhere.nil> writes:

> Larry Kilgallen wrote:
>
>> And what client on my VMS system would display those characters on my
>> VT102 (emulator) ?
>
> I don't know VMS. comp.os.vms might be a better place to ask about that.
>
>> It seems to me that people in newsgroups should stick to ASCII.
>
> So, you want the entire world to use the American Standard Code? I suppose
> we should all drop our un-American, nonstandard languages and only speak
> and write American Standard English, right? Maybe we should give up all
> un-American, nonstandard culture and watch nothing but American Standard
> Hollywood movies? Perhaps you also want all countries to join the Holy
> American Empire and let the American Standard President reign for ever and
> ever?

Look, Bj�rn -- I think this wall uncalled for. _I_ remember times when
it was considered part of the netiquette to use only 7-Bit-ASCII,
because you couldn't expect everybody haiving the latest and greatest
software. There were various Unices in various states of coming to
grips with non-7-bit characters and there was VMS and not all software
was readily available for all systems.

And I would like to add: That really hasn't changed in principle. 5
years ago I could read almost every mail I got. Then mails with
8859-15 became more common (Euro sign) and I couldn't read them. And
then UTF-8 mails abounded. Without me doing anything wrong, my news
reader slowly decayed into obsolescence.

I hate it when that happens. 

> Look, nobody is forcing you to use a MIME-aware newsreader. It may be that
> there is none that runs on VMS. In that case you have a choice: Use VMS and

Tell you what: VT102. It's a hardware problem, not a software one. You
seem to be missing some historical perspective :-).

> not see all characters right, or see the characters but not on VMS. Decide
> what's more important to you. I don't care what you choose, but I do take
> offence when you try to force an outdated and hopelessly insufficient

Did he force you? Or did he just inform you that he can't see the 'Pi'
and probably won't see it ever. You can ignore his information, I
think.

> standard on *me* just because *your* software is limited.

Ah, well, I've seen people applying the same rethorics to HTML
mail.

> Usenet is international. Deal with it.

15 years ago, you'd simply have refused to participate, wouldn't you?
And if not what does that tell us about the absolute necessity of
umlauts? Especially in the context of being able to be read by other
people.

BTW: I have Gnus on a rather current Linux system. I couldn't see the
Pi, too. This happens sometimes and do you know what: I don't read
posts I can't display or decode (same with web pages). Yes there are
probably ways to fix this, but since this doesn't occur too often, I
think I can live without the things I'm missing.

Regards -- Markus

Re: Wasteful internationalization

[Markus E Leypold]

Markus E Leypold <development-2006-8ecbb5cc8aREMOVETHIS@ANDTHATm-e-leypold.de> writes:

> Bj�rn Persson <spam-away@nowhere.nil> writes:
>
>> Larry Kilgallen wrote:
>>
>>> And what client on my VMS system would display those characters on my
>>> VT102 (emulator) ?
>>
>> I don't know VMS. comp.os.vms might be a better place to ask about that.
>>
>>> It seems to me that people in newsgroups should stick to ASCII.
>>
>> So, you want the entire world to use the American Standard Code? I suppose
>> we should all drop our un-American, nonstandard languages and only speak
>> and write American Standard English, right? Maybe we should give up all
>> un-American, nonstandard culture and watch nothing but American Standard
>> Hollywood movies? Perhaps you also want all countries to join the Holy
>> American Empire and let the American Standard President reign for ever and
>> ever?
>
> Look, Bj�rn -- I think this wall uncalled for. _I_ remember times when

=> 'was uncalled for'.

> it was considered part of the netiquette to use only 7-Bit-ASCII,

etc. ...

- M

Re: Wasteful internationalization

[Björn Persson]

Markus E Leypold wrote:

> Look, Björn -- I think this wall uncalled for. _I_ remember times when
> it was considered part of the netiquette to use only 7-Bit-ASCII,
> because you couldn't expect everybody haiving the latest and greatest
> software. There were various Unices in various states of coming to
> grips with non-7-bit characters and there was VMS and not all software
> was readily available for all systems.

That's a good approach. For a while, not forever. You can avoid using a new
standard as long as it's brand new, but what's the point in defining new
standards if nobody ever starts using the new capabilities?

The protocols are carefully designed to be as backwards compatible as
possible. Non-MIME messages are assumed to be in ASCII, precisely to let
Larry keep posting with his old newsreader. Well-behaved email and Usenet
programs also use the simplest encoding possible for each message – ASCII
when ASCII is enough, and UTF-8 only when Latin-1 won't do – to be
backwards compatible whenever possible, and they use UTF-8 instead of UCS-2
or UCS-4 so that Larry will at least be able to read most of the message.
This way, users with old software can still participate within the limits
of their software, and the rest of us can use the characters we need when
we need them.

> And I would like to add: That really hasn't changed in principle. 5
> years ago I could read almost every mail I got. Then mails with
> 8859-15 became more common (Euro sign) and I couldn't read them. And
> then UTF-8 mails abounded. Without me doing anything wrong, my news
> reader slowly decayed into obsolescence.
> 
> I hate it when that happens.

I hate it too, but the problem was with the old software, not with the new
one. MIME and Unicode solved some very real problems caused by lack of
forethought in the past, and the only long-term solution was to upgrade the
software.

> Tell you what: VT102. It's a hardware problem, not a software one. You
> seem to be missing some historical perspective :-).

"Emulator" sounds like software to me, but that's irrelevant anyway. Larry
could get adequate software *and* hardware if he wanted to. It's not like
it would be expensive. Hardware capable of running MIME-aware newsreaders
can be found in dumps. He doesn't want to, and that's fine with me, but
then he must accept that his equipment lacks some modern features.

> Did he force you? Or did he just inform you that he can't see the 'Pi'
> and probably won't see it ever. You can ignore his information, I
> think.

Of course he has no means to literally force me. He's trying to *persuade*
everyone to go back to ASCII. It was not just information. He stated
explicitly that everyone should use ASCII.

His first post looked like he didn't know why he didn't see the right
character, and I tried to be helpful, not remembering that it was Larry who
complained to a newbie who used UTF-8 in May last year. I'll probably
ignore him next time he complains to me, but I may intervene if he attacks
newbies again.

> BTW: I have Gnus on a rather current Linux system. I couldn't see the
> Pi, too. This happens sometimes and do you know what: I don't read
> posts I can't display or decode (same with web pages).

I do the same. I don't have Flash installed (because I can't stand web pages
full of animated ads). There have been a few Flash applets that were
important enough that I installed the Flash plugin, watched the applet and
removed Flash again, but when people send out links to funny clips on
Youtube and the like I usually don't watch them, thinking they probably
aren't worth all the trouble. But I don't complain about it! Especially not
i public forums. I have made my choice and I accept the consequences. I
don't try to make people stop posting Flash clips just because watching
them is too much trouble for me.

-- 
Björn Persson                              PGP key A88682FD
                   omb jor ers @sv ge.
                   r o.b n.p son eri nu

Re: Wasteful internationalization

[Markus E Leypold]

Bj�rn Persson <spam-away@nowhere.nil> writes:

> Markus E Leypold wrote:

>> Did he force you? Or did he just inform you that he can't see the 'Pi'
>> and probably won't see it ever. You can ignore his information, I
>> think.
>
> Of course he has no means to literally force me. He's trying to *persuade*
> everyone to go back to ASCII. It was not just information. He stated
> explicitly that everyone should use ASCII.


Yes. And I have to support him there. I think this is actually a good
idea. We're writing english here, you might notice, so I fail to see
any reason to write umlauts, expect in personal names. For this there
are transscription. Or would you, if someone from China partcipated
here, write his/her name in chinese letters every time you address the
person in the text?

Regards -- Markus


PS:

> His first post looked like he didn't know why he didn't see the right
> character, and I tried to be helpful, not remembering that it was Larry who
> complained to a newbie who used UTF-8 in May last year. I'll probably

Newbie. Exactly.

> ignore him next time he complains to me, but I may intervene if he attacks
> newbies again.

>> BTW: I have Gnus on a rather current Linux system. I couldn't see the
>> Pi, too. This happens sometimes and do you know what: I don't read
>> posts I can't display or decode (same with web pages).
>
> I do the same. I don't have Flash installed (because I can't stand web pages
> full of animated ads). There have been a few Flash applets that were
> important enough that I installed the Flash plugin, watched the applet and
> removed Flash again, but when people send out links to funny clips on
> Youtube and the like I usually don't watch them, thinking they probably
> aren't worth all the trouble. But I don't complain about it! Especially not
> i public forums. I have made my choice and I accept the consequences. I
> don't try to make people stop posting Flash clips just because watching
> them is too much trouble for me.

You will try to stop them as soon as your online banking is beginning
to be tied to flash. :-)

Re: Wasteful internationalization

[Björn Persson]

Markus E Leypold wrote:

> We're writing english here, you might notice, so I fail to see
> any reason to write umlauts, expect in personal names.

And also in some special cases, like when discussing character encoding bugs
perhaps. (There are far too many of those, even in Ada software.) Or maybe
when mentioning a particular constant that is defined in the standard.

> For this there 
> are transscription. Or would you, if someone from China partcipated
> here, write his/her name in chinese letters every time you address the
> person in the text?

Most of the time I would address them as "you", but if I'd need to write out
the name I'd write it the same way as they had written it. (I'd have to, as
I don't know how to transliterate.) If they'd write it in Pinyin I could
type it. If they'd write it with Chinese characters I'd have to copy and
paste it, but that doesn't take all that much effort.

-- 
Bj�rn Persson                              PGP key A88682FD
                   omb jor ers @sv ge.
                   r o.b n.p son eri nu

Re: Wasteful internationalization

[Alexander E. Kopilovich]

Bj?rn Persson wrote:
> what's the point in defining new
>standards if nobody ever starts using the new capabilities?

Why "nobody"? Unicode provides some reasonable way for mixed-language texts,
so those who need that kind of texts may use it successfully.

But this does not mean that with emergence of Unicode all kinds of text should
be regarded as mixed-language and thus employ Unicode. There is no such strict
alternative for the use of those standards: either everybody or nobody.

> He's trying to *persuade*
>everyone to go back to ASCII. It was not just information. He stated
>explicitly that everyone should use ASCII.

And he is certainly right in that. Perhaps you'll see the truth later, when
you encounter Chinese hieroglyphs and Arabic letters in messages that you
are reading. Your brand new Unicode-capable newsreader will give you pretty
pictures of them, you will not have a foggiest idea about their possible
meaning or how they may sound... perhaps you even will not know in which
direction they should be read.

>I'll probably
>ignore him next time he complains to me, but I may intervene if he attacks
>newbies again.

It seems that you are contemplating flames on this topic. Well, I should tell
you that your current position regarding this subject is not strong enough
for reasonably good flaming. Below is just a simple example of the direction
of a possible counter-attack that you may experience:

[flame on]

It isn't enough to update you newsreader - you should update your brains to
compatibility with Internationally Agreed Standard. Well, perhaps you are 
ready for that... updates are relatively easy when there is enough free space
and production runs aren't frequent and are delayable. But why do you think
that others should be equally ready for that? Do you really think that
Internationally Agreed Brain Contents Standard is somehow better than just
American standard?

[flame off]

Re: Wasteful internationalization

[Björn Persson]

Alexander E. Kopilovich wrote:

> Bj?rn Persson wrote:
>> what's the point in defining new
>>standards if nobody ever starts using the new capabilities?
> 
> Why "nobody"? Unicode provides some reasonable way for mixed-language
> texts, so those who need that kind of texts may use it successfully.

Yes, and in this case I needed a π, so I wrote one. I couldn't write "pi".
The constant Pi isn't new in Ada 2005. What's new is that it is also
defined with the name "π", so that was the name I wrote.

> But this does not mean that with emergence of Unicode all kinds of text
> should be regarded as mixed-language and thus employ Unicode. There is no
> such strict alternative for the use of those standards: either everybody
> or nobody.

Exactly, and there is even software in place that tries to ensure that texts
are as readable as possible with old and limited programs. There is UTF-8,
and there are algorithms to choose the simplest encoding that can encode
the text. The easiest approach would have been to always use UCS-4, but
instead programmers have gone to great lengths to make their programs as
backwards compatible as possible.

>> He's trying to *persuade*
>>everyone to go back to ASCII. It was not just information. He stated
>>explicitly that everyone should use ASCII.
> 
> And he is certainly right in that. Perhaps you'll see the truth later,
> when you encounter Chinese hieroglyphs and Arabic letters in messages that
> you are reading. Your brand new Unicode-capable newsreader will give you
> pretty pictures of them, you will not have a foggiest idea about their
> possible meaning or how they may sound... perhaps you even will not know
> in which direction they should be read.

Now you're confusing character encodings with human languages. It's true
that I can't read Chinese. I can't read it the slightest bit better in
Pinyin. Same thing with Arabic: Transliterating Arabic to Latin letters
wouldn't help me understand it. This isn't even a hypothetical situation.
It has already happened: I've seen a few posts in French around here, and I
didn't understand them even though I recognized all the letters. Messing up
the French spelling by dropping all the accents to force it into ASCII
would not have helped.

I didn't write a post in Greek. I used π in its mathematical meaning. I do
in fact expect every programmer to recognize π when they see a "pretty
picture" of it, and know exactly what it means.

-- 
Björn Persson                              PGP key A88682FD
                   omb jor ers @sv ge.
                   r o.b n.p son eri nu

Re: Wasteful internationalization

[Randy Brukardt]

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

"Bj�rn Persson" <spam-away@nowhere.nil> wrote in message
news:SQ5xh.31105$E02.12554@newsb.telia.net...
...
> I do the same. I don't have Flash installed (because I can't stand web
pages
> full of animated ads). There have been a few Flash applets that were
> important enough that I installed the Flash plugin, watched the applet and
> removed Flash again, but when people send out links to funny clips on
> Youtube and the like I usually don't watch them, thinking they probably
> aren't worth all the trouble. But I don't complain about it!

Gee, that's too bad. Someone needs to point out to these marketing types
that "cool" websites get in the way of finding/providing information. When I
was shopping for a car last year, I tried the web sites of various dealers.
Several were completely unusable without Flash! I didn't want "brochureware"
(in this case, lovely videos of cars driving about with beautiful models at
the wheel): I was looking for specs (like the size of the hatch or trunk
opening). I ended up having to drive to most of dealers (I consider Flash
adware: I spent several hours rooting it out of my Windows XP laptop, as it
comes installed by default, complete with its many vulnerabilities.) In the
end, I ended up buying from the dealer that allowed plain text navigation.

Anyway, the discussion point was the readability and portability of Ada
sources. You can probably get by ignoring the exact content of strings, but
that's impossible with identifiers. So a program with Chinese identifiers is
going to be unreadable to someone outside of China. Now, how am I going to
do technical support for those programs? Or use open source programs written
that way? Ugh!!

                           Randy.

Re: Wasteful internationalization

[Markus E Leypold]

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

> Anyway, the discussion point was the readability and portability of Ada
> sources. You can probably get by ignoring the exact content of strings, but
> that's impossible with identifiers. So a program with Chinese identifiers is
> going to be unreadable to someone outside of China. Now, how am I going to
> do technical support for those programs? Or use open source programs written
> that way? Ugh!!
>
>                            Randy.

Some 10 years ago one could buy a russian DOS clone (PTS Dos) with
full sources. That was funny too: The comment where mostly in russian
(cyrillic) and one couldn't read them on a DOS machine. A small number
of comments were in english which became more understandable after
translating it into german word for word (i.e. w/o looking at the
possible meaning, just use "Speicher-Loch" for " memory hole" (which
should have been "memory leak") etc. The identifiers were just
nonsense or bad english too. Such a program is absolutely
unmaintainable (outside of russia, that is, in this case).

Regards -- Markus

Re: Wasteful internationalization

[Björn Persson]

Markus E Leypold wrote:

> "Randy Brukardt" <randy@rrsoftware.com> writes:
> 
>> Anyway, the discussion point was the readability and portability of Ada
>> sources.

I thought the discussion point was whether it's OK to occasionally include a
non-ASCII character in an otherwise English-language Usenet post.

>> You can probably get by ignoring the exact content of strings, 
>> but that's impossible with identifiers. So a program with Chinese
>> identifiers is going to be unreadable to someone outside of China.

Conversely, a program with English identifiers and comments may not be so
easy to read to someone *in* China. Many people over there are rather bad
at English. A Chinese programmer team at a Chinese company on the Chinese
market may well choose to write in Chinese because it makes the code more
readable and maintainable *to them*. And as Markus demonstrates below, if
they'd try to write in English the code might end up illegible to you
anyway:

> A small number
> of comments were in english which became more understandable after
> translating it into german word for word (i.e. w/o looking at the
> possible meaning, just use "Speicher-Loch" for " memory hole" (which
> should have been "memory leak") etc. The identifiers were just
> nonsense or bad english too.

See? Their attempt to write in English didn't help much. This isn't a matter
of character encodings at all; it's a matter of knowledge of languages.

And once again: There's a big difference between a Chinese text and a
well-known mathematical symbol which just happens to be a Greek letter.

-- 
Bj�rn Persson                              PGP key A88682FD
                   omb jor ers @sv ge.
                   r o.b n.p son eri nu

Re: Wasteful internationalization

[Markus E Leypold]

Bj�rn Persson <spam-away@nowhere.nil> writes:

> Markus E Leypold wrote:
>
>> "Randy Brukardt" <randy@rrsoftware.com> writes:
>> 
>>> Anyway, the discussion point was the readability and portability of Ada
>>> sources.
>
> I thought the discussion point was whether it's OK to occasionally include a
> non-ASCII character in an otherwise English-language Usenet post.

Not really. We started out (approximately) wether it should be
considered a good thing that Ada sourcec can / will be able to be full
unicode and what evil would come from writing identifiers in all
unicode characters. Or something like this.

>>> You can probably get by ignoring the exact content of strings, 
>>> but that's impossible with identifiers. So a program with Chinese
>>> identifiers is going to be unreadable to someone outside of China.
>
> Conversely, a program with English identifiers and comments may not be so
> easy to read to someone *in* China. Many people over there are rather bad
> at English. A Chinese programmer team at a Chinese company on the Chinese
> market may well choose to write in Chinese because it makes the code more
> readable and maintainable *to them*. 



> And as Markus demonstrates below, if
> they'd try to write in English the code might end up illegible to you
> anyway:

Yes. But that anekdote was not contributed to support your case :-),
and also it refers to comments especially. I know a number of cases of
absolutely incomprehensible docs by native speakers. Documentation is
more than just language. And while you're at learning it you can as
well learn the "universal" tech pidgin which happens to be dreived
from English.

( Actually: The occurrence of pidgin languages somwhat indicates to
  me, that the trend of cultures trading with others is usually more
  to develop some common / intermediate language and not translate
  everything. Much less work, since anyone has to learn the common
  language just once. And it delights me that the "natural order of
  things" enrages "linguistic" purists like the VDS-EV -- a society
  which tries to rescue German from the English influence. )

>> A small number
>> of comments were in english which became more understandable after
>> translating it into german word for word (i.e. w/o looking at the
>> possible meaning, just use "Speicher-Loch" for " memory hole" (which
>> should have been "memory leak") etc. The identifiers were just
>> nonsense or bad english too.

> See? Their attempt to write in English didn't help much. This isn't

Curiously enough it was probably better understandable to me (a
German) than to some english native speaker. The anekdote has only
entertainment value. To comclude something from it would premature.

> a matter of character encodings at all; it's a matter of knowledge
> of languages.


So why do you feel so strongly on encodings? At least German can well
be transcribed into 7-Bit ASCII and I hardly ever write German on the
net.

> And once again: There's a big difference between a Chinese text and a
> well-known mathematical symbol which just happens to be a Greek letter.

If we start to support display mathematics in news readers we can as
well go the whole way and support a good layout system (like that TeX
has). Unfortunately the editors (with the possible ecxeption of
TeXmacs are not up to the task. So if I can't write/display proper
math at all, what does the support of an occasional greek letter for
math buy me? Has Lars to stop reading mail with his VT102 only because
some people sometimes want to stray in the occasional greek character
and therefore we all switch to full UTF-8 and Mime and so on?

Just playing (being?) advocatus diablo -- Markus

Re: Wasteful internationalization

[Björn Persson]

Markus E Leypold wrote:

> So why do you feel so strongly on encodings?

Lots and lots of software is crawling with character encoding bugs. Take our
brand new Gnuada-maintainers mailing list for example. In the welcome
message my name was turned into "Björn". Somebody's had the
*scintillating* idea of encoding non-English letters as XML character
references – in a plaintext message! And if you look in the archive, at the
message I sent to the list, my ö has become an invalid UTF-8 code, because
they've specified the encoding of the web page as UTF-8, but they haven't
bothered converting the message from Latin-1 to UTF-8. These things happen
all the time and I'm thoroughly sick of it.

These bugs are produced by egocentric USian coders who think that the USA is
the entire world and that the English alphabet is the only one that
matters. They only test their programs with English sample texts, and as
all of the most popular encodings are compatible with ASCII they never see
any bad consequences of ignoring character encodings, so they keep doing
it. I'm not going to avoid non-ASCII characters just to help ignorant
coders remain ignorant.

> I hardly ever write German on the
> net.

So how representative are you? Do Germans mostly communicate in English
between themselves? I kind of doubt it. Swedes send email in Swedish to
each other, and web sites for a Swedish audience are written in Swedish,
and it's damned annoying every time buggy USian software mangles the text.

-- 
Björn Persson                              PGP key A88682FD
                   omb jor ers @sv ge.
                   r o.b n.p son eri nu

Re: Wasteful internationalization

[Franz Kruse]

Björn Persson:

> > I hardly ever write German on the
> > net.
>
> So how representative are you? Do Germans mostly communicate in
> English between themselves? I kind of doubt it. Swedes send email in
> Swedish to each other, and web sites for a Swedish audience are
> written in Swedish, and it's damned annoying every time buggy USian
> software mangles the text.

I do very much support your complaint!

Franz (German)

Not at all wasteful internationalization

[Martin Krischik]

Björn Persson schrieb:

> These bugs are produced by egocentric USian coders who think that the USA is
> the entire world and that the English alphabet is the only one that
> matters. They only test their programs with English sample texts, and as
> all of the most popular encodings are compatible with ASCII they never see
> any bad consequences of ignoring character encodings, so they keep doing
> it. I'm not going to avoid non-ASCII characters just to help ignorant
> coders remain ignorant.

Right, I noticed a decline in I18N support in SuSE Linux right in the 
first release under Novel Management. So I would say: it's not just 
egocentric USian coders but egocentric USian management as well.

Martin

PS: Mind you; the one thing which pissed me of most was the switch from 
A4 to Letter - I would not even know where to buy US-Letter sized paper 
if I wanted to - which I don't.

Re: Not at all wasteful internationalization

[Georg Bauhaus]

On Mon, 2007-02-12 at 10:20 +0100, Martin Krischik wrote:
> Björn Persson schrieb:
> 
>  I noticed a decline in I18N support in SuSE Linux right in the 
> first release under Novel Management. So I would say: it's not just 
> egocentric USian coders but egocentric USian management as well.

I think many in the US know French or Spanish, and then your
 writing will
profit from Latin-1 which requires some I18N.
So I guess there are more reasons why 7bit is so popular among
technical people.

What are typical SuSE customer like? Well they want I18N?
Programmers claim they can communicate well using just 7bit ASCII,
possibly turning Latin-1 characters into a sequence of two 7bit
charaters. Poor man's UTF-)? When needed, the write a" for ä or
o/ for ø etc...

These character sequence provide for enough magic. No need to
finally learn how to use a keyboard and use the real characters :-)


-- Georg 
Watt de buer nich kennt, datt eet hei nich.

Re: Not at all wasteful internationalization

[Martin Krischik]

Georg Bauhaus schrieb:
> On Mon, 2007-02-12 at 10:20 +0100, Martin Krischik wrote:
>>  I noticed a decline in I18N support in SuSE Linux right in the 
>> first release under Novel Management. So I would say: it's not just 
>> egocentric USian coders but egocentric USian management as well.

> What are typical SuSE customer like? Well they want I18N?

LC_ALL=de_DE.utf8

  ;-)

Martin

RE: Wasteful internationalization

[Randy Brukardt]

[I'm trying to use the Ada-France comp.lang.ada scheme, as I'm using a new
Internet provider without a news server (or at least they won't tell me
where one is. So I've missed a couple of days messages, hopefully I'm not
repeating stuff.]

Bj�rn Persson writes (mostly responding to me):

> Markus E Leypold wrote:
>
> > "Randy Brukardt" <randy@rrsoftware.com> writes:
> >
> >> Anyway, the discussion point was the readability and portability of Ada
> >> sources.
>
> I thought the discussion point was whether it's OK to occasionally include
a
> non-ASCII character in an otherwise English-language Usenet post.

I hope you're kidding. That side discussion erupted over examples of the
readability of Ada sources.

> >> You can probably get by ignoring the exact content of strings,
> >> but that's impossible with identifiers. So a program with Chinese
> >> identifiers is going to be unreadable to someone outside of China.
>
> Conversely, a program with English identifiers and comments may not be so
> easy to read to someone *in* China. Many people over there are rather bad
> at English. A Chinese programmer team at a Chinese company on the Chinese
> market may well choose to write in Chinese because it makes the code more
> readable and maintainable *to them*.

That's fine if they never want any help. If they post a question here with
that program, the odds are that they won't get many, if any answers. Most of
us will see nothing except a bunch of boxes. (Indeed, if you're using the
e-mail version of cla, and have a decent spam filter, you'll never see the
thread in the first place.)

Similarly, if someone was to ask for help with Janus/Ada and sent such a
program, I wouldn't be able to do anything for them. That's not good for
either us (it does not allow us to provide support up to the level of our
standard) nor for the customer.

The point is that if you want to be part of the Ada *Community*, you have to
use characters that the vast majority of the Community can understand. If
you don't care or expect any help or sharing, then it doesn't matter.

A number of us were very strongly opposed to the PI thing, simply because it
suggests that program abuse of this type is OK.

> And as Markus demonstrates below, if
> they'd try to write in English the code might end up illegible to you
> anyway:
>
> > A small number
> > of comments were in english which became more understandable after
> > translating it into german word for word (i.e. w/o looking at the
> > possible meaning, just use "Speicher-Loch" for " memory hole" (which
> > should have been "memory leak") etc. The identifiers were just
> > nonsense or bad english too.
>
> See? Their attempt to write in English didn't help much. This isn't a
matter
> of character encodings at all; it's a matter of knowledge of languages.

Not relevant. I've had to provide technical support for programs with
foreign language comments. It's not fun, but it is possible because you can
just follow the identifiers. You can't do that if the ids are just blocks of
square boxes -- they'll all look the same.

> And once again: There's a big difference between a Chinese text and a
> well-known mathematical symbol which just happens to be a Greek letter.

And that's irrelevant to the primary thread (which is programs written
primarily in non-Latin-1 fonts). I personally don't mind program texts that
stick to the roughly 600 characters that are available in most Windows
fonts. But other people's systems may vary as to what is available. And I
don't want to encourage use of characters that can't be displayed by most.
So a "single Greek character" is an example of the slippery slope to
obblivion: people are not going to stop there.

                     Randy.

Re: Wasteful internationalization

[Stephen Leake]

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

> [I'm trying to use the Ada-France comp.lang.ada scheme, as I'm using a new
> Internet provider without a news server (or at least they won't tell me
> where one is. So I've missed a couple of days messages, hopefully I'm not
> repeating stuff.]

I gave up on my ISP's newserver, and now pay a small fee to
flashnewsgroups.com. It's worth it; the email gateway to comp.lang.ada
is not reliable.


-- 
-- Stephe

RE: Wasteful internationalization

[Björn Persson]

Randy Brukardt wrote:

> [I'm trying to use the Ada-France comp.lang.ada scheme, as I'm using a new
> Internet provider without a news server (or at least they won't tell me
> where one is. So I've missed a couple of days messages, hopefully I'm not
> repeating stuff.]

Well, apparently the backward references get lost somewhere along the way,
making navigation among the threads rather difficult. :-(

> Björn Persson writes (mostly responding to me):
> 
>> I thought the discussion point was whether it's OK to occasionally
>> include
> a
>> non-ASCII character in an otherwise English-language Usenet post.
> 
> I hope you're kidding. That side discussion erupted over examples of the
> readability of Ada sources.

That was the topic briefly before Larry complained about my not sticking to
ASCII – in a Usenet post, not in Ada code. Even earlier the topic was
internationalization, as the title of each post still suggests. Before that
the title was "Structured exception information", and in the direct
ancestors of this branch the discussion was about whether there is any need
for structured exception information. The topic always changes in a long
discussion.

And now the discussion has deteriorated into a meta-discussion about what
the topic of the discussion was, so I'm stopping here.

-- 
Björn Persson                              PGP key A88682FD
                   omb jor ers @sv ge.
                   r o.b n.p son eri nu

Re: Wasteful internationalization

[Peter Hermann]

Randy Brukardt <randy@rrsoftware.com> wrote:
> end, I ended up buying from the dealer that allowed plain text navigation.

useit.com : Jakob Nielsen's Website    ;-)

OT: Flash (was: Re: Wasteful internationalization)

[Jeffrey R. Carter]

Randy Brukardt wrote:
> 
> Gee, that's too bad. Someone needs to point out to these marketing types
> that "cool" websites get in the way of finding/providing information. When I
> was shopping for a car last year, I tried the web sites of various dealers.
> Several were completely unusable without Flash! I didn't want "brochureware"
> (in this case, lovely videos of cars driving about with beautiful models at
> the wheel): I was looking for specs (like the size of the hatch or trunk
> opening). I ended up having to drive to most of dealers (I consider Flash
> adware: I spent several hours rooting it out of my Windows XP laptop, as it
> comes installed by default, complete with its many vulnerabilities.) In the
> end, I ended up buying from the dealer that allowed plain text navigation.

Firefox with NoScript and AdBlock let you get rid of unwanted Flash 
while still being able to see it when you want.

-- 
Jeff Carter
"Pray that there's intelligent life somewhere up in
space, 'cause there's bugger all down here on earth."
Monty Python's Meaning of Life
61

Re: OT: Flash

[Markus E Leypold]

"Jeffrey R. Carter" <jrcarter@acm.org> writes:

> Randy Brukardt wrote:
>> Gee, that's too bad. Someone needs to point out to these marketing
>> types
>> that "cool" websites get in the way of finding/providing information. When I
>> was shopping for a car last year, I tried the web sites of various dealers.
>> Several were completely unusable without Flash! I didn't want "brochureware"
>> (in this case, lovely videos of cars driving about with beautiful models at
>> the wheel): I was looking for specs (like the size of the hatch or trunk
>> opening). I ended up having to drive to most of dealers (I consider Flash
>> adware: I spent several hours rooting it out of my Windows XP laptop, as it
>> comes installed by default, complete with its many vulnerabilities.) In the
>> end, I ended up buying from the dealer that allowed plain text navigation.
>
> Firefox with NoScript and AdBlock let you get rid of unwanted Flash
> while still being able to see it when you want.

In those "cool" sites it also gets you rid of all the information that
there is to have -- since they don't provide any othere because
"everybody has flash anyway today" and "those that don't should better
upgrade to modern software".

It'd be nice to see their faces when they realize (in the years to
come) that the part of the relatives that has money left ofter to
realizes their dreams of luxury are the older people who are somewhat
overtaxed and with pop-ups, pop-unders, all that blinking and
microscopic writing -- and therefore will in the long run prefer to
get their information (and the things to buy) from a side that looks
like the media they know: Books, brochures, magazines and which can be
read even by someone with aging eyes who doesn't have the reflexes and
the coordination of a jet pilot. What will I be laughing ...

Regards -- Markus

Re: Wasteful internationalization

[Larry Kilgallen]

In article <dZQwh.31058$E02.12529@newsb.telia.net>, =?ISO-8859-1?Q?Bj=F6rn?= Persson <spam-away@nowhere.nil> writes:
> Larry Kilgallen wrote:

>> It seems to me that people in newsgroups should stick to ASCII.
> 
> So, you want the entire world to use the American Standard Code?

No, only those who wish to communicate in an English language newsgroup.

> Look, nobody is forcing you to use a MIME-aware newsreader. It may be that
> there is none that runs on VMS. In that case you have a choice: Use VMS and
> not see all characters right, or see the characters but not on VMS. Decide
> what's more important to you.

VMS is a given to me, newsgroups are secondary.

Re: Wasteful internationalization

[Björn Persson]

Markus E Leypold wrote:

> Bj�rn Persson <spam-away@nowhere.nil> writes:
> 
>> Bah! That was supposed to be a ?. (Obviously Knode, my Usenet client, is
> 
> Was that supposed to be rendered as a box? Or does _my_ client not get it
> right?

A box is often displayed when there is no glyph available for the character.
I see your client switches encodings as needed and the pi is intact in your
reply, so apparently SCUG is cool enough to understand MIME and UTF-8, but
you probably don't have any Greek fonts installed.

-- 
Bj�rn Persson                              PGP key A88682FD
                   omb jor ers @sv ge.
                   r o.b n.p son eri nu

Re: Wasteful internationalization

[Markus E Leypold]

Bj�rn Persson <spam-away@nowhere.nil> writes:

> Markus E Leypold wrote:
>
>> Bj�rn Persson <spam-away@nowhere.nil> writes:
>> 
>>> Bah! That was supposed to be a ?. (Obviously Knode, my Usenet client, is
>> 
>> Was that supposed to be rendered as a box? Or does _my_ client not get it
>> right?
>
> A box is often displayed when there is no glyph available for the character.

I know, therefore my question. 

> I see your client switches encodings as needed and the pi is intact in your
> reply, so apparently SCUG is cool enough to understand MIME and UTF-8, but

SCUG is Gnus with gnushus.el :-).

> you probably don't have any Greek fonts installed.

Yes, that might be.

Yes, 'PI' as greek letter in programs might be nice. But is h-bar
(Plack constant) somewhere in Unicode? :-)


Regards -- Markus

Re: Wasteful internationalization

[Georg Bauhaus]

On Mon, 2007-01-29 at 20:03 +0100, Markus E Leypold wrote:

> Yes, 'PI' as greek letter in programs might be nice. But is h-bar
> (Plack constant) somewhere in Unicode? :-)

Sure,
U+210F PLANCK CONSTANT OVER TWO PI
or 'ℏ'

Re: Wasteful internationalization

[Markus E Leypold]

Georg Bauhaus <bauhaus@futureapps.de> writes:

> On Mon, 2007-01-29 at 20:03 +0100, Markus E Leypold wrote:
>
>> Yes, 'PI' as greek letter in programs might be nice. But is h-bar
>> (Plack constant) somewhere in Unicode? :-)
>
> Sure,
> U+210F PLANCK CONSTANT OVER TWO PI
> or 'ℏ'

So that's the same as PI (a small box). I know you can define some
physical constants as 1 by using the right units, but I'd never have
expected that you could define h-bar as PI ...

(no, no, I'm joking. But impressing that unicode even has
h-bar. Probably they also have everyone of the more "funny" operators
of theoretical physics too. Of course that does not help in writing
better physics programs, since some of the stuff need special parsing
too).

Regards -- Markus

Re: Wasteful internationalization

[Georg Bauhaus]

On Tue, 2007-01-30 at 20:37 +0100, Markus E Leypold wrote:
> Georg Bauhaus <bauhaus@futureapps.de> writes:
> 
> > On Mon, 2007-01-29 at 20:03 +0100, Markus E Leypold wrote:
> >
> >> Yes, 'PI' as greek letter in programs might be nice. But is h-bar
> >> (Plack constant) somewhere in Unicode? :-)
> >
> > Sure,
> > U+210F PLANCK CONSTANT OVER TWO PI
> > or 'ℏ'

> (no, no, I'm joking. But impressing that unicode even has
> h-bar. Probably they also have everyone of the more "funny" operators
> of theoretical physics too. Of course that does not help in writing
> better physics programs, since some of the stuff need special parsing
> too).

Ada 2007 doesn't add symbols, AFAICS, but you can use symbols and more
in comments.
Both characters (Greek Pi) ('π') and (Planck Constant / 2*PI) ('ℏ')
are letters and can be used as identifiers.
Some of the symbols of Unicode have an internationally recognized
meaning, sometimes even a standardized meaning. They can therefore
add value to specification and review,

  -- In case of too much radiation (☢), start the shutdown procedure
  -- and press the eject button (⏏)!

  if Radiation > Limit then
      System.Shutdown(Now);
      Press(Control_Panel, Button => Eject);
  end if;


 -- Georg

Re: Wasteful internationalization

[Georg Bauhaus]

On Tue, 2007-01-30 at 21:43 +0100, Georg Bauhaus wrote:


> Ada 2007 doesn't add symbols, AFAICS, but you can use symbols and more
                        ^^^^^^^^^^^
                for user defined operators, I meant

Re: Wasteful internationalization

[Markus E Leypold]

Georg Bauhaus <bauhaus@arcor.de> writes:

> On Tue, 2007-01-30 at 20:37 +0100, Markus E Leypold wrote:
>> Georg Bauhaus <bauhaus@futureapps.de> writes:
>> 
>> > On Mon, 2007-01-29 at 20:03 +0100, Markus E Leypold wrote:
>> >
>> >> Yes, 'PI' as greek letter in programs might be nice. But is h-bar
>> >> (Plack constant) somewhere in Unicode? :-)
>> >
>> > Sure,
>> > U+210F PLANCK CONSTANT OVER TWO PI
>> > or 'ℏ'
>
>> (no, no, I'm joking. But impressing that unicode even has
>> h-bar. Probably they also have everyone of the more "funny" operators
>> of theoretical physics too. Of course that does not help in writing
>> better physics programs, since some of the stuff need special parsing
>> too).
>
> Ada 2007 doesn't add symbols, AFAICS, but you can use symbols and more
> in comments.
> Both characters (Greek Pi) ('π') and (Planck Constant / 2*PI) ('ℏ')
> are letters and can be used as identifiers.
> Some of the symbols of Unicode have an internationally recognized
> meaning, sometimes even a standardized meaning. They can therefore
> add value to specification and review,
>
>   -- In case of too much radiation (☢), start the shutdown procedure
>   -- and press the eject button (⏏)!


Yes, true -- if physicists (and engineers) could agree on the actual
meaning of symbols. Which they can't, so, usually it is safer to use a
clear text term. Especially in the user interface ...

Regards -- Markus

Re: Wasteful internationalization

[Alex R. Mosteo]

Markus E Leypold wrote:

> 
> Georg Bauhaus <bauhaus@futureapps.de> writes:
> 
>> On Mon, 2007-01-29 at 20:03 +0100, Markus E Leypold wrote:
>>
>>> Yes, 'PI' as greek letter in programs might be nice. But is h-bar
>>> (Plack constant) somewhere in Unicode? :-)
>>
>> Sure,
>> U+210F PLANCK CONSTANT OVER TWO PI
>> or '?'
> 
> So that's the same as PI (a small box). I know you can define some
> physical constants as 1 by using the right units, but I'd never have
> expected that you could define h-bar as PI ...
> 
> (no, no, I'm joking. But impressing that unicode even has
> h-bar. Probably they also have everyone of the more "funny" operators
> of theoretical physics too. Of course that does not help in writing
> better physics programs, since some of the stuff need special parsing
> too).

Isn't supposed unicode to have /everything/? Well, or almost. I think they
rejected to include Klingon.

Here, I found it:

http://unicode.org/alloc/rejected.html

Actually it's even a fun read:

http://std.dkuug.dk/jtc1/sc2/wg2/docs/n1643/n1643.htm

Re: Wasteful internationalization

[Markus E Leypold]

"Alex R. Mosteo" <devnull@mailinator.com> writes:

> Markus E Leypold wrote:
>
>> 
>> Georg Bauhaus <bauhaus@futureapps.de> writes:
>> 
>>> On Mon, 2007-01-29 at 20:03 +0100, Markus E Leypold wrote:
>>>
>>>> Yes, 'PI' as greek letter in programs might be nice. But is h-bar
>>>> (Plack constant) somewhere in Unicode? :-)
>>>
>>> Sure,
>>> U+210F PLANCK CONSTANT OVER TWO PI
>>> or '?'
>> 
>> So that's the same as PI (a small box). I know you can define some
>> physical constants as 1 by using the right units, but I'd never have
>> expected that you could define h-bar as PI ...
>> 
>> (no, no, I'm joking. But impressing that unicode even has
>> h-bar. Probably they also have everyone of the more "funny" operators
>> of theoretical physics too. Of course that does not help in writing
>> better physics programs, since some of the stuff need special parsing
>> too).
>
> Isn't supposed unicode to have /everything/? Well, or almost. I think they
> rejected to include Klingon.

They did? If that doesn't spell trouble, I don't know ... 

Regards -- Markus

Re: Wasteful internationalization

[Björn Persson]

Alex R. Mosteo wrote:

> Isn't supposed unicode to have /everything/? Well, or almost. I think they
> rejected to include Klingon.

I suspect that if they'd accept Klingon they'd soon be drowned in proposals
to include fantasy scripts. :-)

-- 
Björn Persson                              PGP key A88682FD
                   omb jor ers @sv ge.
                   r o.b n.p son eri nu

Re: Wasteful internationalization

[Alex R. Mosteo]

Bj�rn Persson wrote:

> Alex R. Mosteo wrote:
> 
>> Isn't supposed unicode to have /everything/? Well, or almost. I think
>> they rejected to include Klingon.
> 
> I suspect that if they'd accept Klingon they'd soon be drowned in
> proposals to include fantasy scripts. :-)

Yep. Actually, I think some people has registered private ranges for the
elvish scripts of Tolkien.

Re: Wasteful internationalization

[Björn Persson]

Markus E Leypold wrote:

> Probably they also have everyone of the more "funny" operators
> of theoretical physics too.

I don't know much about what operators are used in theoretical physics, but
have a look at these:

http://www.unicode.org/charts/PDF/U2200.pdf
http://www.unicode.org/charts/PDF/U27C0.pdf
http://www.unicode.org/charts/PDF/U2980.pdf
http://www.unicode.org/charts/PDF/U2A00.pdf

-- 
Björn Persson                              PGP key A88682FD
                   omb jor ers @sv ge.
                   r o.b n.p son eri nu

Re: Wasteful internationalization

[Stephen Leake]

Georg Bauhaus <bauhaus@futureapps.de> writes:

> On Mon, 2007-01-29 at 20:03 +0100, Markus E Leypold wrote:
>
>> Yes, 'PI' as greek letter in programs might be nice. But is h-bar
>> (Plack constant) somewhere in Unicode? :-)
>
> Sure,
> U+210F PLANCK CONSTANT OVER TWO PI
> or 'ℏ'

That's a "small box" on my display. Apparently I'm missing that font.

Which is a good reason to not use such characters in programs. How
many people would know how to install the right fonts? (hint; not me
:) And how do you figure out what fonts they will need? 

I assume these problems will eventually be solved. But I don't trust
Microsoft to solve them in a nice way ("the program you are trying to
compile requires font foobar. Please deposit $20.00 to download it" :).

With ASCII source, the necessary fonts are sure to be already installed.

-- 
-- Stephe

Re: Wasteful internationalization

[Björn Persson]

Stephen Leake wrote:

> That's a "small box" on my display. Apparently I'm missing that font.
> 
> Which is a good reason to not use such characters in programs. How
> many people would know how to install the right fonts? (hint; not me
> :) And how do you figure out what fonts they will need?

I don't see the problem.

There are two cases: Characters that the program itself uses, and Unicode
text data that the program processes and displays. The first case might
apply to a physics program that uses certain mathematical symbols. This is
no different from dynamic linking. You have complete control over which
characters your program uses, so you know what fonts it needs just like you
know what libraries it needs. For Windows the common practice is to
distribute all the necessary DLLs with your program. (At least I think it
still is. I don't follow the events in the Windows world very closely.)
Just handle fonts the same way – distribute them with the program. The
modern Unix-like operating systems that I know anything about are typically
based on some kind of package manager that handles dependencies. When
packaging the program you specify which library packages it depends on, and
the user's package manager will ensure that they are installed. Again, just
handle fonts the same way – make the program depend on the necessary fonts.

The second case applies to web browsers, email and Usenet clients, word
processors and so on. These programs should ideally be able to display any
Unicode character. That's impossible in practice as long as Unicode is
growing. Users may also prefer not to have so many fonts installed. You
might not want to have 60000 Chinese characters occupying disk space if you
can't read Chinese anyway. This is no reason to limit these programs to
ASCII. They're much more useful with Unicode support and an incomplete set
of fonts than with only ASCII support. They just need to cope with missing
fonts and display something else instead – and that's exactly what they do.

> I assume these problems will eventually be solved. But I don't trust
> Microsoft to solve them in a nice way ("the program you are trying to
> compile requires font foobar. Please deposit $20.00 to download it" :).

Yes, some fonts cost money, as do some libraries. There are also free and
gratis fonts, just like there are free and gratis libraries.

-- 
Björn Persson                              PGP key A88682FD
                   omb jor ers @sv ge.
                   r o.b n.p son eri nu

Re: Wasteful internationalization

[Dmitry A. Kazakov]

On Sat, 03 Feb 2007 00:49:45 GMT, Bj�rn Persson wrote:

> For Windows the common practice is to
> distribute all the necessary DLLs with your program. (At least I think it
> still is. I don't follow the events in the Windows world very closely.)

No, for Windows the common practice is to do nothing. If you install a
Russian Windows software you will see all letters shown as _____.

> You
> might not want to have 60000 Chinese characters occupying disk space if you
> can't read Chinese anyway.

But the point was about Chinese programs. Do you need 60000 Chinese
characters to read an Ada program? A clear question of modularization,
isn't it?

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

Re: Wasteful internationalization

[Stephen Leake]

Björn Persson <spam-away@nowhere.nil> writes:

> Stephen Leake wrote:
>
>> That's a "small box" on my display. Apparently I'm missing that font.
>> 
>> Which is a good reason to not use such characters in programs. How
>> many people would know how to install the right fonts? (hint; not me
>> :) And how do you figure out what fonts they will need?
>
> I don't see the problem.
>
> There are two cases: Characters that the program itself uses, and Unicode
> text data that the program processes and displays. The first case might
> apply to a physics program that uses certain mathematical symbols. This is
> no different from dynamic linking. You have complete control over which
> characters your program uses, so you know what fonts it needs just like you
> know what libraries it needs. 

No, I don't know what fonts the program itself needs; that's the point.

The unicode Pi and other Greek characters display properly in the
Emacs binary distribution I'm using. So I might be tempted to use
unicode Greek characters in my Ada source code as variable names. But
someone else, using another editor on another OS, may not be able to
see it.

Fonts are different from dlls, because they are used by editors, not
my executable. 

And while I can build Emacs from scratch, that still doesn't tell me
what font Pi is in. 

There probably is an Emacs command that could tell me; I just don't
know what it is. And I don't want to get into that discussion with the
personal favorite editor of every user of my code.

> The second case applies to web browsers, email and Usenet clients, word
> processors and so on. 

And program source code editors; that's the case I'm talking about.

> These programs should ideally be able to display any Unicode
> character. That's impossible in practice as long as Unicode is
> growing. Users may also prefer not to have so many fonts installed.
> You might not want to have 60000 Chinese characters occupying disk
> space if you can't read Chinese anyway. This is no reason to limit
> these programs to ASCII. They're much more useful with Unicode
> support and an incomplete set of fonts than with only ASCII support.
> They just need to cope with missing fonts and display something else
> instead – and that's exactly what they do.

If my program uses unicode Greek delta and omega as variable names,
having them both display as a box will make the code unreadable.

-- 
-- Stephe

Re: Wasteful internationalization

[Björn Persson]

Stephen Leake wrote:

> The unicode Pi and other Greek characters display properly in the
> Emacs binary distribution I'm using. So I might be tempted to use
> unicode Greek characters in my Ada source code as variable names. But
> someone else, using another editor on another OS, may not be able to
> see it.

Oh, I misunderstood you. I thought you meant using non-ASCII characters in
compiled programs, in the user interface.

Oh well, if you want your code to work with Gnat you have to stick to ASCII
anyway, at least in libraries.

-- 
Bj�rn Persson                              PGP key A88682FD
                   omb jor ers @sv ge.
                   r o.b n.p son eri nu

Re: Wasteful internationalization

[Stephen Leake]

Markus E Leypold <development-2006-8ecbb5cc8aREMOVETHIS@ANDTHATm-e-leypold.de> writes:

> Björn Persson <spam-away@nowhere.nil> writes:
>
>> Björn Persson wrote:
>>
>>> The constant ? is defined.
>>
>> Bah! That was supposed to be a π. (Obviously Knode, my Usenet client, is
>
> Was that supposed to be rendered as a box? Or does _my_ client not
> get it right?

Gnus (Emacs mail reader) on Windows shows the Greek letter Pi. Which
is declared in Ada.Numerics in Ada 2005, with the normal numerical
value:

package Ada.Numerics is
   pragma Pure;

   Argument_Error : exception;

   Pi : constant :=
          3.14159_26535_89793_23846_26433_83279_50288_41971_69399_37511;

   ["03C0"] : constant := Pi;
   --  This is the greek letter Pi (for Ada 2005 AI-388). 


-- 
-- Stephe

Re: Wasteful internationalization (Was: Structured exception information)

[Harald Korneliussen]

On 24 Jan, 22:03, "Randy Brukardt" <r...@rrsoftware.com> wrote:

> It depends on the application, of course, but for many things (like compiler
> error messages), attempts to localize just make things more confusing. Most
> important stuff in the world is in English these days -- that's the reality,
> and forcing localization of that is counterproductive.
>
They said that about French as well not all that long ago. How much 
effort is reduplicated because some russian statistician's work, or 
perhaps a chinese computer scientist's, is never adequately 
translated? Once China gets more industrialised (and if the US/Britain 
should become less important for some reason), things may change even 
within our lifetimes. Assuming that english will always be the user 
interface language is as silly as assuming dates can always be stored 
in a 16-bit int or something.

Re: Structured exception information

[Robert A Duff]

Stephen Leake <stephen_leake@stephe-leake.org> writes:

> I don't follow. Strings are perfectly valid Ada constructs. Why does
> the code to build the string not feel like Ada to you?

Building strings is fine.  Requiring clients to parse them is evil --
not type safe.

The whole point of exceptions is to separate the detection of potential
errors from the handing of them.  A well-designed exception mechanism
would allow the client to make these decisions:

Is this condition really an error?

If so, is it a recoverable error, or is it a plain old bug?

If recoverable, what should I do?

If it's a bug, should I print out useful information?  Useful to the
user, or useful to the programmer who wants to fix the bug (or both)?
(Example: if the gnat front end detects a bug in itself, it prints
out the line number it was processing at the time, which is useful
to the user who wants to find a workaround.)

Granularity of handling -- do I want to handle all I/O errors,
or just the "disk full" error?

Etc.

Constructing a string at the "raise" point is wrong because it presumes
that the client wants to print a string and exit, and it presumes the
format of that string.  If that were OK, then why have exceptions -- why
not make the code that detects the error print a string and exit?

Suppose we want to print error messages in French.  If the "raise" point
constructs a message in English, the client can't make that decision.

- Bob

Re: Structured exception information

[Stephen Leake]

Robert A Duff <bobduff@shell01.TheWorld.com> writes:

> Stephen Leake <stephen_leake@stephe-leake.org> writes:
>
>> I don't follow. Strings are perfectly valid Ada constructs. Why does
>> the code to build the string not feel like Ada to you?
>
> Building strings is fine.  Requiring clients to parse them is evil --
> not type safe.

Well, "evil" is a judgement (more below). I agree with "not type safe".

> The whole point of exceptions is to separate the detection of potential
> errors from the handing of them.  

Well, that's one view. I don't think that's consistent with the
current definition of exceptions in Ada. Which is the point of this
thread, I guess :).

I think the point of exceptions is non-local transfer of control. A
low-level routine encounters a problem, that only some routine several
layers up is prepared to handle. Rather than passing status thru each
layer, you raise an exception, and jump directly to the right place.

> A well-designed exception mechanism would allow the client to make
> these decisions:
>
> Is this condition really an error?
>
> If so, is it a recoverable error, or is it a plain old bug?
>
> If recoverable, what should I do?

That's a reasonable list. My current project does make those
decisions, based solely on the exception names. 

I have not thought very hard about whether it could make better
decisions if it had more information. So far, I'm happy with the
decisions it is making.

> If it's a bug, should I print out useful information?  Useful to the
> user, or useful to the programmer who wants to fix the bug (or both)?

That's an upfront design decision, not a run-time decision.

> (Example: if the gnat front end detects a bug in itself, it prints
> out the line number it was processing at the time, which is useful
> to the user who wants to find a workaround.)

Right. And that is a design choice was made by AdaCore, not a run-time
choice of the compiler; the compiler does not do that for some bugs,
but something else for other bugs.

> Granularity of handling -- do I want to handle all I/O errors,
> or just the "disk full" error?

I think you are hinting that you want classes of exceptions, rather
than single names. I agree I would find that useful sometimes. 

In Ada, we get this only by including each name in an exception choice
list. Ugly, but functional.

> Etc.

That's always a fun word. I doubt that the things I extrapolate here
are the same ones you do :).

> Constructing a string at the "raise" point is wrong because it presumes
> that the client wants to print a string 

That is the overall design of my application, so it is correct in this
case.

Designing a library that will be used by unknown future applications,
yet still returns truly useful information in error cases, is a very
hard problem. 

> and exit, 

Not in my application. Some exception names indicate fatal bugs that
require exit, others indicate a user error that require "stop, let the
user change something, try again".

Again, that is the overall design of my program.

> and it presumes the format of that string. 

No, since the string is never parsed by the program, only by the user
(a much more flexible parser :).

Hmm. I do have some formatting conventions; if a file is involved, I
format the file name, line number, and column information using the
Gnu standard, so Emacs parses it easily. 

VMS had a binary file format for error messages from the compiler,
that LSE could interpret. Other programs could output that same format; it
was a VMS standard. That is an example of structured information, vs
the Gnu standard of formatted strings. It appears that the market has
voted for formatted strings in this case :).

> If that were OK, then why have exceptions -- why not make the code
> that detects the error print a string and exit?

See above. In addition, in the case of fatal errors, there is cleanup
work to be done; shutdown external sockets, terminate other tasks. 

I suppose you could leave all that to the operating system, but I
choose not to. I get better error messages this way, so I have a
better chance of fixing the problem.

> Suppose we want to print error messages in French.  If the "raise" point
> constructs a message in English, the client can't make that decision.

Yes, that is what Internationalization libraries attempt to
accomplish. I have not investigated doing that in depth (it is _not_
a requirement for my current project). What little I have heard about
this sounds like it is impossible to get truly right; at best you must
impose very strict rules on formatting of all messages, and use some
sort of codes rather than any natural language when constructing the
messages.

That is a case where the error information is structured, rather
than a flat string. So doing that with exceptions in Ada may be
difficult. On the other hand, I think the Gnu internationalization
libraries use formatted strings for this.

Randy often says "sometimes you have to go outside the language" in
order to get something useful done. It may be that error handling is a
case where it is appropriate to forgo type safety, because of all the
other practical issues that come up. Let's remember that type safety
is a means to writing programs more efficiently, not an end in itself.
If it gets in the way of writing programs efficiently in some limited
area, it should be relaxed in that area. That seems to be the case
here.

-- 
-- Stephe

Re: Structured exception information

[Robert A Duff]

(By the way, one of my other posts crossed a couple of yours,
so if it sounds like we're talking past each other, it's because
we were both typing at the same time.  ;-) )

Stephen Leake <stephen_leake@stephe-leake.org> writes:

> Robert A Duff <bobduff@shell01.TheWorld.com> writes:

>> The whole point of exceptions is to separate the detection of potential
>> errors from the handing of them.  
>
> Well, that's one view. I don't think that's consistent with the
> current definition of exceptions in Ada. Which is the point of this
> thread, I guess :).

Precisely!  Clearly we can both agree on this point.  ;-)

> I think the point of exceptions is non-local transfer of control. A
> low-level routine encounters a problem, that only some routine several
> layers up is prepared to handle. Rather than passing status thru each
> layer, you raise an exception, and jump directly to the right place.

OK, that's another valid way to look at it.

But note one key point: the place you're jumping to is determined via
dynamic scoping.  It's not like Pascal, where you can goto a label
outside the current procedure, and that label has to be (statically)
visible.  An exception is a goto, but you don't know where you're
going to -- you often are going to someplace invisible at the "raise".

>> If it's a bug, should I print out useful information?  Useful to the
>> user, or useful to the programmer who wants to fix the bug (or both)?
>
> That's an upfront design decision, not a run-time decision.

My point is that this decision can be taken differently for different
clients (of the thing that raised the exception).  I agree it's
"upfront", but it's a separate design decision for each client.

>> Etc.
>
> That's always a fun word. I doubt that the things I extrapolate here
> are the same ones you do :).

What do you expect?  This is just a friendly usenet discussion.  ;-)

I plead guilty to using "etc" to mean "I want to pretend there are many
more issues, but I'm too lazy to think of any right now."  ;-)

>> Constructing a string at the "raise" point is wrong because it presumes
>> that the client wants to print a string 
>
> That is the overall design of my application, so it is correct in this
> case.
>
> Designing a library that will be used by unknown future applications,
> yet still returns truly useful information in error cases, is a very
> hard problem. 

Indeed.  It's unhelpful if the language gets in the way, though.

You made several other interesting points, but I think I'll leave it at
that -- this post is long enough.

- Bob

Re: Structured exception information

[Ray Blaak]

Stephen Leake <stephen_leake@stephe-leake.org> writes:
> Maciej Sobczak <no.spam@no.spam.com> writes:
> > Doesn't feel as type-safe as advertised.
> 
> But you have not given an actual example where a string is not
> a type-safe solution to the actual problem at hand.
> 
> The only example you have given is "present the error to the user". In
> that case, a string is precisely the correct type.

A common example I run into is to have the exception contain user-level versus
detailed information. The top exception handler will tend to present the
user-level information as a popup dialog, whereas the detailed information
will be logged for later analysis, sent out as a bug report, etc.

Often the detailed information could have various numeric values, e.g. source
locations for parse errors.

Even if both the user and detailed information are simple strings, one still
has two strings, and it is a pain to have to come up with an encoding scheme
(e.g. xml) and parse them back out when handled.

Usage should be able to be simple and direct.

> If you look into the details of "structured exception handling" in
> other languages and implementations, they have bugs, and fundamental
> flaws in design. [...]
> So if you find yourself fighting Ada to do something, you need to step
> back and think more carefully about _why_ you are doing it that way.
> Ada is telling you it is inherently unsafe.

The usage I described above is perfectly safe and bug free in all other
languages I use, even C++. 

It is also convenient.

Ada's philosophy is "correct", but the convenience can certainly be improved
in this area.

Consider also that any serialization scheme into exception strings is itself
more complex and thus more likely to be buggy.

-- 
Cheers,                                        The Rhythm is around me,
                                               The Rhythm has control.
Ray Blaak                                      The Rhythm is inside me,
rAYblaaK@STRIPCAPStelus.net                    The Rhythm has my soul.

Re: Structured exception information

[Robert A Duff]

Stephen Leake <stephen_leake@stephe-leake.org> writes:

> Lots of people expect lots of things. Sometimes, those expectations
> are unreasonable, and should be changed.

Sometimes.

>...That's what I'm trying to
> explore here; I think expecting anything other than a string for
> exception data is unreasonable. 

I don't agree.

> So far, you have presented no case to show I am wrong.

By now, several cases have been presented.  Are you convinced?

To me, it seems pretty simple: if you restrict the type of anything
(parameters, variables, exception-data) to be String, you're losing
type information.

> If you look into the details of "structured exception handling" in
> other languages and implementations, they have bugs, and fundamental
> flaws in design.

Please be more specific.

>...That is why Ada did not go that way. Ada is _much_
> more careful about getting the core design right, allowing fully
> robust and safe implementations of _all_ features, especially in
> multi-tasking and multi-processing environments.

Please explain why exceptions-as-objects causes any trouble with respect
to multi-<t&p>.

> So if you find yourself fighting Ada to do something, you need to step
> back and think more carefully about _why_ you are doing it that way.
> Ada is telling you it is inherently unsafe.

Well, I suppose I should be flattered, given that I was one of the
designers of Ada 95.  But the fact is: we made mistakes.  If Ada is
telling you "it is inherently unsafe", perhaps Ada is simply wrong.

- Bob

Re: Structured exception information

[Stephen Leake]

Robert A Duff <bobduff@shell01.TheWorld.com> writes:

> Stephen Leake <stephen_leake@stephe-leake.org> writes:
>
>> So far, you have presented no case to show I am wrong.
>
> By now, several cases have been presented.  Are you convinced?

Well, none were very detailed. 

But I agree there are times when some more structure is needed.

I'm certainly not willing to give up any of Ada's other features to
get it.

> To me, it seems pretty simple: if you restrict the type of anything
> (parameters, variables, exception-data) to be String, you're losing
> type information.

That's true. But the devil is in the details. 

>> If you look into the details of "structured exception handling" in
>> other languages and implementations, they have bugs, and fundamental
>> flaws in design.
>
> Please be more specific.

Well, I can't. I plead guilty to arguing from authority and vague
memory on this one. The memory is of discussions of problems with
various exception implementations in C++ and Java, on other
newsgroups. 

I _believe_ that if you read the discussions of attempting to add
structured exceptions to Ada, you will find these arguments.
Obviously, you are closer to that than I am.

>> So if you find yourself fighting Ada to do something, you need to step
>> back and think more carefully about _why_ you are doing it that way.
>> Ada is telling you it is inherently unsafe.
>
> Well, I suppose I should be flattered, given that I was one of the
> designers of Ada 95.  But the fact is: we made mistakes.  If Ada is
> telling you "it is inherently unsafe", perhaps Ada is simply wrong.

That's certainly possible.

But I still find it a useful approach, especially since I'm stuck with
today's Ada language :).

I look forward to proposals for safe structured exceptions in Ada 2015 :).

-- 
-- Stephe

Re: Structured exception information

[Ray Blaak]

Stephen Leake <stephen_leake@stephe-leake.org> writes:
> Robert A Duff <bobduff@shell01.TheWorld.com> writes:
> > By now, several cases have been presented.  Are you convinced?
> 
> Well, none were very detailed. 

What about mine (with the user vs "internal" detail strings)?

That forces a parsing problem, which is a pain, and potentially more buggy.

The point that Ada could improve in this area to be more convenient to the
programmer.

> > Please be more specific.
> 
> Well, I can't. I plead guilty to arguing from authority and vague
> memory on this one. The memory is of discussions of problems with
> various exception implementations in C++ and Java, on other
> newsgroups. 

These days, exceptions work well in other languages, especially in the
controlled languages like C# and Java.

"Buggy exceptions" are no longer an issue in practice.

There is no reason for Ada to be behind in this area.

-- 
Cheers,                                        The Rhythm is around me,
                                               The Rhythm has control.
Ray Blaak                                      The Rhythm is inside me,
rAYblaaK@STRIPCAPStelus.net                    The Rhythm has my soul.

Re: Structured exception information

[Stephen Leake]

Ray Blaak <rAYblaaK@STRIPCAPStelus.net> writes:

> Stephen Leake <stephen_leake@stephe-leake.org> writes:
>> Robert A Duff <bobduff@shell01.TheWorld.com> writes:
>> > By now, several cases have been presented.  Are you convinced?
>> 
>> Well, none were very detailed. 
>
> What about mine (with the user vs "internal" detail strings)?

Yes, sorry, that was well presented, and convincing.

>> Well, I can't. I plead guilty to arguing from authority and vague
>> memory on this one. The memory is of discussions of problems with
>> various exception implementations in C++ and Java, on other
>> newsgroups. 
>
> These days, exceptions work well in other languages, especially in the
> controlled languages like C# and Java.
>
> "Buggy exceptions" are no longer an issue in practice.
>
> There is no reason for Ada to be behind in this area.

Ok, I'll accept that.

-- 
-- Stephe

Re: Structured exception information

[Robert A Duff]

Stephen Leake <stephen_leake@stephe-leake.org> writes:

> I'm certainly not willing to give up any of Ada's other features to
> get it.

I think there's no need to give up anything.

>>> If you look into the details of "structured exception handling" in
>>> other languages and implementations, they have bugs, and fundamental
>>> flaws in design.
>>
>> Please be more specific.
>
> Well, I can't. I plead guilty to arguing from authority and vague
> memory on this one. The memory is of discussions of problems with
> various exception implementations in C++ and Java, on other
> newsgroups. 

OK, fair enough.

Here's my vague memory:

C++ always had finalization (destructors).  Later on, exceptions were
added.  There was much moaning and gnashing of teeth from implementers,
claiming "exceptions are hard to implement properly".

Ada always had exceptions.  Later on, finalization was added.  There
was much moaning and gnashing of teeth from implementers, claiming
"finalization is hard to implement properly".

The truth is, the interactions between exceptions and finalization are
nasty, and hard to get right.

- Bob

Re: Structured exception information

[Dmitry A. Kazakov]

On Sat, 20 Jan 2007 17:07:18 -0500, Robert A Duff wrote:

> The truth is, the interactions between exceptions and finalization are
> nasty, and hard to get right.

Yes. I wondering, isn't it the *same* problem as with Storage_Error?

I remember you had some ideas on how to approach it. Maybe it would also
work for exceptions from constructors?

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

Re: Structured exception information

[Robert A Duff]

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

> On Sat, 20 Jan 2007 17:07:18 -0500, Robert A Duff wrote:
>
>> The truth is, the interactions between exceptions and finalization are
>> nasty, and hard to get right.
>
> Yes. I wondering, isn't it the *same* problem as with Storage_Error?

Please remind me which Storage_Error problem we're talking about.

There are language problems with Storage_Error (you can't know what data
was half-baked at the point of running out of memory).  But perhaps
you're referring to something else?

> I remember you had some ideas on how to approach it. Maybe it would also
> work for exceptions from constructors?

- Bob

Re: Structured exception information

[Dmitry A. Kazakov]

On Sun, 21 Jan 2007 18:51:22 -0500, Robert A Duff wrote:

> "Dmitry A. Kazakov" <mailbox@dmitry-kazakov.de> writes:
> 
>> On Sat, 20 Jan 2007 17:07:18 -0500, Robert A Duff wrote:
>>
>>> The truth is, the interactions between exceptions and finalization are
>>> nasty, and hard to get right.
>>
>> Yes. I wondering, isn't it the *same* problem as with Storage_Error?
> 
> Please remind me which Storage_Error problem we're talking about.
>
> There are language problems with Storage_Error (you can't know what data
> was half-baked at the point of running out of memory).  But perhaps
> you're referring to something else?

It was about handling S_E. If I remember correctly it was a thread a year
or so ago, in which you started to talk about some alternative, about how
it could/should be done, but then stopped yourself with usual mantra "that
would not be Ada." (:-))

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

Re: Structured exception information

[Robert A Duff]

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

> On Sun, 21 Jan 2007 18:51:22 -0500, Robert A Duff wrote:
>
>> "Dmitry A. Kazakov" <mailbox@dmitry-kazakov.de> writes:
>> 
>>> On Sat, 20 Jan 2007 17:07:18 -0500, Robert A Duff wrote:
>>>
>>>> The truth is, the interactions between exceptions and finalization are
>>>> nasty, and hard to get right.
>>>
>>> Yes. I wondering, isn't it the *same* problem as with Storage_Error?
>> 
>> Please remind me which Storage_Error problem we're talking about.
>>
>> There are language problems with Storage_Error (you can't know what data
>> was half-baked at the point of running out of memory).  But perhaps
>> you're referring to something else?
>
> It was about handling S_E. If I remember correctly it was a thread a year
> or so ago, in which you started to talk about some alternative, about how
> it could/should be done, but then stopped yourself with usual mantra "that
> would not be Ada." (:-))

OK, I was probably talking about this:

    ...you can't know what data
    was half-baked at the point of running out of memory.

- Bob

Re: Structured exception information

[Dmitry A. Kazakov]

On Mon, 22 Jan 2007 14:02:22 -0500, Robert A Duff wrote:

> "Dmitry A. Kazakov" <mailbox@dmitry-kazakov.de> writes:
> 
>> On Sun, 21 Jan 2007 18:51:22 -0500, Robert A Duff wrote:
>>
>>> "Dmitry A. Kazakov" <mailbox@dmitry-kazakov.de> writes:
>>> 
>>>> On Sat, 20 Jan 2007 17:07:18 -0500, Robert A Duff wrote:
>>>>
>>>>> The truth is, the interactions between exceptions and finalization are
>>>>> nasty, and hard to get right.
>>>>
>>>> Yes. I wondering, isn't it the *same* problem as with Storage_Error?
>>> 
>>> Please remind me which Storage_Error problem we're talking about.
>>>
>>> There are language problems with Storage_Error (you can't know what data
>>> was half-baked at the point of running out of memory).  But perhaps
>>> you're referring to something else?
>>
>> It was about handling S_E. If I remember correctly it was a thread a year
>> or so ago, in which you started to talk about some alternative, about how
>> it could/should be done, but then stopped yourself with usual mantra "that
>> would not be Ada." (:-))
> 
> OK, I was probably talking about this:
> 
>     ...you can't know what data
>     was half-baked at the point of running out of memory.

And also about how to battle with, that it can be raised at any time in any
place.

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

Re: Structured exception information

[Brian May]

>>>>> "Stephen" == Stephen Leake <stephen_leake@stephe-leake.org> writes:

    Stephen> Why do you want to? Generally, all you can do is report
    Stephen> the error to the user.

Sorry, found this thread late.

It depends on the situation. Reporting the error is just one possible
action. There are others:

* log the error.
* display error on console.
* retry the operation.
* do something else instead.
* ignore the error.
* panic.

The more structured information the exception handler gets, it more
help it gets in deciding the proper course of action.

If it was a procedure that caused an exception, it might be able to
store some of this information for later retrieval, but if it was a
function that caused the exception, this may be harder.

Unfortunately, I cannot think of an example that isn't seriously brain
dead right now.
-- 
Brian May <bam@snoopy.apana.org.au>

Re: Structured exception information (task, ANEX E)

[Martin Krischik]

Maciej Sobczak schrieb:

> Yes, I'm asking for "throwing objects", in the C++ parlance.
> 
> How to do this in Ada?
> If I cannot - how to solve this design problem?

I believe this was skipped in Ada because of ANEX E and task types. You 
must understand that Ada exceptions quite often propagated across thread 
borders and sometimes - if ANEX E is implemented - over a network 
connections to another computer.

I do not say this is impossible but it could be quite expensive 
performance wise.

Martin

Re: Structured exception information (task, ANEX E)

[Randy Brukardt]

"Martin Krischik" <krischik@users.sourceforge.net> wrote in message
news:45acd36e$1@news.post.ch...
> Maciej Sobczak schrieb:
>
> > Yes, I'm asking for "throwing objects", in the C++ parlance.
> >
> > How to do this in Ada?
> > If I cannot - how to solve this design problem?
>
> I believe this was skipped in Ada because of ANEX E and task types. You
> must understand that Ada exceptions quite often propagated across thread
> borders and sometimes - if ANEX E is implemented - over a network
> connections to another computer.
>
> I do not say this is impossible but it could be quite expensive
> performance wise.

Possibly, but that's easily solved (now) by requiring any such types to
support external streaming. The problem was that we didn't have the concept
of external streaming at the time that we considered extra information for
exceptions (the language had it, but it wasn't defined consistently and it
didn't have a name).

I suspect it would be quite a bit easier to define now than it was in 2002
(although there would certainly be some gotcha).

                             Randy.

Re: Structured exception information (task, ANEX E)

[Robert A Duff]

Martin Krischik <krischik@users.sourceforge.net> writes:

> Maciej Sobczak schrieb:
>
>> Yes, I'm asking for "throwing objects", in the C++ parlance.
>> How to do this in Ada?
>> If I cannot - how to solve this design problem?
>
> I believe this was skipped in Ada because of ANEX E and task types.

I don't see any problems there.

>...You
> must understand that Ada exceptions quite often propagated across thread
> borders and sometimes - if ANEX E is implemented - over a network
> connections to another computer.
>
> I do not say this is impossible but it could be quite expensive
> performance wise.

Efficiency is irrelevant to language design.  You should never leave a
feature out merely because it's slow.  What matters is distributed
overhead, and I see none here.  Yes, if an exception propagates across a
network, you have to ship all the data across the network.  The
programmer controls how much data that is, so it's not a problem.
Besides, shipping a String is no more efficient than shipping properly
typed data.

Many other languages have solved this problem (even in the presence of
threads and distributed systems).  The obvious solution is that what Ada
calls "exception" should be a type (derived from Root_Exception), and
what Ada calls "exception occurrence" should be an object of that type.
This language design is much simpler than Ada's, because we don't need
a bunch of separate concepts, with their own special rules -- just reuse
the concepts of type and object.

The 200-character limit was a mistake, by the way.  It was based on
fictitious implementation difficulties.  Ada already has functions
that return results whose size is not known at the call site (e.g.
"return String").  The same memory-management techniques would apply to
arbitrary-sized exception occurrences.

- Bob

Re: Structured exception information (task, ANEX E)

[Martin Krischik]

Robert A Duff schrieb:
> Martin Krischik <krischik@users.sourceforge.net> writes:
> 
>> Maciej Sobczak schrieb:
>>
>>> Yes, I'm asking for "throwing objects", in the C++ parlance.
>>> How to do this in Ada?
>>> If I cannot - how to solve this design problem?
>> I believe this was skipped in Ada because of ANEX E and task types.
> 
> I don't see any problems there.
> 
>> ...You
>> must understand that Ada exceptions quite often propagated across thread
>> borders and sometimes - if ANEX E is implemented - over a network
>> connections to another computer.
>>
>> I do not say this is impossible but it could be quite expensive
>> performance wise.
> 
> Efficiency is irrelevant to language design.  You should never leave a
> feature out merely because it's slow.  What matters is distributed
> overhead, and I see none here.  Yes, if an exception propagates across a
> network, you have to ship all the data across the network.  The
> programmer controls how much data that is, so it's not a problem.
> Besides, shipping a String is no more efficient than shipping properly
> typed data.

Realy? How about access types? C++ allows access types inside exceptions.

> Many other languages have solved this problem (even in the presence of
> threads and distributed systems).

A Weblogic Server just converts the exception into ...UserException or 
...SystemException and then adds the old exception name as string. Any 
"structured exception information" beeing stripped before propagation.

What a great solution.

> The 200-character limit was a mistake, by the way.  It was based on
> fictitious implementation difficulties.  Ada already has functions
> that return results whose size is not known at the call site (e.g.
> "return String").  The same memory-management techniques would apply to
> arbitrary-sized exception occurrences.

And it is optional - a implementation is free to do it better.

Martin

Re: Structured exception information (task, ANEX E)

[Robert A Duff]

Martin Krischik <krischik@users.sourceforge.net> writes:

> Robert A Duff schrieb:
>> Besides, shipping a String is no more efficient than shipping properly
>> typed data.
>
> Realy? How about access types? C++ allows access types inside exceptions.

The programmer has a choice: Don't use access types, or write streaming
operations for types containing access types.  The same is true for
parameter passing.  I don't see the problem.

>> The 200-character limit was a mistake, by the way.  It was based on
>> fictitious implementation difficulties.  Ada already has functions
>> that return results whose size is not known at the call site (e.g.
>> "return String").  The same memory-management techniques would apply to
>> arbitrary-sized exception occurrences.
>
> And it is optional - a implementation is free to do it better.

True, but that's not much help to the Ada programmer -- 200 is all you
can count on.  I'm not a big fan of optional features...

- Bob

Re: Structured exception information

[Alex R. Mosteo]

Maciej Sobczak wrote:

> BTW - How can I ensure in a general way that the constructor function
> must be used to initialize the object, otherwise compile-time error is
> reported?

> If I make My_Type a discriminated type (so that the discriminant value
> is used in the default initialization), does it limit anything, like
> constructor parameter types?

You can use a fake discriminant this way:

package ...

   type Blah (<>) is private;

private

   type Blah is ...;

end

That is, you say to the world that the type has discriminants, so it can't
be declared uninitialized. Internally, you don't have discriminants nor any
limitation derived from them. 

Re: Structured exception information

[Jeffrey Carter]

Applying the KISS principle, I'd think the way to do this would be

with Ada.Exceptions;
generic -- Exceptions_With_Info
    type Problem_Info (<>) is limited private;

    with function Image (Value : Problem_Info) return String;
    with function Value (Image : String) return Problem_Info;
package Exceptions_With_Info is
    procedure Raise_With_Info (ID   : in Ada.Exceptions.Exception_ID;
                               Info : in Problem_Info);

    procedure Raise_With_Info
       (Occurrence : in Ada.Exceptions.Exception_Occurrence;
        Info       : in Problem_Info);

    function Info (Occurrence : Ada.Exceptions.Exception_Occurrence)
    return Problem_Info;
end Exceptions_With_Info;

Re: Structured exception information

[Duncan Sands]

On Tuesday 16 January 2007 19:07, Jeffrey Carter wrote:
> Applying the KISS principle, I'd think the way to do this would be
> 
> with Ada.Exceptions;
> generic -- Exceptions_With_Info
>     type Problem_Info (<>) is limited private;
> 
>     with function Image (Value : Problem_Info) return String;
>     with function Value (Image : String) return Problem_Info;
> package Exceptions_With_Info is
>     procedure Raise_With_Info (ID   : in Ada.Exceptions.Exception_ID;
>                                Info : in Problem_Info);
> 
>     procedure Raise_With_Info
>        (Occurrence : in Ada.Exceptions.Exception_Occurrence;
>         Info       : in Problem_Info);
> 
>     function Info (Occurrence : Ada.Exceptions.Exception_Occurrence)
>     return Problem_Info;
> end Exceptions_With_Info;

The maximum length of an exception message is 200 for GNAT.

Best wishes,

Duncan.