Groups | Search | Server Info | Keyboard shortcuts | Login | Register [http] [https] [nntp] [nntps]

Groups > comp.lang.forth > #55863 > unrolled thread

Recognizer for strings and ABORT"

Back to article view | Back to comp.lang.forth

Contents

  Recognizer for strings and ABORT" albert@cherry.spenarnc.xs4all.nl (Albert van der Horst) - 2017-03-17 11:59 +0100
    Re: Recognizer for strings and ABORT" minforth@arcor.de - 2017-03-17 12:39 -0700
      Re: Recognizer for strings and ABORT" "HAA" <someone@microsoft.com> - 2017-03-18 10:27 +1100
        Re: Recognizer for strings and ABORT" minforth@arcor.de - 2017-03-18 00:48 -0700
        Re: Recognizer for strings and ABORT" anton@mips.complang.tuwien.ac.at (Anton Ertl) - 2017-03-18 11:24 +0000
          Re: Recognizer for strings and ABORT" "HAA" <someone@microsoft.com> - 2017-03-19 11:48 +1100
            Re: Recognizer for strings and ABORT" minforth@arcor.de - 2017-03-19 07:59 -0700
      Re: Recognizer for strings and ABORT" Andrew Haley <andrew29@littlepinkcloud.invalid> - 2017-03-18 03:08 -0500
      Re: Recognizer for strings and ABORT" anton@mips.complang.tuwien.ac.at (Anton Ertl) - 2017-03-18 13:21 +0000
        Re: Recognizer for strings and ABORT" minforth@arcor.de - 2017-03-18 11:16 -0700
    Re: Recognizer for strings and ABORT" anton@mips.complang.tuwien.ac.at (Anton Ertl) - 2017-03-18 14:27 +0000

#55863 — Recognizer for strings and ABORT"

I see that ABORT" is in the CORE words in Forth 2012.

Personally I never use
    ABORT" You're a DUMMY"
and use instead
    "You're a DUMMY" ETYPE 1982277 THROW

where the throw exactly identifies the error. It also goes into the
documentation, so in fact the error number alone already tells you
that you're a dummy.

Having yet another parsing ahead for " is worrysome to me.
I'd want to use the 2012 type string-recognizer here.

Something like

: ABORT"    POSTPONE "   POSTPONE (ABORT) ;

Is this possible?

(I also don't care much about ABORT" .  With CATCH/THROW it seems
archaic. Does it really belongs in the CORE ? )

Groetjes Albert
-- 
Albert van der Horst, UTRECHT,THE NETHERLANDS
Economic growth -- being exponential -- ultimately falters.
albert@spe&ar&c.xs4all.nl &=n http://home.hccnet.nl/a.w.m.van.der.horst

[toc] | [next] | [standalone]

#55870

Am Freitag, 17. März 2017 12:00:02 UTC+1 schrieb Albert van der Horst:
> I see that ABORT" is in the CORE words in Forth 2012.
> 
> Personally I never use
>     ABORT" You're a DUMMY"
> and use instead
>     "You're a DUMMY" ETYPE 1982277 THROW
> 
> where the throw exactly identifies the error. It also goes into the
> documentation, so in fact the error number alone already tells you
> that you're a dummy.
> 
> Having yet another parsing ahead for " is worrysome to me.
> I'd want to use the 2012 type string-recognizer here.
> 
> Something like
> 
> : ABORT"    POSTPONE "   POSTPONE (ABORT) ;
> 
> Is this possible?
> 
> (I also don't care much about ABORT" .  With CATCH/THROW it seems
> archaic. Does it really belongs in the CORE ? )
> 
> Groetjes Albert
> -- 
> Albert van der Horst, UTRECHT,THE NETHERLANDS
> Economic growth -- being exponential -- ultimately falters.
> albert@spe&ar&c.xs4all.nl &=n http://home.hccnet.nl/a.w.m.van.der.horst

As you know ABORT" also checks for a flag, so your a.m. preference is not equivalent.
Personally  ?THROW ( flag xc -- ) a lot.

And I am not at all happy with the reference implementation E6.1.2050 in the Forth 200x/16.1 draft which places the runtime of ABORT" to within QUIT. IMO this is a messy quick&dirty solution that should not be recommended this way. 
 

[toc] | [prev] | [next] | [standalone]

#55880

minforth@arcor.de wrote:
> ...
> And I am not at all happy with the reference implementation E6.1.2050 in the Forth
> 200x/16.1 draft which places the runtime of ABORT" to within QUIT. IMO this is a messy
> quick&dirty solution that should not be recommended this way.

Sometimes standards don't offer the flexibility needed.  E.g. for turnkey applications
I needed a way to differentiate between 'abort to OS with error code' and 'quit to OS
with no error'.  To that end I use ABORT ABORT" for the former and QUIT for the latter.
Also QUIT in my system is not trap-able with CATCH (contrary to ANS which assigns
QUIT a throw code).

[toc] | [prev] | [next] | [standalone]

#55886

