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

#54522

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:
>>>> Andrew Haley <andrew29@littlepinkcloud.invalid> writes:
>>>>>Anton Ertl <anton@mips.complang.tuwien.ac.at> wrote:
>> Concerning distinctiveness, let's see how often names with that prefix
>> occur:
>
>What for?  This point is not specific to any particular prefix.

A prefix that has not been used at all is much more distinctive than
one that a lot of words start with.

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

For me a big attraction is that we can use recognizers in cases where
people have tended to use STATE-smart immediate parsing words, e.g.

"bla bla" instead of s\" bla bla"
$ff instead of H# ff

So yes, I hope that we will see a number of recognizers, but I expect
that among the general-purpose ones, those that are used by many,
will be known to most Forth programmers, even those that don't use
them.  And for special-purpose recognizers, they will typically use
domain-specific patterns that should be obvious to anybody familiar
with the domain (e.g. the angle example I gave).  Therefore, I don't
expect that program will contain recognized words that look like
definition names to Forth programmers.

Of course, this being Forth, the will be some people who think that
the commonly accepted $ff is wrong and that the only way to go to
write 0ffH, and will have a recognizer for that, but we already have
that problem with definition names, and we live with that (and we do
not necessarily have LOCATE to deal with that; iForth-2.1, which I
have, certainly does not).

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

People define few recognizers using the existing non-standardized
features.  If it's a matter of degree, they will define a few more,
but not a huge number.

I guess there will be some experimenting with the new feature at the
start until we settle down on a small number of commonly accepted
general-purpose recognizers.

>Perhaps you have, but I suspect that you have spent far more time
>constructing elaborate rebuttals than properly considering the
>downsides of the proposal.

Elaborate rebuttals are more your territory.  I have implemented and
described
<http://www.complang.tuwien.ac.at/anton/euroforth/ef16/papers/ertl-recognizers.pdf>
an alternative way to implement recognizers, and compared the two
approaches, including downsides.

>What about recursive calls of
>DO-RECOGNIZER, for example?  Possible, or not?  Forbidden, or not?

Possible.  The problem I see with ->... is that in the ... part we
only want to recognize definitions to which we can apply TO, and we
have no standard way to achieve that (but then, we probably have no
standard way to implement ->NAME, either).  In general I see no
problem with calling DO-RECOGNIZER/RECOGNIZE inside a recognizer.

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

#54526

In article <2017Jan29.175925@mips.complang.tuwien.ac.at>,
Anton Ertl <anton@mips.complang.tuwien.ac.at> wrote:
<SNIP>
>For me a big attraction is that we can use recognizers in cases where
>people have tended to use STATE-smart immediate parsing words, e.g.
>
>"bla bla" instead of s\" bla bla"
>$ff instead of H# ff

What is a recognizer, if not a STATE-smart immediate parsing word
without blank space required after it?

<SNIP>

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

#54578

albert@cherry.spenarnc.xs4all.nl (Albert van der Horst) writes:
>In article <2017Jan29.175925@mips.complang.tuwien.ac.at>,
>Anton Ertl <anton@mips.complang.tuwien.ac.at> wrote:
><SNIP>
>>For me a big attraction is that we can use recognizers in cases where
>>people have tended to use STATE-smart immediate parsing words, e.g.
>>
>>"bla bla" instead of s\" bla bla"
>>$ff instead of H# ff
>
>What is a recognizer, if not a STATE-smart immediate parsing word
>without blank space required after it?

1) It's not STATE-smart
2) It's not immediate
3) It's not parsing (exceptions prove the rule)
4) It's not a word in the way you are thinking of.
5) The pattern may be something other than a prefix, so the stuff
   about "without blank space required after it" does not apply.

You can read more about it in my paper
<http://www.complang.tuwien.ac.at/anton/euroforth/ef16/papers/ertl-recognizers.pdf>,
which outlines the temporary word approach.  In the temporary word
approach, when the string recognizer recognizes, say, "bla", you get a
temporary word equivalent to

: "bla" s" bla" ;

Such a temporary word does not behave like a STATE-smart immediate
parsing word; Consider:

: "bla" s" bla" ;
: foo postpone "bla" ;
: bar [ foo ] ;
bar type

Let's see what happens in SwiftForth:

SwiftForth i386-Linux 3.4.8a 21-Jul-2013 
: "bla" s" bla" ;  ok                                                          
: foo postpone "bla" ;  ok
: bar [ foo ] ;  ok
bar type bla ok

Let's see what happens with the STATE-smart immediate parsing S" in
SwiftForth:

