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 2 of 6 — ← Prev page 1 [2] 3 4 5 6  Next page →

#27358

on 19/12/2013 03:15:07, "Ed" wrote:
> Bernd Paysan wrote:
>> ...
>> 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.
> 
> I wonder what Chuck would say. Names are meant to be a convenience,
> not a burden. In Forth, it's names that make definitions "readable"
> and re-usable and provide access for testing/debugging.
> 
> It's one thing to strip out names after an app has been completed
> (e.g. you want to make the exe smaller). Stripping them out, or not
> having them during the writing/testing phase, strikes me as
> counter-productive.
> 
> Nested definitions?  No thanks.
> 
> 

The point is that it's very similar to the code ... in DO ... LOOP but
without an explicit xt. We don't call that a nested definition, but it
is.

Given that there isn't any requirement beyond our usual factoring best
practices for a named body for DO ... LOOP ; does there need to be one
for words like [: ... ;] CATCH ?

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

#27378

Alex McDonald wrote:
> ...
> The point is that it's very similar to the code ... in DO ... LOOP but
> without an explicit xt. We don't call that a nested definition, but it
> is.

What is a "definition"?  According to ANS it's:

    "A Forth execution procedure compiled into the dictionary."

If I had code within a DO LOOP that justified the criteria of a
"definition" then properly I should remove it and give it a name.
Why should I do that?  For all the reasons Forth advises one to
write short definitions and factor.

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

#27380

on 20/12/2013 10:07:49, "Ed" wrote:
> Alex McDonald wrote:
>> ...
>> The point is that it's very similar to the code ... in DO ... LOOP but
>> without an explicit xt. We don't call that a nested definition, but it
>> is.
> 
> What is a "definition"?  According to ANS it's:
> 
> "A Forth execution procedure compiled into the dictionary."
> 
> If I had code within a DO LOOP that justified the criteria of a
> "definition" then properly I should remove it and give it a name.
> Why should I do that?  For all the reasons Forth advises one to
> write short definitions and factor.
> 
> 
> 

We can do this

: dashes 0 do s" -" type loop ;

or this

: (dash) s" -" type ;
: dashes 0 do (dash) loop ;

but we can't, without what you are calling "nested definitions" and
others call quotations, do this:

: safe-dash [: 0 do s" -" type loop ;] catch ;

and we can't do this either:

: safe-dash [: 0 do (dash) loop ;] catch ;

We can only do this:
 
: safe-dash dashes catch ;
 
In other words, we're not forced to factor for DO LOOP but we are forced
to for CATCH TRAVERSE-WORDLIST and so on. The code we're being forced to
factor may be consided a "factoring too far". Take for example

: words ( -- )
  [: .name true ;] current @ traverse-wordlist ;

If this was within a DO LOOP rather than [: ;] would you factor it?

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

#27381

on 20/12/2013 12:34:59, "Alex McDonald" wrote:

> 
>: safe-dash dashes catch ;

Errata: should read