Am Samstag, 18. März 2017 00:24:59 UTC+1 schrieb HAA:
> minforth@arcor.de wrote:
> > ...
> > And I am not at all happy with the reference implementation E6.1.2050 in the Forth
> > 200x/16.1 draft which places the runtime of ABORT" to within QUIT. IMO this is a messy
> > quick&dirty solution that should not be recommended this way.
> 
> Sometimes standards don't offer the flexibility needed.  E.g. for turnkey applications
> I needed a way to differentiate between 'abort to OS with error code' and 'quit to OS
> with no error'.  To that end I use ABORT ABORT" for the former and QUIT for the latter.
> Also QUIT in my system is not trap-able with CATCH (contrary to ANS which assigns
> QUIT a throw code).

My naked Forth kernel is defined in C. So I use exit(xc) to abort to the OS.
DEFER THROW
:NONAME c[ exit(pop()); ] ; IS THROW
The Forth system redefines THROW when the exception wordset is loaded.

Forceful return to the OS w/o error is via BYE. 

ABORT performs QUIT as prescribed by the standard.

[toc] | [prev] | [next] | [standalone]

#55897

"HAA" <someone@microsoft.com> writes:
>minforth@arcor.de wrote:
>> ...
>> And I am not at all happy with the reference implementation E6.1.2050 in the Forth
>> 200x/16.1 draft which places the runtime of ABORT" to within QUIT. IMO this is a messy
>> quick&dirty solution that should not be recommended this way.
>
>Sometimes standards don't offer the flexibility needed.  E.g. for turnkey applications
>I needed a way to differentiate between 'abort to OS with error code' and 'quit to OS
>with no error'.  To that end I use ABORT ABORT" for the former and QUIT for the latter.

For leaving the Forth system and returning to the OS, the standard has
BYE (with no error on the systems I tested).  Apart from that, exiting
or entering the Forth system has not been standardized yet.

Gforth has (BYE) ( n -- ) for leaving the Forth system with code n.

