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

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

RFD Recognizer

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

Contents

  RFD Recognizer Matthias Trute <matthias.trute@gmail.com> - 2015-01-02 11:56 -0800
    Re: RFD Recognizer Andrew Haley <andrew29@littlepinkcloud.invalid> - 2015-01-03 05:37 -0600
      Re: RFD Recognizer anton@mips.complang.tuwien.ac.at (Anton Ertl) - 2015-01-03 12:56 +0000
        Re: RFD Recognizer Andrew Haley <andrew29@littlepinkcloud.invalid> - 2015-01-04 04:23 -0600
          Re: RFD Recognizer anton@mips.complang.tuwien.ac.at (Anton Ertl) - 2015-01-04 11:25 +0000
            Re: RFD Recognizer Andrew Haley <andrew29@littlepinkcloud.invalid> - 2015-01-05 04:43 -0600
              Re: RFD Recognizer anton@mips.complang.tuwien.ac.at (Anton Ertl) - 2015-01-05 12:35 +0000
                Re: RFD Recognizer Andrew Haley <andrew29@littlepinkcloud.invalid> - 2015-01-06 10:33 -0600
                  Re: RFD Recognizer anton@mips.complang.tuwien.ac.at (Anton Ertl) - 2015-01-07 15:29 +0000
                    Re: RFD Recognizer Andrew Haley <andrew29@littlepinkcloud.invalid> - 2015-01-07 12:57 -0600
                      Re: RFD Recognizer Matthias Trute <matthias.trute@gmail.com> - 2015-01-07 12:27 -0800
                        Re: RFD Recognizer Bernd Paysan <bernd.paysan@gmx.de> - 2015-01-09 00:42 +0100
                      Re: RFD Recognizer albert@spenarnc.xs4all.nl (Albert van der Horst) - 2015-01-07 20:55 +0000
      Re: RFD Recognizer Matthias Trute <matthias.trute@gmail.com> - 2015-01-03 06:43 -0800
        Re: RFD Recognizer JennyB <jennybrien@googlemail.com> - 2015-01-03 07:54 -0800
          Re: RFD Recognizer Matthias Trute <matthias.trute@gmail.com> - 2015-01-03 08:37 -0800
            Re: RFD Recognizer JennyB <jennybrien@googlemail.com> - 2015-01-03 10:08 -0800
          Re: RFD Recognizer anton@mips.complang.tuwien.ac.at (Anton Ertl) - 2015-01-04 12:15 +0000
            Re: RFD Recognizer JennyB <jennybrien@googlemail.com> - 2015-01-09 10:15 -0800
              Re: RFD Recognizer Matthias Trute <matthias.trute@gmail.com> - 2015-01-09 12:11 -0800
                Re: RFD Recognizer Bernd Paysan <bernd.paysan@gmx.de> - 2015-01-09 22:46 +0100
        Re: RFD Recognizer Andrew Haley <andrew29@littlepinkcloud.invalid> - 2015-01-04 04:37 -0600
          Re: RFD Recognizer Matthias Trute <matthias.trute@gmail.com> - 2015-01-04 06:32 -0800
            Re: RFD Recognizer Andrew Haley <andrew29@littlepinkcloud.invalid> - 2015-01-05 04:55 -0600
              Re: RFD Recognizer Matthias Trute <matthias.trute@gmail.com> - 2015-01-05 10:06 -0800
        Re: RFD Recognizer albert@spenarnc.xs4all.nl (Albert van der Horst) - 2015-01-04 16:02 +0000
          Re: RFD Recognizer Matthias Trute <matthias.trute@gmail.com> - 2015-01-04 11:06 -0800
            Re: RFD Recognizer JennyB <jennybrien@googlemail.com> - 2015-01-05 08:18 -0800
              Re: RFD Recognizer JennyB <jennybrien@googlemail.com> - 2015-01-05 08:59 -0800
              Re: RFD Recognizer Matthias Trute <matthias.trute@gmail.com> - 2015-01-05 10:23 -0800
                Re: RFD Recognizer anton@mips.complang.tuwien.ac.at (Anton Ertl) - 2015-01-08 15:36 +0000
                  Re: RFD Recognizer Matthias Trute <matthias.trute@gmail.com> - 2015-01-08 10:54 -0800
                  Re: RFD Recognizer Gerry Jackson <gerry@jackson9000.fsnet.co.uk> - 2015-01-08 20:50 +0000
            Re: RFD Recognizer anton@mips.complang.tuwien.ac.at (Anton Ertl) - 2015-01-08 14:24 +0000
              Re: RFD Recognizer albert@spenarnc.xs4all.nl (Albert van der Horst) - 2015-01-08 16:06 +0000
              Re: RFD Recognizer Bernd Paysan <bernd.paysan@gmx.de> - 2015-01-09 01:11 +0100
          Re: RFD Recognizer Matthias Koch <matthias.koch@hot.uni-hannover.de> - 2015-01-05 17:19 +0100
      Re: RFD Recognizer Bernd Paysan <bernd.paysan@gmx.de> - 2015-01-03 16:08 +0100
      Re: RFD Recognizer hughaguilar96@gmail.com - 2015-01-03 16:05 -0800
        Re: RFD Recognizer Andrew Haley <andrew29@littlepinkcloud.invalid> - 2015-01-04 04:42 -0600
        Re: RFD Recognizer stephen@mpeforth.com (Stephen Pelc) - 2015-01-06 18:01 +0000
      Re: RFD Recognizer albert@spenarnc.xs4all.nl (Albert van der Horst) - 2015-01-04 15:11 +0000
        Re: RFD Recognizer Andrew Haley <andrew29@littlepinkcloud.invalid> - 2015-01-05 05:00 -0600
          Re: RFD Recognizer albert@spenarnc.xs4all.nl (Albert van der Horst) - 2015-01-05 13:39 +0000
            Re: RFD Recognizer Andrew Haley <andrew29@littlepinkcloud.invalid> - 2015-01-06 04:57 -0600
              Re: RFD Recognizer albert@spenarnc.xs4all.nl (Albert van der Horst) - 2015-01-06 18:00 +0000
                Re: RFD Recognizer Andrew Haley <andrew29@littlepinkcloud.invalid> - 2015-01-07 05:13 -0600
                  Re: RFD Recognizer albert@spenarnc.xs4all.nl (Albert van der Horst) - 2015-01-07 17:18 +0000
                    Re: RFD Recognizer Andrew Haley <andrew29@littlepinkcloud.invalid> - 2015-01-07 13:04 -0600
    Re: RFD Recognizer Julian Fondren <julian.fondren@gmail.com> - 2015-01-04 07:48 -0800
      Re: RFD Recognizer JennyB <jennybrien@googlemail.com> - 2015-01-05 06:01 -0800
        Re: RFD Recognizer anton@mips.complang.tuwien.ac.at (Anton Ertl) - 2015-01-05 14:31 +0000
          Re: RFD Recognizer JennyB <jennybrien@googlemail.com> - 2015-01-05 08:43 -0800
            Re: RFD Recognizer anton@mips.complang.tuwien.ac.at (Anton Ertl) - 2015-01-08 15:22 +0000
          Re: RFD Recognizer Bernd Paysan <bernd.paysan@gmx.de> - 2015-01-06 02:48 +0100
            Re: RFD Recognizer albert@spenarnc.xs4all.nl (Albert van der Horst) - 2015-01-06 03:13 +0000
      Re: RFD Recognizer anton@mips.complang.tuwien.ac.at (Anton Ertl) - 2015-01-08 13:45 +0000
    Re: RFD Recognizer Gerry Jackson <gerry@jackson9000.fsnet.co.uk> - 2015-01-08 20:44 +0000
      Re: RFD Recognizer JennyB <jennybrien@googlemail.com> - 2015-01-17 09:26 -0800
        Re: RFD Recognizer Bernd Paysan <bernd.paysan@gmx.de> - 2015-01-17 18:54 +0100
          Re: RFD Recognizer JennyB <jennybrien@googlemail.com> - 2015-01-17 12:35 -0800
        Re: RFD Recognizer Matthias Trute <matthias.trute@gmail.com> - 2015-01-18 04:16 -0800
          Re: RFD Recognizer albert@spenarnc.xs4all.nl (Albert van der Horst) - 2015-01-18 13:38 +0000
            Re: RFD Recognizer anton@mips.complang.tuwien.ac.at (Anton Ertl) - 2015-01-18 13:56 +0000
              Re: RFD Recognizer JennyB <jennybrien@googlemail.com> - 2015-01-18 07:10 -0800
                Re: RFD Recognizer anton@mips.complang.tuwien.ac.at (Anton Ertl) - 2015-01-18 16:14 +0000
        Re: RFD Recognizer Gerry Jackson <gerry@jackson9000.fsnet.co.uk> - 2015-01-20 18:26 +0000
          Re: RFD Recognizer Bernd Paysan <bernd.paysan@gmx.de> - 2015-01-20 23:54 +0100
            Re: RFD Recognizer JennyB <jennybrien@googlemail.com> - 2015-01-21 09:05 -0800
              Re: RFD Recognizer Bernd Paysan <bernd.paysan@gmx.de> - 2015-01-21 20:50 +0100
              Re: RFD Recognizer albert@spenarnc.xs4all.nl (Albert van der Horst) - 2015-01-22 10:55 +0000

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