: safe-dash ['] dashes catch ;

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

#27395

Alex McDonald wrote:
> ...
> We can do this
>
> : dashes 0 do s" -" type loop ;
>
> or this
>
> : (dash) s" -" type ;
> : dashes 0 do (dash) loop ;
>
> but we can't, without what you are calling "nested definitions" and
> others call quotations, do this:
>
> : safe-dash [: 0 do s" -" type loop ;] catch ;
>
> and we can't do this either:
>
> : safe-dash [: 0 do (dash) loop ;] catch ;
>
> We can only do this:
>
> : safe-dash dashes catch ;
>
> Errata: should read
>
> : safe-dash ['] dashes catch ;
>
> In other words, we're not forced to factor for DO LOOP but we are forced
> to for CATCH TRAVERSE-WORDLIST and so on. The code we're being forced to
> factor may be consided a "factoring too far". Take for example
>
> : words ( -- )
>   [: .name true ;] current @ traverse-wordlist ;
>
> If this was within a DO LOOP rather than [: ;] would you factor it?

Would I create a factor explicitly for ticking for the few occasions such
things are needed?  Without hesitation.  Quotations have no redeeming
features.  They create problems where none previously existed.

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

#27396

on 22/12/2013 03:19:26, "Ed" wrote:
> Alex McDonald wrote:
[snip]
>>
>> : words ( -- )
>>   [: .name true ;] current @ traverse-wordlist ;
>>
>> If this was within a DO LOOP rather than [: ;] would you factor it?
> 
> Would I create a factor explicitly for ticking for the few occasions
> such things are needed? 

Ticking wasn't the question, but never mind. Incidentally, what would you
call it?

> Without hesitation. Quotations have no
> redeeming features. They create problems where none previously
> existed.
> 

I'm interested in what you've identfied as potential problems, but you
don't say what they are. 

There's no extant practice for quotatations and that might lead to all
sorts of abuses in the hands of the unwashed. There are some
considerations that any formal proposal will have to deal with; xt
visibility outside of the enclosing definition and locals visibility and
lifetime being two that come immediately to mind.

Can you be more specific please?

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

#27409

Alex McDonald wrote:
> on 22/12/2013 03:19:26, "Ed" wrote:
> > Alex McDonald wrote:
> [snip]
> >>
> >> : words ( -- )
> >>   [: .name true ;] current @ traverse-wordlist ;
> >>
> >> If this was within a DO LOOP rather than [: ;] would you factor it?
> >
> > Would I create a factor explicitly for ticking for the few occasions
> > such things are needed?
>
> Ticking wasn't the question, but never mind.

Ticking provides an xt - which I presume was the goal of the exercise.

> > Without hesitation. Quotations have no
> > redeeming features. They create problems where none previously
> > existed.
> >
>
> I'm interested in what you've identfied as potential problems, but you
> don't say what they are.

From my previous post:

    "In Forth, it's names that make definitions "readable" and re-usable
    and provide access for testing/debugging.

    It's one thing to strip out names after an app has been completed [...]
    Stripping them out, or not having them
    during the writing/testing phase, strikes me as counter-productive.

    Nested definitions?  No thanks."

> There's no extant practice for quotatations and that might lead to all
> sorts of abuses in the hands of the unwashed. There are some
> considerations that any formal proposal will have to deal with; xt
> visibility outside of the enclosing definition and locals visibility and
> lifetime being two that come immediately to mind.
>
> Can you be more specific please?

As you insist.

Quotations don't exist in Forth because they've never been necessary.
They offer nothing but convoluted code and all that comes with it.
They force the programmer to make arbitrary decisions - when to use
quotations, when not.  In adding yet another redundant/questionable tool
to Forth, simplicity is undermined making it less likely anyone will
want to use the language.

That's enough to make me want nothing to do with quotations, locals,
quoted chars etc.  YMMV

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

#27433

In article <l9ao4g$h9g$1@speranza.aioe.org>, Ed <invalid@invalid.com> wrote:
>Alex McDonald wrote:
<SNIP>
>
>That's enough to make me want nothing to do with quotations, locals,
>quoted chars etc.  YMMV

I agree with you a long way , at least the sentiment, except for the special
notations.

Suppose &A replaces CHAR A and [CHAR] A .

1. I think it makes no sense to have two different denotations
   depending on compilation state
   for characters that are clearly all time constants
2. The idea of & as a prefix word is sooooooooooo simple.
3. You really want &A as a constant, not as something that is calculated,
 and absolutely not as something that is calculated from parsing the
 input stream in two different ways.

Really, if there is one thing I'd agree with in the 20xx proposal is
that CHAR and [CHAR] have to go.

Now look:
: &  >IN C@  1 >IN +!  POSTPONE LITERAL ; PREFIX IMMEDIATE

The only provision needed is that the word & is a match for
all words that start with a & as indicated by it being a prefix.
A very long time ago I showed that this can be had by adding one line
to the dictionary search.
Total addition to a Forth kernel is about 5 lines, seriously.
(Not taking into account that more lines than that are removed. )
While quotations have a heavy toll on learning, and even more
in learning what you've come to expect, but will not work in
Forth, the PREFIX facility is really bang for the buck.

Once you have it you can define the dreaded and hated $ prefix
in high level Forth whenever needed,
such that you never have to incorporate it into your interpreter:

: $   HEX (NUMBER) POSTPONE LITERAL DECIMAL ; IMMEDIATE

(I wouldn't have $ as a non-portable kernel feature in a million
years.)

I really want to stress there is only PREFIX and an addition to
the search. This replaces all specific code for & '.' 1] $ etc.
Plus it allows a nice " (for `` "hello" TYPE '' ), plus you can kick
the special handling of numbers out of the interpreter. I mean all
numbers.

Groetjes Albert

1] Extremely ugly in view of our usage of ' , a c-ism to really hate.

