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

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

Extending the interpreter?

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

Contents

  Extending the interpreter? lehs <skydda.barnen@gmail.com> - 2016-02-08 09:06 -0800
    Re: Extending the interpreter? anton@mips.complang.tuwien.ac.at (Anton Ertl) - 2016-02-08 17:28 +0000
      Re: Extending the interpreter? lehs <skydda.barnen@gmail.com> - 2016-02-08 10:43 -0800
        Re: Extending the interpreter? anton@mips.complang.tuwien.ac.at (Anton Ertl) - 2016-02-09 06:46 +0000
          Re: Extending the interpreter? lehs <skydda.barnen@gmail.com> - 2016-02-09 00:22 -0800
            Re: Extending the interpreter? anton@mips.complang.tuwien.ac.at (Anton Ertl) - 2016-02-09 08:34 +0000
            Re: Extending the interpreter? Albert van der Horst <albert@spenarnc.xs4all.nl> - 2016-02-09 11:54 +0000
              Re: Extending the interpreter? lehs <skydda.barnen@gmail.com> - 2016-02-09 07:53 -0800
              Re: Extending the interpreter? lehs <skydda.barnen@gmail.com> - 2016-02-09 10:46 -0800
    Re: Extending the interpreter? Chris Curl <ccurl609@gmail.com> - 2016-02-09 05:18 -0800
      Re: Extending the interpreter? Chris Curl <ccurl609@gmail.com> - 2016-02-09 05:23 -0800
        Re: Extending the interpreter? Doug Hoffman <glidedog@gmail.com> - 2016-02-09 10:22 -0500
        Re: Extending the interpreter? lehs <skydda.barnen@gmail.com> - 2016-02-09 08:00 -0800
        Re: Extending the interpreter? hughaguilar96@gmail.com - 2016-02-09 12:59 -0800
          Re: Extending the interpreter? lehs <skydda.barnen@gmail.com> - 2016-02-09 13:21 -0800
            Re: Extending the interpreter? hughaguilar96@gmail.com - 2016-02-09 14:52 -0800
              Re: Extending the interpreter? hughaguilar96@gmail.com - 2016-02-09 14:57 -0800
      Re: Extending the interpreter? lehs <skydda.barnen@gmail.com> - 2016-02-09 07:55 -0800
    Re: Extending the interpreter? minforth@arcor.de - 2016-02-09 06:42 -0800
    Re: Extending the interpreter? lehs <skydda.barnen@gmail.com> - 2016-02-13 14:55 -0800
      Re: Extending the interpreter? lehs <skydda.barnen@gmail.com> - 2016-02-13 15:05 -0800
        Re: Extending the interpreter? anton@mips.complang.tuwien.ac.at (Anton Ertl) - 2016-02-14 15:18 +0000
          Re: Extending the interpreter? Albert van der Horst <albert@spenarnc.xs4all.nl> - 2016-02-14 18:03 +0000
            Re: Extending the interpreter? lehs <skydda.barnen@gmail.com> - 2016-02-14 11:24 -0800
          Re: Extending the interpreter? lehs <skydda.barnen@gmail.com> - 2016-02-14 11:32 -0800
    Re: Extending the interpreter? lehs <skydda.barnen@gmail.com> - 2016-02-14 01:39 -0800
    Re: Extending the interpreter? humptydumpty <ouatubi@gmail.com> - 2016-02-14 10:20 -0800

Page 1 of 2  [1] 2  Next page →

#45369 — Extending the interpreter?

I would like the possibility of "extending the interpreter", letting it recognize new data structures. Could this be done?

[toc] | [next] | [standalone]

#45371

lehs <skydda.barnen@gmail.com> writes:
>I would like the possibility of "extending the interpreter", letting it recognize new data structures. Could this be done?

Not sure if that is what you have in mind, but there has been a
discussion on recognizers for some time.  Recognizers are a
generalization of what the text interpreter does for "words": Instead
of just recognizing strings as names from the search order or as
numbers, they can also recgnize other things.  E.g., you could have a
recognizer for strings ("bla"), or for date specifications
(2016-02-08).  Some expect recognizers to be standardized in the
not-too-distant future.

- 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 2015: http://www.rigwit.co.uk/EuroForth2015/

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

#45374