#35511

On Sat, 3 Jan 2015 16:05:13 -0800 (PST), hughaguilar96@gmail.com
wrote:

>He (Ching)
>as asked me to ask Stephen Pelc if >NUMBER can be made a vectored function 
>in VFX, and I said that I would ask

Like everyone else, Ching is free to ask me questions himself.

The DEFERred word in VFX's interpreter loop is NUMBER? and it
is documented in the manual.

defer NUMBER?   \ addr -- d/n/- 2/1/0
\ *G Attempt to convert the counted string at 'addr' to an
\ ** integer. The return result is either zero for failed, a
\ ** single cell number and one for a single-cell conversion,
\ ** or a double cell number and two for a double number
\ ** conversion. The ASCII number string supplied can also contain
\ ** an explicit radix (number base) override. A leading $
\ ** enforces hexadecimal, a leading # enforces decimal and a
\ ** leading % enforces binary. Hexadecimal numbers can also be
\ ** specified by a leading '0x' or trailing 'h'. After a floating
\ ** point pack has been compiled from the *\i{Lib} directory, the
\ ** action of *\fo{NUMBER?} is changed to accept floating point
\ ** numbers as well as integers.

Stephen

-- 
Stephen Pelc, stephenXXX@mpeforth.com
MicroProcessor Engineering Ltd - More Real, Less Time
133 Hill Lane, Southampton SO15 5AF, England
tel: +44 (0)23 8063 1441, fax: +44 (0)23 8033 9691
web: http://www.mpeforth.com - free VFX Forth downloads

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

#35454

