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

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

Recognizers and LOCATE

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

Contents

  Recognizers and LOCATE Andrew Haley <andrew29@littlepinkcloud.invalid> - 2017-01-24 12:38 -0600
    Recognizers and LOCATE JennyB <jennybrien@googlemail.com> - 2017-01-24 10:56 -0800
      Re: Recognizers and LOCATE Bernd Paysan <bernd@net2o.de> - 2017-01-24 22:25 +0000
        Re: Recognizers and LOCATE Andrew Haley <andrew29@littlepinkcloud.invalid> - 2017-01-25 03:16 -0600
          Re: Recognizers and LOCATE JennyB <jennybrien@googlemail.com> - 2017-01-25 08:37 -0800
            Re: Recognizers and LOCATE Alex <alex@rivadpm.com> - 2017-01-25 14:22 -0500
              Re: Recognizers and LOCATE Alex <alex@rivadpm.com> - 2017-01-25 14:26 -0500
              Re: Recognizers and LOCATE Matthias Trute <matthias.trute@gmail.com> - 2017-01-25 11:49 -0800
                Re: Recognizers and LOCATE Andrew Haley <andrew29@littlepinkcloud.invalid> - 2017-01-26 03:33 -0600
                  Re: Recognizers and LOCATE Matthias Trute <matthias.trute@gmail.com> - 2017-01-26 10:14 -0800
                    Re: Recognizers and LOCATE JennyB <jennybrien@googlemail.com> - 2017-01-26 11:04 -0800
              Re: Recognizers and LOCATE Bernd Paysan <bernd@net2o.de> - 2017-01-26 01:24 +0000
                Re: Recognizers and LOCATE Andrew Haley <andrew29@littlepinkcloud.invalid> - 2017-01-26 06:26 -0600
                  Re: Recognizers and LOCATE Bernd Paysan <bernd@net2o.de> - 2017-03-12 00:47 +0000
                    Re: Recognizers and LOCATE albert@cherry.spenarnc.xs4all.nl (Albert van der Horst) - 2017-03-12 17:01 +0100
                      Re: Recognizers and LOCATE Matthias Trute <matthias.trute@gmail.com> - 2017-03-13 12:31 -0700
                        Re: Recognizers and LOCATE Andrew Haley <andrew29@littlepinkcloud.invalid> - 2017-03-14 04:51 -0500
                          Re: Recognizers and LOCATE Matthias Trute <matthias.trute@gmail.com> - 2017-03-14 12:48 -0700
                Re: Recognizers and LOCATE Alex <alex@rivadpm.com> - 2017-01-27 17:18 +0000
                  Re: Recognizers and LOCATE Matthias Trute <matthias.trute@gmail.com> - 2017-01-27 09:28 -0800
                    Re: Recognizers and LOCATE Alex <alex@rivadpm.com> - 2017-01-27 17:35 +0000
                      Re: Recognizers and LOCATE Matthias Trute <matthias.trute@gmail.com> - 2017-01-28 04:29 -0800
          Re: Recognizers and LOCATE Bernd Paysan <bernd@net2o.de> - 2017-01-25 21:07 +0000
            Re: Recognizers and LOCATE anton@mips.complang.tuwien.ac.at (Anton Ertl) - 2017-01-26 11:24 +0000
              Re: Recognizers and LOCATE Andrew Haley <andrew29@littlepinkcloud.invalid> - 2017-01-26 06:23 -0600
                Re: Recognizers and LOCATE anton@mips.complang.tuwien.ac.at (Anton Ertl) - 2017-01-26 15:39 +0000
                  Re: Recognizers and LOCATE Andrew Haley <andrew29@littlepinkcloud.invalid> - 2017-01-26 11:14 -0600
                    Re: Recognizers and LOCATE anton@mips.complang.tuwien.ac.at (Anton Ertl) - 2017-01-27 08:37 +0000
                      Re: Recognizers and LOCATE Andrew Haley <andrew29@littlepinkcloud.invalid> - 2017-01-27 03:26 -0600
                        Re: Recognizers and LOCATE anton@mips.complang.tuwien.ac.at (Anton Ertl) - 2017-01-27 11:37 +0000
                          Re: Recognizers and LOCATE stephen@mpeforth.com (Stephen Pelc) - 2017-01-27 17:28 +0000
                          Re: Recognizers and LOCATE Andrew Haley <andrew29@littlepinkcloud.invalid> - 2017-01-28 04:22 -0600
                            Re: Recognizers and LOCATE Matthias Trute <matthias.trute@gmail.com> - 2017-01-28 04:35 -0800
                              Re: Recognizers and LOCATE JennyB <jennybrien@googlemail.com> - 2017-01-28 07:03 -0800
                                Re: Recognizers and LOCATE Matthias Trute <matthias.trute@gmail.com> - 2017-01-28 07:42 -0800
                                  Re: Recognizers and LOCATE anton@mips.complang.tuwien.ac.at (Anton Ertl) - 2017-01-28 17:25 +0000
                                Re: Recognizers and LOCATE peter.m.falth@gmail.com - 2017-01-28 08:05 -0800
                                  Re: Recognizers and LOCATE JennyB <jennybrien@googlemail.com> - 2017-01-28 09:27 -0800
                              Re: Recognizers and LOCATE albert@cherry.spenarnc.xs4all.nl (Albert van der Horst) - 2017-01-28 19:18 +0100
                              Re: Recognizers and LOCATE Andrew Haley <andrew29@littlepinkcloud.invalid> - 2017-01-29 04:35 -0600
                            Re: Recognizers and LOCATE anton@mips.complang.tuwien.ac.at (Anton Ertl) - 2017-01-29 16:59 +0000
                              Re: Recognizers and LOCATE albert@cherry.spenarnc.xs4all.nl (Albert van der Horst) - 2017-01-29 19:40 +0100
                                Re: Recognizers and LOCATE anton@mips.complang.tuwien.ac.at (Anton Ertl) - 2017-01-31 17:01 +0000
                              Re: Recognizers and LOCATE Andrew Haley <andrew29@littlepinkcloud.invalid> - 2017-01-31 04:12 -0600
                          Re: Recognizers and LOCATE Bernd Paysan <bernd@net2o.de> - 2017-03-12 01:25 +0000
                            Re: Recognizers and LOCATE minforth@arcor.de - 2017-03-12 01:30 -0800
                            Re: Recognizers and LOCATE anton@mips.complang.tuwien.ac.at (Anton Ertl) - 2017-03-12 10:07 +0000
                              Re: Recognizers and LOCATE Bernd Paysan <bernd@net2o.de> - 2017-03-15 23:30 +0000
                                Re: Recognizers and LOCATE anton@mips.complang.tuwien.ac.at (Anton Ertl) - 2017-03-16 11:59 +0000
                                  Re: Recognizers and LOCATE Bernd Paysan <bernd@net2o.de> - 2017-03-17 21:46 +0000
                            Re: Recognizers and LOCATE Andrew Haley <andrew29@littlepinkcloud.invalid> - 2017-03-12 06:51 -0500
                              Re: Recognizers and LOCATE anton@mips.complang.tuwien.ac.at (Anton Ertl) - 2017-03-12 13:05 +0000
                                Re: Recognizers and LOCATE Andrew Haley <andrew29@littlepinkcloud.invalid> - 2017-03-12 12:04 -0500
    Re: Recognizers and LOCATE albert@cherry.spenarnc.xs4all.nl (Albert van der Horst) - 2017-01-24 20:41 +0100
    Re: Recognizers and LOCATE anton@mips.complang.tuwien.ac.at (Anton Ertl) - 2017-01-26 11:52 +0000
      Re: Recognizers and LOCATE Andrew Haley <andrew29@littlepinkcloud.invalid> - 2017-01-26 08:20 -0600
        Re: Recognizers and LOCATE anton@mips.complang.tuwien.ac.at (Anton Ertl) - 2017-01-26 16:26 +0000
          Re: Recognizers and LOCATE Andrew Haley <andrew29@littlepinkcloud.invalid> - 2017-01-26 11:27 -0600
            Re: Recognizers and LOCATE anton@mips.complang.tuwien.ac.at (Anton Ertl) - 2017-01-27 09:10 +0000
              Re: Recognizers and LOCATE Andrew Haley <andrew29@littlepinkcloud.invalid> - 2017-01-27 09:59 -0600
                Re: Recognizers and LOCATE anton@mips.complang.tuwien.ac.at (Anton Ertl) - 2017-01-27 16:16 +0000
                  Re: Recognizers and LOCATE Andrew Haley <andrew29@littlepinkcloud.invalid> - 2017-01-28 04:35 -0600
                    Re: Recognizers and LOCATE albert@cherry.spenarnc.xs4all.nl (Albert van der Horst) - 2017-01-28 19:41 +0100
                    Re: Recognizers and LOCATE anton@mips.complang.tuwien.ac.at (Anton Ertl) - 2017-01-29 16:18 +0000
                      Re: Recognizers and LOCATE Andrew Haley <andrew29@littlepinkcloud.invalid> - 2017-01-31 04:21 -0600
                  Re: Recognizers and LOCATE Bernd Paysan <bernd@net2o.de> - 2017-03-12 01:07 +0000
      Re: Recognizers and LOCATE albert@cherry.spenarnc.xs4all.nl (Albert van der Horst) - 2017-01-26 21:08 +0100
        Re: Recognizers and LOCATE anton@mips.complang.tuwien.ac.at (Anton Ertl) - 2017-01-27 10:13 +0000

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