: foo1 postpone s" bla" ;
: foo2 postpone s" ;
: bar2 [ foo2 bla" ] ; .s
bar2 .s type

Here's the program with output:

: foo1 postpone s" bla" ; bla" ?
: foo2 postpone s" ;  ok
: bar2 [ foo2 bla" ] ; .s 
134591021 3 <-Top  ok
bar2 .s type 
134591021 3 <-Top bla ok

FOO1 and FOO2 demonstrate that a parsing word works differently.  BAR2
demonstrates that the STATE-smartness leads to a deviation from the
behaviour you see for the temporary word.  And for me the avoidance of
STATE-smart parsing words is a major advantage of recognizers.

The approach in the RfD does not define a temporary word when
recognizing something, so it is even farther from your description
than the temporary word approach.  Still, the behaviour for the cases
above is as in the temporary word approach:

Gforth 0.7.9_20170112, Copyright (C) 1995-2016 Free Software Foundation, Inc.
Gforth comes with ABSOLUTELY NO WARRANTY; for details type `license'
Type `help' for basic help
: foo postpone "bla" ;  ok
: bar [ foo ] ;  ok
bar type bla ok

Note that there is no definition of "bla" here.  A difference from the
temporary word approach is that you can tick a temporary word, but
not a recognized string in the RfD approach:

' "bla" 
*the terminal*:4: error: Can't tick literal

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

#54568

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:
> 
>>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.
> 
> People define few recognizers using the existing non-standardized
> features.  If it's a matter of degree, they will define a few more,
> but not a huge number.

Well, we live in hope.  If you're right, it's a smaller problem.  It's
still worth striving to get the proposal as good as it can be, even if
the less it is used, the better.

>>What about recursive calls of DO-RECOGNIZER, for example?  Possible,
>>or not?  Forbidden, or not?
> 
> Possible.  The problem I see with ->... is that in the ... part we
> only want to recognize definitions to which we can apply TO, and we
> have no standard way to achieve that (but then, we probably have no
> standard way to implement ->NAME, either).  In general I see no
> problem with calling DO-RECOGNIZER/RECOGNIZE inside a recognizer.

I'm wondering about a recognizer for S-expressions.  I'm think that
static buffers would be problematic for such a recognizer, but I'm not
sure.

Andrew.

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

#55655

Am Fri, 27 Jan 2017 11:37:06 +0000 schrieb Anton Ertl:

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

I'm still trying to figure out what the right convention for a message 
word is. Erlang e.g. uses PID ! message, but ! is already used in 
Forth... Ideas?  The -> recognizer came later, and mentally conflicts.

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

#55674

Am Sonntag, 12. März 2017 02:28:02 UTC+1 schrieb Bernd Paysan:
> Am Fri, 27 Jan 2017 11:37:06 +0000 schrieb Anton Ertl:
> 
> > 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.
> 
> I'm still trying to figure out what the right convention for a message 
> word is. Erlang e.g. uses PID ! message, but ! is already used in 
> Forth... Ideas?  The -> recognizer came later, and mentally conflicts.
> 
> -- 
> 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/

the array symbola -> <- -^ -v represent messaging rather well, mentally.
i would change the recognizer syntax instead.

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

#55678

Bernd Paysan <bernd@net2o.de> writes:
>Am Fri, 27 Jan 2017 11:37:06 +0000 schrieb Anton Ertl:
>
>> 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.
>
>I'm still trying to figure out what the right convention for a message 
>word is.

What is a "message word"?  If you mean an OO method selector, I don't
think we need a naming convention for it.

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

#55833

Am Sun, 12 Mar 2017 10:07:47 +0000 schrieb Anton Ertl:

> Bernd Paysan <bernd@net2o.de> writes:
>>Am Fri, 27 Jan 2017 11:37:06 +0000 schrieb Anton Ertl:
>>
>>> 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.
>>
>>I'm still trying to figure out what the right convention for a message
>>word is.
> 
> What is a "message word"?  If you mean an OO method selector, I don't
> think we need a naming convention for it.

Inter-task messages... The word is invoked in one task, and then executed 
in another task (when the other task runs through its message queue).

I think that would have been pretty clear if you grepped for ': ->', the 
definitions are "event: ->something".

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

#55849

Bernd Paysan <bernd@net2o.de> writes:
>Am Sun, 12 Mar 2017 10:07:47 +0000 schrieb Anton Ertl:
>
>> Bernd Paysan <bernd@net2o.de> writes:
>>>I'm still trying to figure out what the right convention for a message
>>>word is.
>> 
>> What is a "message word"?  If you mean an OO method selector, I don't
>> think we need a naming convention for it.
>
>Inter-task messages... The word is invoked in one task, and then executed 
>in another task (when the other task runs through its message queue).
>
>I think that would have been pretty clear if you grepped for ': ->', the 
>definitions are "event: ->something".

You think wrong.  I did grep for -> definitions, and saw these
definitions, and had no idea what they were about.  "Event" is a
pretty generic word, and this could have been about discrete event
simulation, or about GUI or about a bunch of other things.  It's
interesting that you call the defined words "message words", not
"event words"; MESSAGE: would probably not have made it much clearer,
though.

As for naming conventions, => or >> or --> would be alternatives to ->.

If "something" in "->something" corresponds to a channel, Go uses

<channel> <- <value>

for sending and

<- <channel>

for receiving.  XC uses 

<channel> <: <value>

for sending and

<channel> :> <var>

for receiving.  Occam uses

<channel> ! <value>

for sending and

<channel> ? <var>

for receiving.

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

#55874

Am Thu, 16 Mar 2017 11:59:32 +0000 schrieb Anton Ertl:

> Bernd Paysan <bernd@net2o.de> writes:
>>Am Sun, 12 Mar 2017 10:07:47 +0000 schrieb Anton Ertl:
>>
>>> Bernd Paysan <bernd@net2o.de> writes:
>>>>I'm still trying to figure out what the right convention for a message
>>>>word is.
>>> 
>>> What is a "message word"?  If you mean an OO method selector, I don't
>>> think we need a naming convention for it.
>>
>>Inter-task messages... The word is invoked in one task, and then
>>executed in another task (when the other task runs through its message
>>queue).
>>
>>I think that would have been pretty clear if you grepped for ': ->', the
>>definitions are "event: ->something".
> 
> You think wrong.  I did grep for -> definitions, and saw these
> definitions, and had no idea what they were about.  "Event" is a pretty
> generic word, and this could have been about discrete event simulation,
> or about GUI or about a bunch of other things.

It's in the documentation.  Read the fucking documentation.

> It's interesting that
> you call the defined words "message words", not "event words"; MESSAGE:
> would probably not have made it much clearer, though.

No, you would then have confused it with OOP, as you did when I told you 
that these things send messages.  They are called "messages" even in the 
event-driven programming paradigm.  But the recipient of such a message 
is an event handler, and that's what's defined right after event: 
(somename).

> As for naming conventions, => or >> or --> would be alternatives to ->.

Yes.

> If "something" in "->something" corresponds to a channel, Go uses
> 
> <channel> <- <value>
> 
> for sending and
> 
> <- <channel>
> 
> for receiving.

This was somewhat the inspiration.  It's however not a value.  The sender 
triggers a named event in the receiver task.

JavaScript's "trigger/on" event system is pretty close from the 
conceptual idea:

http://api.jquery.com/trigger/

JavaScript has no particular syntax to be inspired from.

> XC uses
> 
> <channel> <: <value>
> 
> for sending and
> 
> <channel> :> <var>
> 
> for receiving.  Occam uses
> 
> <channel> ! <value>
> 
> for sending and
> 
> <channel> ? <var>
> 
> for receiving.

Occam's symbols are used up.

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

#55691

Bernd Paysan <bernd@net2o.de> wrote:
> Am Fri, 27 Jan 2017 11:37:06 +0000 schrieb Anton Ertl:
> 
>> 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.
> 
> I'm still trying to figure out what the right convention for a
> message word is. Erlang e.g. uses PID ! message, but ! is already
> used in Forth... Ideas?  The -> recognizer came later, and mentally
> conflicts.

Are we really still limited to ASCII?  U+2192 is a right arrow, but
perhaps U+21D2 would be better.  UTF-8 seems to "just work" in Linux
SwiftForth, and it probably just works in other Forths too.  I suppose
the real problem is finding such stuff on a keyboard.  :-)

Andrew.

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

#55697

Andrew Haley <andrew29@littlepinkcloud.invalid> writes:
>Are we really still limited to ASCII?

Yes.  While the xchar wordset provides the infrastructure to deal with
individual characters in other charsets, we currently have no way to
specify that the charset we work with is something other than ASCII.

>UTF-8 seems to "just work" in Linux
>SwiftForth, and it probably just works in other Forths too.

That's the magic of UTF-8.  However, one of the usual problem spots is
still a problem spot in SwiftForth 3.6.3: Command-line editing: Use
the cursor keys to walk back and forward across a non-ASCII character.
SwiftForth avoids the other usual problem spot, indicating the
position of an error within a line, by not indicating the position of
the error.

>I suppose
>the real problem is finding such stuff on a keyboard.  :-)