Disclaimer: code samples are for illustration purposes, not tested or
anything.
-- 
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]

#27482

Albert van der Horst wrote:
> ...
> Suppose &A replaces CHAR A and [CHAR] A .
>
> 1. I think it makes no sense to have two different denotations
>    depending on compilation state
>    for characters that are clearly all time constants
> 2. The idea of & as a prefix word is sooooooooooo simple.
> 3. You really want &A as a constant, not as something that is calculated,
>  and absolutely not as something that is calculated from parsing the
>  input stream in two different ways.
>
> Really, if there is one thing I'd agree with in the 20xx proposal is
> that CHAR and [CHAR] have to go.
> ...

There are things which epitomize Forth and have existed for a very long time.
CHAR and [CHAR] are examples.  The names were changed but not the principles
underlying them.  Their brilliance (and the 'Forth Way') is that they could be
defined from existing words.  Are they broken, hard to use, or lack functionality
that Forth should replace them?  Not that I'm aware.

I have no issue with someone wishing to implement something different for
themselves for whatever reason.  They do so at their own risk and it affects
no-one but themselves.  That's not the case with 20xx, or for that matter, Forth-94.

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

#27484

In article <l9l4qm$vlu$1@speranza.aioe.org>, Ed <invalid@invalid.com> wrote:
>Albert van der Horst wrote:
>> ...
>> Suppose &A replaces CHAR A and [CHAR] A .
>>
>> 1. I think it makes no sense to have two different denotations
>>    depending on compilation state
>>    for characters that are clearly all time constants
>> 2. The idea of & as a prefix word is sooooooooooo simple.
>> 3. You really want &A as a constant, not as something that is calculated,
>>  and absolutely not as something that is calculated from parsing the
>>  input stream in two different ways.
>>
>> Really, if there is one thing I'd agree with in the 20xx proposal is
>> that CHAR and [CHAR] have to go.
>> ...
>
>There are things which epitomize Forth and have existed for a very long time.
>CHAR and [CHAR] are examples.  The names were changed but not the principles
>underlying them.  Their brilliance (and the 'Forth Way') is that they could be
>defined from existing words.  Are they broken, hard to use, or lack
>functionality
>that Forth should replace them?  Not that I'm aware.

I think a state smart CHAR is fine, with the caveat that it must not be
postponed or the infamous demons will fly out of your nose.
I dislike the CHAR [CHAR] . It adds a level of attention at the bottom,
which cost you a level of attention at the top. I remember a remark of
a lisp programmer that since the brackets where taken care of by a tool
he was unburdened so could program more easily.

Come one! &A is just the character A and it is constant. I don't want my
brain to a detour: "What the hell I have to insert here, is it
CHAR or [CHAR], fortunately ci86.lina64.html is open in the browser."

>
>I have no issue with someone wishing to implement something different for
>themselves for whatever reason.  They do so at their own risk and it affects
>no-one but themselves.  That's not the case with 20xx, or for that
>matter, Forth-94.

That is exactly the reason why I want PREFIX. Without CHAR [CHAR] and
(god forbid $ #) in the kernel, you can add a one liner at the top of
your program to make it happen, the way you want it.

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]

#27461

"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.

>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.

- 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]

#27462

