* Re: Ada exception block does NOT work?
2005-08-18 8:44 ` Maciej Sobczak
@ 2005-08-18 11:40 ` Jean-Pierre Rosen
2005-08-18 12:56 ` Maciej Sobczak
2005-08-18 13:15 ` Alex R. Mosteo
2005-08-18 16:13 ` Jeffrey Carter
` (3 subsequent siblings)
4 siblings, 2 replies; 78+ messages in thread
From: Jean-Pierre Rosen @ 2005-08-18 11:40 UTC (permalink / raw)
Maciej Sobczak a �crit :
> Jeffrey R. Carter wrote:
>
>> Ada has had exceptions, well integrated with the rest of the language,
>> since Ada 80. Ada's terminology is that exceptions are raised and
>> handled.
>
>
> OK, but the question is not about terminology, really.
>
> If you claim that exceptions were "patched" on to the C++ language that
> did not have them originally, then let's switch the context to other
> language that has no history issue like this.
There are no predefined exceptions in C++, therefore things like
arithmetic overflow have undefined semantics, rather than raising an
exception
[...]
> Why do you claim that Ada's exceptions are "better integrated into the
> language than in the languages that throw and catch them"?
Every sequence of statements can have an exception handler in Ada, while
in C++/Java/C# you must add an extra level of nesting. This gives the
feeling that dealing with exceptions is something you just put in very
special places, while in Ada you are more inclined to considering
exceptions everywhere.
> Note that those other languages can throw regular objects as exceptions,
> thus enabling polymorphism when they are handled. One could say that
> *this* is the point of good integration and that Ada's exceptions are a
> conceptual patch that did not integrate with the rest of the object
> model, leading to two separate spaces of language entities instead of
> only one.
This boils down to the (controversial) question of how much information
should be associated to an exception. It could be the programmer's
responsibility to store the context when an exception is raised, rather
than propagating it with the exception. In Ada83, an exception had just
an identity, and Jean Ichbiah (the father of Ada) claimed that he
regretted having more than one exception. In Ada95, a string can be
associated to an exception. In C++, any object can be thrown, while in
Java only an object belonging to the throwable class. Note also that
augmenting the quantity of information associated to an exception has a
performance cost, which may be important for a real-time oriented
language like Ada. So, you see the question is quite open...
--
---------------------------------------------------------
J-P. Rosen (rosen@adalog.fr)
Visit Adalog's web site at http://www.adalog.fr
^ permalink raw reply [flat|nested] 78+ messages in thread
* Re: Ada exception block does NOT work?
2005-08-18 11:40 ` Jean-Pierre Rosen
@ 2005-08-18 12:56 ` Maciej Sobczak
2005-08-18 14:42 ` Jean-Pierre Rosen
2005-08-18 18:03 ` Martin Krischik
2005-08-18 13:15 ` Alex R. Mosteo
1 sibling, 2 replies; 78+ messages in thread
From: Maciej Sobczak @ 2005-08-18 12:56 UTC (permalink / raw)
Jean-Pierre Rosen wrote:
> There are no predefined exceptions in C++
There are.
In particular, creating a new object on the free store can result in
failure due to inability of the system to allocate memory. This is how
you create new object on the free store:
int *p1 = new int;
MyType *p2 = new MyType();
etc.
In case of memory allocation error, the above will result in the
std::bad_alloc exception being thrown.
This is predefined and standard exception in C++.
> therefore things like
> arithmetic overflow have undefined semantics
The "therefore" part above is not correct. Since there *are* predefined
exceptions in C++, dealing with arithmetic anomalies certainly was based
on other, unrelated policies.
Whether this is good or bad in any particular context is another issue.
>> Why do you claim that Ada's exceptions are "better integrated into the
>> language than in the languages that throw and catch them"?
>
> Every sequence of statements can have an exception handler in Ada, while
> in C++/Java/C# you must add an extra level of nesting.
You add the nesting if you want to handle the exception. If you don't
want to handle it, you don't add the nesting. This is rather the result
of having a *pair* of parentheses to denote a block, with no sensible
way of extending this punctuation. In Ada, "begin" and "end" are not a
closed pair and are easier to extend with any other keyword, thus making
a "comb" of arbitrary length. But this is a syntax issue.
I treat Ada's "begin" as having implicit "try" if there is any handler
downstream. Is there anything inherently wrong in this?
> This gives the
> feeling that dealing with exceptions is something you just put in very
> special places, while in Ada you are more inclined to considering
> exceptions everywhere.
But then we will drift to discuss whether it makes sense to deal with
exceptions everywhere or maybe only where the actual handler has
something to do. I haven't seen enough real Ada code to have any opinion
what is good in the Ada context.
Don't you do this:
begin
-- ...
Some_Procedure_That_Might_Raise;
-- ...
end;
and just let the exception (if any) travel up the chain to where there
is enough context to actually *do* somethng with the exception?
>> Note that those other languages can throw regular objects as
>> exceptions
>
> This boils down to the (controversial) question of how much information
> should be associated to an exception.
[...]
> So, you see the question is quite open...
Yes, it is and I understand the concerns you mention. But I'm still not
sure about the "integration with the language" issue. In what way the
Ada exceptions are more integrated with the language than the C++
exceptions (or take any other language from the "throwing" family)?
--
Maciej Sobczak : http://www.msobczak.com/
Programming : http://www.msobczak.com/prog/
^ permalink raw reply [flat|nested] 78+ messages in thread
* Re: Ada exception block does NOT work?
2005-08-18 12:56 ` Maciej Sobczak
@ 2005-08-18 14:42 ` Jean-Pierre Rosen
2005-08-18 18:03 ` Martin Krischik
1 sibling, 0 replies; 78+ messages in thread
From: Jean-Pierre Rosen @ 2005-08-18 14:42 UTC (permalink / raw)
Maciej Sobczak a �crit :
> Jean-Pierre Rosen wrote:
>
>> There are no predefined exceptions in C++
>
>
> There are.
Certainly depends on which version of C++. I am happy to learn that they
eventually made it, but still the language hasn't been designed with
exceptions in mind.
>> therefore things like arithmetic overflow have undefined semantics
>
>
> The "therefore" part above is not correct. Since there *are* predefined
> exceptions in C++, dealing with arithmetic anomalies certainly was based
> on other, unrelated policies.
At the time where this policy was decided, there was no exceptions at
all. I guess that changing this to raising exceptions would have been
too incompatible.
>> Every sequence of statements can have an exception handler in Ada,
>> while in C++/Java/C# you must add an extra level of nesting.
>
>
> You add the nesting if you want to handle the exception. If you don't
> want to handle it, you don't add the nesting. This is rather the result
> of having a *pair* of parentheses to denote a block, with no sensible
> way of extending this punctuation. In Ada, "begin" and "end" are not a
> closed pair and are easier to extend with any other keyword, thus making
> a "comb" of arbitrary length. But this is a syntax issue.
>
> I treat Ada's "begin" as having implicit "try" if there is any handler
> downstream. Is there anything inherently wrong in this?
Well, in C++ you pretty well need to know precisely what code will raise
which exception. That's what the syntax says; "try" means: I know that
the following code may fail (and conversely, without a "try", I assume
it may not fail). Ada is more oriented towards "expecting the
unexpected". That's what I meant with the sentence below:
>> This gives the feeling that dealing with exceptions is something you
>> just put in very special places, while in Ada you are more inclined to
>> considering exceptions everywhere.
>
>
> But then we will drift to discuss whether it makes sense to deal with
> exceptions everywhere or maybe only where the actual handler has
> something to do. I haven't seen enough real Ada code to have any opinion
> what is good in the Ada context.
> Don't you do this:
>
> begin
> -- ...
> Some_Procedure_That_Might_Raise;
> -- ...
> end;
>
> and just let the exception (if any) travel up the chain to where there
> is enough context to actually *do* somethng with the exception?
Of course.
--
---------------------------------------------------------
J-P. Rosen (rosen@adalog.fr)
Visit Adalog's web site at http://www.adalog.fr
^ permalink raw reply [flat|nested] 78+ messages in thread
* Re: Ada exception block does NOT work?
2005-08-18 12:56 ` Maciej Sobczak
2005-08-18 14:42 ` Jean-Pierre Rosen
@ 2005-08-18 18:03 ` Martin Krischik
1 sibling, 0 replies; 78+ messages in thread
From: Martin Krischik @ 2005-08-18 18:03 UTC (permalink / raw)
Maciej Sobczak wrote:
> In case of memory allocation error, the above will result in the
> std::bad_alloc exception being thrown.
> This is predefined and standard exception in C++.
True but again: In C++ bolted on later (even after exceptions have been
bolted on) in Ada it had been there from day 1.
Martin
--
mailto://krischik@users.sourceforge.net
Ada programming at: http://ada.krischik.com
^ permalink raw reply [flat|nested] 78+ messages in thread
* Re: Ada exception block does NOT work?
2005-08-18 11:40 ` Jean-Pierre Rosen
2005-08-18 12:56 ` Maciej Sobczak
@ 2005-08-18 13:15 ` Alex R. Mosteo
2005-08-18 15:23 ` Dmitry A. Kazakov
2005-08-18 18:00 ` Martin Krischik
1 sibling, 2 replies; 78+ messages in thread
From: Alex R. Mosteo @ 2005-08-18 13:15 UTC (permalink / raw)
Jean-Pierre Rosen wrote:
> Maciej Sobczak a �crit :
>> Note that those other languages can throw regular objects as
>> exceptions, thus enabling polymorphism when they are handled. One
>> could say that *this* is the point of good integration and that Ada's
>> exceptions are a conceptual patch that did not integrate with the rest
>> of the object model, leading to two separate spaces of language
>> entities instead of only one.
>
> This boils down to the (controversial) question of how much information
> should be associated to an exception. It could be the programmer's
> responsibility to store the context when an exception is raised, rather
> than propagating it with the exception. In Ada83, an exception had just
> an identity, and Jean Ichbiah (the father of Ada) claimed that he
> regretted having more than one exception. In Ada95, a string can be
> associated to an exception. In C++, any object can be thrown, while in
> Java only an object belonging to the throwable class. Note also that
> augmenting the quantity of information associated to an exception has a
> performance cost, which may be important for a real-time oriented
> language like Ada. So, you see the question is quite open...
I think the crux in this last point: you don't want that, once an
exception is being raised, you fail to propagate it because it can't be
allocated due to exhausted memory, for example. I suppose this can
happen in any language which allows propagation of arbitrary objects,
though I don't have experience in this scenary and its side effects. In
Ada, one can argue that being the exception a special feature with known
and limited form, can't have this kind of failure (which is important
since exceptions are raised mostly when error conditions arise). I see
in the RM that there's a permission for an implementation to truncate
the message associated with any exception, could be this the reason?
I suppose this can be mitigated if some "raw" exception is always
propagable when everything else fails. In that case, failing to allocate
the proper exception could raise this "raw" other, and we would be in
equal terms (almost) with Ada. Well, I'm speculating but would be
definitely interested in hearing more from someone more informed.
--
Take the Snape polls: http://snape.mosteo.com [Updated 16/05]
^ permalink raw reply [flat|nested] 78+ messages in thread
* Re: Ada exception block does NOT work?
2005-08-18 13:15 ` Alex R. Mosteo
@ 2005-08-18 15:23 ` Dmitry A. Kazakov
2005-08-18 18:00 ` Martin Krischik
1 sibling, 0 replies; 78+ messages in thread
From: Dmitry A. Kazakov @ 2005-08-18 15:23 UTC (permalink / raw)
On Thu, 18 Aug 2005 15:15:14 +0200, Alex R. Mosteo wrote:
> Jean-Pierre Rosen wrote:
>> Maciej Sobczak a �crit :
>
>>> Note that those other languages can throw regular objects as
>>> exceptions, thus enabling polymorphism when they are handled. One
>>> could say that *this* is the point of good integration and that Ada's
>>> exceptions are a conceptual patch that did not integrate with the rest
>>> of the object model, leading to two separate spaces of language
>>> entities instead of only one.
>>
>> This boils down to the (controversial) question of how much information
>> should be associated to an exception. It could be the programmer's
>> responsibility to store the context when an exception is raised, rather
>> than propagating it with the exception. In Ada83, an exception had just
>> an identity, and Jean Ichbiah (the father of Ada) claimed that he
>> regretted having more than one exception. In Ada95, a string can be
>> associated to an exception. In C++, any object can be thrown, while in
>> Java only an object belonging to the throwable class. Note also that
>> augmenting the quantity of information associated to an exception has a
>> performance cost, which may be important for a real-time oriented
>> language like Ada. So, you see the question is quite open...
>
> I think the crux in this last point: you don't want that, once an
> exception is being raised, you fail to propagate it because it can't be
> allocated due to exhausted memory, for example.
Another problem is that the type of the exception object may leave its
scope while exception propagation. It might not be the case in C++ which
has it global, but it is in Ada.
--
Regards,
Dmitry A. Kazakov
http://www.dmitry-kazakov.de
^ permalink raw reply [flat|nested] 78+ messages in thread
* Re: Ada exception block does NOT work?
2005-08-18 13:15 ` Alex R. Mosteo
2005-08-18 15:23 ` Dmitry A. Kazakov
@ 2005-08-18 18:00 ` Martin Krischik
1 sibling, 0 replies; 78+ messages in thread
From: Martin Krischik @ 2005-08-18 18:00 UTC (permalink / raw)
Alex R. Mosteo wrote:
> I see
> in the RM that there's a permission for an implementation to truncate
> the message associated with any exception, could be this the reason?
In Ada an exception may need to be send over the network to another
computer. Read the dreaded Annex E for details:
http://www.adaic.com/standards/95lrm/html/RM-E.html
But even without Annex E - exceptions inside a rendezvous need to be raised
in both threads and exceptions raised inside the thread initialisation is
transfered from the newly created thread to the creating thread - a thread
which failed to initialise can't handle an exception and somebody has to.
Martin
--
mailto://krischik@users.sourceforge.net
Ada programming at: http://ada.krischik.com
^ permalink raw reply [flat|nested] 78+ messages in thread
* Re: Ada exception block does NOT work?
2005-08-18 8:44 ` Maciej Sobczak
2005-08-18 11:40 ` Jean-Pierre Rosen
@ 2005-08-18 16:13 ` Jeffrey Carter
2005-08-18 16:38 ` Hyman Rosen
2005-08-18 17:54 ` Martin Krischik
` (2 subsequent siblings)
4 siblings, 1 reply; 78+ messages in thread
From: Jeffrey Carter @ 2005-08-18 16:13 UTC (permalink / raw)
Maciej Sobczak wrote:
>
> Why do you claim that Ada's exceptions are "better integrated into the
> language than in the languages that throw and catch them"?
The core of C++ was designed before exceptions were added to the
language, so the main part of the language is not designed with
exceptions in mind. Ada's design included exceptions from the beginning,
and exceptions are part of the definition of the semantics of all parts
of the language. That's the basis of the claim.
This appears in different ways, which considered independently may not
be sufficiently compelling as support for the claim. The try/catch block
is one such symptom. That the C++ core language tends to have
undefined/implementation-defined semantics where Ada has semantics
defined in terms of exceptions is another.
Other C descendants seem to have adopted C++'s exception handling syntax
and semantics, with varying degrees of back fitting to the core language.
> Note that those other languages can throw regular objects as exceptions,
> thus enabling polymorphism when they are handled. One could say that
> *this* is the point of good integration and that Ada's exceptions are a
> conceptual patch that did not integrate with the rest of the object
> model, leading to two separate spaces of language entities instead of
> only one.
The idea that disparate concepts should be implemented using a single
mechanism is generally a poor one. Not everything should be viewed as a
number; not everything should be viewed as an object; not everything
should be implemented with inheritance and dispatching; not everything
should be implemented with tasks and protected objects.
On a more concrete level, Ada's was initially intended for critical,
real-time, embedded SW. Allowing an arbitrary object to be used
as/associated with an exception in such systems may not be a good idea.
Additionally, Ada allows nested scopes, which C and its descendants do
not. This allows the existence of anonymous exceptions, exceptions that
have propagated out of the scope of their definitions. Allowing
arbitrary objects as/associated with exceptions gives rise to a similar
set of problems as allowing type extensions at a deeper scope than the
parent.
--
Jeffrey Carter
"Now go away or I shall taunt you a second time."
Monty Python and the Holy Grail
E-mail: jeffrey_r_carter-nr [commercial-at]
raytheon [period | full stop] com
^ permalink raw reply [flat|nested] 78+ messages in thread
* Re: Ada exception block does NOT work?
2005-08-18 16:13 ` Jeffrey Carter
@ 2005-08-18 16:38 ` Hyman Rosen
2005-08-18 18:07 ` jimmaureenrogers
2005-08-19 14:58 ` Robert A Duff
0 siblings, 2 replies; 78+ messages in thread
From: Hyman Rosen @ 2005-08-18 16:38 UTC (permalink / raw)
Jeffrey Carter wrote:
> The try/catch block is one such symptom.
No. It would have been perfectly possible to not have
'try' at all, and simply allow a sequence of catch
clauses to follow any statement. Bjarne Stroustrup
addresses this explicitly in _The Design and Evolution
of C++_. The problem was that the resulting code looked
ambiguous and difficult to understand. Having explicit
try and a brace-enclosed section enhanced readability.
> That the C++ core language tends to have undefined/
> implementation-defined semantics where Ada has semantics
> defined in terms of exceptions is another.
The designers of C++ simply followed the lead of their
parent language in not checking certain core operations.
The choice was made not to check, so debating which
mechanism would not be used to not report the error is
silly. Where C++ does require checks, generally exceptions
are raised on failure. (Formatted I/O allows the choice to
silently fail subsequent operations once one fails, and
then to check once for failure at the end.)
> On a more concrete level, Ada's was initially intended for critical,
> real-time, embedded SW. Allowing an arbitrary object to be used
> as/associated with an exception in such systems may not be a good idea.
But as we know from SPARK, use of Ada in such environments
generally involves throwing away much of the existing language.
Therefore I do not find this to be a valid argument.
> Additionally, Ada allows nested scopes, which C and its descendants do
> not. This allows the existence of anonymous exceptions, exceptions that
> have propagated out of the scope of their definitions. Allowing
> arbitrary objects as/associated with exceptions gives rise to a similar
> set of problems as allowing type extensions at a deeper scope than the
> parent.
Yes, that's a much better argument. It puts the cause squarely on
other aspects of Ada's design rather than harrumphing and handwaving.
By the way, it's not correct to say that Ada allows nested scopes and
C-like languages do not. The problem here is that in Ada types are
dynamic while in C-like languages all types are static regardless of
the scope in which they are defined. So in those languages, there is
no concept of an object being able to outlive its type, and thus no
problem with throwing it out of the scope in which the type was defined.
^ permalink raw reply [flat|nested] 78+ messages in thread
* Re: Ada exception block does NOT work?
2005-08-18 16:38 ` Hyman Rosen
@ 2005-08-18 18:07 ` jimmaureenrogers
2005-08-18 18:44 ` Hyman Rosen
2005-08-19 17:48 ` Martin Krischik
2005-08-19 14:58 ` Robert A Duff
1 sibling, 2 replies; 78+ messages in thread
From: jimmaureenrogers @ 2005-08-18 18:07 UTC (permalink / raw)
Hyman Rosen wrote:
> Yes, that's a much better argument. It puts the cause squarely on
> other aspects of Ada's design rather than harrumphing and handwaving.
> By the way, it's not correct to say that Ada allows nested scopes and
> C-like languages do not. The problem here is that in Ada types are
> dynamic while in C-like languages all types are static regardless of
> the scope in which they are defined. So in those languages, there is
> no concept of an object being able to outlive its type, and thus no
> problem with throwing it out of the scope in which the type was defined.
Please describe how you believe that Ada types are dynamic. I am not
clear
that I understand your use of the term.
Jim Rogers
^ permalink raw reply [flat|nested] 78+ messages in thread
* Re: Ada exception block does NOT work?
2005-08-18 18:07 ` jimmaureenrogers
@ 2005-08-18 18:44 ` Hyman Rosen
2005-08-18 20:52 ` Frank J. Lhota
2005-08-19 0:57 ` jimmaureenrogers
2005-08-19 17:48 ` Martin Krischik
1 sibling, 2 replies; 78+ messages in thread
From: Hyman Rosen @ 2005-08-18 18:44 UTC (permalink / raw)
jimmaureenrogers@worldnet.att.net wrote:
> Please describe how you believe that Ada types are dynamic.
Ada types incorporate values that depend upon runtime values.
Array size is probably the simplest example - you can declare
an array inside a procedure whose size is determined by a
parameter to that procedure. I don't know Ada, but I'm pretty
sure that you can also have types whose discriminants are set
using values determined at runtime. As such, Ada types require
local storage (in principle) for their representation, and it
makes sense to free that storage once the scope in which the
type is declared is exited. C++ types never depend on runtime
values - they are always fully determined at compile time.
^ permalink raw reply [flat|nested] 78+ messages in thread
* Re: Ada exception block does NOT work?
2005-08-18 18:44 ` Hyman Rosen
@ 2005-08-18 20:52 ` Frank J. Lhota
2005-08-19 0:57 ` jimmaureenrogers
1 sibling, 0 replies; 78+ messages in thread
From: Frank J. Lhota @ 2005-08-18 20:52 UTC (permalink / raw)
Hyman Rosen wrote:
> Ada types incorporate values that depend upon runtime values.
> Array size is probably the simplest example - you can declare
> an array inside a procedure whose size is determined by a
> parameter to that procedure. I don't know Ada, but I'm pretty
> sure that you can also have types whose discriminants are set
> using values determined at runtime. As such, Ada types require
> local storage (in principle) for their representation, and it
> makes sense to free that storage once the scope in which the
> type is declared is exited. C++ types never depend on runtime
> values - they are always fully determined at compile time.
>
It is true that C++ types are static, but it is still possible to have
scope problems with C++ exceptions, for example:
class CBadException
{
public:
int& m_Count;
CBadException (int& Count) : m_Count (Count) {}
};
void foo ()
{
int Count;
CBadException Expt (Count);
throw Expt; // Expt now references Count,
// which is going out of scope
}
--
"All things extant in this world,
Gods of Heaven, gods of Earth,
Let everything be as it should be;
Thus shall it be!"
- Magical chant from "Magical Shopping Arcade Abenobashi"
"Drizzle, Drazzle, Drozzle, Drome,
Time for the this one to come home!"
- Mr. Lizard from "Tutor Turtle"
^ permalink raw reply [flat|nested] 78+ messages in thread
* Re: Ada exception block does NOT work?
2005-08-18 18:44 ` Hyman Rosen
2005-08-18 20:52 ` Frank J. Lhota
@ 2005-08-19 0:57 ` jimmaureenrogers
2005-08-19 7:52 ` Dmitry A. Kazakov
2005-08-19 14:41 ` Robert A Duff
1 sibling, 2 replies; 78+ messages in thread
From: jimmaureenrogers @ 2005-08-19 0:57 UTC (permalink / raw)
Hyman Rosen wrote:
> jimmaureenrogers@worldnet.att.net wrote:
> > Please describe how you believe that Ada types are dynamic.
>
> Ada types incorporate values that depend upon runtime values.
> Array size is probably the simplest example - you can declare
> an array inside a procedure whose size is determined by a
> parameter to that procedure. I don't know Ada, but I'm pretty
> sure that you can also have types whose discriminants are set
> using values determined at runtime. As such, Ada types require
> local storage (in principle) for their representation, and it
> makes sense to free that storage once the scope in which the
> type is declared is exited. C++ types never depend on runtime
> values - they are always fully determined at compile time.
Ada types are also fully determined at compile time.
An unconstrained array type may have instances of different
lengths, but the type does not change. Likewise, a discriminant
type can have separate instances with different structures, but the
type is fixed at compile time.
C++ does not allow the definition of an array type in the sense
that it is defined in Ada. The typedef reserved word does not
create or designate a unique type. It only provides an alias or
alternate name for a type.
Ada types do not require any storage. Instances of types require
storage. In C++ a class with no static members requires no storage.
Each instance of that class requires its own separate storage. C++
variables may have scoping rules. Ada variables have scoping rules.
The rules are somewhat different, but the concepts are similar.
In C++ you can use a pointer to pass an array instance by reference.
The size of the array passed is determined at run-time. Ada allows
the definition of an unconstrained array type. Such a type can be
used as the parameter for a procedure or function. Each instance
of an unconstrained type must be constrained. The size of the
instance passed to an function or procedure may be determined at
run-time.
Ada also allows the definition of constrained array types. All
instances on a constrained array type have the same number of elements.
The size of all such instances is determined at compile time.
Except for classes, the C++ type system is relatively weak, and
is very similar to the C type system. Both C, and C++ provide a
wealth of implicit conversions between primitive types. This
makes the type system to appear much more dynamic than the Ada
type system. Ada provides no implicit conversions between types.
Ada's type system is both very strong and static.
You can declare local Ada types in internal blocks, according to
the values of variables:
procedure New_Type(Min, Max : Integer) is
type Local_Type is range Min..Max;
begin
for I in Local_Type'range loop
Put_Line(Local_type'Image(I));
end loop;
end New_Type;
Each time the procedure New_Type is executed Local_Type is
redefined. Local_Type has a scope only within the procedure
New_Type. If Min is greater than Max Local_Type will have a
null value range. This is not a case of a dynamic type.
It is an example of Ada elaboration. The declarative part of
the procedure New_Type is elaborated each time the procedure
is called, before execution of the body of the procedure
occurs.
Quoting from the Ada Language Reference Manual section 3.2.1:
The elaboration of a full_type_declaration consists of the elaboration
of the full type definition. Each elaboration of a full type definition
creates a distinct type and its first subtype.
This means that the type does not mutate from one call of the
procedure to another. Separate, distinct types are declared with
a lifetime controlled by the scope of their definition.
Jim Rogers
^ permalink raw reply [flat|nested] 78+ messages in thread
* Re: Ada exception block does NOT work?
2005-08-19 0:57 ` jimmaureenrogers
@ 2005-08-19 7:52 ` Dmitry A. Kazakov
2005-08-19 14:41 ` Robert A Duff
1 sibling, 0 replies; 78+ messages in thread
From: Dmitry A. Kazakov @ 2005-08-19 7:52 UTC (permalink / raw)
On 18 Aug 2005 17:57:47 -0700, jimmaureenrogers@worldnet.att.net wrote:
> Quoting from the Ada Language Reference Manual section 3.2.1:
>
> The elaboration of a full_type_declaration consists of the elaboration
> of the full type definition. Each elaboration of a full type definition
> creates a distinct type and its first subtype.
Which means exactly that types in Ada are dynamic.
> This means that the type does not mutate from one call of the
> procedure to another. Separate, distinct types are declared with
> a lifetime controlled by the scope of their definition.
Which was the point. Types in Ada have scopes, this is why they are
dynamic.
[ Mutability is an independent issue. First Ada does not have types as
first-class objects, so it is not very accurate to talk about them in the
context of mutable or not "types variables". Though because they are not
objects, there is also no way no change any "types variable". If they were
objects then highly probably limited ones. ]
--
Regards,
Dmitry A. Kazakov
http://www.dmitry-kazakov.de
^ permalink raw reply [flat|nested] 78+ messages in thread
* Re: Ada exception block does NOT work?
2005-08-19 0:57 ` jimmaureenrogers
2005-08-19 7:52 ` Dmitry A. Kazakov
@ 2005-08-19 14:41 ` Robert A Duff
1 sibling, 0 replies; 78+ messages in thread
From: Robert A Duff @ 2005-08-19 14:41 UTC (permalink / raw)
"jimmaureenrogers@worldnet.att.net" <jimmaureenrogers@worldnet.att.net> writes:
> Ada types do not require any storage. Instances of types require
> storage.
Well, *subtypes* require storage, which is really what matters for
Hymen's point.
> Ada also allows the definition of constrained array types. All
> instances on a constrained array type have the same number of elements.
> The size of all such instances is determined at compile time.
No, actually, it can be determined at run time. For example:
type Index is new Integer range 1..F(X);
type T is array(Index) of Character;
where F(X) is a function call that reads from the keyboard.
All objects of type T have the same length, but that length
is not known at compile time.
Actually, there is one obscure exception:
X: T := ...;
Mid: Index := ...;
X := X(Mid+1..X'Last) & X(X'First..Mid);
There are two intermediate results that have other lengths.
OK, OK, that's a nit. ;-)
> ...Ada provides no implicit conversions between types.
It does, but they're less error prone than those of C++.
> Ada's type system is both very strong and static.
Well, Ada does lots of checks at run time. They're not called "type
checks", but if they were, would that make the language less safe?
Would it mean Ada does dynamic type checking?
> You can declare local Ada types in internal blocks, according to
> the values of variables:
>
> procedure New_Type(Min, Max : Integer) is
> type Local_Type is range Min..Max;
That's illegal. Min and Max must be static. However, you could
say:
type Local_Type is new Integer range Min..Max;
- Bob
^ permalink raw reply [flat|nested] 78+ messages in thread
* Re: Ada exception block does NOT work?
2005-08-18 18:07 ` jimmaureenrogers
2005-08-18 18:44 ` Hyman Rosen
@ 2005-08-19 17:48 ` Martin Krischik
1 sibling, 0 replies; 78+ messages in thread
From: Martin Krischik @ 2005-08-19 17:48 UTC (permalink / raw)
jimmaureenrogers@worldnet.att.net wrote:
> Please describe how you believe that Ada types are dynamic. I am not
> clear
> that I understand your use of the term.
Just a few examples:
http://en.wikibooks.org/wiki/Ada_Programming/Types/array#With_unknown_subrange
http://en.wikibooks.org/wiki/Ada_Programming/Strings#Fixed-length_string_handling
Martin
--
mailto://krischik@users.sourceforge.net
Ada programming at: http://ada.krischik.com
^ permalink raw reply [flat|nested] 78+ messages in thread
* Re: Ada exception block does NOT work?
2005-08-18 16:38 ` Hyman Rosen
2005-08-18 18:07 ` jimmaureenrogers
@ 2005-08-19 14:58 ` Robert A Duff
1 sibling, 0 replies; 78+ messages in thread
From: Robert A Duff @ 2005-08-19 14:58 UTC (permalink / raw)
"Hyman Rosen" <hyman.rosen@gmail.com> writes:
> Jeffrey Carter wrote:
> > The try/catch block is one such symptom.
>
> No. It would have been perfectly possible to not have
> 'try' at all, and simply allow a sequence of catch
> clauses to follow any statement. Bjarne Stroustrup
> addresses this explicitly in _The Design and Evolution
> of C++_. The problem was that the resulting code looked
> ambiguous and difficult to understand. Having explicit
> try and a brace-enclosed section enhanced readability.
I agree with Hyman Rosen here (and with Bjarne Stroustrup!).
Not only is it more readable to have a separate statement for handled
regions, it simplifies the language. And it obviates the need for
extraneous block_statements.
On the other hand, it's not that big of a deal, either way.
> > That the C++ core language tends to have undefined/
> > implementation-defined semantics where Ada has semantics
> > defined in terms of exceptions is another.
>
> The designers of C++ simply followed the lead of their
> parent language in not checking certain core operations.
> The choice was made not to check, so debating which
> mechanism would not be used to not report the error is
> silly. Where C++ does require checks, generally exceptions
> are raised on failure. (Formatted I/O allows the choice to
> silently fail subsequent operations once one fails, and
> then to check once for failure at the end.)
OK, fair enough. But I still think allowing the programmer to choose
whether to do overflow checking or not is a far superior language design
than one that doesn't allow that choice. The programmer, not the
language designer, is the only one in a position to make that choice.
> > On a more concrete level, Ada's was initially intended for critical,
> > real-time, embedded SW. Allowing an arbitrary object to be used
> > as/associated with an exception in such systems may not be a good idea.
>
> But as we know from SPARK, use of Ada in such environments
> generally involves throwing away much of the existing language.
> Therefore I do not find this to be a valid argument.
I don't find it to be valid, either. But I think your point about SPARK
is invalid, too, because many real-time embedded systems use much larger
subsets of Ada than SPARK.
The real issue is whether exception (occurrences) can have non-static
size. If that's bad for your real-time system, then don't use that
feature; it's not a good reason to leave the feature out of the
language. Another case where the programmer, not the language design,
should make the decision.
> > Additionally, Ada allows nested scopes, which C and its descendants do
> > not. This allows the existence of anonymous exceptions, exceptions that
> > have propagated out of the scope of their definitions. Allowing
> > arbitrary objects as/associated with exceptions gives rise to a similar
> > set of problems as allowing type extensions at a deeper scope than the
> > parent.
>
> Yes, that's a much better argument. It puts the cause squarely on
> other aspects of Ada's design rather than harrumphing and handwaving.
> By the way, it's not correct to say that Ada allows nested scopes and
> C-like languages do not. The problem here is that in Ada types are
> dynamic while in C-like languages all types are static regardless of
> the scope in which they are defined. So in those languages, there is
> no concept of an object being able to outlive its type, and thus no
> problem with throwing it out of the scope in which the type was
> defined.
But in both C++ and Ada, types have type descriptors (or method dispatch
tables, or whatever you want to call them). These point at procedures.
And if those procedures can be nested, those procedures can depend on
(and modify) the stack-allocated data.
In other words, I agree with Jeff here, that the issue is nesting (not
staticness of types).
- Bob
^ permalink raw reply [flat|nested] 78+ messages in thread
* Re: Ada exception block does NOT work?
2005-08-18 8:44 ` Maciej Sobczak
2005-08-18 11:40 ` Jean-Pierre Rosen
2005-08-18 16:13 ` Jeffrey Carter
@ 2005-08-18 17:54 ` Martin Krischik
2005-08-18 20:56 ` Robert A Duff
2005-08-18 21:15 ` Robert A Duff
4 siblings, 0 replies; 78+ messages in thread
From: Martin Krischik @ 2005-08-18 17:54 UTC (permalink / raw)
Maciej Sobczak wrote:
> Note that those other languages can throw regular objects as exceptions,
> thus enabling polymorphism when they are handled.
It is interesting to note that Java and C# has reversed from C++ not
allowing any object to be thrown - but only object which are "Throwable".
Besides: can you throw C++/Java/C# exception across Threads, Processes or
Distributed (from on computer to the next over a network). You can with
Ada.
> One could say that
> this is the point of good integration and that Ada's exceptions are a
> conceptual patch that did not integrate with the rest of the object
> model, leading to two separate spaces of language entities instead of
> only one.
Well Ada 83 had exceptions but not objects with dispatching so exceptions
could not be objects.
In fact this is one point you should remember: Ada 83 hat exceptions,
generics, well defined type system with type extension for primitive (int,
emum, etc. pp) types and a concept for "private".
The only thing which was missing and was added with Ada 95 where objects as
a C++ would see then.
C++ programmers often see Ada object as something bolted on - and I too had
some problems - but once you understand how it works you will see that it
is far better integrated into the language then in C++.
Surprised? Well Ada 95 had a concept of "RTTI" right from the beginning - in
C++ RTTI was bolted on later. And because Ada had "RTTI" right from the
beginning Ada does not need those "clone ()" functions often suggested in
C++ and Java tutorials. In Ada can clone any object without the aid of
clone () or Clonable.
How it works? Read:
http://en.wikibooks.org/wiki/Ada_Programming/Subtypes#Indefinite_subtype
http://en.wikibooks.org/wiki/Ada_Programming/Object_Orientation#The_class-wide_type
Martin
--
mailto://krischik@users.sourceforge.net
Ada programming at: http://ada.krischik.com
^ permalink raw reply [flat|nested] 78+ messages in thread
* Re: Ada exception block does NOT work?
2005-08-18 8:44 ` Maciej Sobczak
` (2 preceding siblings ...)
2005-08-18 17:54 ` Martin Krischik
@ 2005-08-18 20:56 ` Robert A Duff
2005-08-18 22:01 ` Hyman Rosen
` (2 more replies)
2005-08-18 21:15 ` Robert A Duff
4 siblings, 3 replies; 78+ messages in thread
From: Robert A Duff @ 2005-08-18 20:56 UTC (permalink / raw)
Maciej Sobczak <no.spam@no.spam.com> writes:
> Jeffrey R. Carter wrote:
>
> > Ada has had exceptions, well integrated with the rest of the language,
> > since Ada 80. Ada's terminology is that exceptions are raised and
> > handled.
>
> OK, but the question is not about terminology, really.
It is unfortunate that different programming languages use different
terminology for what is essentially the same concept. "Raise" and
"handle" mean essentially the same thing as "throw" and "catch".
There are important differences in syntax and semantics among different
languages, but terminology differences just get in the way of
understanding the "real" differences. And the differences between C++
and Java are just as important as the differences between C++ and Ada,
even though C++ and Java use more-similar terminology.
Anyway, if you say "throw" in an Ada newsgroup, folks ought to know what
you're talking about.
> If you claim that exceptions were "patched" on to the C++ language that
> did not have them originally, then let's switch the context to other
> language that has no history issue like this.
>
> I don't know the full history of Java, but I suppose that it had
> exceptions from the very beginning.
Yes, it did.
>... If not, let's take C#. Whether those
> languages tried to mimic the syntax from C++ does not matter at all when
> it comes to discussion how well the mechanism is integrated into the
> language.
Agreed.
> Why do you claim that Ada's exceptions are "better integrated into the
> language than in the languages that throw and catch them"?
Well, given something that ought to be considered an "error", the
language designer has to decide how to deal with it: make it raise/throw
an exception, or make it return a well-defined but likely-wrong answer,
or make the behavior "unpredictable", or restrict things so it can be
detected at compile time, or ....
The raise/throw exception choice was not available to Stroustrup when he
designed C++, since C++ at that time had no exception facility, and
since he intended to be compatible with C. This has nothing to do with
whether you call it "raise" or "throw". But it does mean that
exceptions are not well-integrated, since certain run-time errors that
really ought to cause exceptions do not. For example, overflow on
signed integer arithmetic. On this point, I agree with Jeff Carter.
On the other hand, the Java designers were not trying to be compatible
with C, and could well have made signed integer overflow throw an
exception. But they chose instead to make it return a probably-wrong
answer; that is, they unwisely chose wraparound arithmetic.
On the third hand, *unsigned* integer arithmetic is wrap-around in C,
C++, Java, *and* Ada.
----------------
As to the syntax: I think the try/catch statement or whatever is
*better* than the Ada syntax, because it makes it quite clear which
region of code is protected by the handler. In Ada:
procedure P(...) is
... -- (1)
begin
... -- (2)
exception
when Some_Error =>
Do_Something;
end P;
An exception at (2) is handled by the handler, whereas an exception at
(1) is not. But it *looks* like both should be handled, from the
syntax, and the usual indentation. More importantly, one moves code
above/below the "begin" line based on criteria having nothing to do with
exceptions -- whether it's needed to initialize or constrain things, for
example.
There are, of course, good reasons why exceptions at (1) are not handled
by the above handler. But I think the try/catch syntax deals with these
issues more neatly.
> Note that those other languages can throw regular objects as exceptions,
> thus enabling polymorphism when they are handled. One could say that
> *this* is the point of good integration and that Ada's exceptions are a
> conceptual patch that did not integrate with the rest of the object
> model, leading to two separate spaces of language entities instead of
> only one.
I agree. If you want to attach information to an exception in Java, you
do it in the same way you attach information to any other sort of object
-- you declare record fields in a type extension (i.e. in a class in the
exception hierarchy). In Ada, you have to use a special gizmo. The
Java way is clearly more well-integrated with the rest of the language.
Besides, the Java way is type safe at compile time, whereas the Ada
gizmo is not.
On the other hand, in C++, an exception can be *anything* -- you can
throw a string, or an int. I don't like that.
> Note that I'm learning Ada and I'm likely to misunderstand things.
Perhaps, but you seem to understand the exception-related issues just
fine. ;-)
>... But
> I'm curious about your way of reasoning and I want to better understand
> the differences between languages (and that's why I'm provoking you with
> the above inverted claim ;) ).
- Bob
^ permalink raw reply [flat|nested] 78+ messages in thread
* Re: Ada exception block does NOT work?
2005-08-18 20:56 ` Robert A Duff
@ 2005-08-18 22:01 ` Hyman Rosen
2005-08-19 2:35 ` Jeffrey R. Carter
2005-08-19 12:34 ` Dr. Adrian Wrigley
2 siblings, 0 replies; 78+ messages in thread
From: Hyman Rosen @ 2005-08-18 22:01 UTC (permalink / raw)
Robert A Duff wrote:
> But it does mean that exceptions are not well-integrated,
> since certain run-time errors that really ought to cause
> exceptions do not. For example, overflow on signed integer
> arithmetic.
This argument is flawed. It would make sense only if C++
detected signed overflow and reported the error other than
by raising an exception. C++ merely follows the lead of
its parent language and does no checking for this condition.
It's not because exceptions were unavailable, it's because
requiring the check was conceived to be potentially too
costly and would have served as a barrier to adoption because
it would have slowed down the equivalent code in C++ with
respect to C.
Actually, since signed overflow is undefined behavior, an
implementation is free to check for it and raise an exception
if it wants to.
The checked vector accessor reports a bad index through
exceptions. The memory allocator reports failure through
exceptions. The formatted I/O system can report failure
through exceptions (although it's normally more convenient
to check for errors at the end).
^ permalink raw reply [flat|nested] 78+ messages in thread
* Re: Ada exception block does NOT work?
2005-08-18 20:56 ` Robert A Duff
2005-08-18 22:01 ` Hyman Rosen
@ 2005-08-19 2:35 ` Jeffrey R. Carter
2005-08-20 15:28 ` Robert A Duff
2005-08-19 12:34 ` Dr. Adrian Wrigley
2 siblings, 1 reply; 78+ messages in thread
From: Jeffrey R. Carter @ 2005-08-19 2:35 UTC (permalink / raw)
Robert A Duff wrote:
> It is unfortunate that different programming languages use different
> terminology for what is essentially the same concept. "Raise" and
> "handle" mean essentially the same thing as "throw" and "catch".
> There are important differences in syntax and semantics among different
> languages, but terminology differences just get in the way of
> understanding the "real" differences. And the differences between C++
> and Java are just as important as the differences between C++ and Ada,
> even though C++ and Java use more-similar terminology.
The point is that Ada was there first, so Ada terminology must be the "Right"
terminology.
--
Jeff Carter
"Now look, Col. Batguano, if that really is your name."
Dr. Strangelove
31
^ permalink raw reply [flat|nested] 78+ messages in thread
* Re: Ada exception block does NOT work?
2005-08-19 2:35 ` Jeffrey R. Carter
@ 2005-08-20 15:28 ` Robert A Duff
2005-08-20 20:24 ` Jeffrey R. Carter
0 siblings, 1 reply; 78+ messages in thread
From: Robert A Duff @ 2005-08-20 15:28 UTC (permalink / raw)
"Jeffrey R. Carter" <spam@spam.com> writes:
> Robert A Duff wrote:
>
> > It is unfortunate that different programming languages use different
> > terminology for what is essentially the same concept. "Raise" and
> > "handle" mean essentially the same thing as "throw" and "catch".
> > There are important differences in syntax and semantics among different
> > languages, but terminology differences just get in the way of
> > understanding the "real" differences. And the differences between C++
> > and Java are just as important as the differences between C++ and Ada,
> > even though C++ and Java use more-similar terminology.
>
> The point is that Ada was there first, so Ada terminology must be the
> "Right" terminology.
Ada was certainly not the first language with exceptions.
Does anybody know which one was? And were they called "exceptions"
and were they "raised" and "handled"?
I believe Symbolics Lisp predates Ada. True? And I believe it had
exceptions, which were called "conditions". (Symbolics Lisp was
the predecessor of Common Lisp.)
Anyway, terminology of programming language concepts is such a mess that
it's hard to say what the "right" terminology is. Too bad.
Besides, there's an element of "pot calling kettle black" here.
Ada misuses quite a few terms. For example, pointers should be called
"pointers" or "references", not "accesses". And it's an abomination to
use the term "integer" for a meager subset of the integers. I believe
the term "integer" to refer to the infinite set predates Ada somewhat.
;-)
- Bob
^ permalink raw reply [flat|nested] 78+ messages in thread
* Re: Ada exception block does NOT work?
2005-08-20 15:28 ` Robert A Duff
@ 2005-08-20 20:24 ` Jeffrey R. Carter
2005-08-20 21:34 ` Robert A Duff
2005-08-21 4:02 ` Larry Kilgallen
0 siblings, 2 replies; 78+ messages in thread
From: Jeffrey R. Carter @ 2005-08-20 20:24 UTC (permalink / raw)
Robert A Duff wrote:
>
> Ada was certainly not the first language with exceptions.
> Does anybody know which one was? And were they called "exceptions"
> and were they "raised" and "handled"?
Perhaps I should have added a smiley in there. But between Ada and those using
the C++ notation, Ada was certainly first.
> Besides, there's an element of "pot calling kettle black" here.
> Ada misuses quite a few terms. For example, pointers should be called
> "pointers" or "references", not "accesses". And it's an abomination to
> use the term "integer" for a meager subset of the integers. I believe
> the term "integer" to refer to the infinite set predates Ada somewhat.
I always thought the whole point of "access" was to not (seem to) require them
to just be "pointers". Bounds information and the like can be part of an access
value.
As for Integer, you're quite right, but it's also quite natural to use that name
(or a shortened form of it) for such a subset. Such a usage is quite common in
computer languages; see FORTRAN (1955?) for an example. What would be a better
name for such a type?
--
Jeff Carter
"If I could find a sheriff who so offends the citizens of Rock
Ridge that his very appearance would drive them out of town ...
but where would I find such a man? Why am I asking you?"
Blazing Saddles
37
^ permalink raw reply [flat|nested] 78+ messages in thread
* Re: Ada exception block does NOT work?
2005-08-20 20:24 ` Jeffrey R. Carter
@ 2005-08-20 21:34 ` Robert A Duff
2005-08-20 22:47 ` Frank J. Lhota
` (3 more replies)
2005-08-21 4:02 ` Larry Kilgallen
1 sibling, 4 replies; 78+ messages in thread
From: Robert A Duff @ 2005-08-20 21:34 UTC (permalink / raw)
"Jeffrey R. Carter" <spam@spam.com> writes:
> Robert A Duff wrote:
>
> > Ada was certainly not the first language with exceptions.
> > Does anybody know which one was? And were they called "exceptions"
> > and were they "raised" and "handled"?
>
> Perhaps I should have added a smiley in there.
;-)
>... But between Ada and those
> using the C++ notation, Ada was certainly first.
Indeed. I do prefer "raise/handle" to "throw/catch", but maybe because
that's what I'm used to.
There are also exceptions in the hardware world, variously called
"exceptions", "traps", and "synchronous interrupts". I'm talking about
divide-by-zero, overflow, and the like. Surely the software concept
came from that?
> > Besides, there's an element of "pot calling kettle black" here.
> > Ada misuses quite a few terms. For example, pointers should be called
> > "pointers" or "references", not "accesses". And it's an abomination to
> > use the term "integer" for a meager subset of the integers. I believe
> > the term "integer" to refer to the infinite set predates Ada somewhat.
>
> I always thought the whole point of "access" was to not (seem to)
> require them to just be "pointers". Bounds information and the like can
> be part of an access value.
Perhaps also to distinguish them from C-style pointers, which are rather
lower level.
To me, "pointer" does not imply "a single machine address".
To me, "pointer" means something that can point at things,
and that includes fat pointers, pointers containing array
dope, pointers represented as offsets instead of addresses,
double indirections, &c.
To me, "pointer" and "reference" are synonymous.
And "address" or "machine address" can be used for the hardware-level
concept.
An index into an array can be used as a pointer to a particular
array element.
Ada evolved from Pascal, and Pascal called them pointers.
In Pascal, there was no requirement or implication that
they must be a single machine address. There is no need
for array dope in Pascal, but adding array dope doesn't seem
like it requires renaming the whole concept.
> As for Integer, you're quite right, but it's also quite natural to use
> that name (or a shortened form of it) for such a subset. Such a usage is
> quite common in computer languages; see FORTRAN (1955?) for an
> example. What would be a better name for such a type?
I'd use "Integer" for what Lisp calls "bignums" -- integers that can
grow without bound (except of course you can run out of memory,
but that's true of Strings and whatnot, too. I'd call the integer type
that is based on the hardware (e.g. 32-bit integers) "Machine_Integer".
And I wouldn't put it in a package called "Standard" and I wouldn't
make it automatically visible everywhere.
I think one ought to be allowed to say:
type T is range 1..10**100;
Portably.
- Bob
^ permalink raw reply [flat|nested] 78+ messages in thread
* Re: Ada exception block does NOT work?
2005-08-20 21:34 ` Robert A Duff
@ 2005-08-20 22:47 ` Frank J. Lhota
2005-08-20 23:34 ` Robert A Duff
2005-08-21 1:12 ` Björn Persson
` (2 subsequent siblings)
3 siblings, 1 reply; 78+ messages in thread
From: Frank J. Lhota @ 2005-08-20 22:47 UTC (permalink / raw)
"Robert A Duff" <bobduff@shell01.TheWorld.com> wrote in message
news:wccslx4gumc.fsf@shell01.TheWorld.com...
> ...
> To me, "pointer" does not imply "a single machine address".
> To me, "pointer" means something that can point at things,
> and that includes fat pointers, pointers containing array
> dope, pointers represented as offsets instead of addresses,
> double indirections, &c.
Thats fine, but also understand that to many others, "pointer" does mean "a
single machine address". It certainly does not hurt to introduce a new term
to avoid potential misunderstandings.
> To me, "pointer" and "reference" are synonymous.
OK, but just be aware that in C++, "pointer" and "reference" are not
synonyms.
> And "address" or "machine address" can be used for the hardware-level
> concept.
>
> An index into an array can be used as a pointer to a particular
> array element.
So the number 3 can be thought of as a pointer into any array indexed by a
integer. An interesting concept, but this is certainly a non-standard use of
the term "pointer".
> Ada evolved from Pascal, and Pascal called them pointers.
> In Pascal, there was no requirement or implication that
> they must be a single machine address. There is no need
> for array dope in Pascal, but adding array dope doesn't seem
> like it requires renaming the whole concept.
For the record, I know of no Pascal compiler that implements a pointer as
anything other than a machine address.
>> As for Integer, you're quite right, but it's also quite natural to use
>> that name (or a shortened form of it) for such a subset. Such a usage is
>> quite common in computer languages; see FORTRAN (1955?) for an
>> example. What would be a better name for such a type?
>
> I'd use "Integer" for what Lisp calls "bignums" -- integers that can
> grow without bound (except of course you can run out of memory,
> but that's true of Strings and whatnot, too. I'd call the integer type
> that is based on the hardware (e.g. 32-bit integers) "Machine_Integer".
> And I wouldn't put it in a package called "Standard" and I wouldn't
> make it automatically visible everywhere.
>
> I think one ought to be allowed to say:
>
> type T is range 1..10**100;
>
> Portably.
Now that is an interesting concept. I am fond of divorcing the language from
platform constrains when practical. There are, however, some practical
concerns about this proposal. An Ada 'bignum' type would undoubtedly be a
controlled type, introducing more overhead than one would expect in a scalar
type.
--
"All things extant in this world,
Gods of Heaven, gods of Earth,
Let everything be as it should be;
Thus shall it be!"
- Magical chant from "Magical Shopping Arcade Abenobashi"
"Drizzle, Drazzle, Drozzle, Drome,
Time for the this one to come home!"
- Mr. Lizard from "Tutor Turtle"
^ permalink raw reply [flat|nested] 78+ messages in thread
* Re: Ada exception block does NOT work?
2005-08-20 22:47 ` Frank J. Lhota
@ 2005-08-20 23:34 ` Robert A Duff
2005-08-21 11:18 ` Simon Wright
` (2 more replies)
0 siblings, 3 replies; 78+ messages in thread
From: Robert A Duff @ 2005-08-20 23:34 UTC (permalink / raw)
"Frank J. Lhota" <NOSPAM.FrankLho@rcn.com> writes:
> "Robert A Duff" <bobduff@shell01.TheWorld.com> wrote in message
> news:wccslx4gumc.fsf@shell01.TheWorld.com...
> > ...
> > To me, "pointer" does not imply "a single machine address".
> > To me, "pointer" means something that can point at things,
> > and that includes fat pointers, pointers containing array
> > dope, pointers represented as offsets instead of addresses,
> > double indirections, &c.
>
> Thats fine, but also understand that to many others, "pointer" does mean "a
> single machine address".
Agreed. And to some folks, "pointer" implies "you can do arithmetic on
it" (i.e. C-style pointers).
There's no uniform terminology across programming languages.
That's not surprising, given that programming language design
is such a new art.
>... It certainly does not hurt to introduce a new term
> to avoid potential misunderstandings.
I think it does hurt to introduce new terms -- we end up with 37
different ways of referring to the same thing (and folks who talk about
"methods" have trouble communicating with folks who talk about
"procedures" and so on).
> > To me, "pointer" and "reference" are synonymous.
>
> OK, but just be aware that in C++, "pointer" and "reference" are not
> synonyms.
True. But they're pretty close. The both "point at" or "refer to"
things. There are differences in which ones you can copy and whether
dereferencing is explicit or implicit and so on.
Interesting that we "dereference" pointers. ;-)
As opposed to "depointering" them.
> > And "address" or "machine address" can be used for the hardware-level
> > concept.
> >
> > An index into an array can be used as a pointer to a particular
> > array element.
>
> So the number 3 can be thought of as a pointer into any array indexed by a
> integer. An interesting concept, but this is certainly a non-standard use of
> the term "pointer".
Really? I sometimes write code something like this:
type Stack_Index is range 1..whatever;
subtype Stack_Count is Stack_Index'Base range 0..whatever;
type Stack(Max: ...) is limited
record
Top: Stack_Count := 0; -- points to the top element of the stack
Elements: Element_Array(1..Max);
end record;
Do you think "points to" is confusing in the above comment?
> > Ada evolved from Pascal, and Pascal called them pointers.
> > In Pascal, there was no requirement or implication that
> > they must be a single machine address. There is no need
> > for array dope in Pascal, but adding array dope doesn't seem
> > like it requires renaming the whole concept.
>
> For the record, I know of no Pascal compiler that implements a pointer as
> anything other than a machine address.
That's true. And almost all Ada compilers use single-machine-address
to represent almost-all access types.
> >> As for Integer, you're quite right, but it's also quite natural to use
> >> that name (or a shortened form of it) for such a subset. Such a usage is
> >> quite common in computer languages; see FORTRAN (1955?) for an
> >> example. What would be a better name for such a type?
> >
> > I'd use "Integer" for what Lisp calls "bignums" -- integers that can
> > grow without bound (except of course you can run out of memory,
> > but that's true of Strings and whatnot, too. I'd call the integer type
> > that is based on the hardware (e.g. 32-bit integers) "Machine_Integer".
> > And I wouldn't put it in a package called "Standard" and I wouldn't
> > make it automatically visible everywhere.
> >
> > I think one ought to be allowed to say:
> >
> > type T is range 1..10**100;
> >
> > Portably.
>
> Now that is an interesting concept. I am fond of divorcing the language from
> platform constrains when practical. There are, however, some practical
> concerns about this proposal. An Ada 'bignum' type would undoubtedly be a
> controlled type, introducing more overhead than one would expect in a scalar
> type.
Well, one has to learn what to "expect" in terms of efficiency.
In a garbage-collected implementation of Ada, bignum would not need to
be a controlled type.
If I said "1..2**80", I would "expect" 3 words to be allocated typically
on the stack, with no heap usage, and no need for either controlled
types or GC. If I said "1..2**1000", I would expect heap usage, and
consequent controlled types or GC. If I'm writing a hard real-time
embedded system, I probably won't say "1..2**1000".
But I'm not even allowedd to say "1..2**80" in any Ada compiler I know
of, and I can't even count on "1..2**35" portably. Sigh.
- Bob
^ permalink raw reply [flat|nested] 78+ messages in thread
* Re: Ada exception block does NOT work?
2005-08-20 23:34 ` Robert A Duff
@ 2005-08-21 11:18 ` Simon Wright
2005-08-21 16:59 ` tmoran
2005-08-21 16:07 ` Frank J. Lhota
2005-08-21 16:23 ` Martin Krischik
2 siblings, 1 reply; 78+ messages in thread
From: Simon Wright @ 2005-08-21 11:18 UTC (permalink / raw)
Robert A Duff <bobduff@shell01.TheWorld.com> writes:
> type Stack_Index is range 1..whatever;
> subtype Stack_Count is Stack_Index'Base range 0..whatever;
Now I see it this idiom is obvious .. thanks!
> type Stack(Max: ...) is limited
> record
> Top: Stack_Count := 0; -- points to the top element of the stack
> Elements: Element_Array(1..Max);
> end record;
>
> Do you think "points to" is confusing in the above comment?
Yes, a bit (sorry)
^ permalink raw reply [flat|nested] 78+ messages in thread
* Re: Ada exception block does NOT work?
2005-08-20 23:34 ` Robert A Duff
2005-08-21 11:18 ` Simon Wright
@ 2005-08-21 16:07 ` Frank J. Lhota
2005-08-21 16:23 ` Martin Krischik
2 siblings, 0 replies; 78+ messages in thread
From: Frank J. Lhota @ 2005-08-21 16:07 UTC (permalink / raw)
"Robert A Duff" <bobduff@shell01.TheWorld.com> wrote in message
news:wcck6ig89oz.fsf@shell01.TheWorld.com...
> ...
>
> Agreed. And to some folks, "pointer" implies "you can do arithmetic on
> it" (i.e. C-style pointers).
>
> There's no uniform terminology across programming languages.
> That's not surprising, given that programming language design
> is such a new art.
This lack of uniform terminology can cause confusion. For example, what does
"package" mean? In some languages, a package is little more than a name
space. In Ada, it is something far more substantial.
>>... It certainly does not hurt to introduce a new term
>> to avoid potential misunderstandings.
>
> I think it does hurt to introduce new terms -- we end up with 37
> different ways of referring to the same thing (and folks who talk about
> "methods" have trouble communicating with folks who talk about
> "procedures" and so on).
I'm in full agreement with the notion that new terms should not be
introduced unless they represent new concepts. The arguments over "throw"
versus "raise", "catch" versus "handle" are silly, and divert attention from
the real issues.
> True. But they're pretty close. The both "point at" or "refer to"
> things. There are differences in which ones you can copy and whether
> dereferencing is explicit or implicit and so on.
>
> Interesting that we "dereference" pointers. ;-)
> As opposed to "depointering" them.
The English language is full of such quirks, even outside of programming.
Why do we drive on the parkway and park on the driveway?
> ...
>> For the record, I know of no Pascal compiler that implements a pointer as
>> anything other than a machine address.
>
> That's true. And almost all Ada compilers use single-machine-address
> to represent almost-all access types.
At least major Ada compiler, GNAT, does use "fat" pointers for accessing
unconstrained arrays unless forbidden by representation clauses.
> ...
>> Now that is an interesting concept. I am fond of divorcing the language
>> from
>> platform constrains when practical. There are, however, some practical
>> concerns about this proposal. An Ada 'bignum' type would undoubtedly be a
>> controlled type, introducing more overhead than one would expect in a
>> scalar
>> type.
>
> Well, one has to learn what to "expect" in terms of efficiency.
>
> In a garbage-collected implementation of Ada, bignum would not need to
> be a controlled type.
>
> If I said "1..2**80", I would "expect" 3 words to be allocated typically
> on the stack, with no heap usage, and no need for either controlled
> types or GC. If I said "1..2**1000", I would expect heap usage, and
> consequent controlled types or GC. If I'm writing a hard real-time
> embedded system, I probably won't say "1..2**1000".
>
> But I'm not even allowedd to say "1..2**80" in any Ada compiler I know
> of, and I can't even count on "1..2**35" portably. Sigh.
Good point. I like the idea of being able to create a new integer type
without concern over details such as machine representation.
> - Bob
^ permalink raw reply [flat|nested] 78+ messages in thread
* Re: Ada exception block does NOT work?
2005-08-20 23:34 ` Robert A Duff
2005-08-21 11:18 ` Simon Wright
2005-08-21 16:07 ` Frank J. Lhota
@ 2005-08-21 16:23 ` Martin Krischik
2 siblings, 0 replies; 78+ messages in thread
From: Martin Krischik @ 2005-08-21 16:23 UTC (permalink / raw)
Robert A Duff wrote:
> But I'm not even allowedd to say "1..2**80" in any Ada compiler I know
> of, and I can't even count on "1..2**35" portably. Sigh.
Well GNAT allows 2*63. But the limits are indeed very low. I started with
8bit CPUs and one of the fist things you learn with 8bit CPUs is how to add
and subtract 16, 24, 32 etc pp values using the "carry bit".
I don't think there is a real reason to restrict integers ranges.
Martin
--
mailto://krischik@users.sourceforge.net
Ada programming at: http://ada.krischik.com
^ permalink raw reply [flat|nested] 78+ messages in thread
* Re: Ada exception block does NOT work?
2005-08-20 21:34 ` Robert A Duff
2005-08-20 22:47 ` Frank J. Lhota
@ 2005-08-21 1:12 ` Björn Persson
2005-08-21 9:01 ` Dmitry A. Kazakov
2005-08-21 16:14 ` Martin Krischik
3 siblings, 0 replies; 78+ messages in thread
From: Björn Persson @ 2005-08-21 1:12 UTC (permalink / raw)
Robert A Duff wrote:
> I do prefer "raise/handle" to "throw/catch", but maybe because
> that's what I'm used to.
Personally I think "catch" is a more descriptive term than "handle". To
"handle" an exception seems to imply that you do something about it. If
you write an exception handler that just contains a null statement, to
ignore exceptions that you really ought to react to, it's doubtful if
that can be called handling them. Or take an exception handler that
doesn't do anything about the exception itself, but only deallocates
some memory or something and then re-raises the exception. Does that
constitute handling the exception? If the re-raised exception propagates
out of the program it will be called an unhandled exception.
So exception handlers ought to be called exception catchers. The
exception catcher catches the exception, and then it's up to the code
inside the exception catcher to handle the exception, ignore it or pass
it on.
And if you say that you catch exceptions it's of course natural to also
say that you throw them.
But this is not in any way important to me. Besides, it would be
unreasonable to expect that people who invent new concepts will always
come up with perfect names for them
--
Bj�rn Persson PGP key A88682FD
omb jor ers @sv ge.
r o.b n.p son eri nu
^ permalink raw reply [flat|nested] 78+ messages in thread
* Re: Ada exception block does NOT work?
2005-08-20 21:34 ` Robert A Duff
2005-08-20 22:47 ` Frank J. Lhota
2005-08-21 1:12 ` Björn Persson
@ 2005-08-21 9:01 ` Dmitry A. Kazakov
2005-08-21 16:14 ` Martin Krischik
3 siblings, 0 replies; 78+ messages in thread
From: Dmitry A. Kazakov @ 2005-08-21 9:01 UTC (permalink / raw)
On 20 Aug 2005 17:34:51 -0400, Robert A Duff wrote:
> I'd use "Integer" for what Lisp calls "bignums" -- integers that can
> grow without bound (except of course you can run out of memory,
> but that's true of Strings and whatnot, too. I'd call the integer type
> that is based on the hardware (e.g. 32-bit integers) "Machine_Integer".
> And I wouldn't put it in a package called "Standard" and I wouldn't
> make it automatically visible everywhere.
>
> I think one ought to be allowed to say:
>
> type T is range 1..10**100;
But that wouldn't be an "integer" you have described! What you want seems
to me rather the Universal_Integer:
X : Universal_Integer;
-- No overflows, ever. Storage_Error instead
subtype T is Universal_Integer range 1..10**100;
-- No overflows in any numerical operations, only when value is stored
> Portably.
Sure!
I think it wouldn't be that difficult to do, I mean to expose
Universal_Integer. However range checks might be tricky to do without
overhead. The memory required to keep bounds might be bigger than all
actual values! Though it is unlikely that somebody would really need to
constrain Universal_Integer by 10**100 instead of using the base type.
--
Regards,
Dmitry A. Kazakov
http://www.dmitry-kazakov.de
^ permalink raw reply [flat|nested] 78+ messages in thread
* Re: Ada exception block does NOT work?
2005-08-20 21:34 ` Robert A Duff
` (2 preceding siblings ...)
2005-08-21 9:01 ` Dmitry A. Kazakov
@ 2005-08-21 16:14 ` Martin Krischik
3 siblings, 0 replies; 78+ messages in thread
From: Martin Krischik @ 2005-08-21 16:14 UTC (permalink / raw)
Robert A Duff wrote:
> I'd use "Integer" for what Lisp calls "bignums" -- integers that can
> grow without bound (except of course you can run out of memory,
> but that's true of Strings and whatnot, too. I'd call the integer type
> that is based on the hardware (e.g. 32-bit integers) "Machine_Integer".
That's a universal integer in Ada - and indeed the universal integer is not
visible anywhere in Ada.
And integer ranges that can grow without bound are not disallowed in Ada. If
you want you can create an Ada implementation that works that way.
It's like the garbage collector - the Ada vendors didn't think its needed,
> And I wouldn't put it in a package called "Standard" and I wouldn't
> make it automatically visible everywhere.
Standard.Integer is needed for Standard.String - There is no need to
support Strings which are larger then available memory.
Martin
--
mailto://krischik@users.sourceforge.net
Ada programming at: http://ada.krischik.com
^ permalink raw reply [flat|nested] 78+ messages in thread
* Re: Ada exception block does NOT work?
2005-08-20 20:24 ` Jeffrey R. Carter
2005-08-20 21:34 ` Robert A Duff
@ 2005-08-21 4:02 ` Larry Kilgallen
1 sibling, 0 replies; 78+ messages in thread
From: Larry Kilgallen @ 2005-08-21 4:02 UTC (permalink / raw)
In article <wccslx4gumc.fsf@shell01.TheWorld.com>, Robert A Duff <bobduff@shell01.TheWorld.com> writes:
> "Jeffrey R. Carter" <spam@spam.com> writes:
>
>> Robert A Duff wrote:
>>
>> > Ada was certainly not the first language with exceptions.
>> > Does anybody know which one was? And were they called "exceptions"
>> > and were they "raised" and "handled"?
>>
>> Perhaps I should have added a smiley in there.
>
> ;-)
>
>>... But between Ada and those
>> using the C++ notation, Ada was certainly first.
>
> Indeed. I do prefer "raise/handle" to "throw/catch", but maybe because
> that's what I'm used to.
>
> There are also exceptions in the hardware world, variously called
> "exceptions", "traps", and "synchronous interrupts". I'm talking about
> divide-by-zero, overflow, and the like. Surely the software concept
> came from that?
VMS had exception handlers/signal handlers in 1978 with most languages
establishing handlers by calls to runtime routines.
^ permalink raw reply [flat|nested] 78+ messages in thread
* Re: Ada exception block does NOT work?
2005-08-18 20:56 ` Robert A Duff
2005-08-18 22:01 ` Hyman Rosen
2005-08-19 2:35 ` Jeffrey R. Carter
@ 2005-08-19 12:34 ` Dr. Adrian Wrigley
2005-08-19 17:29 ` Martin Krischik
2 siblings, 1 reply; 78+ messages in thread
From: Dr. Adrian Wrigley @ 2005-08-19 12:34 UTC (permalink / raw)
On Thu, 18 Aug 2005 16:56:35 -0400, Robert A Duff wrote:
> On the third hand, *unsigned* integer arithmetic is wrap-around in C,
> C++, Java, *and* Ada.
err... doesn't Ada raise exceptions on overflow for unsigned types?
presumably you are talking of Ada's modular types(?) which are
(obviously) wrap-around, exactly as users want from such a type(!)
--
Adrian
^ permalink raw reply [flat|nested] 78+ messages in thread
* Re: Ada exception block does NOT work?
2005-08-19 12:34 ` Dr. Adrian Wrigley
@ 2005-08-19 17:29 ` Martin Krischik
2005-08-19 18:14 ` Frank J. Lhota
0 siblings, 1 reply; 78+ messages in thread
From: Martin Krischik @ 2005-08-19 17:29 UTC (permalink / raw)
Dr. Adrian Wrigley wrote:
> On Thu, 18 Aug 2005 16:56:35 -0400, Robert A Duff wrote:
>
>> On the third hand, *unsigned* integer arithmetic is wrap-around in C,
>> C++, Java, *and* Ada.
>
> err... doesn't Ada raise exceptions on overflow for unsigned types?
> presumably you are talking of Ada's modular types(?) which are
> (obviously) wrap-around, exactly as users want from such a type(!)
Well, the very first C did not have "unsigned int" there was just int.
That's why unix has a 2GB limit on files and not a 4 GB limit. (There is a
new set of file IO which can deal with larger files).
I think Java is still without "unsigned".
And last not least Ada "mod" type in not only unsigned it also has warp
around as extra - which you might not actually want.
Martin
--
mailto://krischik@users.sourceforge.net
Ada programming at: http://ada.krischik.com
^ permalink raw reply [flat|nested] 78+ messages in thread
* Re: Ada exception block does NOT work?
2005-08-19 17:29 ` Martin Krischik
@ 2005-08-19 18:14 ` Frank J. Lhota
2005-08-21 16:02 ` Martin Krischik
2005-08-22 8:12 ` Hyman Rosen
0 siblings, 2 replies; 78+ messages in thread
From: Frank J. Lhota @ 2005-08-19 18:14 UTC (permalink / raw)
Martin Krischik wrote:
> Well, the very first C did not have "unsigned int" there was just int.
> That's why unix has a 2GB limit on files and not a 4 GB limit. (There is a
> new set of file IO which can deal with larger files).
The standard of the Vanilla, K&R C language "The C Programming Language"
first edition, does include unsigned integer types. The old Unix file
size limit is probably due to other reasons.
> I think Java is still without "unsigned".
That is true, but Java does provide the common bit twiddling operations
for its signed integers.
> And last not least Ada "mod" type in not only unsigned it also has warp
> around as extra - which you might not actually want.
Or it might be exactly what you want. It depends on the application.
> Martin
>
--
"All things extant in this world,
Gods of Heaven, gods of Earth,
Let everything be as it should be;
Thus shall it be!"
- Magical chant from "Magical Shopping Arcade Abenobashi"
"Drizzle, Drazzle, Drozzle, Drome,
Time for the this one to come home!"
- Mr. Lizard from "Tutor Turtle"
^ permalink raw reply [flat|nested] 78+ messages in thread
* Re: Ada exception block does NOT work?
2005-08-19 18:14 ` Frank J. Lhota
@ 2005-08-21 16:02 ` Martin Krischik
2005-08-21 16:48 ` Frank J. Lhota
2005-08-23 0:32 ` Larry Elmore
2005-08-22 8:12 ` Hyman Rosen
1 sibling, 2 replies; 78+ messages in thread
From: Martin Krischik @ 2005-08-21 16:02 UTC (permalink / raw)
Frank J. Lhota wrote:
> Martin Krischik wrote:
>> Well, the very first C did not have "unsigned int" there was just int.
>> That's why unix has a 2GB limit on files and not a 4 GB limit. (There is
>> a new set of file IO which can deal with larger files).
>
> The standard of the Vanilla, K&R C language "The C Programming Language"
> first edition, does include unsigned integer types. The old Unix file
> size limit is probably due to other reasons.
It's because they used "signed int" for all file operations. Personally I
consider that damm stupid - after all: have you ever seen a file with a
negative size?
Martin
--
mailto://krischik@users.sourceforge.net
Ada programming at: http://ada.krischik.com
^ permalink raw reply [flat|nested] 78+ messages in thread
* Re: Ada exception block does NOT work?
2005-08-21 16:02 ` Martin Krischik
@ 2005-08-21 16:48 ` Frank J. Lhota
2005-08-22 15:51 ` Martin Krischik
2005-08-23 0:32 ` Larry Elmore
1 sibling, 1 reply; 78+ messages in thread
From: Frank J. Lhota @ 2005-08-21 16:48 UTC (permalink / raw)
"Martin Krischik" <krischik@users.sourceforge.net> wrote in message
news:1227518.U5hWOOGjT8@linux1.krischik.com...
> It's because they used "signed int" for all file operations. Personally I
> consider that damm stupid - after all: have you ever seen a file with a
> negative size?
>
> Martin
There is some utility to a negative file offset, for example fseek. The real
mistake was not using a typedef for the file sizes and file offsets.
> --
> mailto://krischik@users.sourceforge.net
> Ada programming at: http://ada.krischik.com
^ permalink raw reply [flat|nested] 78+ messages in thread
* Re: Ada exception block does NOT work?
2005-08-21 16:48 ` Frank J. Lhota
@ 2005-08-22 15:51 ` Martin Krischik
0 siblings, 0 replies; 78+ messages in thread
From: Martin Krischik @ 2005-08-22 15:51 UTC (permalink / raw)
Frank J. Lhota wrote:
> "Martin Krischik" <krischik@users.sourceforge.net> wrote in message
> news:1227518.U5hWOOGjT8@linux1.krischik.com...
>> It's because they used "signed int" for all file operations. Personally I
>> consider that damm stupid - after all: have you ever seen a file with a
>> negative size?
>>
>> Martin
>
> There is some utility to a negative file offset, for example fseek.
I know - It was also a mistake to make a "do it all" fseek - There should
have been a fabsseek and frelseek - then there wouldn't have been a problem
with using unsigned long for file positions. But that's all water under the
bridge now.
> The
> real mistake was not using a typedef for the file sizes and file offsets.
Well they have it now with fgetpos and fsetpos.
Martin
--
mailto://krischik@users.sourceforge.net
Ada programming at: http://ada.krischik.com
^ permalink raw reply [flat|nested] 78+ messages in thread
* Re: Ada exception block does NOT work?
2005-08-21 16:02 ` Martin Krischik
2005-08-21 16:48 ` Frank J. Lhota
@ 2005-08-23 0:32 ` Larry Elmore
[not found] ` <h5dlg1tsie8n3ikirvbi508t9afobhctkj@4ax.com>
1 sibling, 1 reply; 78+ messages in thread
From: Larry Elmore @ 2005-08-23 0:32 UTC (permalink / raw)
Martin Krischik wrote:
> Frank J. Lhota wrote:
>
>
>>Martin Krischik wrote:
>>
>>>Well, the very first C did not have "unsigned int" there was just int.
>>>That's why unix has a 2GB limit on files and not a 4 GB limit. (There is
>>>a new set of file IO which can deal with larger files).
>>
>>The standard of the Vanilla, K&R C language "The C Programming Language"
>>first edition, does include unsigned integer types. The old Unix file
>>size limit is probably due to other reasons.
I'm not sure that's necessarily the case. After all, Unix predates K&R
and K&R C was certainly not the first version of C.
> It's because they used "signed int" for all file operations. Personally I
> consider that damm stupid - after all: have you ever seen a file with a
> negative size?
>
> Martin
^ permalink raw reply [flat|nested] 78+ messages in thread
* Re: Ada exception block does NOT work?
2005-08-19 18:14 ` Frank J. Lhota
2005-08-21 16:02 ` Martin Krischik
@ 2005-08-22 8:12 ` Hyman Rosen
1 sibling, 0 replies; 78+ messages in thread
From: Hyman Rosen @ 2005-08-22 8:12 UTC (permalink / raw)
Frank J. Lhota wrote:
> The standard of the Vanilla, K&R C language "The C Programming Language"
> first edition, does include unsigned integer types.
But the earliest C compilers didn't. I know, because I used one around
1979. My college was running a verly early version of UNIX on a PDP-11/45.
We had terminals that printed out on rolls of paper, upper-case only. In
addition to not having unsigned arithmetic, the compiler was primitive in
many other ways. For instance, no two structures (records, for you Ada
folks) could have a field with the same name if they were at different
offsets from the beginning. It didn't have unions either. It was quite
the occasion a couple of years later when we got a full K&R compiler
(and video display terminals, which even supported both cases!)
^ permalink raw reply [flat|nested] 78+ messages in thread
* Re: Ada exception block does NOT work?
2005-08-18 8:44 ` Maciej Sobczak
` (3 preceding siblings ...)
2005-08-18 20:56 ` Robert A Duff
@ 2005-08-18 21:15 ` Robert A Duff
2005-08-19 12:00 ` Dmitry A. Kazakov
4 siblings, 1 reply; 78+ messages in thread
From: Robert A Duff @ 2005-08-18 21:15 UTC (permalink / raw)
Maciej Sobczak <no.spam@no.spam.com> writes:
> Jeffrey R. Carter wrote:
>
> > Ada has had exceptions, well integrated with the rest of the language,
> > since Ada 80. Ada's terminology is that exceptions are raised and
> > handled.
>
> OK, but the question is not about terminology, really.
By the way, here's a more subtle terminology difference:
What Ada calls "an exception" is what some other languages call "an
exception type" or "an exception class". What Ada calls "an exception
occurrence" is what other languages call "an exception" (i.e. "an object
of an exception type/class").
And by the by the way, here's an analogy:
In very-early versions of Ada (the Green language), tasks were a
separate gizmo. The designers of Ada 83 wisely chose to make tasks be
more integrated with the rest of the language -- to create a task, you
declare an object of a task type, or create a heap object of a task type
using "new", just like other sorts of objects are created.
In Green, there was something called a "task family", indexed by
integers. In Ada, you simply create an array of tasks. This is both
simpler (no need for a separate "task family" concept) and more general
(you can create any other sort of data structure using tasks -- arrays
of pointers to variant records containing tasks, etc).
I wish exceptions were treated the same way, with first-class exception
types and exception objects. This would be both simpler and more
general.
- Bob
P.S. Regarding tasks, they didn't go quite far enough. For example, why
do we say "task type T is..." instead of "type T is task..." like all
the other kinds of types?
^ permalink raw reply [flat|nested] 78+ messages in thread