In article <QrednZcoJNYbSTrJnZ2dnUU7-Q2dnZ2d@supernews.com>,
Andrew Haley  <andrew29@littlepinkcloud.invalid> wrote:
>Matthias Trute <matthias.trute@gmail.com> wrote:
>>
>> some time ago I posted the following text to the Forth200x mailing list.
>> There I got really valuable feedback and decided now to post the same text
>> here at c.l.f as well. Why the same text, you may ask? Well, we
>> discussed many use cases of the concept and even some fundamental
>> changes in different areas of Forth but not the concept as such.
>>
>> There is a nicely formatted PDF at
>> http://amforth.sourceforge.net/pr/Recognizer-rfc.pdf
>
>My initial reactions:
>
>1.  Vectored NUMBER or some more general equivalent has been around
>    for a long time.  It's a good thing to have.
>
>2.  This proposal looks rather complicated.  Can it not be made simpler
>    without loss of functionality?  For example, R:FAIL does not seem
>    to do anything useful.  It's very cute to make it the failure
>    action but there's an awful lot of DUP R:FAIL <> IF executed in
>    the inner loop of DO-RECOGNIZER.  Should the token used for
>    notifying a failure not simply be zero?
>
>3.  I'm not convinced that it makes any sense to invoke the recognizer
>    mechanism for simple dictionary lookups.  It's a big chunk of
>    overhead for such a critical inner loop.
>
>4.  How often does it make sense to have a POSTPONE action for a
>    recognizer?  Right now I can think of no use for it at all.
>
>5.  SET-RECOGNIZERS and GET-RECOGNIZERS push a lot of stuff onto the
>    data stack for no obvious purpose.  They make it possible to
>    prepend a recognizer before dictionary lookup, but that is a Bad
>    Idea.  IMO...
>
>So, while the basic idea is OK, I think this is an over-engineered
>proposal which could be cut down to something smaller without loss of
>power.
>
>I am rather concerned that most of the more exotic uses for this won't
>make Forth programs any easier to read or write, but are more of the
>unnecessarily "cute" syntactical tricks loved by a subset of Forth
>programmers, especially newbies.  (I have this nagging feeling that
>we may be about to repeat the mistakes of Smalltalk-72, where programs
>parsed their own arguments.  The system was made much cleaner in
>Smalltalk-80 which has a fixed simple syntax.)  But I accept that such
>an argument doesn't have much traction in Forth, where our tradition
>is very much "Your bullet, your gun, your foot."

I'm guilty of abusing the prefix mechanism in my ciasdis (compiler/decompiler).

I use the word : as a prefix to identify labels:
For example there are three labels around DROP for the assembly
of some old version of ciforth in the following fragment:
"
( 0804,A308 )   :N_DROP   d$  4  0  0  0  "DROP"

( 0804,A310 )   :X_DROP   dl H_DROP H_DROP 0 X_OVER
( 0804,A320 )                 dl N_DROP 0

( 0804,A328 )   :H_DROP    POP|X, AX|
( 0804,A329 )                  LODS, X'|
( 0804,A32A )                  JMPO, ZO| [AX]
"

The labels implement a traditional two pass assembly,
in the first pass they register the label, and in the second
pass they resolve to an address. Note that H_DROP is used
before it :H_DROP fixes its value.
(No, the prefix : doesn't interfere with the colon definer.)

This mechanism is involved as it is, but it is feasible because
the prefix-: is just a word and has no interferences, like so:

: : NAME
    KNOWN-LABEL? IF 2DROP ELSE 2>R _AP_ 2R> POSTFIX CONSTANT THEN
; PREFIX IMMEDIATE

: does what it pleases. : does or doesn't add a definition to the
dictionary, depending on whether we saw the label before. Now it
would be a considerable headache to do this in the context
of the underlying proposal.

A very long time ago I introduced denotations/prefixes by
showing an implementation that amounts to adding 1 (one)
line to an existing interpreter...

>
>Andrew.

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]

#35468

Albert van der Horst <albert@spenarnc.xs4all.nl> wrote:
> 
> I'm guilty of abusing the prefix mechanism in my ciasdis (compiler/decompiler).
> 
> I use the word : as a prefix to identify labels:
> For example there are three labels around DROP for the assembly
> of some old version of ciforth in the following fragment:
> "
> ( 0804,A308 )   :N_DROP   d$  4  0  0  0  "DROP"
> 
> ( 0804,A310 )   :X_DROP   dl H_DROP H_DROP 0 X_OVER
> ( 0804,A320 )                 dl N_DROP 0
> 
> ( 0804,A328 )   :H_DROP    POP|X, AX|
> ( 0804,A329 )                  LODS, X'|
> ( 0804,A32A )                  JMPO, ZO| [AX]
> "

I don't get it.  Why don't you just use

   label N_DROP   d$  4  0  0  0  "DROP"

   label X_DROP   dl H_DROP H_DROP 0 X_OVER
                  dl N_DROP 0

   label H_DROP   POP|X, AX|
                  LODS, X'|
                  JMPO, ZO| [AX]
Andrew.

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

#35471

In article <X4GdnYkvpbNc8zfJnZ2dnUU7-QWdnZ2d@supernews.com>,
Andrew Haley  <andrew29@littlepinkcloud.invalid> wrote:
>Albert van der Horst <albert@spenarnc.xs4all.nl> wrote:
>>
>> I'm guilty of abusing the prefix mechanism in my ciasdis (compiler/decompiler).
>>
>> I use the word : as a prefix to identify labels:
>> For example there are three labels around DROP for the assembly
>> of some old version of ciforth in the following fragment:
>> "
>> ( 0804,A308 )   :N_DROP   d$  4  0  0  0  "DROP"
>>
>> ( 0804,A310 )   :X_DROP   dl H_DROP H_DROP 0 X_OVER
>> ( 0804,A320 )                 dl N_DROP 0
>>
>> ( 0804,A328 )   :H_DROP    POP|X, AX|
>> ( 0804,A329 )                  LODS, X'|
>> ( 0804,A32A )                  JMPO, ZO| [AX]
>> "
>
>I don't get it.  Why don't you just use
>
>   label N_DROP   d$  4  0  0  0  "DROP"
>
>   label X_DROP   dl H_DROP H_DROP 0 X_OVER
>                  dl N_DROP 0
>
>   label H_DROP   POP|X, AX|
>                  LODS, X'|
>                  JMPO, ZO| [AX]