anton@mips.complang.tuwien.ac.at (Anton Ertl) writes:
> [Quotations] 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.

EXECUTE has been around forever, I thought.  So I have the impression
that xt-passing style was frowned upon in the past, but is more ok in
the present, i.e. there has been something of a cultural change rather
than a technical one.  Is that accurate?  How did this happen?

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

#27479

Paul Rubin <no.email@nospam.invalid> writes:
>anton@mips.complang.tuwien.ac.at (Anton Ertl) writes:
>> [Quotations] 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.
>
>EXECUTE has been around forever, I thought.

Sure, but nobody would write

[: bla bla ;] execute

Instead, they would just write

bla bla

So EXECUTE is used differently.  But quotations are useful in
combination with words like CATCH, TRAVERSE-WORDLIST, and
EXECUTE-PARSING.

>So I have the impression
>that xt-passing style was frowned upon in the past, but is more ok in
>the present, i.e. there has been something of a cultural change rather
>than a technical one.  Is that accurate?  How did this happen?

Frowned upon in the past?  No.  Just not used.

Cultural change?  Probably yes.  At least we see a little culture
clash between those who see a need for quotations and those who don't.

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.

There was a need to pass arbitrary strings to parsing words, and for a
long time I played with the idea of words for that in the SAVE-INPUT
RESTORE-INPUT style, but that did not look good technically.  Then
Jonah Thomas came up with the idea of having a wrapper word for that
feature (i.e., a word that you pass an xt to), and this led to
EXECUTE-PARSING, which I consider a success.  Other words of that kind
followed, and lately TRAVERSE-WORDLIST was standardized.

- 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]

#27486

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.

[...]


-- 
Gerry

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

#27487

Gerry Jackson <gerry@jackson9000.fsnet.co.uk> writes:
>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?

They do not provide any guaranteed functionality, and it's unclear
what functionality they should guarantee.  E.g., the following is
arguably a compliant, but useless implementation:

: save-input 0 ;
: restore-input drop true ;

So I have been quite reluctant to use it.

Also, the specification of RESTORE-INPUT with both a flag and an
ambiguous condition points to the technical deficits of this kind of
interface.

- 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]

#27489

On 28/12/2013 17:53, Anton Ertl wrote:
> Gerry Jackson <gerry@jackson9000.fsnet.co.uk> writes:
>> 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?
>
> They do not provide any guaranteed functionality, and it's unclear
> what functionality they should guarantee.  E.g., the following is
> arguably a compliant, but useless implementation:
>
> : save-input 0 ;
> : restore-input drop true ;
>
> So I have been quite reluctant to use it.
>
> Also, the specification of RESTORE-INPUT with both a flag and an
> ambiguous condition points to the technical deficits of this kind of
> interface.
>
> - anton
>

So why don't we attempt to correct these deficiencies. In practice they 
have worked on most Forths I have tried, the only exception being Win32 
Forth where it didn't always work and possibly still doesn't.

Why not e.g.
- forbid the useless implementation
- SAVE-INPUT returns n=0 (or negative) if the input is non-restorable
- remove the ambiguous condition from RESTORE-INPUT and replace it with 
a value for the returned flag e.g.
      -1 for non-restorable
      +1 for current input source incorrect

If a system can't do these things it shouldn't provide SAVE-INPUT and 
RESTORE-INPUT.

I suppose that would require an RfD, is it worth it?

-- 
Gerry

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

#27505

