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

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

What is wrong with U.? (SwiftForth)

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

Contents

  What is wrong with U.? (SwiftForth) Gerard Sontag <gerardsontag@gmail.com> - 2015-07-08 05:22 -0700
    Re: What is wrong with U.? (SwiftForth) Raimond Dragomir <raimond.dragomir@gmail.com> - 2015-07-08 05:49 -0700
    Re: What is wrong with U.? (SwiftForth) coos <chforth@hccnet.nl> - 2015-07-08 14:57 +0200
      Re: What is wrong with U.? (SwiftForth) Gerard Sontag <gerardsontag@gmail.com> - 2015-07-08 06:20 -0700
    Re: What is wrong with U.? (SwiftForth) "Elizabeth D. Rather" <erather@forth.com> - 2015-07-08 09:00 -1000
    Re: What is wrong with U.? (SwiftForth) jfong@ms4.hinet.net - 2015-07-08 17:37 -0700
      Re: What is wrong with U.? (SwiftForth) foxaudioresearch@gmail.com - 2015-07-08 18:01 -0700
      Re: What is wrong with U.? (SwiftForth) "Elizabeth D. Rather" <erather@forth.com> - 2015-07-08 15:56 -1000
      Re: What is wrong with U.? (SwiftForth) anton@mips.complang.tuwien.ac.at (Anton Ertl) - 2015-07-09 05:12 +0000
        Re: What is wrong with U.? (SwiftForth) djc <ciesinger@gmx.net> - 2015-07-09 00:52 -0700
          Re: What is wrong with U.? (SwiftForth) anton@mips.complang.tuwien.ac.at (Anton Ertl) - 2015-07-09 08:54 +0000
            Re: What is wrong with U.? (SwiftForth) franck.bensusan@gmail.com - 2015-07-09 03:50 -0700
              Re: What is wrong with U.? (SwiftForth) anton@mips.complang.tuwien.ac.at (Anton Ertl) - 2015-07-09 13:52 +0000
                Re: What is wrong with U.? (SwiftForth) franck.bensusan@gmail.com - 2015-07-09 09:20 -0700
                  Re: What is wrong with U.? (SwiftForth) anton@mips.complang.tuwien.ac.at (Anton Ertl) - 2015-07-09 17:13 +0000
                    Re: What is wrong with U.? (SwiftForth) franck.bensusan@gmail.com - 2015-07-09 10:45 -0700
                      Re: What is wrong with U.? (SwiftForth) anton@mips.complang.tuwien.ac.at (Anton Ertl) - 2015-07-10 05:51 +0000
                        Re: What is wrong with U.? (SwiftForth) franck.bensusan@gmail.com - 2015-07-09 23:11 -0700
                          Re: What is wrong with U.? (SwiftForth) Mark Wills <markwills1970@gmail.com> - 2015-07-10 01:09 -0700
                            Re: What is wrong with U.? (SwiftForth) franck.bensusan@gmail.com - 2015-07-10 01:20 -0700
                          Re: What is wrong with U.? (SwiftForth) anton@mips.complang.tuwien.ac.at (Anton Ertl) - 2015-07-10 07:55 +0000
                            Re: What is wrong with U.? (SwiftForth) franck.bensusan@gmail.com - 2015-07-10 01:53 -0700
                              Re: What is wrong with U.? (SwiftForth) "Elizabeth D. Rather" <erather@forth.com> - 2015-07-10 07:53 -1000
                                Re: What is wrong with U.? (SwiftForth) franck.bensusan@gmail.com - 2015-07-11 02:08 -0700
                                  Re: What is wrong with U.? (SwiftForth) Mark Wills <markwills1970@gmail.com> - 2015-07-11 02:32 -0700
                                  Re: What is wrong with U.? (SwiftForth) anton@mips.complang.tuwien.ac.at (Anton Ertl) - 2015-07-11 15:06 +0000
        Re: What is wrong with U.? (SwiftForth) "Elizabeth D. Rather" <erather@forth.com> - 2015-07-09 08:22 -1000
          Re: What is wrong with U.? (SwiftForth) anton@mips.complang.tuwien.ac.at (Anton Ertl) - 2015-07-10 05:55 +0000
      Re: What is wrong with U.? (SwiftForth) "HAA" <someone@microsoft.com> - 2015-07-09 20:12 +1000
        Re: What is wrong with U.? (SwiftForth) coos <chforth@hccnet.nl> - 2015-07-09 15:34 +0200
      Re: What is wrong with U.? (SwiftForth) Ron Aaron <rambamist@gmail.com> - 2015-07-10 14:16 +0300
    Re: What is wrong with U.? (SwiftForth) rickman <gnuarm@gmail.com> - 2015-07-10 02:20 -0400