That, too.

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

#55707

Anton Ertl <anton@mips.complang.tuwien.ac.at> wrote:
> Andrew Haley <andrew29@littlepinkcloud.invalid> writes:
>>Are we really still limited to ASCII?
> 
> Yes.  While the xchar wordset provides the infrastructure to deal with
> individual characters in other charsets, we currently have no way to
> specify that the charset we work with is something other than ASCII.
> 
>>UTF-8 seems to "just work" in Linux SwiftForth, and it probably just
>>works in other Forths too.
> 
> That's the magic of UTF-8.  However, one of the usual problem spots is
> still a problem spot in SwiftForth 3.6.3: Command-line editing: Use
> the cursor keys to walk back and forward across a non-ASCII character.

Sure, but that one's easily fixable.  I'm not suggesting that the
entire Forth universe should standardize on UTF-8 tomorrow, but it
seems to me that we are very close anyway.

Andrew.

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

#54365

In article <Hd2dnfK32o-9AhrFnZ2dnUU7-bHNnZ2d@supernews.com>,
Andrew Haley  <andrew29@littlepinkcloud.invalid> wrote:
>For me, and probably many others, LOCATE is an essential part of the
>Forth toolbox.  It works like this:
>
>locate if
>/home/aph/SwiftForth/src/kernel/struct.f
>   50: : IF ( -- addr)   POSTPONE (IF)  (BEGIN) ;  IMMEDIATE
>
>So, whenever browsing Forth code I use LOCATE to help me find my way
>around.
>
>One of my concerns about recognizers is that they would be an obstacle
>to a maintenance programmer.  For example, I'd see something like this:
>
>  : barf ( --)   >blurge plunge bletch pluke ;
>
>and the first thing I would do is:
>
> locate >blurge >blurge Can't be located
>
>because >BLURGE is a word which was parsed by a recognizer.  At this
>point I'd start to panic: the system must be broken!
>
>So what should LOCATE do with recognizers?  Ideally, it should display
>the recognizer which successfully parsed >BLURGE , but I can't see a
>way to make that work with the current proposal.