Den måndag 8 februari 2016 kl. 18:38:34 UTC+1 skrev Anton Ertl:
> lehs <skydda.barnen@gmail.com> writes:
> >I would like the possibility of "extending the interpreter", letting it recognize new data structures. Could this be done?
> 
> Not sure if that is what you have in mind, but there has been a
> discussion on recognizers for some time.  Recognizers are a
> generalization of what the text interpreter does for "words": Instead
> of just recognizing strings as names from the search order or as
> numbers, they can also recgnize other things.  E.g., you could have a
> recognizer for strings ("bla"), or for date specifications
> (2016-02-08).  Some expect recognizers to be standardized in the
> not-too-distant future.
> 
> - 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 2015: http://www.rigwit.co.uk/EuroForth2015/

Could such a recognizer be set to recognize i.e. 

{1,2,{3,4},5} and
123+27i

as userdefined strucured data?

http://forthmath.blogspot.se

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

#45382

lehs <skydda.barnen@gmail.com> writes:
>Could such a recognizer be set to recognize i.e.=20
>
>{1,2,{3,4},5} and
>123+27i
>
>as userdefined strucured data?

Yes.  However, you typically also need some way to build structures
where not all components are literals.  If you have that, do you still
need the literal-only recognizer?  Of course, you might also consider
supporting, say, {a,{1,b},2}, where a and b are locals, and that would
be possible, too, but where do you stop?  I guess we will see a period
of overuse while people explore that feature (and, of course, other
people claiming that recognizers are devil's work), until we get a
good feel for where it is appropriate and where not.

- 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 2015: http://www.rigwit.co.uk/EuroForth2015/

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

#45383

Den tisdag 9 februari 2016 kl. 07:53:56 UTC+1 skrev Anton Ertl:
> lehs <skydda.barnen@gmail.com> writes:
> >Could such a recognizer be set to recognize i.e.=20
> >
> >{1,2,{3,4},5} and
> >123+27i
> >
> >as userdefined strucured data?
> 
> Yes.  However, you typically also need some way to build structures
> where not all components are literals.  If you have that, do you still
> need the literal-only recognizer?  Of course, you might also consider
> supporting, say, {a,{1,b},2}, where a and b are locals, and that would
> be possible, too, but where do you stop?  I guess we will see a period
> of overuse while people explore that feature (and, of course, other
> people claiming that recognizers are devil's work), until we get a
> good feel for where it is appropriate and where not.
> 
> - 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 2015: http://www.rigwit.co.uk/EuroForth2015/

As it is now, the interpreter can recognize integers, double integers and floating point numbers, and that is all except from the wordlist. It wouldn't be a bad thing if the user could extend the number of recognizable data types written for input of data. 

Of course, the user must define the pattern as well as the words handling the data recognized by the pattern. And I would stop with certain patterns of numbers and a set of signs (i.e. "()[]{}./-+iE").

It couldn't be too difficult to design an efficient extendable interpreter. I would even consider to make a patch if I just know where the interpreter was hidden. :)

http://forthmath.blogspot.se

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

#45384

lehs <skydda.barnen@gmail.com> writes:
>As it is now, the interpreter can recognize integers, double integers and f=
>loating point numbers, and that is all except from the wordlist. It wouldn'=
>t be a bad thing if the user could extend the number of recognizable data t=
>ypes written for input of data.=20

Yes, that's the idea.

>Of course, the user must define the pattern as well as the words handling t=
>he data recognized by the pattern.

Yes.

- 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 2015: http://www.rigwit.co.uk/EuroForth2015/

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

#45386

lehs <skydda.barnen@gmail.com> writes:

>Den tisdag 9 februari 2016 kl. 07:53:56 UTC+1 skrev Anton Ertl:
>> lehs <skydda.barnen@gmail.com> writes:
>> >Could such a recognizer be set to recognize i.e.=3D20
>> >
>> >{1,2,{3,4},5} and
>> >123+27i
>> >
>> >as userdefined strucured data?
>>=20
>> Yes.  However, you typically also need some way to build structures
>> where not all components are literals.  If you have that, do you still
>> need the literal-only recognizer?  Of course, you might also consider
>> supporting, say, {a,{1,b},2}, where a and b are locals, and that would
>> be possible, too, but where do you stop?  I guess we will see a period
>> of overuse while people explore that feature (and, of course, other
>> people claiming that recognizers are devil's work), until we get a
>> good feel for where it is appropriate and where not.
>>=20
>> - anton
>> --=20
>> 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 2015: http://www.rigwit.co.uk/EuroForth2015/

>As it is now, the interpreter can recognize integers, double integers and f=
>loating point numbers, and that is all except from the wordlist. It wouldn'=
>t be a bad thing if the user could extend the number of recognizable data t=
>ypes written for input of data.=20

>Of course, the user must define the pattern as well as the words handling t=
>he data recognized by the pattern. And I would stop with certain patterns o=
>f numbers and a set of signs (i.e. "()[]{}./-+iE").

>It couldn't be too difficult to design an efficient extendable interpreter.=
> I would even consider to make a patch if I just know where the interpreter=
> was hidden. :)

>http://forthmath.blogspot.se

My basic idea with recognizers has always been
1. it must be a prefix:
    only the first part of a word determines what kind recognizer is
    used:
    a decimal digit, or one of : & $ 0x "
2. The result must be a compile time constant.
  STATE determines whether it is compiled or put on the stack.

If it starts with a digit, it may discriminate between sort of numbers
(single or double precision).

Long ago I demonstrated that this can be made available by adding
two lines to a Forth.

What is easy to parse for a computer is easy to parse for a human.
Expressions with three slots like (in c)
  .. ? ... : ...
are cursed for unreadibility. (Though I think this ?: is not --yet-- over
the top.)
If a programmer can add multiple slot expressions at a whim you
end up with a very unreadable language. I'm good with r.e. but
apparently few people are.

I'm not against but e.g. an expression for complex expressions can be
done with an operator not with a tangle containing i.
Algol 68
<complex> := <real> <bold>i</bold> <real>

I've now 15 years experience with implementing numbers via
prefixes. I've explored other possibilities for strings and
environment variables. I've not experienced a need for making
things more complicated.

Yes of course. One could make a recognizer for 1235H Intel suffix
strings, while there is $ that is more Forthish and trivial to
implemented. We need the power to recognize hex numbers, not
the power to emulate not-well-thought-out expressions of other
languages.

Groetjes Albert
-- 
Albert van der Horst, UTRECHT,THE NETHERLANDS
Economic growth -- being exponential -- ultimately falters.
albert@spe&ar&c.xs4all.nl &=n http://home.hccnet.nl/a.w.m.van.der.horst

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

#45400

Den tisdag 9 februari 2016 kl. 12:54:30 UTC+1 skrev Albert van der Horst:
> lehs <skydda.barnen@gmail.com> writes:
> 
> >Den tisdag 9 februari 2016 kl. 07:53:56 UTC+1 skrev Anton Ertl:
> >> lehs <skydda.barnen@gmail.com> writes:
> >> >Could such a recognizer be set to recognize i.e.=3D20
> >> >
> >> >{1,2,{3,4},5} and
> >> >123+27i
> >> >
> >> >as userdefined strucured data?
> >>=20
> >> Yes.  However, you typically also need some way to build structures
> >> where not all components are literals.  If you have that, do you still
> >> need the literal-only recognizer?  Of course, you might also consider
> >> supporting, say, {a,{1,b},2}, where a and b are locals, and that would
> >> be possible, too, but where do you stop?  I guess we will see a period
> >> of overuse while people explore that feature (and, of course, other
> >> people claiming that recognizers are devil's work), until we get a
> >> good feel for where it is appropriate and where not.
> >>=20
> >> - anton
> >> --=20
> >> 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 2015: http://www.rigwit.co.uk/EuroForth2015/
> 
> >As it is now, the interpreter can recognize integers, double integers and f=
> >loating point numbers, and that is all except from the wordlist. It wouldn'=
> >t be a bad thing if the user could extend the number of recognizable data t=
> >ypes written for input of data.=20
> 
> >Of course, the user must define the pattern as well as the words handling t=
> >he data recognized by the pattern. And I would stop with certain patterns o=
> >f numbers and a set of signs (i.e. "()[]{}./-+iE").
> 
> >It couldn't be too difficult to design an efficient extendable interpreter.=
> > I would even consider to make a patch if I just know where the interpreter=
> > was hidden. :)
> 
> >http://forthmath.blogspot.se
> 
> My basic idea with recognizers has always been
> 1. it must be a prefix:
>     only the first part of a word determines what kind recognizer is
>     used:
>     a decimal digit, or one of : & $ 0x "
> 2. The result must be a compile time constant.
>   STATE determines whether it is compiled or put on the stack.
> 
> If it starts with a digit, it may discriminate between sort of numbers
> (single or double precision).
> 
> Long ago I demonstrated that this can be made available by adding
> two lines to a Forth.
> 
> What is easy to parse for a computer is easy to parse for a human.
> Expressions with three slots like (in c)
>   .. ? ... : ...
> are cursed for unreadibility. (Though I think this ?: is not --yet-- over
> the top.)
> If a programmer can add multiple slot expressions at a whim you
> end up with a very unreadable language. I'm good with r.e. but
> apparently few people are.
> 
> I'm not against but e.g. an expression for complex expressions can be
> done with an operator not with a tangle containing i.
> Algol 68
> <complex> := <real> <bold>i</bold> <real>
> 
> I've now 15 years experience with implementing numbers via
> prefixes. I've explored other possibilities for strings and
> environment variables. I've not experienced a need for making
> things more complicated.
> 
> Yes of course. One could make a recognizer for 1235H Intel suffix
> strings, while there is $ that is more Forthish and trivial to
> implemented. We need the power to recognize hex numbers, not
> the power to emulate not-well-thought-out expressions of other
> languages.
> 
> Groetjes Albert
> -- 
> Albert van der Horst, UTRECHT,THE NETHERLANDS
> Economic growth -- being exponential -- ultimately falters.
> albert@spe&ar&c.xs4all.nl &=n http://home.hccnet.nl/a.w.m.van.der.horst

Prefixes would be fast but a somewhat more freely method could be made almost as fast, I think. Writing

"Hello world!" 

is perfect with prefix and would hopefully put the string on a string stack. But I think that an easy pattern recognization 

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

#45404

Extending the interpreter need:

1. the pattern for recognizing the input data
2. the word that compute the numerical representation and store it someheow
3. the word that reset stacks and variables on error
4. the words that handle the data

In my set environment ZET I have to write

{ 1 2 3 } { 0 1 } cartprod zet. {(3,1),(3,0),(2,1),(2,0),(1,1),(1,0)} ok

instead of

{1,2,3} {0,1} cartprod zet. {(3,1),(3,0),(2,1),(2,0),(1,1),(1,0)} ok

and I have to reserve { and } for set inputs. It's okay, but not perfect. Here the pattern would be {*} or just {. In my implementation the words does what the interpreter should do, put "bundles" on a stack called zst:

1 2 3 -6 0 1 -4 <cartprod zet.> 3 1 -5 3 0 -5 2 1 -5 2 0 -5 1 1 -5 1 0 -5 -36

and check for duplicate elements in all levels. On error some stacks (xst, yst, zst) and some variables must be reset. Can error handling be extended in ANS Forth today?

The words that handles sets are words like: set=, member, subset, union, intersection, diff, powerset, cartprod etc.

With such an interpreter Forth would be too good: I might get so excited that I would be paralyzed...

http://forthmath.blogspot.se

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

#45387

On Monday, February 8, 2016 at 12:06:37 PM UTC-5, lehs wrote:
> I would like the possibility of "extending the interpreter", 
> letting it recognize new data structures. Could this be done?

I'm having a hard time understanding your question.

Is there anything keeping you from being able to completely re-write
the interpreter if you want to behave however you want it to behave?

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

#45388

On Tuesday, February 9, 2016 at 8:18:49 AM UTC-5, Chris Curl wrote:
> On Monday, February 8, 2016 at 12:06:37 PM UTC-5, lehs wrote:
> > I would like the possibility of "extending the interpreter", 
> > letting it recognize new data structures. Could this be done?
> 
> I'm having a hard time understanding your question.
> 
> Is there anything keeping you from being able to completely re-write
> the interpreter if you want to behave however you want it to behave?

So if you want an interpreter that does more than the current one does,
why not write your own? Then you have complete control over what it
does and how it does it.

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

#45399

On 2/9/16 8:23 AM, Chris Curl wrote:
> On Tuesday, February 9, 2016 at 8:18:49 AM UTC-5, Chris Curl wrote:
>> On Monday, February 8, 2016 at 12:06:37 PM UTC-5, lehs wrote:
>>> I would like the possibility of "extending the interpreter",
>>> letting it recognize new data structures. Could this be done?
>>
>> I'm having a hard time understanding your question.
>>
>> Is there anything keeping you from being able to completely re-write
>> the interpreter if you want to behave however you want it to behave?
>
> So if you want an interpreter that does more than the current one does,
> why not write your own? Then you have complete control over what it
> does and how it does it.
>

The idea is to be able to portably move a recognizer from one Forth to
another. The hook(s) for doing so will be the same. Much simpler than
digging into each Forth's interpreter even if that were allowed.

-Doug

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

#45402

Den tisdag 9 februari 2016 kl. 14:23:18 UTC+1 skrev Chris Curl:
> On Tuesday, February 9, 2016 at 8:18:49 AM UTC-5, Chris Curl wrote:
> > On Monday, February 8, 2016 at 12:06:37 PM UTC-5, lehs wrote:
> > > I would like the possibility of "extending the interpreter", 
> > > letting it recognize new data structures. Could this be done?
> > 
> > I'm having a hard time understanding your question.
> > 
> > Is there anything keeping you from being able to completely re-write
> > the interpreter if you want to behave however you want it to behave?
> 
> So if you want an interpreter that does more than the current one does,
> why not write your own? Then you have complete control over what it
> does and how it does it.

Ignorance? But I would love to have my own interpreter.

Also, the idea of an extendable interpreter is interesting as such. 

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

#45413

On Tuesday, February 9, 2016 at 6:23:18 AM UTC-7, Chris Curl wrote:
> So if you want an interpreter that does more than the current one does,
> why not write your own? Then you have complete control over what it
> does and how it does it.

ANS-Forth was purposely sabotaged to prevent the users from writing their own outer-interpreter --- this was done for the purpose of preventing the users from writing cross-compilers (the compiler vendors make their money primarily from cross-compilers and they want a monopoly; they want to prevent people such as myself from writing cross-compilers such as MFX which I wrote in UR/Forth prior to the introduction of ANS-Forth).

Section 4.1.2 of the ANS-Forth document has the ominous heading: "Ambiguous Conditions." One of the ambiguous conditions is: "attempting to obtain the execution token, (e.g., with 6.1.0070 ', 6.1.1550 FIND, etc.) of a definition with undefined interpretation semantics." There are over 50 words in the ANS-Standard that have undefined interpretation semantics, so tick and FIND will fail on all of them --- this was done to make writing an outer-interpreter in ANS-Forth impossible --- but my disambiguifiers work around this sabotage so that tick and FIND work they way that they did in Forth-83 on all ANS-Forth implementations.

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

#45414

Den tisdag 9 februari 2016 kl. 21:59:46 UTC+1 skrev hughag...@gmail.com:
> On Tuesday, February 9, 2016 at 6:23:18 AM UTC-7, Chris Curl wrote:
> > So if you want an interpreter that does more than the current one does,
> > why not write your own? Then you have complete control over what it
> > does and how it does it.
> 
> ANS-Forth was purposely sabotaged to prevent the users from writing their own outer-interpreter --- this was done for the purpose of preventing the users from writing cross-compilers (the compiler vendors make their money primarily from cross-compilers and they want a monopoly; they want to prevent people such as myself from writing cross-compilers such as MFX which I wrote in UR/Forth prior to the introduction of ANS-Forth).
> 
> Section 4.1.2 of the ANS-Forth document has the ominous heading: "Ambiguous Conditions." One of the ambiguous conditions is: "attempting to obtain the execution token, (e.g., with 6.1.0070 ', 6.1.1550 FIND, etc.) of a definition with undefined interpretation semantics." There are over 50 words in the ANS-Standard that have undefined interpretation semantics, so tick and FIND will fail on all of them --- this was done to make writing an outer-interpreter in ANS-Forth impossible --- but my disambiguifiers work around this sabotage so that tick and FIND work they way that they did in Forth-83 on all ANS-Forth implementations.

Is it possible to read about those disambiguifiers?

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

#45417

On Tuesday, February 9, 2016 at 2:21:16 PM UTC-7, lehs wrote:
> Den tisdag 9 februari 2016 kl. 21:59:46 UTC+1 skrev hughag...@gmail.com:
> > On Tuesday, February 9, 2016 at 6:23:18 AM UTC-7, Chris Curl wrote:
> > > So if you want an interpreter that does more than the current one does,
> > > why not write your own? Then you have complete control over what it
> > > does and how it does it.
> > 
> > ANS-Forth was purposely sabotaged to prevent the users from writing their own outer-interpreter --- this was done for the purpose of preventing the users from writing cross-compilers (the compiler vendors make their money primarily from cross-compilers and they want a monopoly; they want to prevent people such as myself from writing cross-compilers such as MFX which I wrote in UR/Forth prior to the introduction of ANS-Forth).
> > 
> > Section 4.1.2 of the ANS-Forth document has the ominous heading: "Ambiguous Conditions." One of the ambiguous conditions is: "attempting to obtain the execution token, (e.g., with 6.1.0070 ', 6.1.1550 FIND, etc.) of a definition with undefined interpretation semantics." There are over 50 words in the ANS-Standard that have undefined interpretation semantics, so tick and FIND will fail on all of them --- this was done to make writing an outer-interpreter in ANS-Forth impossible --- but my disambiguifiers work around this sabotage so that tick and FIND work they way that they did in Forth-83 on all ANS-Forth implementations.
> 
> Is it possible to read about those disambiguifiers?

They were discussed here:
https://groups.google.com/forum/#!searchin/comp.lang.forth/bug$20vfx/comp.lang.forth/oXXQAGDKP7w/iMLU1ExXOAIJ

Tick and FIND were sabotaged with section 4.1.2. that make their behavior ambiguous (gForth crashes when tick is used on IF etc. and FIND returns different xt values depending upon what STATE is when FIND is executed, which is horribly confusing). Also, whether a word is immediate or non-immediate is implementation-defined (another term that essentially means "ambiguous"), so words such as IF that were always immediate can now be non-immediate (VFX and some others make these non-immediate and special-case them in COMPILE, so they execute like immediate words rather than just get compiled by COMPILE, which is typical for non-immediate words).

The solution is simple though! Tick and FIND are hopelessly sabotaged, but POSTPONE was not sabotaged. So, this is a disambiguifier:

: if  
    state @ 0= abort" *** no interpretation semantics for: IF ***"  postpone if  ;  
immediate 

We get these advantages:

1.) Previously tick and FIND would have ambiguous behavior when trying to look up IF but now they always provide an xt value that works (and it is always the same xt value, despite Anton saying that it should sometimes be one xt value and sometimes another xt value depending upon STATE). 

2.) Previously IF could be immediate in some ANS-Forth systems and non-immediate in other ANS-Forth systems, but now IF is always immediate. 

