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

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

What about code blocks (not Forth blocks)?

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

Contents

  What about code blocks (not Forth blocks)? Alexander Skobelev <al.skobelev@gmail.com> - 2013-12-17 23:56 -0800
    Re: What about code blocks (not Forth blocks)? mhx@iae.nl - 2013-12-18 01:14 -0800
      Re: What about code blocks (not Forth blocks)? Mark Wills <markrobertwills@yahoo.co.uk> - 2013-12-18 01:34 -0800
      Re: What about code blocks (not Forth blocks)? Alexander Skobelev <al.skobelev@gmail.com> - 2013-12-18 02:33 -0800
        Re: What about code blocks (not Forth blocks)? Coos Haak <chforth@hccnet.nl> - 2013-12-18 14:36 +0100
          Re: What about code blocks (not Forth blocks)? Alexander Skobelev <al.skobelev@gmail.com> - 2013-12-18 06:24 -0800
            Re: What about code blocks (not Forth blocks)? Coos Haak <chforth@hccnet.nl> - 2013-12-19 02:54 +0100
              Re: What about code blocks (not Forth blocks)? Alexander Skobelev <al.skobelev@gmail.com> - 2013-12-18 22:12 -0800
        Re: What about code blocks (not Forth blocks)? mhx@iae.nl - 2013-12-18 05:43 -0800
    Re: What about code blocks (not Forth blocks)? albert@spenarnc.xs4all.nl (Albert van der Horst) - 2013-12-18 11:21 +0000
      Re: What about code blocks (not Forth blocks)? Alexander Skobelev <al.skobelev@gmail.com> - 2013-12-18 04:31 -0800
        Re: What about code blocks (not Forth blocks)? Ilya Tarasov <ilya74.tarasov@gmail.com> - 2013-12-18 04:49 -0800
          Re: What about code blocks (not Forth blocks)? Alexander Skobelev <al.skobelev@gmail.com> - 2013-12-18 05:12 -0800
    Re: What about code blocks (not Forth blocks)? "Elizabeth D. Rather" <erather@forth.com> - 2013-12-18 08:26 -1000
      Re: What about code blocks (not Forth blocks)? Paul Rubin <no.email@nospam.invalid> - 2013-12-18 11:03 -0800
        Re: What about code blocks (not Forth blocks)? Alexander Skobelev <al.skobelev@gmail.com> - 2013-12-18 11:21 -0800
      Re: What about code blocks (not Forth blocks)? Alexander Skobelev <al.skobelev@gmail.com> - 2013-12-18 11:19 -0800
        Re: What about code blocks (not Forth blocks)? "Elizabeth D. Rather" <erather@forth.com> - 2013-12-18 10:08 -1000
          Re: What about code blocks (not Forth blocks)? Bernd Paysan <bernd.paysan@gmx.de> - 2013-12-18 21:58 +0100
            Re: What about code blocks (not Forth blocks)? "Ed" <invalid@invalid.com> - 2013-12-19 14:15 +1100
              Re: What about code blocks (not Forth blocks)? "Alex McDonald" <blog@rivadpm.com> - 2013-12-19 13:32 +0000
                Re: What about code blocks (not Forth blocks)? "Ed" <invalid@invalid.com> - 2013-12-20 21:07 +1100
                  Re: What about code blocks (not Forth blocks)? "Alex McDonald" <blog@rivadpm.com> - 2013-12-20 12:35 +0000
                    Re: What about code blocks (not Forth blocks)? "Alex McDonald" <blog@rivadpm.com> - 2013-12-20 13:02 +0000
                    Re: What about code blocks (not Forth blocks)? "Ed" <invalid@invalid.com> - 2013-12-22 14:19 +1100
                      Re: What about code blocks (not Forth blocks)? "Alex McDonald" <blog@rivadpm.com> - 2013-12-22 10:15 +0000
                        Re: What about code blocks (not Forth blocks)? "Ed" <invalid@invalid.com> - 2013-12-24 12:30 +1100
                          Re: What about code blocks (not Forth blocks)? albert@spenarnc.xs4all.nl (Albert van der Horst) - 2013-12-24 16:48 +0000
                            Re: What about code blocks (not Forth blocks)? "Ed" <invalid@invalid.com> - 2013-12-28 11:08 +1100
                              Re: What about code blocks (not Forth blocks)? albert@spenarnc.xs4all.nl (Albert van der Horst) - 2013-12-28 11:40 +0000
                          Re: What about code blocks (not Forth blocks)? anton@mips.complang.tuwien.ac.at (Anton Ertl) - 2013-12-26 18:03 +0000
                            Re: What about code blocks (not Forth blocks)? Paul Rubin <no.email@nospam.invalid> - 2013-12-26 10:34 -0800
                              Re: What about code blocks (not Forth blocks)? anton@mips.complang.tuwien.ac.at (Anton Ertl) - 2013-12-27 15:53 +0000
                                Re: What about code blocks (not Forth blocks)? Gerry Jackson <gerry@jackson9000.fsnet.co.uk> - 2013-12-28 17:26 +0000
                                  Re: What about code blocks (not Forth blocks)? anton@mips.complang.tuwien.ac.at (Anton Ertl) - 2013-12-28 17:53 +0000
                                    Re: What about code blocks (not Forth blocks)? Gerry Jackson <gerry@jackson9000.fsnet.co.uk> - 2013-12-28 18:21 +0000
                                      Re: What about code blocks (not Forth blocks)? anton@mips.complang.tuwien.ac.at (Anton Ertl) - 2013-12-29 14:49 +0000
                                        Re: What about code blocks (not Forth blocks)? Gerry Jackson <gerry@jackson9000.fsnet.co.uk> - 2013-12-29 20:45 +0000
                                          Re: What about code blocks (not Forth blocks)? anton@mips.complang.tuwien.ac.at (Anton Ertl) - 2013-12-30 17:08 +0000
                                            Re: What about code blocks (not Forth blocks)? Gerry Jackson <gerry@jackson9000.fsnet.co.uk> - 2013-12-30 20:00 +0000
                                  Re: What about code blocks (not Forth blocks)? albert@spenarnc.xs4all.nl (Albert van der Horst) - 2013-12-28 18:04 +0000
                                    Re: What about code blocks (not Forth blocks)? Gerry Jackson <gerry@jackson9000.fsnet.co.uk> - 2013-12-28 18:47 +0000
                                      Re: What about code blocks (not Forth blocks)? Gerry Jackson <gerry@jackson9000.fsnet.co.uk> - 2013-12-28 19:12 +0000
                            Re: What about code blocks (not Forth blocks)? "Ed" <invalid@invalid.com> - 2013-12-28 11:09 +1100
                              Re: What about code blocks (not Forth blocks)? anton@mips.complang.tuwien.ac.at (Anton Ertl) - 2013-12-28 13:45 +0000
            Re: What about code blocks (not Forth blocks)? Elizabeth D Rather <erather@forth.com> - 2013-12-18 19:04 -1000
              Re: What about code blocks (not Forth blocks)? anton@mips.complang.tuwien.ac.at (Anton Ertl) - 2013-12-19 09:25 +0000
              Re: What about code blocks (not Forth blocks)? Paul Rubin <no.email@nospam.invalid> - 2013-12-19 05:00 -0800
          Re: What about code blocks (not Forth blocks)? Alexander Skobelev <al.skobelev@gmail.com> - 2013-12-18 23:41 -0800
          Re: What about code blocks (not Forth blocks)? Alexander Skobelev <al.skobelev@gmail.com> - 2013-12-19 01:00 -0800
          Re: What about code blocks (not Forth blocks)? Alexander Skobelev <al.skobelev@gmail.com> - 2013-12-19 02:47 -0800
            Re: What about code blocks (not Forth blocks)? Gerry Jackson <gerry@jackson9000.fsnet.co.uk> - 2013-12-19 11:23 +0000
              Re: What about code blocks (not Forth blocks)? Alexander Skobelev <al.skobelev@gmail.com> - 2013-12-19 03:52 -0800
    Re: What about code blocks (not Forth blocks)? anton@mips.complang.tuwien.ac.at (Anton Ertl) - 2013-12-19 15:58 +0000
      Re: What about code blocks (not Forth blocks)? Paul Rubin <no.email@nospam.invalid> - 2013-12-19 10:05 -0800
        Re: What about code blocks (not Forth blocks)? "Alex McDonald" <blog@rivadpm.com> - 2013-12-19 20:07 +0000
          Re: What about code blocks (not Forth blocks)? Paul Rubin <no.email@nospam.invalid> - 2013-12-19 12:33 -0800
            Re: What about code blocks (not Forth blocks)? "Alex McDonald" <blog@rivadpm.com> - 2013-12-19 20:33 +0000
              Re: What about code blocks (not Forth blocks)? albert@spenarnc.xs4all.nl (Albert van der Horst) - 2013-12-19 20:52 +0000
              Re: What about code blocks (not Forth blocks)? Paul Rubin <no.email@nospam.invalid> - 2013-12-19 18:52 -0800
            Re: What about code blocks (not Forth blocks)? Andrew Haley <andrew29@littlepinkcloud.invalid> - 2013-12-28 12:52 -0600
              Re: What about code blocks (not Forth blocks)? Paul Rubin <no.email@nospam.invalid> - 2013-12-28 11:47 -0800
                Re: What about code blocks (not Forth blocks)? Andrew Haley <andrew29@littlepinkcloud.invalid> - 2013-12-29 07:39 -0600
                  Re: What about code blocks (not Forth blocks)? Paul Rubin <no.email@nospam.invalid> - 2013-12-29 08:11 -0800
              Re: What about code blocks (not Forth blocks)? anton@mips.complang.tuwien.ac.at (Anton Ertl) - 2013-12-29 15:25 +0000
                Re: What about code blocks (not Forth blocks)? Paul Rubin <no.email@nospam.invalid> - 2013-12-29 08:15 -0800
                  Re: What about code blocks (not Forth blocks)? anton@mips.complang.tuwien.ac.at (Anton Ertl) - 2013-12-29 16:03 +0000
                    Re: What about code blocks (not Forth blocks)? Gerry Jackson <gerry@jackson9000.fsnet.co.uk> - 2013-12-29 20:54 +0000
                      Re: What about code blocks (not Forth blocks)? mhx@iae.nl - 2013-12-29 13:38 -0800
                      Re: What about code blocks (not Forth blocks)? anton@mips.complang.tuwien.ac.at (Anton Ertl) - 2013-12-30 17:04 +0000
                        Re: What about code blocks (not Forth blocks)? Gerry Jackson <gerry@jackson9000.fsnet.co.uk> - 2013-12-30 20:05 +0000
                          Re: What about code blocks (not Forth blocks)? Paul Rubin <no.email@nospam.invalid> - 2013-12-30 16:49 -0800
                          Re: What about code blocks (not Forth blocks)? anton@mips.complang.tuwien.ac.at (Anton Ertl) - 2014-01-02 17:27 +0000
                Re: What about code blocks (not Forth blocks)? Andrew Haley <andrew29@littlepinkcloud.invalid> - 2013-12-29 16:40 -0600
                  Re: What about code blocks (not Forth blocks)? anton@mips.complang.tuwien.ac.at (Anton Ertl) - 2013-12-30 16:51 +0000
                    Re: What about code blocks (not Forth blocks)? Andrew Haley <andrew29@littlepinkcloud.invalid> - 2013-12-30 11:15 -0600
                      Re: What about code blocks (not Forth blocks)? anton@mips.complang.tuwien.ac.at (Anton Ertl) - 2013-12-30 17:37 +0000
                        Re: What about code blocks (not Forth blocks)? Andrew Haley <andrew29@littlepinkcloud.invalid> - 2013-12-30 12:07 -0600
          Re: What about code blocks (not Forth blocks)? "Alex McDonald" <blog@rivadpm.com> - 2013-12-20 13:50 +0000
        Re: What about code blocks (not Forth blocks)? hughaguilar96@yahoo.com - 2013-12-19 21:49 -0800
          Re: What about code blocks (not Forth blocks)? "Alex McDonald" <blog@rivadpm.com> - 2013-12-20 08:56 +0000
            Re: What about code blocks (not Forth blocks)? hughaguilar96@yahoo.com - 2014-04-03 19:13 -0700
          Re: What about code blocks (not Forth blocks)? "WJ" <w_a_x_man@yahoo.com> - 2014-03-11 05:35 +0000
            Re: What about code blocks (not Forth blocks)? Bernd Paysan <bernd.paysan@gmx.de> - 2014-03-11 12:59 +0100
              Re: What about code blocks (not Forth blocks)? hughaguilar96@yahoo.com - 2014-03-11 23:44 -0700
                Re: What about code blocks (not Forth blocks)? Julian Fondren <ayrnieu@gmail.com> - 2014-03-12 11:48 -0700
                  Re: What about code blocks (not Forth blocks)? Bernd Paysan <bernd.paysan@gmx.de> - 2014-03-12 20:21 +0100
                    Re: What about code blocks (not Forth blocks)? hughaguilar96@yahoo.com - 2014-03-12 23:35 -0700
                      Re: What about code blocks (not Forth blocks)? "Alex McDonald" <blog@rivadpm.com> - 2014-03-14 14:25 +0000
                        Re: What about code blocks (not Forth blocks)? Bernd Paysan <bernd.paysan@gmx.de> - 2014-03-14 16:36 +0100
                          Re: What about code blocks (not Forth blocks)? mhx@iae.nl - 2014-03-14 11:27 -0700
                          Re: What about code blocks (not Forth blocks)? hughaguilar96@yahoo.com - 2014-03-16 17:38 -0700
                            Re: What about code blocks (not Forth blocks)? "Rod Pemberton" <dont_use_email@xnothavet.cqm> - 2014-03-17 03:35 -0400
                          Re: What about code blocks (not Forth blocks)? Paul Rubin <no.email@nospam.invalid> - 2014-03-17 20:36 -0700
                            Re: What about code blocks (not Forth blocks)? anton@mips.complang.tuwien.ac.at (Anton Ertl) - 2014-03-18 13:13 +0000
                              Re: What about code blocks (not Forth blocks)? albert@spenarnc.xs4all.nl (Albert van der Horst) - 2014-03-18 14:28 +0000
                              Re: What about code blocks (not Forth blocks)? Paul Rubin <no.email@nospam.invalid> - 2014-03-18 10:10 -0700
                              Re: What about code blocks (not Forth blocks)? Paul Rubin <no.email@nospam.invalid> - 2014-03-25 12:54 -0700
                                Re: What about code blocks (not Forth blocks)? hughaguilar96@yahoo.com - 2014-03-25 23:09 -0700
                                Re: What about code blocks (not Forth blocks)? anton@mips.complang.tuwien.ac.at (Anton Ertl) - 2014-03-26 13:49 +0000
                                  Re: What about code blocks (not Forth blocks)? Bernd Paysan <bernd.paysan@gmx.de> - 2014-03-26 22:07 +0100
                            Re: What about code blocks (not Forth blocks)? hughaguilar96@yahoo.com - 2014-03-20 22:11 -0700
                          Re: What about code blocks (not Forth blocks)? hughaguilar96@yahoo.com - 2014-03-28 22:18 -0700
                            Re: What about code blocks (not Forth blocks)? "Alex McDonald" <blog@rivadpm.com> - 2014-03-29 10:57 +0000
                    Re: What about code blocks (not Forth blocks)? anton@mips.complang.tuwien.ac.at (Anton Ertl) - 2014-03-13 16:42 +0000
            Re: What about code blocks (not Forth blocks)? albert@spenarnc.xs4all.nl (Albert van der Horst) - 2014-03-11 12:51 +0000
              Re: What about code blocks (not Forth blocks)? "Alex McDonald" <blog@rivadpm.com> - 2014-03-11 14:54 +0000
      Re: What about code blocks (not Forth blocks)? Alexander Skobelev <al.skobelev@gmail.com> - 2013-12-19 21:36 -0800
        Re: What about code blocks (not Forth blocks)? anton@mips.complang.tuwien.ac.at (Anton Ertl) - 2013-12-20 16:56 +0000
      Re: What about code blocks (not Forth blocks)? Alexander Skobelev <al.skobelev@gmail.com> - 2013-12-19 23:24 -0800
        Re: What about code blocks (not Forth blocks)? mhx@iae.nl - 2013-12-20 02:05 -0800
        Re: What about code blocks (not Forth blocks)? anton@mips.complang.tuwien.ac.at (Anton Ertl) - 2013-12-20 12:41 +0000
          Re: What about code blocks (not Forth blocks)? anton@mips.complang.tuwien.ac.at (Anton Ertl) - 2013-12-20 17:46 +0000
            Re: What about code blocks (not Forth blocks)? Alexander Skobelev <al.skobelev@gmail.com> - 2013-12-21 08:11 -0800
              Re: What about code blocks (not Forth blocks)? anton@mips.complang.tuwien.ac.at (Anton Ertl) - 2013-12-23 10:07 +0000
                Re: What about code blocks (not Forth blocks)? Bernd Paysan <bernd.paysan@gmx.de> - 2013-12-23 19:31 +0100
                  Re: What about code blocks (not Forth blocks)? anton@mips.complang.tuwien.ac.at (Anton Ertl) - 2013-12-26 17:45 +0000