Let's see how that is with denotations, the primordial recognizers.

    ~$ lina64 -a
      WANT $-PREFIX H. LOCATE
      # : ISN'T UNIQUE
      $-PREFIX : (WARNING) NOT PRESENT, THOUGH WANTED
       OK
      $1234 H.
      0000,0000,0000,1234 OK
      LOCATE $
      SCR # 121
      0 ( $-PREFIX #-PREFIX  ESC ) \ AvdH A1apr15
      1
      2
      3
      4 \ ONLY DEFINITIONS ... PREVIOUS doesn't work because ONLY
      5 \ terminates the search order.
      6 'ONLY >WID CURRENT !
      7 \ Define $ as a prefix for hex.
      8 : $ BASE @ >R HEX (NUMBER) R> BASE ! POSTPONE SDLITERAL ;
      9 PREFIX IMMEDIATE
      10 \ Define # as a prefix for decimal.
      11 : # BASE @ >R DECIMAL (NUMBER) R> BASE ! POSTPONE SDLITERAL ;
      12 PREFIX IMMEDIATE
      13 DEFINITIONS
      14
      15 $1B CONSTANT ESC                                                OK

Because the $ prefix blends in with the Forth, there is no exceptional
situation here.

(``LOCATE $1234 '' works too )
<SNIP>

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

#54424

Andrew Haley <andrew29@littlepinkcloud.invalid> writes:
>For me, and probably many others, LOCATE is an essential part of the
>Forth toolbox.  It works like this:
>
>locate if 
>/home/aph/SwiftForth/src/kernel/struct.f
>   50: : IF ( -- addr)   POSTPONE (IF)  (BEGIN) ;  IMMEDIATE
>
>So, whenever browsing Forth code I use LOCATE to help me find my way
>around.
>
>One of my concerns about recognizers is that they would be an obstacle
>to a maintenance programmer.  For example, I'd see something like this:
>
>  : barf ( --)   >blurge plunge bletch pluke ;
>
>and the first thing I would do is:
>
> locate >blurge >blurge Can't be located
>
>because >BLURGE is a word which was parsed by a recognizer.  At this
>point I'd start to panic: the system must be broken!

Let's see:

SwiftForth i386-Linux 3.4.4 31-Jul-2012 
locate if 
/usr/local/src/SwiftForth/src/kernel/struct.f ok

Not very helpful, but ok, working with an evaluation version has its
downsides.

: f1+ 1e f+ ;  ok                                                              
locate 1e 1e Can't be located

Panic!  The system must be broken!

Let's try another system:

VFX Forth for Linux IA32 Version: 4.72 [build 0555]
Including /usr/local/VfxLinEval/Lib/x86/Ndp387.fth
: f1+ 1e f+ ;  ok
locate 1e 
Err# -13 ERR: Undefined word.
 -> locate 1e
            ^

Panic!  The system must be broken!

The VFX documentation contains an example which contains the line

    5 to Myline.end.y

I could not include MakeClassVfx.bld successfully to try the example,
but I doubt that "LOCATE Myline.end.y" will show the source code of
the dot-parser extension, or of MYLINE, END, and Y.

Let's try another system:

Gforth 0.7.9_20170112, Copyright (C) 1995-2016 Free Software Foundation, Inc.
Gforth comes with ABSOLUTELY NO WARRANTY; for details type `license'
Type `help' for basic help
: f1+ 1e f+ ;  ok
locate 1e  
float.fs:190:3
...
*  190: : rec:float ( addr u -- r r:float | r:fail )
...

>So what should LOCATE do with recognizers?  Ideally, it should display
>the recognizer which successfully parsed >BLURGE , but I can't see a
>way to make that work with the current proposal.

As you can see above, that way exists.  

>I'd like to be able to call each element in the recognizer stack in
>turn, asking it if it recognizes >BLURGE.  But recognizer's parsing
>methods have a side effect: they also return some parsed data on the
>stack

That can be thrown away by saving the stack depths at the start if
LOCATE, and restoring them afterwards.

>and indeed might have other effects, change >IN, and so on.

If you want to restore >IN, you can do that, but I think it's better
not to restore it:

"abc def" type abc def ok
locate "abc def" 
quotedstring.fs:24:3
...
*   24: : rec:string ( addr u -- addr u' r:string | r:fail )
...

Would it be better to follow that up with a complaint about
unrecognized 'def"'?  I don't think so.

As for "and so on", what do you mean?

>For this reason they can't be called by LOCATE: LOCATE must be
>side-effect free.

Where does it say so?

>It seems to me like the recognizer proposal would be more useful if it
>did not always mix the parsing of a string and the conversion of that
>string.  It would make LOCATE-style Forth exploration possible if a
>recognizer could be asked "Is this yours?"  Perhaps it'd be possible
>to have an undo action: throw away the data on the stack, back up >IN,
>etc.

I have seen this tactic before.  At one point we discussed
EXECUTE-PARSING, and one committee member asked for a generalization
for all kinds of input streams, because one might want to use it with
input from flash etc. (none of which was ever needed, except for a
very few uses of EXECUTE-PARSING-FILE).  I worked out a way to do that
without needing a new word for each input source; of course the result
looked complicated and cumbersome to use (and relatively to
EXECUTE-PARSING, the most frequent usage by far, it was); I did not
like it much, and nobody else was interested.  But most importantly,
EXECUTE-PARSING was off the table.  Mission accomplished!

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

#54425

Anton Ertl <anton@mips.complang.tuwien.ac.at> wrote:
> Andrew Haley <andrew29@littlepinkcloud.invalid> writes:
>>For me, and probably many others, LOCATE is an essential part of the
>>Forth toolbox.  It works like this:
>>
>>locate if
>>/home/aph/SwiftForth/src/kernel/struct.f
>>   50: : IF ( -- addr)   POSTPONE (IF)  (BEGIN) ;  IMMEDIATE
>>
>>So, whenever browsing Forth code I use LOCATE to help me find my way
>>around.
>>
>>One of my concerns about recognizers is that they would be an obstacle
>>to a maintenance programmer.  For example, I'd see something like this:
>>
>>  : barf ( --)   >blurge plunge bletch pluke ;
>>
>>and the first thing I would do is:
>>
>> locate >blurge >blurge Can't be located
>>
>>because >BLURGE is a word which was parsed by a recognizer.  At this
>>point I'd start to panic: the system must be broken!
>
> Let's see:
>
> SwiftForth i386-Linux 3.4.4 31-Jul-2012
> locate if
> /usr/local/src/SwiftForth/src/kernel/struct.f ok
>
> Not very helpful, but ok, working with an evaluation version has its
> downsides.

Works for me.

> : f1+ 1e f+ ;  ok
> locate 1e 1e Can't be located
>
> Panic!  The system must be broken!

Oh, no.  I should have predicted that response.  :-(

Obviously the maintenace programmer is a Forth programmer, and knows
what a number is.

>>and indeed might have other effects, change >IN, and so on.
>
> If you want to restore >IN, you can do that, but I think it's better
> not to restore it:

That's not what I meant.  A recognizer might andvance >IN beyond the
initial parsed word, and indeed the RFC mentions this possibility.
Other side effetcs are possible.  It's not helpful for it to have such
side effects when used with LOCATE.

>>For this reason they can't be called by LOCATE: LOCATE must be
>>side-effect free.
>
> Where does it say so?

 LOCATE <name> ( -- )  Common usage

 If name is the name of a definition compiled from source code,
 display the source code for name. On some systems, the phrase VIEW
 name performs a similar function.

My suggestion is that LOCATE should be extended to recognizers.  It
would make developers who use LOCATE more productive when working on
programs which heavily use recognizers.

>>It seems to me like the recognizer proposal would be more useful if
>>it did not always mix the parsing of a string and the conversion of
>>that string.  It would make LOCATE-style Forth exploration possible
>>if a recognizer could be asked "Is this yours?"  Perhaps it'd be
>>possible to have an undo action: throw away the data on the stack,
>>back up >IN, etc.  >

> I have seen this tactic before.

It's not intended to be a disruptive tactic.  I'm engaging with the
proposal in a positive way, by pointing out how it might be improved.
Of course I can't make you believe that.

Andrew.

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

#54430

Andrew Haley <andrew29@littlepinkcloud.invalid> writes:
>Anton Ertl <anton@mips.complang.tuwien.ac.at> wrote:
>> : f1+ 1e f+ ;  ok
>> locate 1e 1e Can't be located
>>
>> Panic!  The system must be broken!
>
>Oh, no.  I should have predicted that response.  :-(
>
>Obviously the maintenace programmer is a Forth programmer, and knows
>what a number is.

I expect that maintainence programmers will also be familiar with the
recognizers used in the programs they maintain.  E.g., if they come
across "Myline.end.y", they will know that there is a word MYLINE, a
word END, and a word Y, and they can try to LOCATE that (hmm, setting
up the search order to have END and Y visible might be cumbersome;
does ClassVFX have a way to deal with that?)

But having a tool for finding out which recognizer recognizes a word
can indeed be useful (and has been useful) when dealing with wide and
overlapping recognizers (not a practice I recommend, but Bernd Paysan
likes that), especially when a recognizer is too wide and recognizes
something that should be an error.

>>>and indeed might have other effects, change >IN, and so on.
>>
>> If you want to restore >IN, you can do that, but I think it's better
>> not to restore it:
>
>That's not what I meant.  A recognizer might andvance >IN beyond the
>initial parsed word, and indeed the RFC mentions this possibility.

Yes, and I gave an example (the only one known) where that comes into
play.  Here it is again, for more diligent consideration:

|"abc def" type abc def ok
|locate "abc def" 
|quotedstring.fs:24:3
|...
|*   24: : rec:string ( addr u -- addr u' r:string | r:fail )
|...

Now what would happen if >IN would be restored to point right before
'def"'?

>Other side effetcs are possible.

Such as?

>>>For this reason they can't be called by LOCATE: LOCATE must be
>>>side-effect free.
>>
>> Where does it say so?
>
> LOCATE <name> ( -- )  Common usage
>
> If name is the name of a definition compiled from source code,
> display the source code for name. On some systems, the phrase VIEW
> name performs a similar function.

That's not an answer to my question.  But anyway, someone documented
his LOCATE to work for names of definitions compiled from source code,
so a LOCATE that worked for recognized strings would not fit this
description anyway; no need to worry about the recognizer changing
>IN, then.

>> I have seen this tactic before.
>
>It's not intended to be a disruptive tactic.  I'm engaging with the
>proposal in a positive way, by pointing out how it might be improved.

Maybe you are.  That does not mean that the end result is not the
same.

I remember stories from other areas (e.g., LWN covers such stories now
and then) where gatekeepers gave a developer one hoop after another to
jump through, and the end result pleased no one; I don't know in how
many such cases the developer gave up at one point (that probably
happens silently and does not get a story on LWN), but in the typical
story as reported someone eventually decided that all the hoop-jumping
had not improved the work, and accepted a simpler non-hoop-compliant
version.  In a recent story, <https://lwn.net/Articles/711013/>, the
developer had jumped through all the officially required hoops in
advance, and wrote a huge patch to cover all the bases, and what was
eventually accepted was a kind of mininal solution that does not jump
any hoops.

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

#54433

Anton Ertl <anton@mips.complang.tuwien.ac.at> wrote:
> Andrew Haley <andrew29@littlepinkcloud.invalid> writes:
>>Anton Ertl <anton@mips.complang.tuwien.ac.at> wrote:
>>> : f1+ 1e f+ ;  ok
>>> locate 1e 1e Can't be located
>>>
>>> Panic!  The system must be broken!
>>
>>Oh, no.  I should have predicted that response.  :-(
>>
>>Obviously the maintenace programmer is a Forth programmer, and knows
>>what a number is.
> 
> I expect that maintainence programmers will also be familiar with the
> recognizers used in the programs they maintain.

Ah.  That's a huge mistake.  I have many times been called to a site
where a mysterious Forth program is malfunctioning, sometimes in very
difficult circumstances.

> But having a tool for finding out which recognizer recognizes a word
> can indeed be useful (and has been useful) when dealing with wide and
> overlapping recognizers (not a practice I recommend, but Bernd Paysan
> likes that), especially when a recognizer is too wide and recognizes
> something that should be an error.

Right.

>>>>and indeed might have other effects, change >IN, and so on.
>>>
>>> If you want to restore >IN, you can do that, but I think it's better
>>> not to restore it:
>>
>>That's not what I meant.  A recognizer might andvance >IN beyond the
>>initial parsed word, and indeed the RFC mentions this possibility.
> 
> Yes, and I gave an example (the only one known) where that comes into
> play.  Here it is again, for more diligent consideration:
> 
> |"abc def" type abc def ok
> |locate "abc def" 
> |quotedstring.fs:24:3
> |...
> |*   24: : rec:string ( addr u -- addr u' r:string | r:fail )
> |...
> 
> Now what would happen if >IN would be restored to point right before
> 'def"'?

I don't get it.  Why would anybody type 

  locate "abc def" 

if they thought  "abc  was a word?

>>Other side effetcs are possible.
> 
> Such as?

Anything.  I don't think that the proposal restricts what user-defined
recognizers can do, does it?

>>> I have seen this tactic before.
>>
>>It's not intended to be a disruptive tactic.  I'm engaging with the
>>proposal in a positive way, by pointing out how it might be improved.
> 
> Maybe you are.  That does not mean that the end result is not the
> same.

Well, sorry.  I can't help that.  

> I remember stories from other areas (e.g., LWN covers such stories
> now and then) where gatekeepers gave a developer one hoop after
> another to jump through, and the end result pleased no one; I don't
> know in how many such cases the developer gave up at one point (that
> probably happens silently and does not get a story on LWN), but in
> the typical story as reported someone eventually decided that all
> the hoop-jumping had not improved the work, and accepted a simpler
> non-hoop-compliant version.  In a recent story,
> <https://lwn.net/Articles/711013/>, the developer had jumped through
> all the officially required hoops in advance, and wrote a huge patch
> to cover all the bases, and what was eventually accepted was a kind
> of mininal solution that does not jump any hoops.

Sure.  That's how it should happen.  glibc is one of the most critical
projects we have, and it's important to get it right.

I think your description of what happened is wrong, though.  It wasn't
about "official hoops" but serious discussions of functionality, as
your reference shows.

Andrew.

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

#54452

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:
>>>> : f1+ 1e f+ ;  ok
>>>> locate 1e 1e Can't be located
>>>>
>>>> Panic!  The system must be broken!
>>>
>>>Oh, no.  I should have predicted that response.  :-(
>>>
>>>Obviously the maintenace programmer is a Forth programmer, and knows
>>>what a number is.

Actually, the idea of the programmer and of the system's number
recognizer may differ:

SwiftForth i386-Linux 3.4.8a 21-Jul-2013 
1. 2,  ok
locate 2, 2, Can't be located

A common case for beginners is "1.0" and "1.".

In both cases, while looking at the specific misinterpreted word would
unravel the issue, the problem is that it typically hides among lots
of other words, that the user has no idea that misinterpretation is
the problem, and that if he knew, he would have little idea which word
is misinterpreted.  So the actual resolution is typically the use of
.s or ~~ in various places until one has zeroed in on the culprit.

>> I expect that maintainence programmers will also be familiar with the
>> recognizers used in the programs they maintain.
>
>Ah.  That's a huge mistake.  I have many times been called to a site
>where a mysterious Forth program is malfunctioning, sometimes in very
>difficult circumstances.

Then if LOCATE reports an error, you will know that the word is not a
definition (or, on some systems, it might be a beheaded definition),
and you know it's time to look at the recognizers loaded into the
system.  Or you have more comfortable system where LOCATE actually
reports the recognizer that recognizes the word.

>>>That's not what I meant.  A recognizer might andvance >IN beyond the
>>>initial parsed word, and indeed the RFC mentions this possibility.
>> 
>> Yes, and I gave an example (the only one known) where that comes into
>> play.  Here it is again, for more diligent consideration:
>> 
>> |"abc def" type abc def ok
>> |locate "abc def" 
>> |quotedstring.fs:24:3
>> |...
>> |*   24: : rec:string ( addr u -- addr u' r:string | r:fail )
>> |...
>> 
>> Now what would happen if >IN would be restored to point right before
>> 'def"'?
>
>I don't get it.  Why would anybody type 
>
>  locate "abc def" 

Why wouldn't they?  When you see

"abc def" type

it's quite obvious that '"abc def"' belong together.  And if you
belong to those who think that "abc and def" are separate words, well,
let's see:

locate "abc 
quotedstring.fs:24:3
...
*   24: : rec:string ( addr u -- addr u' r:string | r:fail )
...

Works, too.  And if you complain that

locate "abc 1 .

will do something other than you claim you expect: I will not take
this complaint seriously unless you have filed a bug report for the
SwiftForth implementation of WORDS, which not only parses (unlike the
standard WORDS), but also does not show all the words in the wordlist
if it is followed by something in the same line.  Example:

words 123 . -4 Stack underflow

In this reality, however, both LOCATE and WORDS are not followed by
unrelated stuff on the same line, that's why nobody complains about
SwiftForth's WORDS, and that's why parsing by the recognizer during
LOCATE is a good thing.  Either the user does not see that "abc def"
belongs together, and then he will type

LOCATE "abc

and will get the correct answer, or they see that "abc def" belongs
together, and then he will type

locate "abc def"

and will get the correct answer.  The case you worry about so much,
e.g.,

locate "abc 123 .

does not happen in practice, just like

words 123 .

does not happen in practice.

>>>Other side effetcs are possible.
>> 
>> Such as?
>
>Anything.  I don't think that the proposal restricts what user-defined
>recognizers can do, does it?

No, this is Forth, the programmer is responsible.  But apparently not
even you can think of a scenario where this would be a problem.  And
there is a reason for that: The use of recognizers in text
interpreters is in sequences like

recognize r>interpret execute
recognize r>compile execute
recognize r>postpone execute

so any wanted side effect can be and are effected through the EXECUTE
in this sequence.

>>>It's not intended to be a disruptive tactic.  I'm engaging with the
>>>proposal in a positive way, by pointing out how it might be improved.
>> 
>> Maybe you are.  That does not mean that the end result is not the
>> same.
>
>Well, sorry.  I can't help that.  

Sure you can.  You can examine the supposed problems you raise and
reality-check them.  Then you, like me, would have found that they are
pure fantasy.  Next, ask yourself whether it is a good idea to make a
fuss over fantasy problems.  Then you can examine the proposal further
and maybe find some real problems or real improvements.

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

#54458

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:
>>> I expect that maintainence programmers will also be familiar with the
>>> recognizers used in the programs they maintain.
>>
>>Ah.  That's a huge mistake.  I have many times been called to a site
>>where a mysterious Forth program is malfunctioning, sometimes in very
>>difficult circumstances.
> 
> Then if LOCATE reports an error, you will know that the word is not a
> definition (or, on some systems, it might be a beheaded definition),
> and you know it's time to look at the recognizers loaded into the
> system.  Or you have more comfortable system where LOCATE actually
> reports the recognizer that recognizes the word.

Yes.  I'm looking at the latter.

>>I don't get it.  Why would anybody type 
>>
>>  locate "abc def" 
> 
> Why wouldn't they?  When you see
> 
> "abc def" type
> 
> it's quite obvious that '"abc def"' belong together.

LOCATE parses a word -- by definition separated by spaces -- from the
input stream.  I am not convinced there would be any benefit in
changing that for recognizers.

> locate "abc 1 .
> 
> will do something other than you claim you expect: I will not take
> this complaint seriously unless you have filed a bug report for the
> SwiftForth implementation of WORDS

OK, so you wouldn't take the complaint seriously.  But it's a bug in
WORDS, certainly.

>>>>Other side effetcs are possible.
>>> 
>>> Such as?
>>
>>Anything.  I don't think that the proposal restricts what user-defined
>>recognizers can do, does it?
> 
> No, this is Forth, the programmer is responsible.  But apparently not
> even you can think of a scenario where this would be a problem.

Of course I can, but that's not the point.  For example, if ALLOCATE
were used to hold a scanned string later to be consumed (and FREEd) by
one of the methods, a recognizer would leak memory when used by
LOCATE.  But the set of potential problems isn't limited by my
imagination!

It might well be that all the proposal needs is some suitable language
about how recognizers might be invoked, and some advice about how to
write them in a way that would not cause any problems.  For example, a
recognizer that scanned strings could use a single buffer, perhaps
enlarging it if needs be.

But if you do that, what about the recursive use of recognizers?  Is
it legitimate for a recognizer to call DO-RECOGNIZER?

>>>>It's not intended to be a disruptive tactic.  I'm engaging with the
>>>>proposal in a positive way, by pointing out how it might be improved.
>>> 
>>> Maybe you are.  That does not mean that the end result is not the
>>> same.
>>
>>Well, sorry.  I can't help that.  
> 
> Sure you can.  You can examine the supposed problems you raise and
> reality-check them.  Then you, like me, would have found that they
> are pure fantasy.  Next, ask yourself whether it is a good idea to
> make a fuss over fantasy problems.  Then you can examine the
> proposal further and maybe find some real problems or real
> improvements.

Dealing with proposals and counter-proposals is similar to a debugging
process.  Some programmers don't write really tough test cases for
their programs, and of course, often the world later bites them in the
arse.  A better technique, which I practice as often as I remember
(but probably not as much as I should) is to write the most difficult
stress test I can think of, in the hope that it'll shake out bugs.  Of
course it doesn't always work, but you'd be a fool not to.

I've often wondered why everybody doesn't do this.  My guess is that
people are so in love with their creations that they don't want to see
the flaws.

Andrew.

[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