3.) Previously the behavior of IF in interpretation-mode (when STATE is FALSE) was "undefined" (yet another word that essentially means "ambiguous") so what actually happened would vary from one ANS-Forth system to another, but now IF will always abort with a helpful error-message when used in interpretation-mode (as it should, as this is obviously a screw-up on the programmer's part).

So, with the above disambiguifier, we dodge all of the weird ambiguity of ANS-Forth and we are back on the solid ground of Forth-83 --- Elizabeth Rather defeated!

There are over 50 words in ANS-Forth that need to be disambiguified. Just look for the phrase "Interpretation semantics for this word are undefined" in the ANS-Forth document and write a disambiguifier for all of them. There are some caveats:

1.) SwiftForth doesn't have [COMPILE] (so SwiftForth isn't really ANS-Forth compliant), so if you try to disambiguify [COMPILE] this will cause SwiftForth to abort and so your code won't be portable. Nobody really uses [COMPILE] (I have no idea why it is in the ANS-Forth document as it is obsoleted by POSTPONE) so you might was well just not bother with this one.

2.) TO theoretically can't be disambiguified because section 6.2.2295 of the ANS-Forth document says: "An ambiguous condition exists if either POSTPONE or [COMPILE] is applied to TO." In VFX however, TO can be disambiguified, so if you need this one to work you have to use VFX rather than some other ANS-Forth system (but you do have to disambiguify it yourself, as VFX doesn't disambiguify anything).