Page 3 of 6 — ← Prev page 1 2 [3] 4 5 6  Next page →

#27488

In article <l9n1j5$h15$1@dont-email.me>,
Gerry Jackson  <gerry@jackson9000.fsnet.co.uk> wrote:
>On 27/12/2013 15:53, Anton Ertl wrote:
>[...]
>
>> But I think this is coming from technical issues, and here's how it
>> happened.  Forth-94 gave us CATCH, which is a success, and SAVE-INPUT
>> RESTORE-INPUT, which are a failure.
>
>Why do you say SAVE-INPUT and RESTORE-INPUT are a failure? I've found
>them useful and I'd hate to see them removed from Forth 200X.

I find them unusable as is.




>
>[...]
>
>
>--
>Gerry

Newsgroups: comp.lang.forth
Subject: Re: What about code blocks (not Forth blocks)?
Summary:
Expires:
References: <583c56b0-8514-4e6c-a120-029bce9ad7c1@googlegroups.com> <7x61qbzck5.fsf@ruckus.brouhaha.com> <2013Dec27.165339@mips.complang.tuwien.ac.at> <l9n1j5$h15$1@dont-email.me>
Sender:
Followup-To:
Distribution:
Organization:
Keywords:
Cc:

In article <l9n1j5$h15$1@dont-email.me>,
Gerry Jackson  <gerry@jackson9000.fsnet.co.uk> wrote:
>On 27/12/2013 15:53, Anton Ertl wrote:
>[...]
>
>> But I think this is coming from technical issues, and here's how it
>> happened.  Forth-94 gave us CATCH, which is a success, and SAVE-INPUT
>> RESTORE-INPUT, which are a failure.
>
>Why do you say SAVE-INPUT and RESTORE-INPUT are a failure? I've found
>them useful and I'd hate to see them removed from Forth 200X.

