enum to throw isn't arbitrary? 
Author Message
 enum to throw isn't arbitrary?

Quote:
> http://www.*-*-*.com/
> http://www.*-*-*.com/
> exception ...
> implementend in Gforth since before release 0.4.0.
> The restriction to values in the range {-4095...-256}
> ensures that existing standard programs continue to work.

Can someone elaborate this claim?  I don't understand it.  I see past
mention of "mae1" in comp.lang.forth didn't mention it.

Quote:
> s" " exception .
> s" " exception .
> : tbd begin s" " exception . again ;
> tbd

I think I see GForth 0.5.0 counts down from -2048.  Me, somewhere
short of -12000 I get a "dictionary overflow".

Quote:
> http://www.*-*-*.com/ #9.6.1.2275

Am I wrong to read Ans Forth 1994 to say that throw numbers other than
0, 1, and 2 have no standard meaning?

I conclude the new exception word could just as well count up from 3,
or use a distinct but not monotonic hash code, rather than having to
count down from -256?

Thanks in advance.    Pat LaVarre



Mon, 15 Mar 2004 07:12:27 GMT  
 enum to throw isn't arbitrary?


Quote:
>> http://dec.bournemouth.ac.uk/forth/ans/extentions/index.html
>> http://dec.bournemouth.ac.uk/forth/ans/extentions/mae1.html
>> exception ...
>> implementend in Gforth since before release 0.4.0.
>> The restriction to values in the range {-4095...-256}
>> ensures that existing standard programs continue to work.

>Can someone elaborate this claim?

|9.3.1 THROW values
|
|The THROW values {-255...-1} shall be used only as assigned by this
|Standard. The values {-4095...-256} shall be used only as assigned by
|a system.

I.e., a standard program can THROW all other values in any way; and it
can expect that the system does not THROW these other values.

What's wrong if EXCEPTION produced values outside the range
{-4095...-1}?  Consider a library written as a standard program, which
does not use EXCEPTION, but instead uses the literals 3, 4, 5, as
THROW codes, and CATCHes these codes and performs some recovery
actions on them; consider that library being used together with
another library that uses EXCEPTION, and on one particular system
produces the value 3 for one EXCEPTION.  Now, these libraries are used
together in a way that a THROW of the EXCEPTION value 3 occurs and is
caught by the other library; the catcher will interpret the value in
an unintended way.

So it's more about being able to combine code that uses EXCEPTION with
existing standard code that doesn't, rather than just "continuing to
work".

Quote:
>> : tbd begin s" " exception . again ;
>> tbd

>I think I see GForth 0.5.0 counts down from -2048.  Me, somewhere
>short of -12000 I get a "dictionary overflow".

Try starting Gforth with more dictionary memory (say, gforth -m 10M),
and it will take longer:-).  At the moment Gforth does not check for
underflow in EXCEPTION, that's why you see values below -4095.

Quote:
>Am I wrong to read Ans Forth 1994 to say that throw numbers other than
>0, 1, and 2 have no standard meaning?

1 and 2 have no standard meaning.  You may be thinking of -1 and -2.
There's a list of standard throw codes in 9.3.5, although the standard
does not specify that any of these will be THROWn at any time, except
-1 on ABORT and -2 on ABORT".  But I guess most standard systems THROW
some of the other values on some error conditions.

Quote:
>I conclude the new exception word could just as well count up from 3,
>or use a distinct but not monotonic hash code, rather than having to
>count down from -256?

The monotonicity requirement is there to allow easy CATCHing of a
whole class of errors, and only those.

- anton
--
M. Anton Ertl  http://www.complang.tuwien.ac.at/anton/home.html
comp.lang.forth FAQs: http://www.complang.tuwien.ac.at/forth/faq/toc.html



Mon, 15 Mar 2004 15:38:36 GMT  
 enum to throw isn't arbitrary?

Quote:
> > > http://dec.bournemouth.ac.uk/forth/ans/extentions/mae1.html
> > > EXCEPTION ... a previously unused THROW value
> > > in the range {-4095...-256}.  Consecutive calls to
> > > EXCEPTION return consecutive decreasing numbers.
> > I think I see GForth 0.5.0 counts down from -2048.