I have written all of these disambiguifiers. The code, as well as a text file documenting the disambiguifiers, will be in my next novice package release. I'm holding off on that right now because the www.forth.org website is down (what you see is the August version, but the web-master David Jaffe is not able to modify it and the only person who knows how to modify it is recovering from a stroke and may never get back to work on the website). So, I'm going to have to post my novice package and STUNDURD.TXT etc. somewhere else on the internet --- in the meantime, if you want this stuff, contact me by email and I will email it to you.

I have been aware of how to disambiguify for almost a whole year now. Weirdly enough, Anton Ertl actually told me how to disambiguify ANS-Forth way back in 2009 in this thread:
https://groups.google.com/forum/#!searchin/comp.lang.forth/LC53/comp.lang.forth/wP5nw1ClzsM/E-TV9v2y9RoJ
I didn't at the time follow through with this and write all of the disambiguifiers, and it took me until last year to realize that this was necessary in order to write an outer-interpreter (the issue didn't come up until last year when I had a job writing a cross-compiler and ran into the sabotage problem and had to figure out a work-around). So, disambiguification has been well-known for many years now --- and yet people such as Stephen Pelc and Anton Ertl continue to refuse to just provide the disambiguifiers in their compilers (VFX and gForth respectively) --- the reason is that they are obliged to support Elizabeth Rather (or she will kick them off the Forth-200x committee) and so they pretend that ANS-Forth can't be disambiguified.