Gerry Jackson <gerry@jackson9000.fsnet.co.uk> writes:
>On 28/12/2013 17:53, Anton Ertl wrote:
>> Gerry Jackson <gerry@jackson9000.fsnet.co.uk> writes:
>>> Why do you say SAVE-INPUT and RESTORE-INPUT are a failure?
>>
>> They do not provide any guaranteed functionality, and it's unclear
>> what functionality they should guarantee.  E.g., the following is
>> arguably a compliant, but useless implementation:
>>
>> : save-input 0 ;
>> : restore-input drop true ;
>>
>> So I have been quite reluctant to use it.
>>
>> Also, the specification of RESTORE-INPUT with both a flag and an
>> ambiguous condition points to the technical deficits of this kind of
>> interface.
>>
>> - anton
>>
>
>So why don't we attempt to correct these deficiencies. In practice they 
>have worked on most Forths I have tried, the only exception being Win32 
>Forth where it didn't always work and possibly still doesn't.
>
>Why not e.g.
>- forbid the useless implementation
>- SAVE-INPUT returns n=0 (or negative) if the input is non-restorable
>- remove the ambiguous condition from RESTORE-INPUT and replace it with 
>a value for the returned flag e.g.
>      -1 for non-restorable
>      +1 for current input source incorrect
>
>If a system can't do these things it shouldn't provide SAVE-INPUT and 
>RESTORE-INPUT.
>
>I suppose that would require an RfD, is it worth it?

Yes, you could write an RfD to tighten the specification of SAVE-INPUT
and RESTORE-INPUT, and this may be the best way to go forward from
where we are, if you want a standardized useful SAVE-INPUT
RESTORE-INPUT.  Is it worth it?  I don't know, but if you find your
uses of SAVE-INPUT RESTORE-INPUT useful, it would be nice if we had a
standard that actually specifies what you find useful.

As for removing the ambiguous condition, I am not sure if that is
feasible.  I think this also covers the case where the data on the
stack does not come from SAVE-INPUT or where the data coming from
SAVE-INPUT was changed in some way.

But let's step one step back.  If we did not already have SAVE-INPUT
RESTORE-INPUT in the standard, how would we best specify a word or
words that provide the functionality that you use SAVE-INPUT
RESTORE-INPUT for?  Would a wrapper word (i.e., a word takes the stuff
you write between SAVE-INPUT and RESTORE-INPUT as xt) be useful for
you?

If so, I think it would be much easier to specify than an
appropriately tightended SAVE-INPUT RESTORE-INPUT.  And that's one
reason why we are seeing more words with wrapper-style interfaces
(another reason is exceptions).

- 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]

#27511

On 29/12/2013 14:49, Anton Ertl wrote:
> Gerry Jackson <gerry@jackson9000.fsnet.co.uk> writes:
>> On 28/12/2013 17:53, Anton Ertl wrote:
>>> Gerry Jackson <gerry@jackson9000.fsnet.co.uk> writes:
>>>> Why do you say SAVE-INPUT and RESTORE-INPUT are a failure?
>>>
>>> They do not provide any guaranteed functionality, and it's unclear
>>> what functionality they should guarantee.  E.g., the following is
>>> arguably a compliant, but useless implementation:
>>>
>>> : save-input 0 ;
>>> : restore-input drop true ;
>>>
>>> So I have been quite reluctant to use it.
>>>
>>> Also, the specification of RESTORE-INPUT with both a flag and an
>>> ambiguous condition points to the technical deficits of this kind of
>>> interface.
>>>
>>> - anton
>>>
>>
>> So why don't we attempt to correct these deficiencies. In practice they
>> have worked on most Forths I have tried, the only exception being Win32
>> Forth where it didn't always work and possibly still doesn't.
>>
>> Why not e.g.
>> - forbid the useless implementation
>> - SAVE-INPUT returns n=0 (or negative) if the input is non-restorable
>> - remove the ambiguous condition from RESTORE-INPUT and replace it with
>> a value for the returned flag e.g.
>>       -1 for non-restorable
>>       +1 for current input source incorrect
>>
>> If a system can't do these things it shouldn't provide SAVE-INPUT and
>> RESTORE-INPUT.
>>
>> I suppose that would require an RfD, is it worth it?
>
> Yes, you could write an RfD to tighten the specification of SAVE-INPUT
> and RESTORE-INPUT, and this may be the best way to go forward from
> where we are, if you want a standardized useful SAVE-INPUT
> RESTORE-INPUT.  Is it worth it?  I don't know, but if you find your
> uses of SAVE-INPUT RESTORE-INPUT useful, it would be nice if we had a
> standard that actually specifies what you find useful.
>
> As for removing the ambiguous condition, I am not sure if that is
> feasible.  I think this also covers the case where the data on the
> stack does not come from SAVE-INPUT or where the data coming from
> SAVE-INPUT was changed in some way.