Me, at first I misread this portion of the mae1 proposal to require a
system to count down from -256 to -4095 and then enter into an
ambiguous condition.  (Though I agree continuing to count down is an
implementation in the Forth spirit of let me quietly enter into
ambiguity when I please.)

To know that a program written to the new standard will work, don't we
have to specify some minimum count of available consecutive decreasing
numbers?  For example, we wouldn't want a system to start counting at
-4094?

This is fun.  If we wish to extend the standard usefully without
affecting any potential standard program, we necessarily have to
affect potential systems, here, namely, those that have been using
throw codes in the range -4095 ... -(4095 + N).  Yes?

Quote:
> > > http://dec.bournemouth.ac.uk/forth/ans/extentions/index.html
> > > http://dec.bournemouth.ac.uk/forth/ans/extentions/mae1.html
> > > exception ...
> > > The restriction to values in the range {-4095...-256}

> > Can someone elaborate this claim?

> > 9.3.1 THROW values
> > ... {-255...-1} ... Standard ...
> > ... {-4095...-256} ... a system ...
> > Programs ... not ... {-4095...-1}.

> > 9.3.5 Possible actions on an ambiguous condition
> > A system choosing ... THROW ... shall use the throw code listed ...
> > [ then appear definitions for throw values -1 .. -58 inclusive ]

EXACTLY the cross-references I needed, thank you.

Pat LaVarre



Mon, 15 Mar 2004 22:38:39 GMT  
 enum to throw isn't arbitrary?


Quote:
>To know that a program written to the new standard will work, don't we
>have to specify some minimum count of available consecutive decreasing
>numbers?  For example, we wouldn't want a system to start counting at
>-4094?

No, we wouldn't.  One can define a minimum number, or one can just say
that this is a quality-of-implementation issue:-).  ANS Forth does not
define minimum numbers for many things (e.g., most stack sizes), so I
guess not specifying a minimum number of exceptions is in spirit with
the standard.

Since this feature is intended to be used for combining libraries,
specifying a minimum number is not very useful anyway: even if each
library stays below the limit, their combination could exceed the
limit; what now?

- anton
--
M. Anton Ertl  http://www.complang.tuwien.ac.at/anton/home.html
comp.lang.forth FAQs: http://www.complang.tuwien.ac.at/forth/faq/toc.html



Wed, 17 Mar 2004 18:07:56 GMT  
 enum to throw isn't arbitrary?

Quote:
> > > ... exception ... throw value ...
> >To know that a program written to the new standard will work, don't we
> >have to specify some minimum count of available consecutive decreasing
> >numbers?  For example, we wouldn't want a system to start counting at
> >-4094?
> Since this feature is intended to be used for combining libraries,
> specifying a minimum number is not very useful anyway: even if each
> library stays below the limit, their combination could exceed the
> limit; what now?

Sorry?  I'm not sure I follow?  Surely we can say, if we know a base
system supplies S distinct throw values, and each library L needs N(L)
values, then we know the base system plus all the libraries in
question works if the sum of N(L) is less than or equal to S?

Is this not a useful thing to know?  Isn't it helpful, in comparing
libraries, to say that my library eats a third of the available throw
values but your library eats only a quarter?

Quote:
> ... my library eats a third ...

Or is the culture such that every library should use so few new throw
values that only an impractically large number of libraries could
possible exhaust the smallest set of throw values any system would be
likely to support?

The sharpest culture shock I'm feeling here is to see GForth exception
range from -2048..-4095...  Nearly half the system-dependent throw
values are gone before I enter my first word of code?  Is the idea
that this can't possibly matter?

Quote:
> One can define a minimum number, or one can just say
> that this is a quality-of-implementation issue:-).  ANS Forth does not
> define minimum numbers for many things (e.g., most stack sizes),
> so I guess not specifying a minimum number of exceptions
> is in spirit with the standard.

This then sounds like a fruitful area for extension of the standard?

Given a program with certain resource requirements, help me guess
whether running it involves me in ambiguous conditions or not.