In short: cuteness. But actually if this tool is to be used
by assembler programmers not used to Forth, a parsing word
like label would be thoroughly unfamiliar. I leave the visibility
And then, it is much shorter.

I started with the word guilty. It is not *necessary* to
use recognizers here, I agree.

However, if we start along this road, we should keep S" and do
floating point numbers like so:
    FP: 123.45e6
and allow for totally portable floating point extensions
(and maybe be obliged to add [FP:] )

In the mean time I'm totally addicted to "AAP" strings and
note that I'm building on top of it (by formatting strings,
which would otherwise lead to confusion.)

The purpose of syntax improvements / abstractions is to make it easier
to forget what is under the bonnet and lift your level of abstraction
one up.

In
    ( 0804,A310 )   :X_DROP   dl H_DROP H_DROP 0 X_OVER
the X_DROP name plays a totally different role than
the X_OVER name. This can be eye-balled.
(Compare with the discussion about two dimensional
math expressions, that can be eye-balled, with the rpn
expressions that can't ).

So I'm pretty convinced of my choice here.

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

#35502

Albert van der Horst <albert@spenarnc.xs4all.nl> wrote:
> 
> I started with the word guilty. It is not *necessary* to
> use recognizers here, I agree.
> 
> However, if we start along this road, we should keep S" and do
> floating point numbers like so:
>    FP: 123.45e6
> and allow for totally portable floating point extensions
> (and maybe be obliged to add [FP:] )

Not at all: there is IMO one application need for recognizers, and
that is user-defined literals, of which floating point is one case.
That's AFAIK where the idea came from.  It's a good idea, if done well
and in accordance with the minimalist philosophy of the language.

Everything else we have seen in this thread is a solution looking for
a problem; a way to define arbitrary syntaxes which serve no purpose
other than to obfuscate code.

> The purpose of syntax improvements / abstractions is to make it easier
> to forget what is under the bonnet and lift your level of abstraction
> one up.
> 
> In
>    ( 0804,A310 )   :X_DROP   dl H_DROP H_DROP 0 X_OVER
> the X_DROP name plays a totally different role than
> the X_OVER name. This can be eye-balled.

Ummm, how is this easier to eye-ball than "label X_DROP" ?  In what
way is it an abstraction over that?

Andrew.

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

#35510

In article <946dnWghLKA-IjbJnZ2dnUU7-f2dnZ2d@supernews.com>,
Andrew Haley  <andrew29@littlepinkcloud.invalid> wrote:
>Albert van der Horst <albert@spenarnc.xs4all.nl> wrote:
>> In
>>    ( 0804,A310 )   :X_DROP   dl H_DROP H_DROP 0 X_OVER
>> the X_DROP name plays a totally different role than
>> the X_OVER name. This can be eye-balled.
>
>Ummm, how is this easier to eye-ball than "label X_DROP" ?  In what
>way is it an abstraction over that?

Nobody believes this, but the visual cortex, through years of training
reading books, blends :X_DROP  into a unity. It'll take years
of using ciasdis (which I myself haven't even done) to
get the same result with label X_DROP .

This is the same subject as the eyeballing of complex 2-dimensional
formulae. Those are there for a reason.
>
>Andrew.
-- 
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]

#35534

Albert van der Horst <albert@spenarnc.xs4all.nl> wrote:
> In article <946dnWghLKA-IjbJnZ2dnUU7-f2dnZ2d@supernews.com>,
> Andrew Haley  <andrew29@littlepinkcloud.invalid> wrote:
>>Albert van der Horst <albert@spenarnc.xs4all.nl> wrote:
>>> In
>>>    ( 0804,A310 )   :X_DROP   dl H_DROP H_DROP 0 X_OVER
>>> the X_DROP name plays a totally different role than
>>> the X_OVER name. This can be eye-balled.
>>
>>Ummm, how is this easier to eye-ball than "label X_DROP" ?  In what
>>way is it an abstraction over that?
> 
> Nobody believes this, but the visual cortex, through years of training
> reading books, blends :X_DROP  into a unity.

I believe that.  However, I want a label to stand out; I don't want it
to blend into anything.  That's not an unusual requirement.  For
example, Ada puts its labels into double angle brackets so that they
stand out.

Andrew.

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

#35550

In article <p9adndQs5Nx_iTDJnZ2dnUU7-QOdnZ2d@supernews.com>,
Andrew Haley  <andrew29@littlepinkcloud.invalid> wrote:
>Albert van der Horst <albert@spenarnc.xs4all.nl> wrote:
<SNIP>
>>
>> Nobody believes this, but the visual cortex, through years of training
>> reading books, blends :X_DROP  into a unity.
>
>I believe that.  However, I want a label to stand out; I don't want it
>to blend into anything.  That's not an unusual requirement.  For
>example, Ada puts its labels into double angle brackets so that they
>stand out.

Because :X_DROP blends into a unity it stands out as different
from X_DROP. Are you intentionally trying to misunderstand this?

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

#35563

Albert van der Horst <albert@spenarnc.xs4all.nl> wrote:
> In article <p9adndQs5Nx_iTDJnZ2dnUU7-QOdnZ2d@supernews.com>,
> Andrew Haley  <andrew29@littlepinkcloud.invalid> wrote:
>>Albert van der Horst <albert@spenarnc.xs4all.nl> wrote:
> <SNIP>
>>>
>>> Nobody believes this, but the visual cortex, through years of
>>> training reading books, blends :X_DROP into a unity.
>>
>>I believe that.  However, I want a label to stand out; I don't want it
>>to blend into anything.  That's not an unusual requirement.  For
>>example, Ada puts its labels into double angle brackets so that they
>>stand out.
> 
> Because :X_DROP blends into a unity it stands out as different from
> X_DROP.

OK.

> Are you intentionally trying to misunderstand this?

No, I'm not.  I honestly would find label X_DROP easier to read in a
forth program, because it's what I expect.  I do not understand why
you prefer :X_DROP ; I do not.

Andrew.

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

#35458

On Saturday, January 3, 2015 5:37:44 AM UTC-6, Andrew Haley wrote:
> 5.  SET-RECOGNIZERS and GET-RECOGNIZERS push a lot of stuff onto the
>     data stack for no obvious purpose.

I'd rather have the 10-cell array from the implementation
provided here, than the 'a b c 3' GET-ORDER style stack
mechanism.  The stack makes it easy to add stuff to the top, and
to add stuff to the bottom, and it makes everything else harder.

> I am rather concerned that most of the more exotic uses for this won't
> make Forth programs any easier to read or write, but are more of the
> unnecessarily "cute" syntactical tricks loved by a subset of Forth
> programmers, especially newbies.

Because of REFILL this can already be done.  Any word can take
over the entire rest of that file's compilation, and it can do
all the same potentially stupid tricks that recognizers can be
used for.  The only difference -- and this is the same difference
where actually useful recognizers are concerned -- is that REFILL
makes it easier to screw up in subtle ways, and harder to combine
unrelated syntactical tricks.


On Saturday, January 3, 2015 9:54:31 AM UTC-6, JennyB wrote:
> 1 How can you be sure, for any implementation, the Julian's code doesn't break EVALUATE? 

True, my code turns EVALUATE into 2DROP in every case except
those where it accidentally applies to a string already beginning
with two spaces.  You posted a solution to that problem that uses
SOURCE-ID , but recognizers still pose a problem to EVALUATE ,
because in some cases you want EVALUATE to make use of your
recognizers and in some cases you don't -- and in many cases, the
person writing the EVALUATE has no expectation that your
recognizers will be involved.

...

Wil Baden had ThisForth, I think, that went crazy with EVALUATE .
Practically even 1+ was defined as S" 1 +" EVALUATE , and you'd
break the system if you ever defined a lexically appropriate (but
non-Forth) +


On Sunday, January 4, 2015 6:51:52 AM UTC-6, Anton Ertl wrote:
> I was somewhat surprised that he used recognizers for his ideas at
> all, because recognizers work at the word level, whereas his stuff is
> about interpreting lines.  Apparently one can make that work with
> recognizers, but it does not seem a very natural solution to me.

No, it wasn't :-)  Also strings-as-lists are pretty pointlessly
awful.  A more serious recognizer that I wrote, though still just
in reply to someone on clf, was to facilitate easy access to
vocabularies:

https://groups.google.com/d/msg/comp.lang.forth/hJg7qsOLJK0/wjWwS5I0k4UJ

That was written back when GET-RECOGNIZERS had an argument in
gforth.

I'd say that some actually good uses of recognizers are:

1. ->foo for TO FOO
2. .foo for >o FOO >o in mini-oof2.fs
3. something like that vocabulary-access recognizer, in code that
   legitimately uses a lot of vocabularies.
3. array, tuple, list, and map literal recognizers, and access
   recognizers.
4. lexically appropriate stuff.  You don't need to really writing
   Forth anymore.


An argument to have a recognizer system, rather than any
particular recognizer, is that it makes it much easier to port
Forth code.  Not just in direction from Forths that use
recognizers and have "string literals" and such, but also in the
direction from Forths that have relatively liberal double
literals, like SwiftForth.



And, completely unrelatedly, here are two commands performed on a
shared webhosting server:

$ time for x in {1..1000}; do php -r 'die();' < /dev/null > /dev/null; done

real	0m33.051s
user	0m15.440s
sys	0m7.480s

$ time for x in {1..1000}; do sf bye < /dev/null > /dev/null; done

real	0m1.966s
user	0m0.060s
sys	0m0.710s


-- Julian

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

#35473

On Sunday, 4 January 2015 15:48:06 UTC, Julian Fondren  wrote:
> On Saturday, January 3, 2015 5:37:44 AM UTC-6, Andrew Haley wrote:
> > 5.  SET-RECOGNIZERS and GET-RECOGNIZERS push a lot of stuff onto the
> >     data stack for no obvious purpose.
> 
> I'd rather have the 10-cell array from the implementation
> provided here, than the 'a b c 3' GET-ORDER style stack
> mechanism.  The stack makes it easy to add stuff to the top, and
> to add stuff to the bottom, and it makes everything else harder.

No reason why you can't do that, but for portability provide GET-CURRENT and SET-CURRENT too.  Then your search-order-changing words become:

  : socw  your-socw your-getcurrent my-set-current ;
> 


> True, my code turns EVALUATE into 2DROP in every case except
> those where it accidentally applies to a string already beginning
> with two spaces.  You posted a solution to that problem that uses
> SOURCE-ID , but recognizers still pose a problem to EVALUATE ,
> because in some cases you want EVALUATE to make use of your
> recognizers and in some cases you don't -- and in many cases, the
> person writing the EVALUATE has no expectation that your
> recognizers will be involved.
> 
Yes that's always going to be a problem if you put a recognizer in front of the dictionary search, because you might end up with something that doesn't recognize properly formatted Forth code.  That's not a problem for later recognizers, because at that point normal code only has to deal with numbers, and presumably you still want to recognize them correctly. :)

> 

> 
> I'd say that some actually good uses of recognizers are:
> 
> 1. ->foo for TO FOO
> 2. .foo for >o FOO >o in mini-oof2.fs
> 3. something like that vocabulary-access recognizer, in code that
>    legitimately uses a lot of vocabularies.
> 3. array, tuple, list, and map literal recognizers, and access
>    recognizers.
> 4. lexically appropriate stuff.  You don't need to really writing
>    Forth anymore.
> 
> 

Is 4 the only one for which a recognizer in front of the dictionary is needed? As you say, you're not really writing Forth any more.  Recognizers make it easy to write interpreter loops (iterate through a series of recognizer XTs) so maybe it would be a better approach to write an LLOAD to interpret literate Forth files?

For vocabulary access I'd prefer to put the wordlist as a parameter, thus:

     wordlist  ::word

instead of vocabulary::word

because it makes the recognition faster, reducing it to a prefix check.

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

#35477

JennyB <jennybrien@googlemail.com> writes:
>For vocabulary access I'd prefer to put the wordlist as a parameter, thus:
>
>     wordlist  ::word
>
>instead of vocabulary::word
>
>because it makes the recognition faster, reducing it to a prefix check.

You want a special parse-time thing to happen for <wordlist>, and
<word> to be interpreted normally, so a recognizer for the <wordlist>
part appears to be more fitting (i.e. "<wordlist>:: <word>" or
somesuch), but even that means that either "<wordlist>::" parses
<word> or you need a one-shot change to the search order; the former
is pretty close to what would happen for <wordlist>::<word>, and is
probably a better solution.

Concerning performance, sure, if we have a lot of recognizers to
process, it may become an issue, and then we might think about
optimizations like having one efficient mechanism for all prefix
recognizers, and one for suffixes, or maybe some FSA-based recognizer
mechanism, but I think that we should discuss the basic functionality
first and leave optimizations for later.

- 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 2014: http://www.euroforth.org/ef14/

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

#35480

On Monday, 5 January 2015 14:46:16 UTC, Anton Ertl  wrote:
> JennyB <jennybrien@googlemail.com> writes:
> >For vocabulary access I'd prefer to put the wordlist as a parameter, thus:
> >
> >     wordlist  ::word
> >
> >instead of vocabulary::word
> >
> >because it makes the recognition faster, reducing it to a prefix check.
> 
> You want a special parse-time thing to happen for <wordlist>, and
> <word> to be interpreted normally, so a recognizer for the <wordlist>
> part appears to be more fitting (i.e. "<wordlist>:: <word>" or
> somesuch), but even that means that either "<wordlist>::" parses
> <word> or you need a one-shot change to the search order; the former
> is pretty close to what would happen for <wordlist>::<word>, and is
> probably a better solution.

Yes, I only noticed after I posted that it doesn't actually work at compile-time: wordlist would need to be both present and immediate. :( I don't like the idea of a recognizer that does extra parsing - wordlist:: word rather than wordlist::word.  Having it all in one unit makes clearer what happens with POSTPONE - the parsing is done early rather than late.
> 
> Concerning performance, sure, if we have a lot of recognizers to
> process, it may become an issue, and then we might think about
> optimizations like having one efficient mechanism for all prefix
> recognizers, and one for suffixes, or maybe some FSA-based recognizer
> mechanism, but I think that we should discuss the basic functionality
> first and leave optimizations for later.
> 
Agreed.  I got distracted thinking maybe all prefix-based recognizers could be in a table so that only one needed to be checked. That's possible, but unnecessary.

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

#35589

JennyB <jennybrien@googlemail.com> writes:
>On Monday, 5 January 2015 14:46:16 UTC, Anton Ertl  wrote:
>> JennyB <jennybrien@googlemail.com> writes:
>> >For vocabulary access I'd prefer to put the wordlist as a parameter, thu=
>s:
>> >
>> >     wordlist  ::word
>> >
>> >instead of vocabulary::word
>> >
>> >because it makes the recognition faster, reducing it to a prefix check.
>>=20
>> You want a special parse-time thing to happen for <wordlist>, and
>> <word> to be interpreted normally, so a recognizer for the <wordlist>
>> part appears to be more fitting (i.e. "<wordlist>:: <word>" or
>> somesuch), but even that means that either "<wordlist>::" parses
>> <word> or you need a one-shot change to the search order; the former
>> is pretty close to what would happen for <wordlist>::<word>, and is
>> probably a better solution.

> I don't lik=
>e the idea of a recognizer that does extra parsing - wordlist:: word rather=
> than wordlist::word.  Having it all in one unit makes clearer what happens=
> with POSTPONE - the parsing is done early rather than late.

Good point.  Parsing extra stuff in the (parse-time part of the)
recognizer is technically ok and used in the string recognizer,
e.g.

"bla bla"

but for readability one should conform with the expectations of Forth
programmers where possible, and recognizers normally should not do
extra parsing.

>> Concerning performance, sure, if we have a lot of recognizers to
>> process, it may become an issue, and then we might think about
>> optimizations like having one efficient mechanism for all prefix
>> recognizers, and one for suffixes, or maybe some FSA-based recognizer
>> mechanism, but I think that we should discuss the basic functionality
>> first and leave optimizations for later.
>>=20
>Agreed.  I got distracted thinking maybe all prefix-based recognizers could=
> be in a table so that only one needed to be checked. That's possible, but =
>unnecessary.

If there are lots of recognizers, it might become necessary.

It may be a good idea to specify a prefix or regexp that covers all
the strings the recognizer can match; a system that wants to spend
little time in recognizer matching could check all the prefixes or
regexps with an FSA first, all of them together in one pass, and then
process only those recognizers from the recognizer stack that have not
been excluded by this quick check.  But that's something for later,
when we have agreed on the more basic functionality.

- 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 2014: http://www.euroforth.org/ef14/

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

#35489

Anton Ertl wrote:

> JennyB <jennybrien@googlemail.com> writes:
>>For vocabulary access I'd prefer to put the wordlist as a parameter, thus:
>>
>>     wordlist  ::word
>>
>>instead of vocabulary::word
>>
>>because it makes the recognition faster, reducing it to a prefix check.
> 
> You want a special parse-time thing to happen for <wordlist>, and
> <word> to be interpreted normally, so a recognizer for the <wordlist>
> part appears to be more fitting (i.e. "<wordlist>:: <word>" or
> somesuch), but even that means that either "<wordlist>::" parses
> <word> or you need a one-shot change to the search order; the former
> is pretty close to what would happen for <wordlist>::<word>, and is
> probably a better solution.

If you want a one-shot lookup like <wordlist>::, that recognizer might push 
a special one-shot recognizer on the top of the recognizer stack (or replace 
the complete stack and save it somewhere else), which looks up the specified 
wordlist, and removes itself from the recognizer stack (restore the original 
stack).

That thing would be difficult with POSTPONE, but would work fine within ]] 
[[.

-- 
Bernd Paysan
"If you want it done right, you have to do it yourself"
http://bernd-paysan.de/
net2o ID: kQusJzA;7*?t=uy@X}1GWr!+0qqp_Cn176t4(dQ*

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

#35491

In article <m8fet3$cec$1@dont-email.me>,
Bernd Paysan  <bernd.paysan@gmx.de> wrote:
>Anton Ertl wrote:
>
>> JennyB <jennybrien@googlemail.com> writes:
>>>For vocabulary access I'd prefer to put the wordlist as a parameter, thus:
>>>
>>>     wordlist  ::word
>>>
>>>instead of vocabulary::word
>>>
>>>because it makes the recognition faster, reducing it to a prefix check.
>> 
>> You want a special parse-time thing to happen for <wordlist>, and
>> <word> to be interpreted normally, so a recognizer for the <wordlist>
>> part appears to be more fitting (i.e. "<wordlist>:: <word>" or
>> somesuch), but even that means that either "<wordlist>::" parses
>> <word> or you need a one-shot change to the search order; the former
>> is pretty close to what would happen for <wordlist>::<word>, and is
>> probably a better solution.
>
>If you want a one-shot lookup like <wordlist>::, that recognizer might push 
>a special one-shot recognizer on the top of the recognizer stack (or replace 
>the complete stack and save it somewhere else), which looks up the specified 
>wordlist, and removes itself from the recognizer stack (restore the original 
>stack).
>
>That thing would be difficult with POSTPONE, but would work fine within ]] 
>[[.

I don't see where POSTPONE comes in.

NAMESPACE AAP
AAP DEFINITIONS
: hello "hello world!" TYPE ;
PREVIOUS DEFINITIONS

\ Add AAP to the search order for one lookup.
: AAP::  AAP NAME EVALUATE PREVIOUS ;  PREFIX IMMEDIATE 

AAP::hello
"hello world!"
: test AAP::hello ;
test
"hello world!"

People who hate EVALUATE can do 
'AAP >WID PARSE-NAME SEARCH-WORDLIST <error handling> EXECUTE 
or some such.

>
>-- 
>Bernd Paysan
>"If you want it done right, you have to do it yourself"
>http://bernd-paysan.de/
>net2o ID: kQusJzA;7*?t=uy@X}1GWr!+0qqp_Cn176t4(dQ*
>


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

#35583

Julian Fondren <julian.fondren@gmail.com> writes:
>On Saturday, January 3, 2015 9:54:31 AM UTC-6, JennyB wrote:
>> 1 How can you be sure, for any implementation, the Julian's code doesn't break EVALUATE? 
>
>True, my code turns EVALUATE into 2DROP in every case except
>those where it accidentally applies to a string already beginning
>with two spaces.  You posted a solution to that problem that uses
>SOURCE-ID , but recognizers still pose a problem to EVALUATE ,
>because in some cases you want EVALUATE to make use of your
>recognizers and in some cases you don't -- and in many cases, the
>person writing the EVALUATE has no expectation that your
>recognizers will be involved.

Sounds like the usual problem of many (bad) uses of EVALUATE: the text
is interpreted in the state (BASE, search order, STATE, recognizer
order, etc.) present at run-time; in some uses of EVALUATE that is
what is wanted, and in those cases EVALUATE is appropriate.  In other
cases one does not want that; one can try to set up the state as
intended, but that is pretty cumbersome, and people typically don't do
it; instead they either avoid EVALUATE and replace it with something
else (e.g., POSTPONE), or they hope that the setting will be fine for
their use of EVALUATE, and the program will not work as intended if
it is not.

Recognizers don't change this, but having a recognizer stack makes it
even more cumbersome to get the setting right.  But since nobody uses
this technique anyway, that does not really matter.  As for the "hope
the setting will be fine" approach, I doubt that recognizers make much
of a difference in the number of cases where this will fail; and if it
does, that this is a bad thing; it might encourage the programmers to
use a more reliable approach.

- 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 2014: http://www.euroforth.org/ef14/

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

#35606

On 02/01/2015 19:56, Matthias Trute wrote:
> some time ago I posted the following text to the Forth200x mailing list.
> There I got really valuable feedback and decided now to post the same text
> here at c.l.f as well. Why the same text, you may ask? Well, we
> discussed many use cases of the concept and even some fundamental
> changes in different areas of Forth but not the concept as such.
>
> There is a nicely formatted PDF at
> http://amforth.sourceforge.net/pr/Recognizer-rfc.pdf

I think the concept of recognizers is a brilliant idea and would solve 
frustrations I've had with the inflexibility of the classic Forth 
interpreter.

Why can't recognisers be unified with the search order so that a user 
can interleave recognisers and wordlist searches as needed. We wouldn't 
need to introduce words such as GET-RECOGNIZERS and SET-RECOGNIZERS 
since GET-ORDER and SET-ORDER could be extended to handle recognizer ids 
(rids) as well as wids.

I suppose this could be achieved by clearing the search order completely 
and writing your own wordlist recognisers but that seems a poor way to 
do it.

-- 
Gerry

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

#35867

On Thursday, 8 January 2015 20:44:19 UTC, Gerry  wrote:

> Why can't recognisers be unified with the search order so that a user 
> can interleave recognisers and wordlist searches as needed. We wouldn't 
> need to introduce words such as GET-RECOGNIZERS and SET-RECOGNIZERS 
> since GET-ORDER and SET-ORDER could be extended to handle recognizer ids 
> (rids) as well as wids.
> 
I've had a look at that and there are several drawbacks:

Recognizers, unlike wordlists, are active.  To explicitly set them in a search order you need to either tick them or define their xts as constants

You can't meaningfully do SET-CURRENT or SEARCH-WORDLIST on rids.

FIND or its equivalent has to either execute all the rids in the search order, or know to skip them. If the former, recognizers with a slow path to R:FAIL could slow search noticeably.

There is no advantage generally in interleaving wids and rids. If you know the recognizer is active you are not going to use definition names that clash with it.  If you do not know it is active then when there is an unexpected clash you will always want the definition, no the result of the recognizer.  so generally you will want the all the wordlists to be searched first. 

When you introduce a new literal type, you may want a wordlist for the words that act on it.  Then you need two new items in the search order, inserted in different places. 

You will need to redeclare any extra recognizers after ONLY.

In short, though superficially similar, they are two different things and are probably best handled on two separate lists. Its useful to have a recognizer like REC:WORD that searches the whole dictionary and responds to changes in the search order if you choose to implement it.

 
It is quite easy to add rids to either end of the recognizer stack

Top:  GET-RECOGNIZERS rid SWAP 1+ SET-RECOGNIZERS
  
Bottom:   rid GET-RECOGNIZERS 1+ SET-RECOGNIZERS

Should REC:WORD and REC:NUM be explicitly in GET-RECOGNIZERS and SET-RECOGNIZERS?

It's possible to have a system interpreter where DO-RECOGNIZERS tries REC:WORD ( or FIND) first, then the items on the system recognizers stack in turn, and finally REC:NUM if it gets that far. Even in that case you can turn off REC:NUM by having a recognizer in front of it that always succeeds.  You can't turn off REC:WORD, but if you remove that you don't have a text interpreter any more. That means that you don't have to declare REC:WORD and REC:NUM whenever you explicitly declare the rec-stack order, but I don't think it gets you anything else.

Recognizer order doesn't matter as much as wordlist order. Mostly it's o.k. to add a recognizer to the bottom of the stack and leave it there until MARKER removes it, so if REC:WORD is explicitly on the top of the stack it will remain there. Sometimes you will want a recognizer to be searched first, because it modifies an existing recognizer, in which case you can tuck it under REC:WORD

 GET-RECOGNIZERS 1+ ROT ROT SET-RECOGNIZERS

and remove it again:

  GET-RECOGNIZERS 1- ROT DROP SET-RECOGNIZERS

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

#35869

JennyB wrote:
> It's possible to have a system interpreter where DO-RECOGNIZERS tries
> REC:WORD ( or FIND) first, then the items on the system recognizers stack
> in turn, and finally REC:NUM if it gets that far. Even in that case you
> can turn off REC:NUM by having a recognizer in front of it that always
> succeeds.  You can't turn off REC:WORD, but if you remove that you don't
> have a text interpreter any more. That means that you don't have to
> declare REC:WORD and REC:NUM whenever you explicitly declare the rec-stack
> order, but I don't think it gets you anything else.

Stop, stop.  Modifying the recognizer stack so that it is no longer Forth is 
a feature, not a bug.  And adding things like e.g. the local recognizer on 
top of the recognizer stack, and the floating point recognizer to the 
bottom, so that rec:word and rec:num are sandwitched in between is even 100% 
standard.

This "let's have xyz fixed" is a bad idea, because it makes the overall 
concept less flexible and thus less useful.

What do you want to achieve with special purposing the recognizer stack?

-- 
Bernd Paysan
"If you want it done right, you have to do it yourself"
http://bernd-paysan.de/
net2o ID: kQusJzA;7*?t=uy@X}1GWr!+0qqp_Cn176t4(dQ*

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

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

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

csiph-web