#54463

On 1/27/2017 17:28, Matthias Trute wrote:
> Am Freitag, 27. Januar 2017 18:18:13 UTC+1 schrieb Alex:
>> On 1/26/2017 01:24, Bernd Paysan wrote:
>>> Am Wed, 25 Jan 2017 14:22:46 -0500 schrieb Alex:
>>>
>>>> For those recognizers that need to do conversions (because they can't
>>>> decide from a single test, such as those for numbers) I would prefer to
>>>> see the recognizer not return ( i*x dt:<type> | dt:null ) but a bare (
>>>> dt:<type> | dt:null ) and communicate the conversion elsewhere off
>>>> stack.
>>>> This has from my perspective the added benefit of avoiding indeterminate
>>>> stack contents that the current proposal requires.
>>>
>>> My take on this is that the next proposal should allow this, and dt>int/
>>> comp/post or the EXECUTE of the token provided by them will extract the
>>> embedded data, but it should not be mandatory for the implementer to use
>>> some off-stack storage.  We don't have a full-blown garbage collected OOP
>>> system in most Forths, and while a desktop system can just store away all
>>> the interpreted tokens without worrying about running out of memory, an
>>> embedded system can't do that.
>>
>> The area could be associated with the token. So for example, dt:num has
>> 3 XTs for interpret compile and postpone and a small cell or two sized
>> scratch area beyond that for the recognised number. A limitation would
>> be: no recursive recognizers.
>
> worse: no parallel recognizers *by design*.

Is parallel different from recursive?

-- 
Alex

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

#54484

Am Freitag, 27. Januar 2017 18:35:40 UTC+1 schrieb Alex:
> On 1/27/2017 17:28, Matthias Trute wrote:
> > Am Freitag, 27. Januar 2017 18:18:13 UTC+1 schrieb Alex:
> >> On 1/26/2017 01:24, Bernd Paysan wrote:
> >>> Am Wed, 25 Jan 2017 14:22:46 -0500 schrieb Alex:
> >>>
> >>>> For those recognizers that need to do conversions (because they can't
> >>>> decide from a single test, such as those for numbers) I would prefer to
> >>>> see the recognizer not return ( i*x dt:<type> | dt:null ) but a bare (
> >>>> dt:<type> | dt:null ) and communicate the conversion elsewhere off
> >>>> stack.
> >>>> This has from my perspective the added benefit of avoiding indeterminate
> >>>> stack contents that the current proposal requires.
> >>>
> >>> My take on this is that the next proposal should allow this, and dt>int/
> >>> comp/post or the EXECUTE of the token provided by them will extract the
> >>> embedded data, but it should not be mandatory for the implementer to use
> >>> some off-stack storage.  We don't have a full-blown garbage collected OOP
> >>> system in most Forths, and while a desktop system can just store away all
> >>> the interpreted tokens without worrying about running out of memory, an
> >>> embedded system can't do that.
> >>
> >> The area could be associated with the token. So for example, dt:num has
> >> 3 XTs for interpret compile and postpone and a small cell or two sized
> >> scratch area beyond that for the recognised number. A limitation would
> >> be: no recursive recognizers.
> >
> > worse: no parallel recognizers *by design*.
> 
> Is parallel different from recursive?

In my world it is.

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

#54400

Am Wed, 25 Jan 2017 03:16:02 -0600 schrieb Andrew Haley:

> Bernd Paysan <bernd@net2o.de> wrote:
>> Am Tue, 24 Jan 2017 10:56:15 -0800 schrieb JennyB:
>>> Doesn't seem too hard to do, just bit of data that can be returned.
>> 
>> No, that is indeed not very difficult.  I think that is the most
>> helpful approach to the problem.
> 
> But it is not possible with the current recognizer proposal.