Yes, good point

>
> But let's step one step back.  If we did not already have SAVE-INPUT
> RESTORE-INPUT in the standard, how would we best specify a word or
> words that provide the functionality that you use SAVE-INPUT
> RESTORE-INPUT for?  Would a wrapper word (i.e., a word takes the stuff
> you write between SAVE-INPUT and RESTORE-INPUT as xt) be useful for
> you?

I think you're assuming that SAVE-INPUT and RESTORE-INPUT occur in the 
same colon definition. That's not necessarily the case e.g. I've used 
them for two different purposes, both of which involve potentially 
multiple passes over bits of Forth source code while interpreting or 
compiling. In both cases SAVE-INPUT and RESTORE-INPUT are called in 
different colon definitions and an arbitrary amount of source code can 
occur between them. This code cannot be represented by an xt, so the 
answer is no, a wrapper approach would not be useful.

It would be nice to think that FILE-POSITION and REPOSITION-FILE could 
be used instead but when I caused a question to be raised (by Leon 
Wagner) at a Forth 200X meeting in 2011 I received a reply that there 
was no entitlement to use them on a file that was being 
interpreted/compiled. That's another area that needs clarifying IMHO.

>
> If so, I think it would be much easier to specify than an
> appropriately tightended SAVE-INPUT RESTORE-INPUT.  And that's one
> reason why we are seeing more words with wrapper-style interfaces
> (another reason is exceptions).
>

I'll think about raising an RfD to tighten the specification of the two 
words.

-- 
Gerry

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

#27536

Gerry Jackson <gerry@jackson9000.fsnet.co.uk> writes:
>I think you're assuming that SAVE-INPUT and RESTORE-INPUT occur in the 
>same colon definition. That's not necessarily the case e.g. I've used 
>them for two different purposes, both of which involve potentially 
>multiple passes over bits of Forth source code while interpreting or 
>compiling. In both cases SAVE-INPUT and RESTORE-INPUT are called in 
>different colon definitions and an arbitrary amount of source code can 
>occur between them. This code cannot be represented by an xt, so the 
>answer is no, a wrapper approach would not be useful.

How hard would it be to reorganize the code so that the code between
SAVE-INPUT and RESTORE-INPUT can be represented by an xt?  Or to write
it from scratch for using a wrapper.

Are there cases where SAVE-INPUT and RESTORE-INPUT are used in a
non-nested way?  In this case there is probably no good way to do that
with wrappers.

- 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]

#27550

On 30/12/2013 17:08, Anton Ertl wrote:
> Gerry Jackson <gerry@jackson9000.fsnet.co.uk> writes:
>> I think you're assuming that SAVE-INPUT and RESTORE-INPUT occur in the
>> same colon definition. That's not necessarily the case e.g. I've used
>> them for two different purposes, both of which involve potentially
>> multiple passes over bits of Forth source code while interpreting or
>> compiling. In both cases SAVE-INPUT and RESTORE-INPUT are called in
>> different colon definitions and an arbitrary amount of source code can
>> occur between them. This code cannot be represented by an xt, so the
>> answer is no, a wrapper approach would not be useful.
>
> How hard would it be to reorganize the code so that the code between
> SAVE-INPUT and RESTORE-INPUT can be represented by an xt?  Or to write
> it from scratch for using a wrapper.

In one case it would defeat the purpose as it is used entirely in 
interpretation mode. In the other for implementing e.g. quotations it 
would be impossible. Both cases are provided as tools for users who can 
program what they want between SAVE-INPUT and RESTORE-INPUT.

>
> Are there cases where SAVE-INPUT and RESTORE-INPUT are used in a
> non-nested way?

Only if the user chooses to not nest them, so no.

In this case there is probably no good way to do that
> with wrappers.


-- 
Gerry

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

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

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

csiph-web