I find them unusable as is.
The data is in the way for anything else. Because it is so flexible
(with the count and all) it is a pain to store on the return stack.
The idea that there is a usage other then nesting input sources
is strange. I can't imagine that is useful for anything.
In the meantime an implementor is burdened with being forced
to make it possible to suspend compiling an input source and
go one with an other one and switch back.
If I would be a serious implementor, I would have to define
a test where this back and forth is done several times.
Then you must read the standard in order to find out whether this
switching can take place in compilation mode.
A serious test for this would be a nightmare ... and to what
purpose?

I have SAVE and RESTORE.
" SAVE            ( -- )
    Save the content of SRC on the return stack to prepare for
    changing the current input source. This must be balanced by a
    RESTORE in the same definition.
"
You see here that the burden on the implementor is simply to
supply something usable. If the user does more than just changing
the current input source he is on his own.

Of course my forth is simplistic but then you have approximately
: INCLUDED SAVE GET-FILE EVALUATE RESTORE ;
(in real life adorned with some CATCH/THROW stuff).

I could use SAVE-INPUT as a factor of SAVE, but actually SAVE itself
is simpler. I would have to define a couple of auxiliary words in
order to make SAVE-INPUT practical.

Bottom-line my SAVE-INPUT is a loadable extension and I expect nobody
to use it.