Stephen Pelc makes his money by selling cross-compilers --- he wants to do everything he can to prevent common Forth programmers such as you or I from writing our own cross-compiler in ANS-Forth --- I think that my MFX (I wrote it in 1994) scared the ANS-Forth committee because they realized that Forth-83 was powerful enough to allow unauthorized Forthers to write their own cross-compiler (Elizabeth Rather made a sales pitch at Testra for Forth Inc. to write the cross-compiler for the MiniForth, but was turned down because her price was "exorbitant," and Testra hired me instead). To prevent Forth Inc. from losing any more sales on cross-compilers, the ANS-Forth committee sabotaged ANS-Forth to make this impossible (but now I have found a work-around that dodges their sabotage and allows the unauthorized Forthers to write their own cross-compiler).

The disambiguifiers are all about empowering the common Forthers and defeating the corporate honchos who want to chain our ankles to a boat-anchor and call that Standard (with a capital 'S').

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

#45418

On Tuesday, February 9, 2016 at 3:52:33 PM UTC-7, hughag...@gmail.com wrote:
> I have written all of these disambiguifiers. ...
> if you want this stuff, contact me by email and I will email it to you.

Actually, I'll just post the disambiguifiers here:

: +loop             state @ 0= abort" *** no interpretation semantics for: +LOOP ***"       postpone +loop          ; immediate
: ."                state @ 0= abort" *** no interpretation semantics for: .quote ***"      postpone ."             ; immediate
: ;                 state @ 0= abort" *** no interpretation semantics for: ; ***"           postpone ;              ; immediate
: >r                state @ 0= abort" *** no interpretation semantics for: >R ***"          postpone >r             ; immediate
: abort"            state @ 0= abort" *** no interpretation semantics for: ABORTquote ***"  postpone abort"         ; immediate
: begin             state @ 0= abort" *** no interpretation semantics for: BEGIN ***"       postpone begin          ; immediate
: do                state @ 0= abort" *** no interpretation semantics for: DO ***"          postpone do             ; immediate
: does>             state @ 0= abort" *** no interpretation semantics for: DOES> ***"       postpone does>          ; immediate
: else              state @ 0= abort" *** no interpretation semantics for: ELSE ***"        postpone else           ; immediate
: exit              state @ 0= abort" *** no interpretation semantics for: EXIT ***"        postpone exit           ; immediate
: I                 state @ 0= abort" *** no interpretation semantics for: I ***"           postpone I              ; immediate
: if                state @ 0= abort" *** no interpretation semantics for: IF ***"          postpone if             ; immediate
: J                 state @ 0= abort" *** no interpretation semantics for: J ***"           postpone J              ; immediate
: leave             state @ 0= abort" *** no interpretation semantics for: LEAVE ***"       postpone leave          ; immediate
: literal           state @ 0= abort" *** no interpretation semantics for: LITERAL ***"     postpone literal        ; immediate
: loop              state @ 0= abort" *** no interpretation semantics for: LOOP ***"        postpone loop           ; immediate
: postpone          state @ 0= abort" *** no interpretation semantics for: POSTPONE ***"    postpone postpone       ; immediate
: r>                state @ 0= abort" *** no interpretation semantics for: R> ***"          postpone r>             ; immediate
: r@                state @ 0= abort" *** no interpretation semantics for: R@ ***"          postpone r@             ; immediate
: recurse           state @ 0= abort" *** no interpretation semantics for: RECURSE ***"     postpone recurse        ; immediate
: repeat            state @ 0= abort" *** no interpretation semantics for: REPEAT ***"      postpone repeat         ; immediate
: s"                state @ 0= abort" *** no interpretation semantics for: Squote ***"      postpone s"             ; immediate
: then              state @ 0= abort" *** no interpretation semantics for: THEN ***"        postpone then           ; immediate
: unloop            state @ 0= abort" *** no interpretation semantics for: UNLOOP ***"      postpone unloop         ; immediate
: until             state @ 0= abort" *** no interpretation semantics for: UNTIL ***"       postpone until          ; immediate
: while             state @ 0= abort" *** no interpretation semantics for: WHILE ***"       postpone while          ; immediate
: [                 state @ 0= abort" *** no interpretation semantics for: [ ***"           postpone [              ; immediate
: [']               state @ 0= abort" *** no interpretation semantics for: ['] ***"         postpone [']            ; immediate
: [char]            state @ 0= abort" *** no interpretation semantics for: [CHAR] ***"      postpone [char]         ; immediate
: 2>r               state @ 0= abort" *** no interpretation semantics for: 2>R ***"         postpone 2>r            ; immediate
: 2r>               state @ 0= abort" *** no interpretation semantics for: 2R> ***"         postpone 2r>            ; immediate
: 2r@               state @ 0= abort" *** no interpretation semantics for: 2R@ ***"         postpone 2r@            ; immediate
: ?do               state @ 0= abort" *** no interpretation semantics for: ?DO ***"         postpone ?do            ; immediate
: again             state @ 0= abort" *** no interpretation semantics for: AGAIN ***"       postpone again          ; immediate
: c"                state @ 0= abort" *** no interpretation semantics for: Cquote ***"      postpone c"             ; immediate
: case              state @ 0= abort" *** no interpretation semantics for: CASE ***"        postpone case           ; immediate
: compile,          state @ 0= abort" *** no interpretation semantics for: COMPILE, ***"    postpone compile,       ; immediate
: endcase           state @ 0= abort" *** no interpretation semantics for: ENDCASE ***"     postpone endcase        ; immediate
: endof             state @ 0= abort" *** no interpretation semantics for: ENDOF ***"       postpone endof          ; immediate
: of                state @ 0= abort" *** no interpretation semantics for: OF ***"          postpone of             ; immediate
char & comment
: [compile]         state @ 0= abort" *** no interpretation semantics for: [COMPILE] ***"   postpone [compile]      ; immediate
&
: 2literal          state @ 0= abort" *** no interpretation semantics for: 2LITERAL ***"    postpone 2literal       ; immediate
: abort"            state @ 0= abort" *** no interpretation semantics for: ABORTquote ***"  postpone abort"         ; immediate
: fliteral          state @ 0= abort" *** no interpretation semantics for: FLITERAL ***"    postpone fliteral       ; immediate
: (local)           state @ 0= abort" *** no interpretation semantics for: (LOCAL) ***"     postpone (local)        ; immediate
: locals|           state @ 0= abort" *** no interpretation semantics for: LOCALS| ***"     postpone locals|        ; immediate
: ;code             state @ 0= abort" *** no interpretation semantics for: ;CODE ***"       postpone ;code          ; immediate
: ahead             state @ 0= abort" *** no interpretation semantics for: AHEAD ***"       postpone ahead          ; immediate
: cs-pick           state @ 0= abort" *** no interpretation semantics for: CS-PICK ***"     postpone cs-pick        ; immediate
: cs-roll           state @ 0= abort" *** no interpretation semantics for: CS-ROLL ***"     postpone cs-roll        ; immediate
: sliteral          state @ 0= abort" *** no interpretation semantics for: SLITERAL ***"    postpone sliteral       ; immediate

VFX? [if]
: to                                                                                        postpone to             ; immediate
[then]

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

#45401

Den tisdag 9 februari 2016 kl. 14:18:49 UTC+1 skrev Chris Curl:
> On Monday, February 8, 2016 at 12:06:37 PM UTC-5, lehs wrote:
> > I would like the possibility of "extending the interpreter", 
> > letting it recognize new data structures. Could this be done?
> 
> I'm having a hard time understanding your question.
> 
> Is there anything keeping you from being able to completely re-write
> the interpreter if you want to behave however you want it to behave?

To change the interpreter I have to find it and understand it.

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

#45394

Am Montag, 8. Februar 2016 18:06:37 UTC+1 schrieb lehs:
> I would like the possibility of "extending the interpreter", letting it recognize new data structures. Could this be done?

Recognisers have been discussed....

Are you aware of data structures extensions eg. in the Forth200x Standard discussion? (but there are others too)

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

#45510

Den måndag 8 februari 2016 kl. 18:06:37 UTC+1 skrev lehs:
> I would like the possibility of "extending the interpreter", letting it recognize new data structures. Could this be done?

Using 'see' with trial and error I'd made this 

: extended_interpret \ -- 
  space ." Ok" cr 
  begin clear-tibstack
     tib max#tib @ accept #tib ! input-start-line tib c@
     case
       [char] + of endof
       [char] { of endof
       [char] ( of endof
            dup of interpret endof
     endcase space ." Ok" cr 
  again ; 

that accepts anything starting with '+', '{' or '(' without error messages. Between of and endof there should be a word for handling those inputs.

I don't know the exact consequences of the routine, but when started it works like quit(?) and keep working until an error.

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

Page 1 of 2  [1] 2  Next page →

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

csiph-web