Page 1 of 2  [1] 2  Next page →

#40415 — What is wrong with U.? (SwiftForth)

Hello,
Here is a very short session with: SwiftForth **EVALUATION**

>>SwiftForth i386-Win32 3.5.6 26-Oct-2014
>>hex  ok
>>-7f  ok
>>.U .U ?
>>U. 7EFDE000 Stack underflow
>>-7f  ok
>>U. FFFFFF81  ok

I know that .U do not exist but is this a reason to :
1/ Give wrong answer after U. 
2/ throw an exception 

Your comment are welcome.

[toc] | [next] | [standalone]

#40416

miercuri, 8 iulie 2015, 15:22:30 UTC+3, Gerard Sontag a scris:
> Hello,
> Here is a very short session with: SwiftForth **EVALUATION**
> 
> >>SwiftForth i386-Win32 3.5.6 26-Oct-2014
> >>hex  ok
> >>-7f  ok
> >>.U .U ?
> >>U. 7EFDE000 Stack underflow
> >>-7f  ok
> >>U. FFFFFF81  ok
> 
> I know that .U do not exist but is this a reason to :
> 1/ Give wrong answer after U. 
> 2/ throw an exception 
> 
> Your comment are welcome.

After a ? error (your .U .U ? line) the system clears the stack (among other 
things). So when you typed U. the stack was empty and the stack underflow is 
normal. I don't know what the 7EFDE000 code means though.

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

#40417

Op Wed, 8 Jul 2015 05:22:29 -0700 (PDT) schreef Gerard Sontag:

> Hello,
> Here is a very short session with: SwiftForth **EVALUATION**
> 
>>>SwiftForth i386-Win32 3.5.6 26-Oct-2014
>>>hex  ok
>>>-7f  ok
>>>.U .U ?
>>>U. 7EFDE000 Stack underflow
>>>-7f  ok
>>>U. FFFFFF81  ok
> 
> I know that .U do not exist but is this a reason to :
> 1/ Give wrong answer after U. 
> 2/ throw an exception 
> 
> Your comment are welcome.

This is normal behavior for any Forth. SwiftForth is a little short
that it only prints the unknown word and a question mark. Others may
respond differently. This is the first exception and the stack will
be emptied.
Yout first U. prints a garbage value, the stack was empty, remember?
The second U. behaves as you expected.

groet Coos

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

#40418

Thank you Raimond and Coos for your fast answer.

Gerard

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

#40424

On 7/8/15 2:22 AM, Gerard Sontag wrote:
> Hello,
> Here is a very short session with: SwiftForth **EVALUATION**
>
>>> SwiftForth i386-Win32 3.5.6 26-Oct-2014
>>> hex  ok
>>> -7f  ok
>>> .U .U ?
>>> U. 7EFDE000 Stack underflow
>>> -7f  ok
>>> U. FFFFFF81  ok
>
> I know that .U do not exist but is this a reason to :
> 1/ Give wrong answer after U.
> 2/ throw an exception
>
> Your comment are welcome.

Aborts clear the stack. After the error message ".U ?" your -7f was 
gone. Your next use of U. was correct, but since the stack was empty you 
got another error message. When you correctly typed -7f U. you get the 
right answer.