"content of SRC" stands for "specification of the current input source".

>--
>Gerry

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] | [prev] | [next] | [standalone]

#27490

On 28/12/2013 18:04, Albert van der Horst wrote:
> In article <l9n1j5$h15$1@dont-email.me>,
> Gerry Jackson  <gerry@jackson9000.fsnet.co.uk> wrote:
>> On 27/12/2013 15:53, Anton Ertl wrote:
>> [...]
>>
>>> But I think this is coming from technical issues, and here's how it
>>> happened.  Forth-94 gave us CATCH, which is a success, and SAVE-INPUT
>>> RESTORE-INPUT, which are a failure.
>>
>> Why do you say SAVE-INPUT and RESTORE-INPUT are a failure? I've found
>> them useful and I'd hate to see them removed from Forth 200X.
>
> I find them unusable as is.
> The data is in the way for anything else. Because it is so flexible
> (with the count and all) it is a pain to store on the return stack.

Using N>R and NR> is a pain?

> The idea that there is a usage other then nesting input sources
> is strange. I can't imagine that is useful for anything.

ANS compliant control flow in interpretation mode

> In the meantime an implementor is burdened with being forced
> to make it possible to suspend compiling an input source and
> go one with an other one and switch back.

Isn't that already necessary, what in ANS Forth stops a programmer 
writing something like:

: foo bar [ s" some-file.fth" included ] baz ;

where the file contains compilable source code. I'm not arguing it is 
sensible, I don't know, just that it's possible already.

> If I would be a serious implementor, I would have to define
> a test where this back and forth is done several times.
> Then you must read the standard in order to find out whether this
> switching can take place in compilation mode.

I can't see where it's forbidden.