Yes, I need the debug hook in Gforth to implement it.

However, the plan is to separate the stack abstraction from the 
recognizer proposal, and the stack abstraction then will get an iterator. 
And this iterator is the tool which can be used to implement the 
functionality: Walk through the recognizer, and if it's a match, you can 
check whether that's a normal word (where R>POST gives ['] NOOP), and if 
not, just locate the recognizer.

LOCATE requires a lot of other carnal knowledge to be implemented...

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

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

#54420

Bernd Paysan <bernd@net2o.de> writes:
>Am Wed, 25 Jan 2017 03:16:02 -0600 schrieb Andrew Haley:
>> But it is not possible with the current recognizer proposal.
>
>Yes, I need the debug hook in Gforth to implement it.

As far as I can see, it is possible with the current recognizer
proposal, as you demonstrated by actually implementing it without
changing the existing recognizers.  The implementation of recognizers
might need a change to support LOCATE (in Gforth it did not, because
the hook was there already), but the proposal does not prescribe the
implementation, and it should not.

>Walk through the recognizer, and if it's a match, you can 
>check whether that's a normal word (where R>POST gives ['] NOOP), and if 
>not, just locate the recognizer.

Another view of this is that showing the source code of the recognizer
may not be the thing that the user of LOCATE is interested in,
especially if there is other related source code.  Apart from the word
recognizer, which should show the word, not the source code of the
word recognizer, similar things would be interesting for the
dot-parser recognizer: If it recognizes A.B.C, it should say that the
dot-parser recognizer has recognized this and show the source code of
A, B and C.

So maybe if someone considers LOCATE important enough to propose
standardizing it, and if he considers LOCATE of recognized strings
important, too, he should also propose a way to specify what LOCATE
should show for certain recognizers.

- anton
-- 
M. Anton Ertl  http://www.complang.tuwien.ac.at/anton/home.html
comp.lang.forth FAQs: http://www.complang.tuwien.ac.at/forth/faq/toc.html
     New standard: http://www.forth200x.org/forth200x.html
   EuroForth 2016: http://www.euroforth.org/ef16/

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

#54421

Anton Ertl <anton@mips.complang.tuwien.ac.at> wrote:

> So maybe if someone considers LOCATE important enough to propose
> standardizing it, and if he considers LOCATE of recognized strings
> important, too, he should also propose a way to specify what LOCATE
> should show for certain recognizers.

That's the wrong way to think about it.  (IMO, of course, as usual.)
The question is not "Does this impact the users of systems which only
provide the standard language?" because there are no such systems.

The problem that you can't ask a recognizer "Would you recognize this
string?" isn't specific to LOCATE, but it is an example of the way
that new language features can interact with existing practice in
adverse ways.

It's not necessary to specify what LOCATE should so when presented
with a recognized string, or to specify LOCATE.  The same capability
goes by other names and does different things in different systems.

Andrew.

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

#54428

Andrew Haley <andrew29@littlepinkcloud.invalid> writes:
>Anton Ertl <anton@mips.complang.tuwien.ac.at> wrote:
>
>> So maybe if someone considers LOCATE important enough to propose
>> standardizing it, and if he considers LOCATE of recognized strings
>> important, too, he should also propose a way to specify what LOCATE
>> should show for certain recognizers.
>
>That's the wrong way to think about it.  (IMO, of course, as usual.)
>The question is not "Does this impact the users of systems which only
>provide the standard language?" because there are no such systems.
>
>The problem that you can't ask a recognizer "Would you recognize this
>string?" isn't specific to LOCATE, but it is an example of the way
>that new language features can interact with existing practice in
>adverse ways.

Reality check!  Look at existing practice for the language feature
that the recognizer proposal intends to standardize: interpreter hooks
for recognizing things like FP numbers, dot-parsing, etc.  They
provide no way for interacting with LOCATE or other language features;
actually, LOCATE reports an error even for integers which are
typically hard-coded in systems.  Apparently no users, not even you,
found it worthwhile to complain about this adverse way of feature
interaction (or maybe you did, and the system implementors ignored
you).

So if LOCATE does not work for recognizers (other than the word
recognizer), that's entirely consistent with existing practice, and
compared to current practice it is certainly not an adverse
interaction.