Cheers,
Elizabeth

-- 
==================================================
Elizabeth D. Rather   (US & Canada)   800-55-FORTH
FORTH Inc.                         +1 310.999.6784
5959 West Century Blvd. Suite 700
Los Angeles, CA 90045
http://www.forth.com

"Forth-based products and Services for real-time
applications since 1973."
==================================================

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

#40436

Gerard Sontag於 2015年7月8日星期三 UTC+8下午8時22分30秒寫道：
> Hello,
> Here is a very short session with: SwiftForth **EVALUATION**
> 
> >>SwiftForth i386-Win32 3.5.6 26-Oct-2014
> >>hex  ok
> >>-7f  ok
> >>.U .U ?
> >>U. 7EFDE000 Stack underflow
> >>-7f  ok
> >>U. FFFFFF81  ok
> 
> I know that .U do not exist but is this a reason to :
> 1/ Give wrong answer after U. 
> 2/ throw an exception 
> 
> Your comment are welcome.

I hate this behavior of Forth trandition. One accidently typing error may cause many minutes lost to rebuild the stack picture during debug. There is no reason to clear the stack without our permission after failing on searching a name in the dictionary. They are irrelevent. Don't know why everyone takes it deservedly.

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

#40437

On Wednesday, July 8, 2015 at 8:37:10 PM UTC-4, jf...@ms4.hinet.net wrote:
> Gerard Sontag於 2015年7月8日星期三 UTC+8下午8時22分30秒寫道：
> > Hello,
> > Here is a very short session with: SwiftForth **EVALUATION**
> > 
> > >>SwiftForth i386-Win32 3.5.6 26-Oct-2014
> > >>hex  ok
> > >>-7f  ok
> > >>.U .U ?
> > >>U. 7EFDE000 Stack underflow
> > >>-7f  ok
> > >>U. FFFFFF81  ok
> > 
> > I know that .U do not exist but is this a reason to :
> > 1/ Give wrong answer after U. 
> > 2/ throw an exception 
> > 
> > Your comment are welcome.
> 
> I hate this behavior of Forth trandition. One accidently typing error may cause many minutes lost to rebuild the stack picture during debug. There is no reason to clear the stack without our permission after failing on searching a name in the dictionary. They are irrelevent. Don't know why everyone takes it deservedly.

In the system that I play with ABORT is a vectored word, meaning I can assign it any behavior that is appropriate for my uses.  I used this when creating a multi-terminal multi-tasking system to allow ABORT write to a log for example.

Perhaps your system allows this or could be altered to allow it?

BF

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

#40439

On 7/8/15 2:37 PM, jfong@ms4.hinet.net wrote:
> Gerard Sontag於 2015年7月8日星期三 UTC+8下午8時22分30秒寫道：
>> Hello,
>> Here is a very short session with: SwiftForth **EVALUATION**
>>
>>>> SwiftForth i386-Win32 3.5.6 26-Oct-2014
>>>> hex  ok
>>>> -7f  ok
>>>> .U .U ?
>>>> U. 7EFDE000 Stack underflow
>>>> -7f  ok
>>>> U. FFFFFF81  ok
>>
>> I know that .U do not exist but is this a reason to :
>> 1/ Give wrong answer after U.
>> 2/ throw an exception
>>
>> Your comment are welcome.
>
> I hate this behavior of Forth trandition. One accidently typing error may cause many minutes lost to rebuild the stack picture during debug. There is no reason to clear the stack without our permission after failing on searching a name in the dictionary. They are irrelevent. Don't know why everyone takes it deservedly.

The aborts in SwiftForth are implemented using THROW. Technically, it's 
possible to go take different action, but we haven't seen much demand 
(including from our own staff, who are debugging stuff all the time).

Cheers,
Elizabeth

-- 
==================================================
Elizabeth D. Rather   (US & Canada)   800-55-FORTH
FORTH Inc.                         +1 310.999.6784
5959 West Century Blvd. Suite 700
Los Angeles, CA 90045
http://www.forth.com