Do Forth system vendors not customarily work to provide exactly this
kind of info?

Quote:
> > > ... exception ... throw value ...
> > For example, we wouldn't want a system to start counting at
> > -4094?
> No, we wouldn't.  One can define a minimum number, or one can just say
> that this is a quality-of-implementation issue:-).  ANS Forth does not
> define minimum numbers for many things (e.g., most stack sizes),

Help me out here?

I think I see, of all the stack lengths discussed in 3.2.3 Stacks,
3.2.6 Environmental Queries says ENVIRONMENT? reports only
RETURN-STACK-CELLS and STACK-CELLS.

Can we say therefore this culture thinks of any Forth as a port of the
more traditional implementations ... for example, that courtesy
demands an explicit caution if an implementation of the control stack
works less often than an implementation that uses one of the data
STACK-CELLS per orig/dest?

Pat LaVarre



Fri, 19 Mar 2004 23:13:16 GMT  
 enum to throw isn't arbitrary?


Quote:
>> > > ... exception ... throw value ...

>> >To know that a program written to the new standard will work, don't we
>> >have to specify some minimum count of available consecutive decreasing
>> >numbers?  For example, we wouldn't want a system to start counting at
>> >-4094?

>> Since this feature is intended to be used for combining libraries,
>> specifying a minimum number is not very useful anyway: even if each
>> library stays below the limit, their combination could exceed the
>> limit; what now?

>Sorry?  I'm not sure I follow?  Surely we can say, if we know a base
>system supplies S distinct throw values, and each library L needs N(L)
>values, then we know the base system plus all the libraries in
>question works if the sum of N(L) is less than or equal to S?

Yes, but I don't think this is very helpful, especially considering
that different people might write and change the libraries, the
program, the Forth system, and other people again might use the whole
thing.

Instead of looking up the numbers in the various docs, adding them up,
and comparing them, it's much faster for the user to just load the
program, and see if there is an underflow.

Quote:
>Or is the culture such that every library should use so few new throw
>values that only an impractically large number of libraries could
>possible exhaust the smallest set of throw values any system would be
>likely to support?

That was my original thinking.

Consider: we reserved 1536 throw values for OS errors; yet even a
fairly complex OS like Linux has less than 128 different error codes
(maybe we should have reserved less, but I don't know how many error
codes VMS or WNT has (if they support strerror at all).

Quote:
>> No, we wouldn't.  One can define a minimum number, or one can just say
>> that this is a quality-of-implementation issue:-).  ANS Forth does not
>> define minimum numbers for many things (e.g., most stack sizes),

>Help me out here?

>I think I see, of all the stack lengths discussed in 3.2.3 Stacks,
>3.2.6 Environmental Queries says ENVIRONMENT? reports only
>RETURN-STACK-CELLS and STACK-CELLS.

Yes, but there is no guaranteed minimum size.

Quote:
>Can we say therefore this culture thinks of any Forth as a port of the
>more traditional implementations ... for example, that courtesy
>demands an explicit caution if an implementation of the control stack
>works less often than an implementation that uses one of the data
>STACK-CELLS per orig/dest?

I think that systems that use larger origs/dests typically have a
stack that is large enough that stack overflows do not normally occur.

- anton
--
M. Anton Ertl  http://www.complang.tuwien.ac.at/anton/home.html
comp.lang.forth FAQs: http://www.complang.tuwien.ac.at/forth/faq/toc.html



Tue, 23 Mar 2004 23:00:51 GMT  
 
 [ 6 post ] 

 Relevant Pages 

1. enum with arbitrary values

2. Beginner's 'enum' question

3. Equivalent of Java 'throws'

4. int('0.0') throws an exception

5. 'arbitrary precision' arithmetic in Fortran

6. Why isn't Haskell mainstream?---A newbie's view

7. GNU Script isn't fixing something that's broken, so is doomed

8. COBOL isn't dead, but I'm learning C++

9. GNU Script isn't fixing something that's broken, so is doomed

10. GNU Script isn't fixing something that's broken, so is doomed

11. Enum's start at 0?

 

 
Powered by phpBB® Forum Software