As it happens, extending LOCATE to work for recognizers turned out to
be not that hard (see
<http://git.savannah.gnu.org/cgit/gforth.git/diff/debugs.fs?id=e677b987ce7c96ec0510005b43badbae00e873a7>),
probably quite a bit easier than doing it for the n interpreter hooks
in VFX (if it is possible to do it with that interface at all), and as
a result the only system that has the capability you asked for is one
that uses recognizers; so if you consider LOCATE of non-words
important, recognizers interact with this feature in a beneficial way.

Another existing and even standardized language feature that the
recognizer proposal interacts with in a beneficial way is POSTPONE.

: foo postpone 1 ;

does not work on SwiftForth or on pre-recognizer Gforth.  It works on
VFX and current Gforth.

- anton
-- 
M. Anton Ertl  http://www.complang.tuwien.ac.at/anton/home.html
comp.lang.forth FAQs: http://www.complang.tuwien.ac.at/forth/faq/toc.html
     New standard: http://www.forth200x.org/forth200x.html
   EuroForth 2016: http://www.euroforth.org/ef16/

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

#54432

Anton Ertl <anton@mips.complang.tuwien.ac.at> wrote:
> Andrew Haley <andrew29@littlepinkcloud.invalid> writes:
>>Anton Ertl <anton@mips.complang.tuwien.ac.at> wrote:
>>
>>> So maybe if someone considers LOCATE important enough to propose
>>> standardizing it, and if he considers LOCATE of recognized strings
>>> important, too, he should also propose a way to specify what LOCATE
>>> should show for certain recognizers.
>>
>>That's the wrong way to think about it.  (IMO, of course, as usual.)
>>The question is not "Does this impact the users of systems which only
>>provide the standard language?" because there are no such systems.
>>
>>The problem that you can't ask a recognizer "Would you recognize this
>>string?" isn't specific to LOCATE, but it is an example of the way
>>that new language features can interact with existing practice in
>>adverse ways.
> 
> Reality check!  Look at existing practice for the language feature
> that the recognizer proposal intends to standardize: interpreter
> hooks for recognizing things like FP numbers, dot-parsing, etc.
> They provide no way for interacting with LOCATE or other language
> features; actually, LOCATE reports an error even for integers which
> are typically hard-coded in systems.  Apparently no users, not even
> you, found it worthwhile to complain about this adverse way of
> feature interaction

Well, no, of course not.  Who would say LOCATE 2 ?  But in the example
I cited there is no way for the reader to be able to tell that what
they're looking at is not a name in the dictionary.  I suppose you
could argue that the same is true for dot parsers, but then that's a
black mark against dot parsers, IMO.  Having said that, dot parsers
aren't being proposed for standardization and their syntax seems to me
to be quite distinctive and therefore quite benign.

> (or maybe you did, and the system implementors ignored you).

It's not a problem yet because the use of special "recognizers" for
dot-parsers etc. is very constrained.

> So if LOCATE does not work for recognizers (other than the word
> recognizer), that's entirely consistent with existing practice, and
> compared to current practice it is certainly not an adverse
> interaction.

It will be *if* recognizers get used.  The problem does not yet exist,
except in a very small way in a few special cases.  The more
recognizers get used the worse the problem will be: what looks like a
Forth word may be a list of strings being parsed in different ways by
different recognizers, and anybody who needs to debug a beast like
that is going to need some serious tools.

Standardization is a very high bar.  It's worth examining how a
feature might work out in practice and carefully and seriously
considering what people have to say.

> As it happens, extending LOCATE to work for recognizers turned out to
> be not that hard (see
> <http://git.savannah.gnu.org/cgit/gforth.git/diff/debugs.fs?id=e677b987ce7c96ec0510005b43badbae00e873a7>),
> probably quite a bit easier than doing it for the n interpreter hooks
> in VFX (if it is possible to do it with that interface at all), and as
> a result the only system that has the capability you asked for

There's no need for recognizers to work with LOCATE if there are no
(user-definable) recognizers.  Therefore any system without
recognizers has the capability that I asked for.

> is one that uses recognizers; so if you consider LOCATE of non-words
> important, recognizers interact with this feature in a beneficial
> way.

I suppose there's some magic hook in recognize, but surely any side
effect in the recognizer would still happen, would it not?

Andrew.

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

#54450

Andrew Haley <andrew29@littlepinkcloud.invalid> writes:
>Anton Ertl <anton@mips.complang.tuwien.ac.at> wrote:
>> Andrew Haley <andrew29@littlepinkcloud.invalid> writes:
>>>The problem that you can't ask a recognizer "Would you recognize this
>>>string?" isn't specific to LOCATE, but it is an example of the way
>>>that new language features can interact with existing practice in
>>>adverse ways.
>> 
>> Reality check!  Look at existing practice for the language feature
>> that the recognizer proposal intends to standardize: interpreter
>> hooks for recognizing things like FP numbers, dot-parsing, etc.
>> They provide no way for interacting with LOCATE or other language
>> features; actually, LOCATE reports an error even for integers which
>> are typically hard-coded in systems.  Apparently no users, not even
>> you, found it worthwhile to complain about this adverse way of
>> feature interaction
>
>Well, no, of course not.  Who would say LOCATE 2 ?

Right, and that despite the possibility in Forth to define, e.g.,

: 2 dup ;

>But in the example
>I cited there is no way for the reader to be able to tell that what
>they're looking at is not a name in the dictionary.  I suppose you
>could argue that the same is true for dot parsers, but then that's a
>black mark against dot parsers, IMO.  Having said that, dot parsers
>aren't being proposed for standardization and their syntax seems to me
>to be quite distinctive and therefore quite benign.

And I expect the same to be true of all successful recognizers, and
the existing system-specific recognizers demonstrate this. You are
proposing to complicate the proposal for a "need" that will probably
never materialize.  A perfect example of Chuck Moore's "Don't
anticipate, solve the problem you've got".

>> (or maybe you did, and the system implementors ignored you).
>
>It's not a problem yet because the use of special "recognizers" for
>dot-parsers etc. is very constrained.

You can hook anything into SwiftForth's NOT-DEFINED and into VFX's n
interpreter hooks, so they are not constrained at all, and certainly
not in the form of strings that they can recognize.

>Standardization is a very high bar.  It's worth examining how a
>feature might work out in practice

We know how the feature works out in practice, because the feature is
present in all Forth systems.  Your predictions are pure fantasy.

And in any case, LOCATE can be implemented to work for recognizers as
currently proposed.

>> As it happens, extending LOCATE to work for recognizers turned out to
>> be not that hard (see
>> <http://git.savannah.gnu.org/cgit/gforth.git/diff/debugs.fs?id=e677b987ce7c96ec0510005b43badbae00e873a7>),
>> probably quite a bit easier than doing it for the n interpreter hooks
>> in VFX (if it is possible to do it with that interface at all), and as
>> a result the only system that has the capability you asked for
>
>There's no need for recognizers to work with LOCATE if there are no
>(user-definable) recognizers.  Therefore any system without
>recognizers has the capability that I asked for.

Ex falso quodlibet.  All popular systems have recognizers, just not
the proposed-standard interface for them.

>I suppose there's some magic hook in recognize, but surely any side
>effect in the recognizer would still happen, would it not?

Sure.  What side effects do you have in mind?  And does anybody care?

- anton
-- 
M. Anton Ertl  http://www.complang.tuwien.ac.at/anton/home.html
comp.lang.forth FAQs: http://www.complang.tuwien.ac.at/forth/faq/toc.html
     New standard: http://www.forth200x.org/forth200x.html
   EuroForth 2016: http://www.euroforth.org/ef16/

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

#54451

Anton Ertl <anton@mips.complang.tuwien.ac.at> wrote:
> Andrew Haley <andrew29@littlepinkcloud.invalid> writes:
>>Anton Ertl <anton@mips.complang.tuwien.ac.at> wrote:

>>But in the example I cited there is no way for the reader to be able
>>to tell that what they're looking at is not a name in the
>>dictionary.  I suppose you could argue that the same is true for dot
>>parsers, but then that's a black mark against dot parsers, IMO.
>>Having said that, dot parsers aren't being proposed for
>>standardization and their syntax seems to me to be quite distinctive
>>and therefore quite benign.
> 
> And I expect the same to be true of all successful recognizers, and
> the existing system-specific recognizers demonstrate this.

But you have already described one recognizer (for TO) for which this
certainly is not true.  It wasn't my idea.  And it's an example of
precisely the problem that I'm anticipating, not a product of my
overheated imagination.

This is not a matter of absolutes, but of degree.

> You are proposing to complicate the proposal

Not at all: I suspect that if this proposal were designed well it
should be possible to accomodate things such as LOCATE well without
greatly complicating it.  But it's hard to retro-fit such things once
the proposal is in wide use.

> for a "need" that will probably never materialize.  A perfect
> example of Chuck Moore's "Don't anticipate, solve the problem you've
> got".

It's not yet a problem.

>>> (or maybe you did, and the system implementors ignored you).
>>
>>It's not a problem yet because the use of special "recognizers" for
>>dot-parsers etc. is very constrained.
> 
> You can hook anything into SwiftForth's NOT-DEFINED and into VFX's n
> interpreter hooks, so they are not constrained at all, and certainly
> not in the form of strings that they can recognize.

You can, but they are not widely used, precisely because they are
internal and system-secific.

>>feature might work out in practice
> 
> We know how the feature works out in practice, because the feature is
> present in all Forth systems.

Actually, no, it is not, as I have explained.  Several times.

> And in any case, LOCATE can be implemented to work for recognizers as
> currently proposed.

No, because of side effects, as I have explained.

>>There's no need for recognizers to work with LOCATE if there are no
>>(user-definable) recognizers.  Therefore any system without
>>recognizers has the capability that I asked for.
> 
> Ex falso quodlibet.

Quod non est sic.  Ut prius.

>>I suppose there's some magic hook in recognize, but surely any side
>>effect in the recognizer would still happen, would it not?
> 
> Sure.  What side effects do you have in mind?  And does anybody
> care?

Anything.  I think so.  I'm a careful and conservative engineer whose
first reaction to any proposal, no matter where it comes from, is
"What adverse effects might this have?"  You need people like that.

Andrew.

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

#54459

Andrew Haley <andrew29@littlepinkcloud.invalid> writes:
>Anton Ertl <anton@mips.complang.tuwien.ac.at> wrote:
>> Andrew Haley <andrew29@littlepinkcloud.invalid> writes:
>>>Anton Ertl <anton@mips.complang.tuwien.ac.at> wrote:
>
>>>But in the example I cited there is no way for the reader to be able
>>>to tell that what they're looking at is not a name in the
>>>dictionary.  I suppose you could argue that the same is true for dot
>>>parsers, but then that's a black mark against dot parsers, IMO.
>>>Having said that, dot parsers aren't being proposed for
>>>standardization and their syntax seems to me to be quite distinctive
>>>and therefore quite benign.
>> 
>> And I expect the same to be true of all successful recognizers, and
>> the existing system-specific recognizers demonstrate this.
>
>But you have already described one recognizer (for TO) for which this
>certainly is not true.

I find a "->" prefix quite distinctive.

Looking at the example from <http://www.forth200x.org/locals.html>:

: foo  {: a b | c d -- :}
   a b + to c
   a b * to d
   cr c .  d .
;

If we use the TO-recognizer instead of TO, it becomes

: foo  {: a b | c d -- :}
   a b + ->c
   a b * ->d
   cr c .  d .
;

Looks pretty obvious and certainly distinctive to me.

Concerning distinctiveness, let's see how often names with that prefix
occur:

In the 85319 lines of .fth files delivered with the Vfxlin Evaluation
version, there are 0 occurences of '->' as a prefix.  Interestingly,
-> (as a separate word) occurs a lot, as a synonym of TO.  So,
certainly for VFX users, ->bla should be quite suggestive.

In the 78671 lines of .f file delivered with SwiftForth, there are 71
occurences of -> as a prefix (find . -name \*.f|xargs grep --
'[[:space:]]->[^[:space:]]'), all in unsupported/fslib/.

In the 94326 lines of .fs files in my gforth directory, there are 28
occurences of -> as a prefix, all of them by Bernd Paysan, who also
chose the syntax ->NAME as TO replacement.

So there is some usage of a -> prefix in ordinary Forth names, and
maybe ->NAME is not the best pattern for a TO recognizer, or maybe the
conflicts are acceptable.  I think that it is still a distinctive
pattern.

An alternative TO recognizer would be to actually recognize TO and
then parse the next name and then work with that.  I.e., TO <name>.

Advantages over ->NAME: Standard syntax; no conflicts with ->NAME
names.

Disadvantages compared to ->NAME: When you do POSTPONE ->NAME, it's
clear that ->NAME is one unit; for POSTPONE TO NAME, it isn't; this is
not a problem for ]] ... TO NAME ... [[, though.  For this reason, I
avoid parsing recognizers when we have a good alternative (i.e., in
most cases).

Advantages over existing implementations of TO: No corner cases with
'/['] (just doesn't work), works as expected for ]] ... TO NAME
... [[.

Disadvantages over existing implementations of TO: If a program
contains a use of POSTPONE TO (non-standard, but possibly existing),
introducing a TO NAME recognizer will probably break it.

In any case, either the ->NAME syntax will catch on, then you will be
unlikely to be confused by it, or it won't, then you will be unlikely
to encounter it.  In the unlikely case that you encounter it but have
already forgotten about it not being the name of a definition, if you
LOCATE it, and LOCATE tells you it does not find it, you will know
that you are dealing with a recognized word; or you are on a friendly
system that actually tells you that this is recognized by the TO
recognizer.

>It wasn't my idea.  And it's an example of
>precisely the problem that I'm anticipating, not a product of my
>overheated imagination.

The claim that a -> prefix is not distinctive is a product of your
imagination.

>> You are proposing to complicate the proposal
>
>Not at all: I suspect that if this proposal were designed well it
>should be possible to accomodate things such as LOCATE well without
>greatly complicating it.  But it's hard to retro-fit such things once
>the proposal is in wide use.

Give examples of how you would change the interface, and before-after
comparisons of a few recognizers.

>> You can hook anything into SwiftForth's NOT-DEFINED and into VFX's n
>> interpreter hooks, so they are not constrained at all, and certainly
>> not in the form of strings that they can recognize.
>
>You can, but they are not widely used, precisely because they are
>internal and system-secific.

As if that has ever kept Forth programmers from using a
system-specific feature.  When Marcel Hendrix gets a standard program
in his fingers, he immediately replaces many words in the code with
iForth-specific equivalents.  Searching for '->' and 'TO' in the VFX
files mentioned above, I find 1198 lines containing '->', more than
the 1057 lines containing TO.

No, the reason why people have not gone overboard with system-specific
recognizers is not that they are system-specific, but that, while
there is a demand for something in that area, as evidenced by the n
hooks in VFX, and repeated discussions on the topic, it is not as
extreme as you imagine.  There will be several general-purpose
recognizers that everybody will be familiar with (maybe including
->NAME, maybe not), and, for specific application areas, specific
recognizers (say, 25°8'13" for dealing with angles); the latter should
be obvious to anyone working in the application area, i.e., hopefully
your maintenance programmer; it would still be cool if the system
provided a LOCATE that says that this is recognized by REC:ANGLE).

>> We know how the feature works out in practice, because the feature is
>> present in all Forth systems.
>
>Actually, no, it is not, as I have explained.  Several times.

I must have missed these explanations.  The only explanations I have
seen are those where you want to make us believe that people don't use
features unless they are standardized.  Which does not combine well
with your other stance that one should establish common practice
before standardization (unless, of course, the goal is never to
standardize anything).

>> And in any case, LOCATE can be implemented to work for recognizers as
>> currently proposed.
>
>No, because of side effects, as I have explained.

The one side effect that exists in practice (changing >IN) is actually
a good idea, and you have not come up with other side effects.

>> Sure.  What side effects do you have in mind?  And does anybody
>> care?
>
>Anything.  I think so.  I'm a careful and conservative engineer whose
>first reaction to any proposal, no matter where it comes from, is
>"What adverse effects might this have?"  You need people like that.

That's fine.  I have examined your concerns, and they don't have
enough weight to justify complicating the interface.  Especially since
you neither give examples of the side effects you fear, nor have you
shown that your interface changes do not complicate the recognizer
definitions.

- anton
-- 
M. Anton Ertl  http://www.complang.tuwien.ac.at/anton/home.html
comp.lang.forth FAQs: http://www.complang.tuwien.ac.at/forth/faq/toc.html
     New standard: http://www.forth200x.org/forth200x.html
   EuroForth 2016: http://www.euroforth.org/ef16/

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

#54462

On Fri, 27 Jan 2017 11:37:06 GMT, anton@mips.complang.tuwien.ac.at
(Anton Ertl) wrote:

>Concerning distinctiveness, let's see how often names with that prefix
>occur:
>
>In the 85319 lines of .fth files delivered with the Vfxlin Evaluation
>version, there are 0 occurences of '->' as a prefix.  Interestingly,
>-> (as a separate word) occurs a lot, as a synonym of TO.  So,
>certainly for VFX users, ->bla should be quite suggestive.

We have a few clients who use -> to indicate structure fields, e.g.
in their worlds
  ->foo 
indicates a field in a structure.

The problems with TO are more likely to be resolved by better
specification of TO and other words around DEFER. There are still 
a number of problems with compilation that should be resolved
before we come to conclusions about recognisers. I am preparing
a paper ...

IMHO the discussion of LOCATE and recognisers is a red herring.
If you use LOCATE on something that is not a word, it should
not be found. In the ClassVfx examples, the dot parser is a
way of "opening" the wordlist(s) of classes. This is system
specific and we have had no requests to make LOCATE handle
the dot notation. WIBNIs (Wouldn't It Be Nice If) are very
low on our priority list.

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]

#54481

Anton Ertl <anton@mips.complang.tuwien.ac.at> wrote:
> Andrew Haley <andrew29@littlepinkcloud.invalid> writes:
>>Anton Ertl <anton@mips.complang.tuwien.ac.at> wrote:
>>> Andrew Haley <andrew29@littlepinkcloud.invalid> writes:
>>>>Anton Ertl <anton@mips.complang.tuwien.ac.at> wrote:
> 
> : foo  {: a b | c d -- :}
>   a b + ->c
>   a b * ->d
>   cr c .  d .
> ;
> 
> Looks pretty obvious and certainly distinctive to me.

It looks confusing and pointless to me.

> An alternative TO recognizer would be to actually recognize TO and
> then parse the next name and then work with that.  I.e., TO <name>.
> 
> Advantages over ->NAME: Standard syntax; no conflicts with ->NAME
> names.
> 
> Disadvantages compared to ->NAME: When you do POSTPONE ->NAME, it's
> clear that ->NAME is one unit; for POSTPONE TO NAME, it isn't

Oh, yuck.  I hadn't realized just how badly a parsing POSTPONE TO
recognizer would work.  Certainly using -> is better than that.

> Concerning distinctiveness, let's see how often names with that prefix
> occur:

What for?  This point is not specific to any particular prefix.

> In any case, either the ->NAME syntax will catch on, then you will be
> unlikely to be confused by it, or it won't, then you will be unlikely
> to encounter it.

This assumption may not hold.

> In the unlikely case that you encounter it but have already
> forgotten about it not being the name of a definition, if you LOCATE
> it, and LOCATE tells you it does not find it, you will know that you
> are dealing with a recognized word; or you are on a friendly system
> that actually tells you that this is recognized by the TO
> recognizer.

Right, so let's take the steps to make such friendly systems happen.

I suspect that all that LOCATE and similar words need is some advice
in the standard to write recognizers that are (mostly) side-effect
free.  They can leave stuff on the stack(s) or parse into a fixed
buffer, but they shouldn't do anything which can't easily be undone.
They shouldn't toggle a variable, for example.

I think the CS principle is that recognizers (the first part, not the
action methods) should be idempotent.  This idempotency criterion can
be satisfied even when a recognizer adjusts >IN and leaves things on
the stack(s) because THROW can be used to undo the effect.  LOCATE can
THROW when a recognizer is not found, which will tidy things up
nicely.

However, there also needs to be more said about the recursive use of
recognizers.  This possibility certainly makes using a fixed-size
buffer problematic.

>>Not at all: I suspect that if this proposal were designed well it
>>should be possible to accommodate things such as LOCATE well without
>>greatly complicating it.  But it's hard to retro-fit such things once
>>the proposal is in wide use.
> 
> Give examples of how you would change the interface, and before-after
> comparisons of a few recognizers.

See above: it might not be necessary.

> No, the reason why people have not gone overboard with
> system-specific recognizers is not that they are system-specific,
> but that, while there is a demand for something in that area, as
> evidenced by the n hooks in VFX, and repeated discussions on the
> topic, it is not as extreme as you imagine.

Surely the purpose of this proposal is to make it standard and more
widely used than at present, is it not?  If not, what is the point?

>>> We know how the feature works out in practice, because the feature is
>>> present in all Forth systems.
>>
>>Actually, no, it is not, as I have explained.  Several times.
> 
> I must have missed these explanations.  The only explanations I have
> seen are those where you want to make us believe that people don't
> use features unless they are standardized.  Which does not combine
> well with your other stance that one should establish common
> practice before standardization (unless, of course, the goal is
> never to standardize anything).

It's a matter of degree, not of absolutes.  You can't say that people
will not use X unless standardized or will not use X if it isn't.
Also, pre-standardization is the right time to experiment.  Once
standardized it's hard to get things changed.  As we know.

>>Anything.  I think so.  I'm a careful and conservative engineer whose
>>first reaction to any proposal, no matter where it comes from, is
>>"What adverse effects might this have?"  You need people like that.
> 
> That's fine.  I have examined your concerns, and they don't have
> enough weight to justify complicating the interface.

Perhaps you have, but I suspect that you have spent far more time
constructing elaborate rebuttals than properly considering the
downsides of the proposal.  There is the issue of side effects, but
there are other possibilities too.  What about recursive calls of
DO-RECOGNIZER, for example?  Possible, or not?  Forbidden, or not?

People advocating proposals should themselves be considering what might
break, but I've seen little evidence of that.

> Especially since you neither give examples of the side effects you
> fear, nor have you shown that your interface changes do not
> complicate the recognizer definitions.

I'm not sure that the interface actually needs to change, maybe just
the proposed wording, in the form of advice to people writing
recognizers.  It's important to consider all of the ways that a
proposal might be used and what the effects might be.

Andrew.

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

#54485

> People advocating proposals should themselves be considering what might
> break, but I've seen little evidence of that.

You want an interactive tool for inspection, right? (see my other posting).
That tool shall tell you, which recognizer is responsible. By doing so
you don't allow any changes in the system (namely some states like >IN
or any stack content). Btw: LOCATE changes at least >IN itself (it
consumes the next word in the input source), so your claim is
not that strong as it seems to be. Lets talk about an example:

LOCATE ->FOO (as an alias for TO FOO)

the trivial LOCATE will tell you "not found". The recognizer
enabled LOCATE has to mimic the interpreter and detects the -> notation 
and that FOO is a value that can work with the -> (TO alias). That is 
what comes out of the RECOGNIZE action: some data (in this case probably
some address of FOO) and an action list (dt:->). If FOO is not
found (or is not a value), the -> recognizer may detect this
and may declare itself not beeing responsible. That's why I
think that's a good idea to get the full task done, including any
conversions or wordlist lookups.

So IMHO the new LOCATE only has to call RECOGNIZE and
work on its results. These results are displayed to the
user and no further state change has to happen. 
Someone with carnal knowledge of  the implementation 
can get more information out of the recognizer iterator 
(deep inside RECOGNIZE) so LOCATE ->FOO may tell

REC:-> detected TO <FOO (address)>

and the stacks (and other stuff as well) are left unchanged (with
the exception of >IN of course) afterwards. That may
even work with nested recognizers (like ->foo.bar.baz).

Matthias

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

#54486

On Saturday, 28 January 2017 12:35:09 UTC, Matthias Trute  wrote:

> So IMHO the new LOCATE only has to call RECOGNIZE and
> work on its results. These results are displayed to the
> user and no further state change has to happen.

I think you're right. A recogniser shouldn't change variables or take anything from a stack (though its interpretation may). Its purpose is simply to leave stuff on some data stack for future use. 

So. LOCATE is used interactively, as is .S When you LOCATE a recognizer you can see not only its definition, but (using an extension of .S) what it has left behind and where it has left it. Presumably you can then clear all the stacks at once.   

 
> Someone with carnal knowledge of  the implementation 
> can get more information out of the recognizer iterator 
> (deep inside RECOGNIZE) so LOCATE ->FOO may tell
> 
> REC:-> detected TO <FOO (address)>
> 
> and the stacks (and other stuff as well) are left unchanged (with
> the exception of >IN of course) afterwards. That may
> even work with nested recognizers (like ->foo.bar.baz).
> 
> Matthias

I'm thinking that if this is going to be a thing, then the natural TO notation would be Ruby-like:
 
   foo.bar.baz.to

Each step uses the dt returned from the stage before to determine what might be recognised next. 

BTW, like Alex, I'm not sure what you mean by "parallel recognizers".

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

#54488

> BTW, like Alex, I'm not sure what you mean by "parallel recognizers".

Thats simple: just another non-standard feature found even in my 
simple amforth: Multitasking. Just think about two tasks that 
ran in parallel and use recognizers. Yes, people do so already 
in amforth with I2C and RS485 networks. Crazy folks.

A recursive recognizer is one that calls itself somehow, the multiple
dot-recognizer in foo.bar.baz may so such a beast, maybe Anton will
give us more information what's behind it.

Matthias

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

#54492

Matthias Trute <matthias.trute@gmail.com> writes:
>A recursive recognizer is one that calls itself somehow, the multiple
>dot-recognizer in foo.bar.baz may so such a beast, maybe Anton will
>give us more information what's behind it.

People often want to have two different structures or objects to have
fields with the same name, e.g., X and Y fields, or NEXT etc.  In
simple cases you can handle this by putting the structure name into
the field name, e.g., LIST-NEXT.

As soon as you have inheritance of fields (e.g., INTLIST is an
extended variant of LIST), this does not work very well; the
programmer could not just say INTLIST-NEXT, but would have to use
LIST-NEXT.  This puts a memory burden on the programmer, and makes the
program less flexible (refactoring the objects would change all the
field names).

There have been various wordlist-based approaches to dealing with
this, but the problem is that search order manipulation in Forth is
not part of the text interpreter, but has to be done explicitly,
maybe resulting in something like

with intlist next endwith

(where "WITH INTLIST" puts the INTLIST wordlist and all its ancestors
on the search order stack, and ENDWITH removes them all).

That would be cumbersome, so nobody does it.  There are various
solutions for it, all unsatisfactory: objects.fs makes field of a
class visible only in methods of that class.  OOF uses state-smart
parsing words to deal with this problem.  Manfred Mahlow introduced
the prelude concept to deal with this problem, but it has not caught
on.

A dot-parser makes this a little less cumbersome.  If you write
INTLIST.NEXT, the dot-parser looks up the NEXT in the search order
given by INTLIST, without affecting the rest of text interpretation.

If you have an INTLIST object X, you can access its next field with

X INTLIST.NEXT

but X.NEXT is more convenient.

Structures can be nested, e.g., a line with start and end points,
and each point having x and y fields.  Then instead of writing

myline.end point.x

one can write myline.end.x.

One might want to extend this to also allow fetching, maybe like
X.NEXT@.NEXT, but that is a slippery slope; if you want to support
array accesses, you have probably gone too far.

Anyway, we don't have a dot-parser recognizer in Gforth yet, but VFX
has a dot-parser recognizer (see the chapter on ClassVfx OOP), pretty
much as described above, but without the @ part.

My guess is that it resolves multiple dots with a loop, not with
recursion, though.

- anton
-- 
M. Anton Ertl  http://www.complang.tuwien.ac.at/anton/home.html
comp.lang.forth FAQs: http://www.complang.tuwien.ac.at/forth/faq/toc.html
     New standard: http://www.forth200x.org/forth200x.html
   EuroForth 2016: http://www.euroforth.org/ef16/

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

#54490

On Saturday, 28 January 2017 16:03:58 UTC+1, JennyB  wrote:
> On Saturday, 28 January 2017 12:35:09 UTC, Matthias Trute  wrote:
> 
> > So IMHO the new LOCATE only has to call RECOGNIZE and
> > work on its results. These results are displayed to the
> > user and no further state change has to happen.
> 
> I think you're right. A recogniser shouldn't change variables or take anything from a stack (though its interpretation may). Its purpose is simply to leave stuff on some data stack for future use. 
> 
> So. LOCATE is used interactively, as is .S When you LOCATE a recognizer you can see not only its definition, but (using an extension of .S) what it has left behind and where it has left it. Presumably you can then clear all the stacks at once.   
> 
>  
> > Someone with carnal knowledge of  the implementation 
> > can get more information out of the recognizer iterator 
> > (deep inside RECOGNIZE) so LOCATE ->FOO may tell
> > 
> > REC:-> detected TO <FOO (address)>
> > 
> > and the stacks (and other stuff as well) are left unchanged (with
> > the exception of >IN of course) afterwards. That may
> > even work with nested recognizers (like ->foo.bar.baz).
> > 
> > Matthias
> 
> I'm thinking that if this is going to be a thing, then the natural TO notation would be Ruby-like:
>  
>    foo.bar.baz.to
> 

Why not use !  foo.bar.baz!  

Then we are just a space away from old forth style
In the same way you can also make @ a recognizer foo.bar.baz@

I am now looking at making each word its own recognizer

Peter

> Each step uses the dt returned from the stage before to determine what might be recognised next. 
> 
> BTW, like Alex, I'm not sure what you mean by "parallel recognizers".

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

#54491

On Saturday, 28 January 2017 16:05:43 UTC, peter....@gmail.com  wrote:
> On Saturday, 28 January 2017 16:03:58 UTC+1, JennyB  wrote:

> > I'm thinking that if this is going to be a thing, then the natural TO notation would be Ruby-like:
> >  
> >    foo.bar.baz.to
> > 
> 
> Why not use !  foo.bar.baz!  
> 
> Then we are just a space away from old forth style

Well, yes, but I think you mean foo.bar.baz.!

baz being some sort of VALUE-like field accessed through foo.bar 

foo.bar.baz would return the current contents of baz, or compile code to return it at runtime but, since there is a continuation, the new value gets stored instead.


> In the same way you can also make @ a recognizer foo.bar.baz@
> 
> I am now looking at making each word its own recognizer
> 
> Peter
> 

I think you might find that trickier and less useful than it might seem. 

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

#54493

In article <82535089-4efa-4853-862a-e6316dfd0fa9@googlegroups.com>,
Matthias Trute  <matthias.trute@gmail.com> wrote:
>> People advocating proposals should themselves be considering what might
>> break, but I've seen little evidence of that.
>
>You want an interactive tool for inspection, right? (see my other posting).
>That tool shall tell you, which recognizer is responsible. By doing so
>you don't allow any changes in the system (namely some states like >IN
>or any stack content). Btw: LOCATE changes at least >IN itself (it
>consumes the next word in the input source), so your claim is
>not that strong as it seems to be. Lets talk about an example:
>
>LOCATE ->FOO (as an alias for TO FOO)
>
>the trivial LOCATE will tell you "not found". The recognizer

Not with the simple denotation "recognizers".
REGRESS are tests. I have verbose on, all tests passed are
logged.

----------------- 8< ---------------------------
WANT REGRESS
WANT VALUE

0 VALUE JAN

REGRESS 1 TO JAN JAN S: 1
REGRESS : q 2 TO JAN ; q JAN S: 2

'TO ALIAS ->    PREFIX

REGRESS 1 ->JAN JAN S: 1
REGRESS : q 2 ->JAN ; q JAN S: 2

\ we gaan naar rome  defect in LOCATE, shows past end of file
\ we gaan naar rome  if file is too large.
\ we gaan naar rome
\ we gaan naar rome
\ we gaan naar rome
\ we gaan naar rome
\ we gaan naar rome
----------------- 8< ---------------------------

  INCLUDE doit.frt
  1 TO JAN JAN S: 1 \ PASSED
  : q 2 TO JAN ; q JAN S: 2 \ PASSED
  1 ->JAN JAN S: 1 \ PASSED
  q : ISN'T UNIQUE
  : q 2 ->JAN ; q JAN S: 2 \ PASSED
   OK

That went well.
Now let's have a look at LOCATE.

  LOCATE ->
  1
  REGRESS : q 2 TO JAN ; q JAN S: 2

  'TO ALIAS ->    PREFIX

  REGRESS 1 ->JAN JAN S: 1
  REGRESS : q 2 ->JAN ; q JAN S: 2


  \ we gaan naar rome
  \ we gaan naar rome
  \ we gaan naar rome
  \ we gaan naar rome

So a recognizer that just uses Forth mechanisms can be located.
How does it fare with ->JAN?
  LOCATE ->JAN
  1
  REGRESS : q 2 TO JAN ; q JAN S: 2

  'TO ALIAS ->    PREFIX

  REGRESS 1 ->JAN JAN S: 1
  REGRESS : q 2 ->JAN ; q JAN S: 2


  \ we gaan naar rome
  \ we gaan naar rome
  \ we gaan naar rome
  \ we gaan naar rome OK

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

#54518

Matthias Trute <matthias.trute@gmail.com> wrote:
>> People advocating proposals should themselves be considering what might
>> break, but I've seen little evidence of that.
> 
> You want an interactive tool for inspection, right? (see my other
> posting).  That tool shall tell you, which recognizer is
> responsible. By doing so you don't allow any changes in the system
> (namely some states like >IN or any stack content). Btw: LOCATE
> changes at least >IN itself (it consumes the next word in the input
> source), so your claim is not that strong as it seems to be.

Huh?

> Lets talk about an example:
> 
> LOCATE ->FOO (as an alias for TO FOO)
> 
> the trivial LOCATE will tell you "not found". The recognizer enabled
> LOCATE has to mimic the interpreter and detects the -> notation and
> that FOO is a value that can work with the -> (TO alias). That is
> what comes out of the RECOGNIZE action: some data (in this case
> probably some address of FOO) and an action list (dt:->). If FOO is
> not found (or is not a value), the -> recognizer may detect this and
> may declare itself not beeing responsible. That's why I think that's
> a good idea to get the full task done, including any conversions or
> wordlist lookups.
> 
> So IMHO the new LOCATE only has to call RECOGNIZE and work on its
> results.

I don't understand any of this.  There is no such word in the proposal
at http://www.forth200x.org/

Andrew.

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

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

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

csiph-web