> A serious test for this would be a nightmare ... and to what
> purpose?

Perhaps I should add something to the File wordset test programs.

>
> I have SAVE and RESTORE.
> " SAVE            ( -- )
>      Save the content of SRC on the return stack to prepare for
>      changing the current input source. This must be balanced by a
>      RESTORE in the same definition.
> "
> You see here that the burden on the implementor is simply to
> supply something usable. If the user does more than just changing
> the current input source he is on his own.
>
> Of course my forth is simplistic but then you have approximately
> : INCLUDED SAVE GET-FILE EVALUATE RESTORE ;
> (in real life adorned with some CATCH/THROW stuff).
>
> I could use SAVE-INPUT as a factor of SAVE, but actually SAVE itself
> is simpler. I would have to define a couple of auxiliary words in
> order to make SAVE-INPUT practical.

At first sight your SAVE and RESTORE seem sensible, but they're not in 
ANS Forth or Forth 200X. We can define your words as

: SAVE SAVE-INPUT N>R ;
: RESTORE NR> RESTORE-INPUT ;

>
> Bottom-line my SAVE-INPUT is a loadable extension and I expect nobody
> to use it.

So why provide it? It's not mandatory.

>
> "content of SRC" stands for "specification of the current input source".
>

-- 
Gerry

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

#27492

On 28/12/2013 18:47, Gerry Jackson wrote:
> On 28/12/2013 18:04, Albert van der Horst wrote:
>> In the meantime an implementor is burdened with being forced
>> to make it possible to suspend compiling an input source and
>> go one with an other one and switch back.
>
> Isn't that already necessary, what in ANS Forth stops a programmer
> writing something like:
>
> : foo bar [ s" some-file.fth" included ] baz ;

Sorry, I realised soon after pressing Send that this is not a correct 
example as it is not in compilation mode when the file is included. 
Please ignore the above. What about

: foo s" some-file.fth" included ; immediate
: bar ... foo ... ;

INCLUDED doesn't change the value of STATE so the system stays in 
compilation mode doesn't it?

-- 
Gerry

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

#27483

Anton Ertl wrote:
> "Ed" <invalid@invalid.com> writes:
> >Quotations don't exist in Forth because they've never been necessary.
>
> They have not been necessary in the past when we did not have words
> that take xts.  Now we have these words, and quotations are at least
> convenient.