As for ABORT, ABORT" and THROW, if you called a word from the Forth
command-line, these words throw you back to the Forth command line.
If you call a word from the OS command line (with 'gforth -e "word
..."'), a THROW, ABORT, or ABORT" throw you back to the OS command
line.  That behaviour has proved very useful, and I hope that other
hosted Forth systems eventually see the light and work the same way.

>Also QUIT in my system is not trap-able with CATCH (contrary to ANS which assigns
>QUIT a throw code).

While there is a QUIT throw code (-56), I have no idea what its
purpose is.  It's obviously not for the word QUIT, which is specified
in a way that does not allow an implementation based on THROW.  In
particular, QUIT preserves the data stack.

Also, a standard-compliant QUIT word must not exit to the OS, but
instead start a Forth command-line interpreter.  If you want to exit
to the OS, use BYE.

- 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
     New standard: http://www.forth200x.org/forth200x.html
   EuroForth 2016: http://www.euroforth.org/ef16/

[toc] | [prev] | [next] | [standalone]

#55913

Anton Ertl wrote:
> "HAA" <someone@microsoft.com> writes:
> >minforth@arcor.de wrote:
> >> ...
> >> And I am not at all happy with the reference implementation E6.1.2050 in the Forth
> >> 200x/16.1 draft which places the runtime of ABORT" to within QUIT. IMO this is a
> >> messy quick&dirty solution that should not be recommended this way.
> >
> >Sometimes standards don't offer the flexibility needed.  E.g. for turnkey applications
> >I needed a way to differentiate between 'abort to OS with error code' and 'quit to OS
> >with no error'.  To that end I use ABORT ABORT" for the former and QUIT for the latter.
>
> For leaving the Forth system and returning to the OS, the standard has
> BYE (with no error on the systems I tested).  Apart from that, exiting
> or entering the Forth system has not been standardized yet.

Apart from being an 'optional programming tool' BYE is not something I'd have in a program
that I'm debugging or running in the forth environment.  ABORT and QUIT are the only
practical words a programmer has for exiting an app at any nesting level.  This is fine but
in using them I have to ignore what the standard says about ABORT executing QUIT when
apps are turnkeyed, and more significantly ignore reference implementations such as
E6.1.2050.  IMO the Standard would be better served with a less prescriptive definition of
ABORT.

[toc] | [prev] | [next] | [standalone]

#55924

Am Sonntag, 19. März 2017 01:45:54 UTC+1 schrieb HAA:
> Anton Ertl wrote:
> > "HAA" <someone@microsoft.com> writes:
> > >minforth@arcor.de wrote:
> > >> ...
> > >> And I am not at all happy with the reference implementation E6.1.2050 in the Forth
> > >> 200x/16.1 draft which places the runtime of ABORT" to within QUIT. IMO this is a
> > >> messy quick&dirty solution that should not be recommended this way.
> > >
> > >Sometimes standards don't offer the flexibility needed.  E.g. for turnkey applications
> > >I needed a way to differentiate between 'abort to OS with error code' and 'quit to OS
> > >with no error'.  To that end I use ABORT ABORT" for the former and QUIT for the latter.
> >
> > For leaving the Forth system and returning to the OS, the standard has
> > BYE (with no error on the systems I tested).  Apart from that, exiting
> > or entering the Forth system has not been standardized yet.
> 
> Apart from being an 'optional programming tool' BYE is not something I'd have in a program
> that I'm debugging or running in the forth environment.  ABORT and QUIT are the only
> practical words a programmer has for exiting an app at any nesting level.  This is fine but
> in using them I have to ignore what the standard says about ABORT executing QUIT when
> apps are turnkeyed, and more significantly ignore reference implementations such as
> E6.1.2050.  IMO the Standard would be better served with a less prescriptive definition of
> ABORT.

In my case BYE executes SHUTDOWN, an orderly shutdown seqeunce of the target system. This is necessary and beyond QUIT or ABORT.

[toc] | [prev] | [next] | [standalone]

#55890

minforth@arcor.de wrote:
> 
> And I am not at all happy with the reference implementation
> E6.1.2050 in the Forth 200x/16.1 draft which places the runtime of
> ABORT" to within QUIT. IMO this is a messy quick&dirty solution that
> should not be recommended this way.

There has to be an outer-level handler for ABORT.  Where would you put
that, if not in QUIT?  And why would it make any difference?

Andrew.

[toc] | [prev] | [next] | [standalone]

#55900

minforth@arcor.de writes:
>And I am not at all happy with the reference implementation E6.1.2050 in th=
>e Forth 200x/16.1 draft which places the runtime of ABORT" to within QUIT. =
>IMO this is a messy quick&dirty solution that should not be recommended thi=
>s way.=20

What would you recomment?

Implementing the "if there is no exception frame" behaviour by putting
a CATCH in QUIT (or thereabouts) and putting that behaviour there
looks quick&clean to me.

- 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
     New standard: http://www.forth200x.org/forth200x.html
   EuroForth 2016: http://www.euroforth.org/ef16/

[toc] | [prev] | [next] | [standalone]

#55902

Am Samstag, 18. März 2017 15:26:55 UTC+1 schrieb Anton Ertl:
> minforth@arcor.de writes:
> >And I am not at all happy with the reference implementation E6.1.2050 in th=
> >e Forth 200x/16.1 draft which places the runtime of ABORT" to within QUIT. =
> >IMO this is a messy quick&dirty solution that should not be recommended thi=
> >s way.=20
> 
> What would you recomment?
> 

It is far from me to recommend a new reference implementation. It is just that the following concept works well in my system (taken from the exception module): 

: _THROW  \ ( xc -- ) throw an exception
   <pseudo if (xc=0) return >
           if (exception-frame) resolve-it /pseudo>
    dup -2 =  IF (abort") EXIT THEN
    dup -1 <> IF ."  ?? exception " . THEN (abort) ;
' _THROW IS THROW	
(pseudo code is in C using longjmp)

This literally follows the standard text 9.6.1.2275. (ABORT) and (ABORT") perform the associated runtime functions of the core wordset. QUIT does not diplay anything but ok. 

THROW is already deferred in kernel in order to allow for throwing exceptions there. When the exception module is not loaded into the application, THROW returns to the OS messaging xc (e.g. -13 for undefined word).

[toc] | [prev] | [next] | [standalone]

#55901

albert@cherry.spenarnc.xs4all.nl (Albert van der Horst) writes:
[ABORT"]
>Having yet another parsing ahead for " is worrysome to me.

I await your proposal for destandardizing it.

>I'd want to use the 2012 type string-recognizer here.

Forth-2012 does not have a string recognizer.  Recognizers are a
proposal that is still in development.

>Something like
>
>: ABORT"    POSTPONE "   POSTPONE (ABORT) ;
>
>Is this possible?

If you have words " and (ABORT), sure.

If you mean that this, combined with a string recognizer that
recognizes 

"bla bla"

gives you a recognizer thttp://www.forth200x.org/exception.htmlhat recognizes

abort"bla bla"

then no:  If you want such a recognizer, you would need to write it
differently.

>(I also don't care much about ABORT" .

Neither do I.  So why have a recognizer for it.

>With CATCH/THROW it seems
>archaic.

It is.

> Does it really belongs in the CORE ? )

If you propose moving it to an optional wordset, you have my support.

As for user-specified error messages in combination with THROW, there
is the (pre-200x) proposal <http://www.forth200x.org/exception.html>.
With that you can write your example as:

s" You are a dummy" exception constant dummy-error

dummy-error throw

and it displays:

:2: You are a dummy
dummy-error >>>throw<<<

This is implemented in Gforth, and you can get a rudimentary
implementation in Forth-94 in <http://theforth.net/package/compat>.
So you can write your programs and libraries using EXCEPTION, and
leave it to the users of your program to complain to their system
implementors that they don't provide a more useful implementation of
EXCEPTION than the compat library; your program will still work on
these systems.  E.g., SwiftForth outputs:

Catch = -10753

while vfxlin outputs:

No text available for THROW code -10753(10)

- 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
     New standard: http://www.forth200x.org/forth200x.html
   EuroForth 2016: http://www.euroforth.org/ef16/

[toc] | [prev] | [standalone]

Back to top | Article view | comp.lang.forth

csiph-web