"Forth-based products and Services for real-time
applications since 1973."
==================================================

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

#40445

jfong@ms4.hinet.net writes:
>I hate this behavior of Forth trandition. One accidently typing error may c=
>ause many minutes lost to rebuild the stack picture during debug. There is =
>no reason to clear the stack without our permission after failing on search=
>ing a name in the dictionary.

An early version of Gforth used to preserve the stack when not finding
a word.  This was changed to the traditional behaviour for technical
reasons, but in my experience this also improved the usability:

A common usage pattern is to have an empty stack at the start of the
line (or maybe two lines ago), and then put some stuff on the stack,
and consume them before the end of the line (or maybe the next line).
Now if I get an error, I type Cursor-up to get the last typed-in line,
and then, if (as happens often) the stack was empty before the line, I
also want it empty when I rerun the line after correcting it.

What one could do is to save the stack items in the history along with
the lines, and, when doing cursor-up etc., restore the stack to the
state at the start of that line (plus maybe display these stack items
as a comment at the start of the restored line).

- 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 2015: http://www.mpeforth.com/euroforth2015/euroforth2015.htm

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

#40448

Am Donnerstag, 9. Juli 2015 07:32:49 UTC+2 schrieb Anton Ertl:
> jfong writes:
> >I hate this behavior of Forth trandition.
> 
> An early version of Gforth used to preserve the stack when not finding
> a word.  This was changed to the traditional behaviour for technical
> reasons, but in my experience this also improved the usability:

The gforth quit clears the stack on every exception caught by quit, as far as I can see. Not only on typos.