Do a search of  [']  instances then tell me Forth has never had words that
take xt's.

> >They force the programmer to make arbitrary decisions - when to use
> >quotations, when not.
>
> It's Forth, not a nanny programming language.  There are lots of
> choices available to Forth programmers, and that's not a bad thing.
> E.g., the decision on how to factor or how to name a word.

No sane language foists upon its users the choices Forth committees
have wrought:

Shall I use  [CHAR] A  or  'A'  ?

Shall I use  LOCALS|  or  {:  :}  ?

Shall I factor or use quotations ?

It's as if application writers had nothing better to do with their time
than obsess over looks.

I say no to silly choices and the committees that spawn them.  That's
my choice.

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

#27485

"Ed" <invalid@invalid.com> writes:
>Anton Ertl wrote:
>> They have not been necessary in the past when we did not have words
>> that take xts.  Now we have these words, and quotations are at least
>> convenient.
>
>Do a search of  [']  instances then tell me Forth has never had words that
>take xt's.

I took a look.

A number of uses of ['] are in combination with IS.  Given that the
deferred word obviously merits a proper name, naming the xt is pretty
natural.

In some cases quotations might have resulted in better factoring.

>No sane language foists upon its users the choices Forth committees
>have wrought:

Can you name a "sane language"?

>Shall I use  [CHAR] A  or  'A'  ?

Simple: Use 'A', unless you want portability to older systems.

>Shall I use  LOCALS|  or  {:  :}  ?

Simple: Use {:.  If you want portability to older systems, use {:,
<http://www.forth200x.org/reference-implementations/locals.fs>,
<http://www.forth200x.org/reference-implementations/parse-name.fs>.
Never ever use LOCALS|.

>Shall I factor or use quotations ?

Shall you factor a sequence of code into a named colon definition or
keep it inline?  That's a chice you have to make in Forth with or
without quotations.  And you have to make the same choice in every
other programming language.  I am really interested in which "sane
language" absolves you of that choice.

- 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 2013: http://www.euroforth.org/ef13/

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

#27345

On 12/18/2013 10:58 AM, Bernd Paysan wrote:
> Elizabeth D. Rather wrote:
>> Sounds more like a question of programming style. In my experience, a
>> sequence that's worth factoring has a conceptual name, and may as well
>> be a definition. I never saw making definitions as a chore! One common
>> approach for naming a major factor of NAME is (NAME), for example. I'd
>> much rather see a reference to a name than a long string of code, and if
>> you needed to see what the word does, you can use LOCATE on any good
>> implementation.
>
> These quotations often go in some sort of what we perceive as control
> structure.  Take TRAVERSE-WORDLIST: It is an implicit loop over the words in
> a wordlist.  WORDS is something like
>
> : words ( -- ) [: .name true ;] current @ traverse-wordlist ;
 >
> As the xt passed to traverse-wordlist needs a "continue" flag, we don't want
> to make this trivial composition a named word of its own.  .NAME is fine as
> word of its own, but a .NAME with a true flag returned wouldn't.

A flag that's always 'true' is useless. Why not just write .name at the
appropriate point in the traverse-wordlist loop? Or, if you need a variable
behavior, use a DEFER? Either would be a lot more straightforward and 
readable,
to me.

> Another example: To wrap words which are BASE-sensitive into a secure layer
> that works even when the word crashes in the middle, we use BASE-EXECUTE.
> Usually this is a very simple word like
>
> : dump-byte ( addr -- addr' ) count [: 2 u.r space ;] $10 base-execute ;
>
> or so.  Factoring these two one-liners even further, and giving the snippets
> a name is too much.  If you have a lengthy piece of code, yes, please give
> it a name or more than one.

Well, I don't handle BASE that way anyhow. My rule is that there is a 
default base (normally DECIMAL) and any word that changes it has the 
obligation to change it back, so there's no need for something like 
base-execute. All of these examples look harder to read than plain 
Forth, to me.

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]

#27350

Elizabeth D Rather <erather@forth.com> writes:
>On 12/18/2013 10:58 AM, Bernd Paysan wrote:
>> These quotations often go in some sort of what we perceive as control
>> structure.  Take TRAVERSE-WORDLIST: It is an implicit loop over the words in
>> a wordlist.  WORDS is something like
>>
>> : words ( -- ) [: .name true ;] current @ traverse-wordlist ;
> >
>> As the xt passed to traverse-wordlist needs a "continue" flag, we don't want
>> to make this trivial composition a named word of its own.  .NAME is fine as
>> word of its own, but a .NAME with a true flag returned wouldn't.
>
>A flag that's always 'true' is useless.

It's not necessarily always true.  You can use it for early
termination of the loop.  I have read several complaints that Gforth's
WORDS just works as shown above.  One way to fix it would be:

: words ( -- )
  [: .name key? dup if key then ;] current @ traverse-wordlist ;

> Why not just write .name at the
>appropriate point in the traverse-wordlist loop?

Because TRAVERSE-WORDLIST is in the system's code and the application
programmer does not necessarily know how to implement it for every
system around, and certainly does not want to implement it for every
system around.

>> Another example: To wrap words which are BASE-sensitive into a secure layer
>> that works even when the word crashes in the middle, we use BASE-EXECUTE.
>> Usually this is a very simple word like
>>
>> : dump-byte ( addr -- addr' ) count [: 2 u.r space ;] $10 base-execute ;
>>
>> or so.  Factoring these two one-liners even further, and giving the snippets
>> a name is too much.  If you have a lengthy piece of code, yes, please give
>> it a name or more than one.
>
>Well, I don't handle BASE that way anyhow. My rule is that there is a 
>default base (normally DECIMAL) and any word that changes it has the 
>obligation to change it back, so there's no need for something like 
>base-execute.

BASE-EXECUTE is a tool to satisfy that obligation.  Code written in
what you call "plain Forth" doesn't, e.g., SwiftForth's DUMP:

here 100000 dump
[...]
 8093FB9 58 02 2C 00 4F 2E 6DSignal #2 at F7FDF430
10 decimal . 16  ok

>All of these examples look harder to read than plain
>Forth, to me.

And you probably don't like CATCH, either.  That's another word that
takes an xt and which makes it necessary to either use quotations or
produce named definitions that do not correspond to a concept.

This kind of interface, which I call wrappers (they do things before
and after the words that they call through their xts) has turned out
to be very useful and avoids problems and complexities that dividing
the functionality into multiple words has.  Examples of wrappers are
CATCH, TRAVERSE-WORDLIST, BASE-EXECUTE, EXECUTE-PARSING and
OUTFILE-EXECUTE (redirects the output of the executed word to a file,
and it would really be inconvenient if that redirection did not end
when the word is left through an exception).

But wrappers introduce the need to create xts for code that is not a
conceptual entity and therefore does not deserve a name, i.e., the
need for quotations.

- 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 2013: http://www.euroforth.org/ef13/

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

#27357

Elizabeth D Rather <erather@forth.com> writes:
>> : words ( -- ) [: .name true ;] current @ traverse-wordlist ; ...
> A flag that's always 'true' is useless. Why not just write .name at the
> appropriate point in the traverse-wordlist loop? 

That means hacking the internals of an existing word, instead of
re-using it.  

I think the issue here is with a coding style that involves passing xt'x
around instead of more explicit parameters.  This is something like OOP,
in that it wasn't initially common in pure Forth but came along later.

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

#27347

Exactly, that is just a question of programming style. I see you point and find
it as a reasonable one. On the other hand I see there are people who think these
construction can be useful. 

The question is what will happen if to make this addition to Forth and what wil
happen if not to make. In the first case, it requires to Forth vendors to make
changes in their implementations (and here is the question: how much the should
change?) and after that who votes against are fre to not use it and who is votes
for are happy to use. In the second case the vendors are happy because they
don't need to make any changes, the people who votes against are happy because
nothing changes, and the people who votes for are unhappy because they haven't
got what they wanted.

So in the both cases the people's voted against are more or less happy. So there
is a dilemma between unhappiness of the vendors and happiness of the some part
of their users.

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

#27348

On Thursday, December 19, 2013 12:08:42 AM UTC+4, Elizabeth D Rather wrote:
> On 12/18/13 9:19 AM, Alexander Skobelev wrote:
> > On Wednesday, December 18, 2013 10:26:43 PM UTC+4, Elizabeth D. Rather wrote:
> >> On 12/17/13 9:56 PM, Alexander Skobelev wrote:
> >>
> >>> Hello all, I'm just wondering, what is common opinion (if it
> >>> exists) about using code blocks (something like 'quotes' in Retro
> >>> forth) among experienced Forthers? Would it be a valuable addition
> >>> to Forth?
> >>>
> >>> Just for example here a very naive Gforth-specific implementation
> >>> of local code blocks (i.e not intended to be used anywhere but
> >>> only inside a word definition):
> >>>
> >>
> >> Could you explain what you see as the advantage of such blocks vs. Forth
> >> definitions? I'm not sure what problem you're trying to solve.
> >>
> >
> > Well, I think, such blocks could make a program code clearer.
> > While they behave like a separate definition (in a sense that they are
> > identified by XT and they get control with a call to EXECUTE), they
> > existence is only meaningful in the context of a definition where they
> > are defined.  They can be useful for iterating over array, or as arguments
> > to some short-circuit operators. Of course the Forth definition can be
> > used in these applications very well, but you need to create a separate
> > definition. You need to think how to name it and not to clash with
> > existing names. Even if it can be sit very close to the place you use it,
> > it is still somewhat out of context the definition that uses it. If
> > you make any changes in that definition, you need go back and check,
> > if nothing has broken in that helper.
> >
> > So this is only a question of convenience and a language flexibility.
> 
> Sounds more like a question of programming style. In my experience, a 
> sequence that's worth factoring has a conceptual name, and may as well 
> be a definition. I never saw making definitions as a chore! One common 
> approach for naming a major factor of NAME is (NAME), for example. I'd 
> much rather see a reference to a name than a long string of code, and if 
> you needed to see what the word does, you can use LOCATE on any good 
> implementation.
> 

BTW here is one more example One more example yet. If implement [| |] to allow
nested blocks (by using some stack instead of CFA-ADDR in my implementation for
example) we can do the following:

: (xt?) ( flag|xt -- flag )
    dup 
    0= if
        drop
        FALSE
    else 
        TRUE <>
    then ;

: e-or ( flag|xt xt - flag )
    swap dup (xt?) if execute then
    if
        TRUE
    else
        dup (xt?) if execute then
    then ; 

: e-and ( flag|xt xt - flag )
    swap dup (xt?) if execute then
    if
        dup (xt?) if execute then
    else
        FALSE
    then ; 


: cstring-contains ( c-addr1 u1 c-addr2 u2 -- flag )
    search -rot 2drop ;

: cstring-prefix { c-addr1 u1 c-addr2 u2 -- flag }
    c-addr1 u1 c-addr2 u2 search if drop c-addr1 = else 2drop FALSE then ;

: test-hello { c-addr u -- }
    u 15 <
    [|
        [| c-addr u S" Hello"         cstring-prefix   |] 
        [| c-addr u S" How do you do" cstring-contains |] e-or
        [| c-addr u S" How are you"   cstring-contains |] e-or
        [| c-addr u S" Good morning"  cstring-prefix   |] e-or
    |] e-and
 
    if ." Hello! " else ." Bye!" then cr ;

s" Hi!" test-hello
s" Hello" test-hello
s" Hello my little fellow" test-hello

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

#27352

Here is one more example One more example yet. If implement [| |] to allow
nested blocks (by using some stack instead of CFA-ADDR in my implementation for
example) we can do the following:

: (xt?) ( flag|xt -- flag )
    dup
    0= if
        drop
        FALSE
    else
        TRUE <>
    then ;

: e-or ( flag|xt xt - flag )
    swap dup (xt?) if execute then
    if
        drop
        TRUE
    else
        dup (xt?) if execute then
    then ;

: e-and ( flag|xt xt - flag )
    swap dup (xt?) if execute then
    if
        dup (xt?) if execute then
    else
        drop
        FALSE
    then ;


: cstring-contains ( c-addr1 u1 c-addr2 u2 -- flag )
    search -rot 2drop ;

: cstring-prefix { c-addr1 u1 c-addr2 u2 -- flag }
    c-addr1 u1 c-addr2 u2 search if drop c-addr1 = else 2drop FALSE then ;

: test-hello { c-addr u -- }
    u 15 <
    [|
        [| c-addr u S" Hello"         cstring-prefix   |]
        [| c-addr u S" How do you do" cstring-contains |] e-or
        [| c-addr u S" How are you"   cstring-contains |] e-or
        [| c-addr u S" Good morning"  cstring-prefix   |] e-or
    |] e-and
 
    if ." Hello! " else ." Bye!" then cr ;

s" Hi!" test-hello
s" Hello" test-hello
s" Hello my little fellow" test-hello 

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

#27355

On 19/12/2013 10:47, Alexander Skobelev wrote:
[...]

> : test-hello { c-addr u -- }
>      u 15 <
>      [|
>          [| c-addr u S" Hello"         cstring-prefix   |]
>          [| c-addr u S" How do you do" cstring-contains |] e-or
>          [| c-addr u S" How are you"   cstring-contains |] e-or
>          [| c-addr u S" Good morning"  cstring-prefix   |] e-or
>      |] e-and
>
>      if ." Hello! " else ." Bye!" then cr ;
>
> s" Hi!" test-hello
> s" Hello" test-hello
> s" Hello my little fellow" test-hello
>

If you want to maintain some compatibility with notation that has been 
agreed by most in previous discussions, it would be better to use:
     [: ... ;]
instead of
     [| ... |]

-- 
Gerry

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

#27356

On Thursday, December 19, 2013 3:23:38 PM UTC+4, Gerry wrote:
> On 19/12/2013 10:47, Alexander Skobelev wrote:
> [...]
> 
> > : test-hello { c-addr u -- }
> >      u 15 <
> >      [|
> >          [| c-addr u S" Hello"         cstring-prefix   |]
> >          [| c-addr u S" How do you do" cstring-contains |] e-or
> >          [| c-addr u S" How are you"   cstring-contains |] e-or
> >          [| c-addr u S" Good morning"  cstring-prefix   |] e-or
> >      |] e-and
> >
> >      if ." Hello! " else ." Bye!" then cr ;
> >
> > s" Hi!" test-hello
> > s" Hello" test-hello
> > s" Hello my little fellow" test-hello
> >
> 
> If you want to maintain some compatibility with notation that has been 
> agreed by most in previous discussions, it would be better to use:
>      [: ... ;]
> instead of
>      [| ... |]
> 

No problem. Sorry for some inconvenience, if any. I'm OK with using [:, ;] instead of [|, |]n and 'quotation' instead of 'code block'.
When I started this topic I just had no idea what was the consensus on the names and notation.

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

#27359

Alexander Skobelev <al.skobelev@gmail.com> writes:
>Hello all,
>I'm just wondering, what is common opinion (if it exists) about using code blocks (something like 'quotes' in Retro forth) among experienced Forthers? Would it be a valuable addition to Forth?

Please limit lines to about 72 chars in length.

Yes, quotations are a valuable addition to Forth.

>Just for example here a very naive Gforth-specific implementation of local  code blocks (i.e not intended to be used anywhere but only inside a word definition):

The current development version of Gforth supports quotations.  You
find the source code in

http://git.savannah.gnu.org/cgit/gforth.git/tree/quotations.fs

But there are also changes in glocals.fs to properly support locals in
quotations.  If you want to use it, better get the current git
version.

- 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 2013: http://www.euroforth.org/ef13/

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

#27361

anton@mips.complang.tuwien.ac.at (Anton Ertl) writes:
> The current development version of Gforth supports quotations. 

Oh interesting.  Can you say how the implementation works?  The obvious
way to do it is rather messy compared with a traditional colon compiler
that just linearly lays down code into the dictionary, occasionally
patching a branch target.  Quotations would seem to require a fair
amount of copying and bookkeeping.  It's doable but seems kind of
un-Forthlike, which might be causing discomfort from some quarters.

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

#27362

on 19/12/2013 18:05:19, Paul Rubin wrote:
> anton@mips.complang.tuwien.ac.at (Anton Ertl) writes:
>> The current development version of Gforth supports quotations.
> 
> Oh interesting. Can you say how the implementation works? The obvious
> way to do it is rather messy compared with a traditional colon
> compiler that just linearly lays down code into the dictionary,
> occasionally patching a branch target. Quotations would seem to
> require a fair amount of copying and bookkeeping. It's doable but
> seems kind of un-Forthlike, which might be causing discomfort from
> some quarters.
> 

The fundamentals are simple.

: [:  postpone ahead 
      here ; immediate
: ;]  postpone exit
      postpone then
      postpone literal ; immediate

That only works for a Forth that lays code & data down in the same space,
and it makes no checks for compilation only nor accounts for compiler
specific stuff. But that's basically it. Even for a compiler woith
seperate code and data, a smart compile, and some additional bookeeping
for locals and internal pointers, it's not that much more.

: [:  ( c: -- xt xt' cs1 cs2 ) ( start an anonymous quotation )
    (comp-only)
    compilation> ( xt -- ) ( xt is for recurse, so don't drop )
      postpone ahead
      over dup latestxt ! swap ( set latestxt & fix it for ;] )
      1 +to localadj ;

: ;]  ( c: xt xt' cs1 cs2 -- ) ( end an anonymous quotation )
    (comp-only)
    compilation> drop
      -1 +to localadj
      postpone exit
      postpone then
      postpone literal
      latestxt ! ;

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

#27363

"Alex McDonald" <blog@rivadpm.com> writes:
> : [:  postpone ahead  here ; immediate

Hmm, does that mean the quotation is compiled inline with the rest of
the function, and branched around during execution?  I guess that's
simple enough, though it adds a little overhead.

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

#27364

on 19/12/2013 20:33:04, Paul Rubin wrote:
> "Alex McDonald" <blog@rivadpm.com> writes:
>> : [:  postpone ahead  here ; immediate
> 
> Hmm, does that mean the quotation is compiled inline with the rest of
> the function, and branched around during execution?  I guess that's
> simple enough, though it adds a little overhead.
> 

Unless you have some way of magicking the code between [: and ;]
somewhere else, there really isn't an alternative. Forth, typically, has
only one code space.

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

#27365

In article <l8vl7c$vcv$1@dont-email.me>,
Alex McDonald <blog@rivadpm.com> wrote:
>on 19/12/2013 20:33:04, Paul Rubin wrote:
>> "Alex McDonald" <blog@rivadpm.com> writes:
>>> : [:  postpone ahead  here ; immediate
>>
>> Hmm, does that mean the quotation is compiled inline with the rest of
>> the function, and branched around during execution?  I guess that's
>> simple enough, though it adds a little overhead.
>>
>
>Unless you have some way of magicking the code between [: and ;]
>somewhere else, there really isn't an alternative. Forth, typically, has
>only one code space.

And, of course, it isn't worth the trouble. Unoptimised Forth is not
fast anyway.
OTOH, if you optimise the code, the branch probably goes away.

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] | [prev] | [next] | [standalone]

#27369

"Alex McDonald" <blog@rivadpm.com> writes:
> Unless you have some way of magicking the code between [: and ;]
> somewhere else, there really isn't an alternative.

Yeah, that's what I was wondering, whether a typical implementation
would somehow squirrel away the quotation to a temp buffer, or
potentially a stack of them in case of nested quotations.  I guess the
branching thing is ok.  As Albert says, a later optimization phase could
clean it up if necessary.

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

Page 3 of 6 — ← Prev page 1 2 [3] 4 5 6  Next page →

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

csiph-web