An implementation of quit without exception handler would allow the user to do something like
: my-quit ['] quit catch IF do-something THEN ;
and clear the stack or do something else.

In Java, exceptions will usually be allowed to pass to high abstraction layers which gains flexibility of handling for different use cases.

Also, a common pattern in Java is to catch an exception, do something about it and then (re-)throw an exception to notify higher layers.

If there is no "runtime engine" which may catch uncaught exceptions, then quit must catch them all.

Daniel

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

#40450

djc <ciesinger@gmx.net> writes:
>Am Donnerstag, 9. Juli 2015 07:32:49 UTC+2 schrieb Anton Ertl:
>> jfong writes:
>> >I hate this behavior of Forth trandition.
>> 
>> An early version of Gforth used to preserve the stack when not finding
>> a word.  This was changed to the traditional behaviour for technical
>> reasons, but in my experience this also improved the usability:
>
>The gforth quit clears the stack on every exception caught by quit, as far as I can see. Not only on typos.

Sure.  Earlier it used to preserve the stack on typos, and clear it in
other cases, or something like that.

>An implementation of quit without exception handler would allow the user to do something like
>: my-quit ['] quit catch IF do-something THEN ;
>and clear the stack or do something else.

This cannot work.  QUIT empties the return stack, and forgets
everything about MY-QUIT, including the CATCH.  If it passed
exceptions through, the next thing that would happen is that THROW
reports an uncaught exception and performs BYE.

QUIT may be useful in a system without CATCH-THROW, but with
CATCH-THROW, it does not fit.  Better don't use it.

>In Java, exceptions will usually be allowed to pass to high abstraction layers which gains flexibility of handling for different use cases.
>
>Also, a common pattern in Java is to catch an exception, do something about it and then (re-)throw an exception to notify higher layers.

That's also common in Forth, including within Gforth, and that is the
techical reason why the stack is no longer preserved on typos in
Gforth: With the originally used BOUNCE, the "do-something-about-it"
code would not find the data on the data stack where it expects it,
and even if it does not need the data stack, it then rethrows the
exception with THROW, and THROW resets the stack depth to the level at
the CATCH.

- 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 2015: http://www.mpeforth.com/euroforth2015/euroforth2015.htm

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

#40452

Le jeudi 9 juillet 2015 11:14:17 UTC+2, Anton Ertl a écrit :
> 
> That's also common in Forth, including within Gforth, and that is the
> techical reason why the stack is no longer preserved on typos in
> Gforth: With the originally used BOUNCE, the "do-something-about-it"
> code would not find the data on the data stack where it expects it,
> and even if it does not need the data stack, it then rethrows the
> exception with THROW, and THROW resets the stack depth to the level at
> the CATCH.
> 

Hello,

Is there a reason why THROW resets the stack depth to the level at the 
CATCH ? Is this true for stack values also or just stack level ? What if 
the current depth is less than the depth it has at CATCH level ?

If someone wants to restore this level (to not disturb a caller for
instance), it can do it after the THROW. 

I can't find a reason why it is a part of THROW job...

Franck

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

#40460

franck.bensusan@gmail.com writes:
>Is there a reason why THROW resets the stack depth to the level at the=20
>CATCH ?

Yes. In general, the caller of CATCH does not know in general at what
depth THROW was called, and what's on the stack, so leaving the depth
as-is is not helpful.

> Is this true for stack values also or just stack level ? What if=20
>the current depth is less than the depth it has at CATCH level ?

Only the depth is restored.  If the xt called by CATCH has, e.g., the
stack effect ( x1 x2 -- x3 ), then two stack elements will have
unknown values and will not be useful; typically the caller will drop
them.  CATCH cannot do that by itself, because it does not know the
stack effect of the passed xt.

>If someone wants to restore this level (to not disturb a caller for
>instance), it can do it after the THROW.=20

How?

Sure, it's possible, but it would be cumbersome (and, without
additional words, expensive).  Given that the depth at the THROW and
the stack elements at THROW are not useful for the intended use of
CATCH and THROW, it's good that they are as they are.

If you want a Forth equivalent of Pascal's GOTO, things would be
different, but that's not the purpose of CATCH...THROW, and few
programming languages have followed Pascal in that area (not even
later languages by Wirth), while CATCH..THROW-like mechanisms have
been pretty common, because they are more useful.

- 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 2015: http://www.mpeforth.com/euroforth2015/euroforth2015.htm

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

#40461

Le jeudi 9 juillet 2015 16:34:11 UTC+2, Anton Ertl a écrit :
> franck.bensusan@gmail.com writes:
> >If someone wants to restore this level (to not disturb a caller for
> >instance), it can do it after the THROW.=20
> 
> How?
> 

Each time I had to control the stack depth after a catch, it was always
to clear the stack, so it was easy.

But if I had to set the stack depth at the same level, it would not 
be difficult : save the stack depth into a local and restore this depth
when the exception is catched.

imo, if this is the only reason for this stack reset by THROW, I think
having the stack available for the user after an exception is a much more
valuable feature.

Franck

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

#40464

franck.bensusan@gmail.com writes:
>Le jeudi 9 juillet 2015 16:34:11 UTC+2, Anton Ertl a =E9crit=A0:
>But if I had to set the stack depth at the same level, it would not=20
>be difficult : save the stack depth into a local and restore this depth
>when the exception is catched.

Please demonstrate this, by rewriting this word to use your FB-CATCH
instead of CATCH:

: collect1 ( -- ior )
  ['] collect-garbage catch ;

COLLECT-GARBAGE has the overall stack effect ( -- ).  If you prefer,
you can also do it for the original word:

: alloc ( u -- a-addr ior )
    \ allocate u aus
    grain nalign
    dup alloc-nocollect if ( u addr )
	drop ['] collect-garbage catch
	?dup-if
	    EXIT
	endif
	dup alloc-nocollect if ( u addr )
	    drop alloc-extend EXIT
	endif
    endif
    nip 0 ;

- 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 2015: http://www.mpeforth.com/euroforth2015/euroforth2015.htm

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

#40465

Le jeudi 9 juillet 2015 19:22:33 UTC+2, Anton Ertl a écrit :
> franck.bensusan@gmail.com writes:
> >Le jeudi 9 juillet 2015 16:34:11 UTC+2, Anton Ertl a =E9crit=A0:
> >But if I had to set the stack depth at the same level, it would not=20
> >be difficult : save the stack depth into a local and restore this depth
> >when the exception is catched.
> 
> Please demonstrate this, by rewriting this word to use your FB-CATCH
> instead of CATCH:
> 
> : collect1 ( -- ior )
>   ['] collect-garbage catch ;
> 

My purpose was not to rewrite a new version of CATCH, but to declare a 
local into collect1 to save the stack depth before collect-garbage call and 
restore the stack at the same depth after the CATCH.

Franck

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

#40475

franck.bensusan@gmail.com writes:
>Le jeudi 9 juillet 2015 19:22:33 UTC+2, Anton Ertl a =E9crit=A0:
>> franck.bensusan@gmail.com writes:
>> >Le jeudi 9 juillet 2015 16:34:11 UTC+2, Anton Ertl a =3DE9crit=3DA0:
>> >But if I had to set the stack depth at the same level, it would not=3D20
>> >be difficult : save the stack depth into a local and restore this depth
>> >when the exception is catched.
>>=20
>> Please demonstrate this, by rewriting this word to use your FB-CATCH
>> instead of CATCH:
>>=20
>> : collect1 ( -- ior )
>>   ['] collect-garbage catch ;
>>=20
>
>My purpose was not to rewrite a new version of CATCH, but to declare a=20
>local into collect1 to save the stack depth before collect-garbage call and=
>=20
>restore the stack at the same depth after the CATCH.

Yes, please demonstrate how you would do that.  You claimed that it
"would not be difficult".

- 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 2015: http://www.mpeforth.com/euroforth2015/euroforth2015.htm

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

#40477

Le vendredi 10 juillet 2015 07:54:15 UTC+2, Anton Ertl a écrit :
> franck.bensusan@gmail.com writes:
> >Le jeudi 9 juillet 2015 19:22:33 UTC+2, Anton Ertl a =E9crit=A0:
> >> franck.bensusan@gmail.com writes:
> >> >Le jeudi 9 juillet 2015 16:34:11 UTC+2, Anton Ertl a =3DE9crit=3DA0:
> >> >But if I had to set the stack depth at the same level, it would not=3D20
> >> >be difficult : save the stack depth into a local and restore this depth
> >> >when the exception is catched.
> >>=20
> >> Please demonstrate this, by rewriting this word to use your FB-CATCH
> >> instead of CATCH:
> >>=20
> >> : collect1 ( -- ior )
> >>   ['] collect-garbage catch ;
> >>=20
> >
> >My purpose was not to rewrite a new version of CATCH, but to declare a=20
> >local into collect1 to save the stack depth before collect-garbage call and=
> >=20
> >restore the stack at the same depth after the CATCH.
> 
> Yes, please demonstrate how you would do that.  You claimed that it
> "would not be difficult".
> 
> - 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 2015: http://www.mpeforth.com/euroforth2015/euroforth2015.htm

You make me have a doubt :) 
I don't see the problem... but perhap's there is one...

Not tested, just the idea :

: catch-save-sp  ( -- ; R: -- x )
   @sp >r ;

: catch-rest-sp ( ior -- ior; R: x -- )
   dup 0= IF 
      r> drop 
   ELSE 
      r> swap >r sp! r> 
   THEN ;

:collect1 ( -- ios )
   catch-save-sp ['] collect-garbage fbcatch catch-rest-sp ;

fbcatch : same as catch (whatever it is) but without handling data stack
fbthrow : same as throw (whatever it is) but without handling data stack.

Franck

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

#40481

On Friday, 10 July 2015 07:12:01 UTC+1, franck....@gmail.com  wrote:
> Le vendredi 10 juillet 2015 07:54:15 UTC+2, Anton Ertl a écrit :
> > franck.bensusan@gmail.com writes:
> > >Le jeudi 9 juillet 2015 19:22:33 UTC+2, Anton Ertl a =E9crit=A0:
> > >> franck.bensusan@gmail.com writes:
> > >> >Le jeudi 9 juillet 2015 16:34:11 UTC+2, Anton Ertl a =3DE9crit=3DA0:
> > >> >But if I had to set the stack depth at the same level, it would not=3D20
> > >> >be difficult : save the stack depth into a local and restore this depth
> > >> >when the exception is catched.
> > >>=20
> > >> Please demonstrate this, by rewriting this word to use your FB-CATCH
> > >> instead of CATCH:
> > >>=20
> > >> : collect1 ( -- ior )
> > >>   ['] collect-garbage catch ;
> > >>=20
> > >
> > >My purpose was not to rewrite a new version of CATCH, but to declare a=20
> > >local into collect1 to save the stack depth before collect-garbage call and=
> > >=20
> > >restore the stack at the same depth after the CATCH.
> > 
> > Yes, please demonstrate how you would do that.  You claimed that it
> > "would not be difficult".
> > 
> > - 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 2015: http://www.mpeforth.com/euroforth2015/euroforth2015.htm
> 
> You make me have a doubt :) 
> I don't see the problem... but perhap's there is one...
> 
> Not tested, just the idea :
> 
> : catch-save-sp  ( -- ; R: -- x )
>    @sp >r ;
> 
[snip]

: catch-save-sp  ( -- ; R: -- x )
   @sp >r ;      <------------ ouch!

I can't see how that would work. You're gonna crash as soon
as the word exits.

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

#40483

Le vendredi 10 juillet 2015 10:09:25 UTC+2, Mark Wills a écrit :
> On Friday, 10 July 2015 07:12:01 UTC+1, franck....@gmail.com  wrote:
> > Le vendredi 10 juillet 2015 07:54:15 UTC+2, Anton Ertl a écrit :
> > > franck.bensusan@gmail.com writes:
> > > >Le jeudi 9 juillet 2015 19:22:33 UTC+2, Anton Ertl a =E9crit=A0:
> > > >> franck.bensusan@gmail.com writes:
> > > >> >Le jeudi 9 juillet 2015 16:34:11 UTC+2, Anton Ertl a =3DE9crit=3DA0:
> > > >> >But if I had to set the stack depth at the same level, it would not=3D20
> > > >> >be difficult : save the stack depth into a local and restore this depth
> > > >> >when the exception is catched.
> > > >>=20
> > > >> Please demonstrate this, by rewriting this word to use your FB-CATCH
> > > >> instead of CATCH:
> > > >>=20
> > > >> : collect1 ( -- ior )
> > > >>   ['] collect-garbage catch ;
> > > >>=20
> > > >
> > > >My purpose was not to rewrite a new version of CATCH, but to declare a=20
> > > >local into collect1 to save the stack depth before collect-garbage call and=
> > > >=20
> > > >restore the stack at the same depth after the CATCH.
> > > 
> > > Yes, please demonstrate how you would do that.  You claimed that it
> > > "would not be difficult".
> > > 
> > > - 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 2015: http://www.mpeforth.com/euroforth2015/euroforth2015.htm
> > 
> > You make me have a doubt :) 
> > I don't see the problem... but perhap's there is one...
> > 
> > Not tested, just the idea :
> > 
> > : catch-save-sp  ( -- ; R: -- x )
> >    @sp >r ;
> > 
> [snip]
> 
> : catch-save-sp  ( -- ; R: -- x )
>    @sp >r ;      <------------ ouch!
> 
> I can't see how that would work. You're gonna crash as soon
> as the word exits.

Yes sorry, code must be into collect1...

: collect1 ( -- ior )
   @sp >r
   ['] collect-garbage catch
   dup 0= IF 
      r> drop 
   ELSE 
      r> swap >r sp! r> 
   THEN ; 

I don't know if this IF .. ELSE ... THEN is required... btw. 

: collect2 ( -- ior )
   @sp >r
   ['] collect-garbage catch
   dup r> swap >r sp! r> ; 

Franck

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

Page 1 of 2  [1] 2  Next page →

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

csiph-web