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

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

MiniForth 0.1.18 has just been released ...

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

Contents

  MiniForth 0.1.18 has just been released ... Rob Sciuk <rob@controlq.com> - 2013-02-26 17:03 -0500
    Re: MiniForth 0.1.18 has just been released ... "Rod Pemberton" <do_not_have@notemailnotz.cnm> - 2013-02-27 04:06 -0500
      Re: MiniForth 0.1.18 has just been released ... Richard Owlett <rowlett@pcnetinc.com> - 2013-02-27 05:30 -0600
        Re: MiniForth 0.1.18 has just been released ... Andrew Haley <andrew29@littlepinkcloud.invalid> - 2013-02-27 06:34 -0600
          Re: MiniForth 0.1.18 has just been released ... anton@mips.complang.tuwien.ac.at (Anton Ertl) - 2013-02-27 14:42 +0000
            Re: MiniForth 0.1.18 has just been released ... Andrew Haley <andrew29@littlepinkcloud.invalid> - 2013-02-27 11:54 -0600
              Re: MiniForth 0.1.18 has just been released ... Rob Sciuk <rob@controlq.com> - 2013-02-27 15:27 -0500
                Re: MiniForth 0.1.18 has just been released ... Coos Haak <chforth@hccnet.nl> - 2013-02-27 21:58 +0100
                Re: MiniForth 0.1.18 has just been released ... Andrew Haley <andrew29@littlepinkcloud.invalid> - 2013-02-27 16:33 -0600
                  Re: MiniForth 0.1.18 has just been released ... anton@mips.complang.tuwien.ac.at (Anton Ertl) - 2013-03-02 17:23 +0000
                    Re: MiniForth 0.1.18 has just been released ... Andrew Haley <andrew29@littlepinkcloud.invalid> - 2013-03-02 15:12 -0600
                      Re: MiniForth 0.1.18 has just been released ... anton@mips.complang.tuwien.ac.at (Anton Ertl) - 2013-03-03 14:30 +0000
                        Re: MiniForth 0.1.18 has just been released ... Andrew Haley <andrew29@littlepinkcloud.invalid> - 2013-03-03 14:49 -0600
                          Re: MiniForth 0.1.18 has just been released ... anton@mips.complang.tuwien.ac.at (Anton Ertl) - 2013-03-07 16:58 +0000
                            Re: MiniForth 0.1.18 has just been released ... Andrew Haley <andrew29@littlepinkcloud.invalid> - 2013-03-07 16:35 -0600
                              Re: MiniForth 0.1.18 has just been released ... anton@mips.complang.tuwien.ac.at (Anton Ertl) - 2013-03-08 17:29 +0000
                                Re: MiniForth 0.1.18 has just been released ... Andrew Haley <andrew29@littlepinkcloud.invalid> - 2013-03-08 12:17 -0600
              Re: MiniForth 0.1.18 has just been released ... Bernd Paysan <bernd.paysan@gmx.de> - 2013-02-28 00:17 +0100
                Re: MiniForth 0.1.18 has just been released ... Paul Rubin <no.email@nospam.invalid> - 2013-02-28 01:04 -0800
                  Re: MiniForth 0.1.18 has just been released ... Bernd Paysan <bernd.paysan@gmx.de> - 2013-02-28 17:10 +0100
                Re: MiniForth 0.1.18 has just been released ... Andrew Haley <andrew29@littlepinkcloud.invalid> - 2013-02-28 11:20 -0600
              Re: MiniForth 0.1.18 has just been released ... anton@mips.complang.tuwien.ac.at (Anton Ertl) - 2013-03-02 16:54 +0000
                Re: MiniForth 0.1.18 has just been released ... Andrew Haley <andrew29@littlepinkcloud.invalid> - 2013-03-02 15:38 -0600
                  Re: MiniForth 0.1.18 has just been released ... anton@mips.complang.tuwien.ac.at (Anton Ertl) - 2013-03-03 14:43 +0000
                    Re: MiniForth 0.1.18 has just been released ... Andrew Haley <andrew29@littlepinkcloud.invalid> - 2013-03-03 15:05 -0600
                      Re: MiniForth 0.1.18 has just been released ... Bernd Paysan <bernd.paysan@gmx.de> - 2013-03-03 23:14 +0100
                        Re: MiniForth 0.1.18 has just been released ... Andrew Haley <andrew29@littlepinkcloud.invalid> - 2013-03-04 03:41 -0600
                          Re: MiniForth 0.1.18 has just been released ... Gerry Jackson <gerry@jackson9000.fsnet.co.uk> - 2013-03-04 11:00 +0000
                            Re: MiniForth 0.1.18 has just been released ... albert@spenarnc.xs4all.nl (Albert van der Horst) - 2013-03-04 12:47 +0000
                              Re: MiniForth 0.1.18 has just been released ... Gerry Jackson <gerry@jackson9000.fsnet.co.uk> - 2013-03-04 16:27 +0000
                                Re: MiniForth 0.1.18 has just been released ... albert@spenarnc.xs4all.nl (Albert van der Horst) - 2013-03-04 19:27 +0000
                                  Re: MiniForth 0.1.18 has just been released ... Gerry Jackson <gerry@jackson9000.fsnet.co.uk> - 2013-03-04 20:46 +0000
                                    Re: MiniForth 0.1.18 has just been released ... Alex McDonald <blog@rivadpm.com> - 2013-03-05 00:19 -0800
                                      Re: MiniForth 0.1.18 has just been released ... albert@spenarnc.xs4all.nl (Albert van der Horst) - 2013-03-05 12:17 +0000
                                        Re: MiniForth 0.1.18 has just been released ... Gerry Jackson <gerry@jackson9000.fsnet.co.uk> - 2013-03-05 17:22 +0000
                                        Re: MiniForth 0.1.18 has just been released ... albert@spenarnc.xs4all.nl (Albert van der Horst) - 2013-03-05 17:52 +0000
                                      Re: MiniForth 0.1.18 has just been released ... Gerry Jackson <gerry@jackson9000.fsnet.co.uk> - 2013-03-05 17:03 +0000
                                        Re: MiniForth 0.1.18 has just been released ... Rob Sciuk <rob@controlq.com> - 2013-03-05 12:38 -0500
                                          Re: MiniForth 0.1.18 has just been released ... anton@mips.complang.tuwien.ac.at (Anton Ertl) - 2013-03-05 17:57 +0000
                                            Re: MiniForth 0.1.18 has just been released ... Rob Sciuk <rob@controlq.com> - 2013-03-05 13:29 -0500
                                            Re: MiniForth 0.1.18 has just been released ... Andy Valencia <user@vsta.org> - 2013-03-05 22:19 +0000
                                        Re: MiniForth 0.1.18 has just been released ... albert@spenarnc.xs4all.nl (Albert van der Horst) - 2013-03-05 17:58 +0000
                                          Re: MiniForth 0.1.18 has just been released ... Gerry Jackson <gerry@jackson9000.fsnet.co.uk> - 2013-03-05 19:26 +0000
                                        Re: MiniForth 0.1.18 has just been released ... Alex McDonald <blog@rivadpm.com> - 2013-03-05 11:19 -0800
                                        Forth convergence with rest of world Andy Valencia <user@vsta.org> - 2013-03-05 22:17 +0000
                                          Re: Forth convergence with rest of world Alex McDonald <blog@rivadpm.com> - 2013-03-05 15:15 -0800
                                            Re: Forth convergence with rest of world Bernd Paysan <bernd.paysan@gmx.de> - 2013-03-06 17:35 +0100
                                              Re: Forth convergence with rest of world albert@spenarnc.xs4all.nl (Albert van der Horst) - 2013-03-06 16:44 +0000
                                                Re: Forth convergence with rest of world Zbiggy <zbigniew2011REMOVE@gmail.REMOVE.com> - 2013-03-06 17:39 +0000
                                          Re: Forth convergence with rest of world Andrew Haley <andrew29@littlepinkcloud.invalid> - 2013-03-05 18:16 -0600
                                            Re: Forth convergence with rest of world Rob Sciuk <rob@controlq.com> - 2013-03-06 13:49 -0500
                                              Re: Forth convergence with rest of world Zbiggy <zbigniew2011REMOVE@gmail.REMOVE.com> - 2013-03-06 19:11 +0000
                                                Re: Forth convergence with rest of world Rob Sciuk <rob@controlq.com> - 2013-03-06 14:24 -0500
                                                  Re: Forth convergence with rest of world Zbiggy <zbigniew2011REMOVE@gmail.REMOVE.com> - 2013-03-06 19:40 +0000
                                                Re: Forth convergence with rest of world "Elizabeth D. Rather" <erather@forth.com> - 2013-03-06 09:26 -1000
                                              Re: Forth convergence with rest of world "Elizabeth D. Rather" <erather@forth.com> - 2013-03-06 09:26 -1000
                                              Re: Forth convergence with rest of world Andrew Haley <andrew29@littlepinkcloud.invalid> - 2013-03-06 15:34 -0600
                                              Re: Forth convergence with rest of world Andy Valencia <user@vsta.org> - 2013-03-06 22:04 +0000
                                                Re: Forth convergence with rest of world "Elizabeth D. Rather" <erather@forth.com> - 2013-03-06 12:09 -1000
                                                Re: Forth convergence with rest of world Andrew Haley <andrew29@littlepinkcloud.invalid> - 2013-03-07 04:24 -0600
                                                  Re: Forth convergence with rest of world Alex McDonald <blog@rivadpm.com> - 2013-03-07 04:15 -0800
                                                    Re: Forth convergence with rest of world Andrew Haley <andrew29@littlepinkcloud.invalid> - 2013-03-07 08:42 -0600
                                                      Re: Forth convergence with rest of world Alex McDonald <blog@rivadpm.com> - 2013-03-07 13:50 -0800
                                                    Re: Forth convergence with rest of world Rob Sciuk <rob@controlq.com> - 2013-03-07 12:12 -0500
                                                      Re: Forth convergence with rest of world Zbiggy <zbigniew2011REMOVE@gmail.REMOVE.com> - 2013-03-07 18:36 +0000
                                                        Re: Forth convergence with rest of world Rob Sciuk <rob@controlq.com> - 2013-03-07 14:07 -0500
                                                          Re: Forth convergence with rest of world Zbiggy <zbigniew2011REMOVE@gmail.REMOVE.com> - 2013-03-07 19:43 +0000
                                                          Re: Forth convergence with rest of world anton@mips.complang.tuwien.ac.at (Anton Ertl) - 2013-03-08 17:27 +0000
                                                    Re: Forth convergence with rest of world "Elizabeth D. Rather" <erather@forth.com> - 2013-03-07 08:47 -1000
                                                      Re: Forth convergence with rest of world awegel@arcor.de (Alex Wegel) - 2013-03-07 21:42 +0100
                                                      Re: Forth convergence with rest of world Alex McDonald <blog@rivadpm.com> - 2013-03-07 14:43 -0800
                                                        Re: Forth convergence with rest of world "Elizabeth D. Rather" <erather@forth.com> - 2013-03-07 13:53 -1000
                                                  Re: Forth convergence with rest of world stephenXXX@mpeforth.com (Stephen Pelc) - 2013-03-07 12:38 +0000
                                                    Re: Forth convergence with rest of world Andrew Haley <andrew29@littlepinkcloud.invalid> - 2013-03-07 08:43 -0600
                                                  Re: Forth convergence with rest of world Syd Rumpo <usenet@nononono.co.uk> - 2013-03-08 18:04 +0000
                                                    Re: Forth convergence with rest of world Andrew Haley <andrew29@littlepinkcloud.invalid> - 2013-03-08 12:18 -0600
                                                      Re: Forth convergence with rest of world Syd Rumpo <usenet@nononono.co.uk> - 2013-03-08 18:36 +0000
                                                        Re: Forth convergence with rest of world "Elizabeth D. Rather" <erather@forth.com> - 2013-03-08 14:30 -1000
                                                          Re: Forth convergence with rest of world Syd Rumpo <usenet@nononono.co.uk> - 2013-03-09 01:27 +0000
                                                        Re: Forth convergence with rest of world Andrew Haley <andrew29@littlepinkcloud.invalid> - 2013-03-09 02:43 -0600
                                  Re: MiniForth 0.1.18 has just been released ... Mark Wills <markrobertwills@yahoo.co.uk> - 2013-03-05 01:19 -0800
                                    Re: MiniForth 0.1.18 has just been released ... albert@spenarnc.xs4all.nl (Albert van der Horst) - 2013-03-05 12:01 +0000
                                      Re: MiniForth 0.1.18 has just been released ... anton@mips.complang.tuwien.ac.at (Anton Ertl) - 2013-03-08 17:02 +0000
                          Re: MiniForth 0.1.18 has just been released ... albert@spenarnc.xs4all.nl (Albert van der Horst) - 2013-03-04 12:45 +0000
                            Re: MiniForth 0.1.18 has just been released ... Andrew Haley <andrew29@littlepinkcloud.invalid> - 2013-03-04 11:58 -0600
                              Re: MiniForth 0.1.18 has just been released ... albert@spenarnc.xs4all.nl (Albert van der Horst) - 2013-03-04 19:34 +0000
                                Re: MiniForth 0.1.18 has just been released ... Andrew Haley <andrew29@littlepinkcloud.invalid> - 2013-03-04 15:15 -0600
                                  Re: MiniForth 0.1.18 has just been released ... Roelf Toxopeus <rt4all@notthis.hetnet.nl> - 2013-03-04 23:31 +0100
                                Re: MiniForth 0.1.18 has just been released ... Gerry Jackson <gerry@jackson9000.fsnet.co.uk> - 2013-03-05 17:07 +0000
                                  Re: MiniForth 0.1.18 has just been released ... Rob Sciuk <rob@controlq.com> - 2013-03-05 12:11 -0500
                          Re: MiniForth 0.1.18 has just been released ... Bernd Paysan <bernd.paysan@gmx.de> - 2013-03-05 00:32 +0100
                      Re: MiniForth 0.1.18 has just been released ... anton@mips.complang.tuwien.ac.at (Anton Ertl) - 2013-03-07 17:00 +0000
                        Re: MiniForth 0.1.18 has just been released ... Andrew Haley <andrew29@littlepinkcloud.invalid> - 2013-03-07 16:52 -0600
                          Re: MiniForth 0.1.18 has just been released ... anton@mips.complang.tuwien.ac.at (Anton Ertl) - 2013-03-08 17:32 +0000
                            Re: MiniForth 0.1.18 has just been released ... Andrew Haley <andrew29@littlepinkcloud.invalid> - 2013-03-08 12:25 -0600
                          Re: MiniForth 0.1.18 has just been released ... Brad Eckert <hwfwguy@gmail.com> - 2013-03-11 09:57 -0700
                            Re: MiniForth 0.1.18 has just been released ... Andrew Haley <andrew29@littlepinkcloud.invalid> - 2013-03-11 12:05 -0500
                              Re: MiniForth 0.1.18 has just been released ... anton@mips.complang.tuwien.ac.at (Anton Ertl) - 2013-03-11 17:20 +0000
                                Re: MiniForth 0.1.18 has just been released ... Andrew Haley <andrew29@littlepinkcloud.invalid> - 2013-03-11 14:05 -0500
                                  Re: MiniForth 0.1.18 has just been released ... Alex McDonald <blog@rivadpm.com> - 2013-03-11 14:35 -0700
                                    Re: MiniForth 0.1.18 has just been released ... Bernd Paysan <bernd.paysan@gmx.de> - 2013-03-12 00:21 +0100
                                Re: MiniForth 0.1.18 has just been released ... stephenXXX@mpeforth.com (Stephen Pelc) - 2013-03-12 12:13 +0000
                              Re: MiniForth 0.1.18 has just been released ... albert@spenarnc.xs4all.nl (Albert van der Horst) - 2013-03-11 19:16 +0000
                                Re: MiniForth 0.1.18 has just been released ... Zbiggy <zbigniew2011REMOVE@gmail.REMOVE.com> - 2013-03-11 19:29 +0000
                                  Re: MiniForth 0.1.18 has just been released ... Bernd Paysan <bernd.paysan@gmx.de> - 2013-03-11 21:36 +0100
                                    Re: MiniForth 0.1.18 has just been released ... Zbiggy <zbigniew2011REMOVE@gmail.REMOVE.com> - 2013-03-11 20:52 +0000
                                      Re: MiniForth 0.1.18 has just been released ... Alex McDonald <blog@rivadpm.com> - 2013-03-11 14:39 -0700
                                        Re: MiniForth 0.1.18 has just been released ... Zbiggy <zbigniew2011REMOVE@gmail.REMOVE.com> - 2013-03-11 21:52 +0000
                                      Re: MiniForth 0.1.18 has just been released ... Coos Haak <chforth@hccnet.nl> - 2013-03-12 01:11 +0100
                                        Re: MiniForth 0.1.18 has just been released ... Zbiggy <zbigniew2011REMOVE@gmail.REMOVE.com> - 2013-03-12 00:41 +0000
                                          Re: MiniForth 0.1.18 has just been released ... Coos Haak <chforth@hccnet.nl> - 2013-03-12 17:33 +0100
      Re: MiniForth 0.1.18 has just been released ... Rob Sciuk <rob@controlq.com> - 2013-02-27 11:51 -0500
        Re: MiniForth 0.1.18 has just been released ... "Elizabeth D. Rather" <erather@forth.com> - 2013-02-27 09:25 -1000
          Re: MiniForth 0.1.18 has just been released ... Rob Sciuk <rob@controlq.com> - 2013-02-27 17:23 -0500
            Re: MiniForth 0.1.18 has just been released ... "Elizabeth D. Rather" <erather@forth.com> - 2013-02-27 13:10 -1000

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

#20106

Bernd Paysan <bernd.paysan@gmx.de> wrote:

> Forth Inc's Forths didn't have a STATE variable for quite some time.
> The Forth Inc. approach therefore was, when there was the need for
> similar words of which one would interpret and the other would
> compile, to use []s for the compiled version.  Or use something like
> .( and ." for interpretation and compilation.
> 
> This might be easy for implementation, but it clutters up the
> conceptual stuff.

IME it made the conceptual stuff simpler.  Much simpler.

> Forth is an interactive environment, and one key feature of an
> interactive environment is that you can use words directly on the
> command line.
> 
> That's why others like figForth had STATE, and used state-smart words.  

No, that's not how the history went.  fig-FORTH was based on earlier
Forth practice, which used STATE; I think at one point there were more
than two states.  Forth, Inc. later figured out how to get rid of STATE
entirely.

Andrew.

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

#20177

Andrew Haley <andrew29@littlepinkcloud.invalid> writes:
>Anton Ertl <anton@mips.complang.tuwien.ac.at> wrote:
>> Andrew Haley <andrew29@littlepinkcloud.invalid> writes:
>>>I don't think so.  State-smartness is a something we're stuck with
>>>because of a few standard words
>> 
>> There is no standard word that is specified as state-smart, so no, we
>> are not stuck with it.
>
>I think we are.  As you may be aware, I do not accept your definition
>of "state-smart" as meaning only words that use the variable STATE.
>As far as I am concerned, state-smart words are those with non-default
>compilation semantics and different compilation and interpretation
>semantics.

I was not aware of that.  Why would you play Humpty Dumpty?  And what
term would you suggest for words that are immediate, test the state at
run-time and behave different according to the STATE at that time?

>The problem with such words is not how state-smartness is
>achieved, it is those different semantics.  It is this property that
>leads to obscure bugs.

Please elaborate on these bugs.

The bugs I have encountered certainly come from STATE-smartness as I
use the term, not combined words (my term for what you call
state-smart words).

>> We have had the ' ['] and ." .( solution for many years, and people
>> still implement STATE-smart words, despite their problems and people
>> like me doing a lot to inform people of these problems.  So maybe we
>> should provide an alternative, less problematic solution instead of
>> trying to get people to use the ." ."( approach.
>
>But that would just result in even more obscure horrors.

Please elaborate on that.  What horrors have you encountered?

Note that we have had recognizers for single-cell integers,
double-cell integers and FP numbers for many years, and more recently
for characters, their just was no well-recognized way for users to
define additional recognizers.

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

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

#20190

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:
>>>>I don't think so.  State-smartness is a something we're stuck with
>>>>because of a few standard words
>>> 
>>> There is no standard word that is specified as state-smart, so no, we
>>> are not stuck with it.
>>
>>I think we are.  As you may be aware, I do not accept your definition
>>of "state-smart" as meaning only words that use the variable STATE.
>>As far as I am concerned, state-smart words are those with non-default
>>compilation semantics and different compilation and interpretation
>>semantics.
> 
> I was not aware of that.  Why would you play Humpty Dumpty?  And what
> term would you suggest for words that are immediate, test the state at
> run-time and behave different according to the STATE at that time?

STATE-smart.  I think you do recognize this in your "State smartness -
why it is evil" paper by putting STATE in a different font to show
that STATE is a variable.  I accept that my usage is obscure, and it
would be nice to have something better.  I think we do need a term for
words that have such a property.

>>The problem with such words is not how state-smartness is achieved,
>>it is those different semantics.  It is this property that leads to
>>obscure bugs.
> 
> Please elaborate on these bugs.
> 
> The bugs I have encountered certainly come from STATE-smartness as I
> use the term, not combined words (my term for what you call
> state-smart words).

That's interesting.  As far as I'm aware all that "combined words"
does is somewhat improve the situation, not solve it.  I'll think
about some examples.

>>> We have had the ' ['] and ." .( solution for many years, and people
>>> still implement STATE-smart words, despite their problems and people
>>> like me doing a lot to inform people of these problems.  So maybe we
>>> should provide an alternative, less problematic solution instead of
>>> trying to get people to use the ." ."( approach.
>>
>>But that would just result in even more obscure horrors.
> 
> Please elaborate on that. 

With recognizers you have another way to define arbitrary syntaxes
that is in no way related to the rest of the Forth langyage.  At
present, if you want to use, say, XML syntax, you must have a word
XML: or equivalent to start the parsing.  This is good.  Given
recognizers, XML: is no longer necessary: the Forth text interpreter
sees <FOO and the XML recognizer parses it as an opening tag.  Some
people may like this; no thank you.

> What horrors have you encountered?

None, because they're not much used.

> Note that we have had recognizers for single-cell integers,
> double-cell integers and FP numbers for many years, and more
> recently for characters, their just was no well-recognized way for
> users to define additional recognizers.

Andrew.

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

#20208

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:
>>>>>I don't think so.  State-smartness is a something we're stuck with
>>>>>because of a few standard words
>>>> 
>>>> There is no standard word that is specified as state-smart, so no, we
>>>> are not stuck with it.
>>>
>>>I think we are.  As you may be aware, I do not accept your definition
>>>of "state-smart" as meaning only words that use the variable STATE.
>>>As far as I am concerned, state-smart words are those with non-default
>>>compilation semantics and different compilation and interpretation
>>>semantics.
>> 
>> I was not aware of that.  Why would you play Humpty Dumpty?  And what
>> term would you suggest for words that are immediate, test the state at
>> run-time and behave different according to the STATE at that time?
>
>STATE-smart.

So you use "STATE-smart" for the flawed implementation technique, and
"state-smart" for combined words?

> I accept that my usage is obscure

Definitely.  And certainly not conducive to productive discussions and
avoiding misunderstandings.  Forth is usually not case sensitive, and
in this group we have regular confusion between F83 and Forth-83.
It's an extremely bad idea to use two terms that differ only by case
for two different concepts.

>and it
>would be nice to have something better.

We have: "combined words".

>With recognizers you have another way to define arbitrary syntaxes
>that is in no way related to the rest of the Forth langyage.  At
>present, if you want to use, say, XML syntax, you must have a word
>XML: or equivalent to start the parsing.  This is good.  Given
>recognizers, XML: is no longer necessary: the Forth text interpreter
>sees <FOO and the XML recognizer parses it as an opening tag.  Some
>people may like this; no thank you.

Forth has not been a nanny language like Ada.  It gives the
programmers enough rope to hang themselves, and relies on the
programmers to use it wisely.  E.g., we can write words with arbitrary
names, like

: 5 4 ;

So why start being nannyish when it comes to recognizers?

>> What horrors have you encountered?
>
>None, because they're not much used.

Case closed.

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

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

#20215

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:
>>>>> Andrew Haley <andrew29@littlepinkcloud.invalid> writes:
>>>>>>I don't think so.  State-smartness is a something we're stuck with
>>>>>>because of a few standard words
>>>>> 
>>>>> There is no standard word that is specified as state-smart, so no, we
>>>>> are not stuck with it.
>>>>
>>>>I think we are.  As you may be aware, I do not accept your definition
>>>>of "state-smart" as meaning only words that use the variable STATE.
>>>>As far as I am concerned, state-smart words are those with non-default
>>>>compilation semantics and different compilation and interpretation
>>>>semantics.
>>> 
>>> I was not aware of that.  Why would you play Humpty Dumpty?  And what
>>> term would you suggest for words that are immediate, test the state at
>>> run-time and behave different according to the STATE at that time?
>>
>>STATE-smart.
> 
> So you use "STATE-smart" for the flawed implementation technique, and
> "state-smart" for combined words?

Basically, yes.  I use "state-smart" for any words that have a dual
meaning (he says, avoiding the contentious "different semantics")
depending on whether the system is in compilation state or
interpretation state.

>> I accept that my usage is obscure
> 
> Definitely.  And certainly not conducive to productive discussions and
> avoiding misunderstandings.  Forth is usually not case sensitive, and
> in this group we have regular confusion between F83 and Forth-83.
> It's an extremely bad idea to use two terms that differ only by case
> for two different concepts.

I accept that.
 
>>and it would be nice to have something better.
> 
> We have: "combined words".

I thought "combined words" was the name of one implementation
technique.  I'm looking for a word that names the idea of these words.
"Janus words", perhaps?

>>With recognizers you have another way to define arbitrary syntaxes
>>that is in no way related to the rest of the Forth langyage.  At
>>present, if you want to use, say, XML syntax, you must have a word
>>XML: or equivalent to start the parsing.  This is good.  Given
>>recognizers, XML: is no longer necessary: the Forth text interpreter
>>sees <FOO and the XML recognizer parses it as an opening tag.  Some
>>people may like this; no thank you.
> 
> Forth has not been a nanny language like Ada.  It gives the
> programmers enough rope to hang themselves, and relies on the
> programmers to use it wisely.  E.g., we can write words with arbitrary
> names, like
> 
> : 5 4 ;
> 
> So why start being nannyish when it comes to recognizers?

It's not a matter of being nannyish: it's a matter of avoiding
complexity for little advantage.  We already have one of the most
flexible and extensible languages, but its tradition is one that
eschews complexity and insists that everything is there for a good
reason.  In this case you're adding scaffolding simply in order to
void having to say XML: .

>>> What horrors have you encountered?
>>
>>None, because they're not much used.
> 
> Case closed.

This makes no sense: a technique that is little used can have little
evidence of its disadvantages, or advantages.  The onus is not on me
to prove that a techinique is bad, but on its proponents to show that
it's not only worthwhile but substantally better than what we already
have.

Andrew.

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

#20224

Andrew Haley wrote:
> I thought "combined words" was the name of one implementation
> technique.  I'm looking for a word that names the idea of these words.
> "Janus words", perhaps?

Suggestion: "Smart macros".  Shows that they will execute their own code in 
compilation state ("macros"), and that they are beyond that.

> It's not a matter of being nannyish: it's a matter of avoiding
> complexity for little advantage.  We already have one of the most
> flexible and extensible languages, but its tradition is one that
> eschews complexity and insists that everything is there for a good
> reason.  In this case you're adding scaffolding simply in order to
> void having to say XML: .

We actually have a subobtimal scaffolding like that in a lot of Forth 
systems, because many of them don't have the floating point wordset built 
in.  So when you load the floating point wordset, you add a recognizer to 
parse floating point numbers, though this is informal and through carnal 
knowledge.  If we had ColorForth, this would be just another color, and like 
your XML:, it would be part of the well-defined system interface, but in a 
Forth without recognizer, this requires carnal knowledge.

Recognizers expose this, and while we are still experimenting with them, and 
therefore, the implementations have significiant differences, it might be 
possible that a standard approach arises.

We have also the issue that adding the floating point recognizer at the 
tail, i.e. through NOTFOUND is not always adequate, especially when your 
double wordset also uses NOTFOUND to add the double number recognizer...  
then you have to load them in the right order.

Forth has never done anything to prevent people from shooting into their 
foot.  If you use the new powerful features, and nuke your foot away, your 
problem.  And Forth is there to write DSLs.  If you take an HP calculator, 
you can enter complex numbers.  How?  Because RPL has something like a 
recognizer for them.  This is not really new.

-- 
Bernd Paysan
"If you want it done right, you have to do it yourself"
http://bernd-paysan.de/

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

#20234

Bernd Paysan <bernd.paysan@gmx.de> wrote:
> Andrew Haley wrote:
>> I thought "combined words" was the name of one implementation
>> technique.  I'm looking for a word that names the idea of these words.
>> "Janus words", perhaps?
> 
> Suggestion: "Smart macros".  Shows that they will execute their own code in 
> compilation state ("macros"), and that they are beyond that.

Ok, ISWYM, but "smart macros" doesn't really address the duality of
such words.

>> It's not a matter of being nannyish: it's a matter of avoiding
>> complexity for little advantage.  We already have one of the most
>> flexible and extensible languages, but its tradition is one that
>> eschews complexity and insists that everything is there for a good
>> reason.  In this case you're adding scaffolding simply in order to
>> void having to say XML: .
> 
> We actually have a subobtimal scaffolding like that in a lot of
> Forth systems, because many of them don't have the floating point
> wordset built in.  So when you load the floating point wordset, you
> add a recognizer to parse floating point numbers, though this is
> informal and through carnal knowledge.  If we had ColorForth, this
> would be just another color, and like your XML:, it would be part of
> the well-defined system interface, but in a Forth without
> recognizer, this requires carnal knowledge.

I accept that point.

There always has been the issue of how exactly a portable program
should extend the literal syntax of Forth.  It's been avoided because
there never has been any common practice and it's easy enough to do in
a nonstandard way.  And also, I suspect, that in practice there isn't
that much application need for it.

> Recognizers expose this, and while we are still experimenting with
> them, and therefore, the implementations have significiant
> differences, it might be possible that a standard approach arises.

Maybe so.  If there is common practice then it becomes an issue for
the TC.

> Forth has never done anything to prevent people from shooting into
> their foot.  If you use the new powerful features, and nuke your
> foot away, your problem.  And Forth is there to write DSLs. 

I take that point.  Recognizers seem to me to be a far more sensible
idea than state-smartness, however it's achieved.  I wonder if the
term "recognizer" isn't helping here, because it sounds like such a
big deal.  As I understand the idea, it's just a way to add a word to
parse a literal and another word to compile the result.

Andrew.

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

#20238

On 04/03/2013 09:41, Andrew Haley wrote:
[...]

> I take that point.  Recognizers seem to me to be a far more sensible
> idea than state-smartness, however it's achieved.  I wonder if the
> term "recognizer" isn't helping here, because it sounds like such a
> big deal.  As I understand the idea, it's just a way to add a word to
> parse a literal and another word to compile the result.
>

As I understand it recognizers (I prefer to spell it recognisers) can be 
more than that. If implemented as a recognizer stack which can be 
manipulated by the user in much the same way as the search order (which 
GForth does I think) then the concept becomes more powerful. For example:

- a number recognizer could be above a word recogniser so that numbers 
can be handled before a dictionary search to avoid wasting time when 
compiling a lot of numbers

- a user definition written as a recognizer can use standard parsing 
words on the input source, removes the need for something like GForths 
EXECUTE-PARSING-FILE.

- [IF] can be written as a recognizer where coding is much simpler than 
the example given in the ANS Forth standard, including nesting of [IF]s

- a user can write an error handler for the text interpreter

If such a recognizer stack is used I agree a better name than recognizer 
is needed.


-- 
Gerry

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

#20243

In article <kh1upe$939$1@dont-email.me>,
Gerry Jackson  <gerry@jackson9000.fsnet.co.uk> wrote:
>On 04/03/2013 09:41, Andrew Haley wrote:
>[...]
>
>> I take that point.  Recognizers seem to me to be a far more sensible
>> idea than state-smartness, however it's achieved.  I wonder if the
>> term "recognizer" isn't helping here, because it sounds like such a
>> big deal.  As I understand the idea, it's just a way to add a word to
>> parse a literal and another word to compile the result.
>>
>
>As I understand it recognizers (I prefer to spell it recognisers) can be
>more than that. If implemented as a recognizer stack which can be
>manipulated by the user in much the same way as the search order (which
>GForth does I think) then the concept becomes more powerful. For example:
>
>- a number recognizer could be above a word recogniser so that numbers
>can be handled before a dictionary search to avoid wasting time when
>compiling a lot of numbers
>
>- a user definition written as a recognizer can use standard parsing
>words on the input source, removes the need for something like GForths
>EXECUTE-PARSING-FILE.
>
>- [IF] can be written as a recognizer where coding is much simpler than
>the example given in the ANS Forth standard, including nesting of [IF]s
>
>- a user can write an error handler for the text interpreter
>
>If such a recognizer stack is used I agree a better name than recognizer
>is needed.

Stack? YET ANOTHER STACK?

My prefixes work the way you intend, using only the normal rules
of search order.

>
>
>--
>Gerry

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]

#20246

On 04/03/2013 12:47, Albert van der Horst wrote:
> In article <kh1upe$939$1@dont-email.me>,
> Gerry Jackson  <gerry@jackson9000.fsnet.co.uk> wrote:
>> On 04/03/2013 09:41, Andrew Haley wrote:
>> [...]
>>
>>> I take that point.  Recognizers seem to me to be a far more sensible
>>> idea than state-smartness, however it's achieved.  I wonder if the
>>> term "recognizer" isn't helping here, because it sounds like such a
>>> big deal.  As I understand the idea, it's just a way to add a word to
>>> parse a literal and another word to compile the result.
>>>
>>
>> As I understand it recognizers (I prefer to spell it recognisers) can be
>> more than that. If implemented as a recognizer stack which can be
>> manipulated by the user in much the same way as the search order (which
>> GForth does I think) then the concept becomes more powerful. For example:
>>
>> - a number recognizer could be above a word recogniser so that numbers
>> can be handled before a dictionary search to avoid wasting time when
>> compiling a lot of numbers
>>
>> - a user definition written as a recognizer can use standard parsing
>> words on the input source, removes the need for something like GForths
>> EXECUTE-PARSING-FILE.
>>
>> - [IF] can be written as a recognizer where coding is much simpler than
>> the example given in the ANS Forth standard, including nesting of [IF]s
>>
>> - a user can write an error handler for the text interpreter
>>
>> If such a recognizer stack is used I agree a better name than recognizer
>> is needed.
>
> Stack? YET ANOTHER STACK?

Yas. Well if that offends you, call it a list.
>
> My prefixes work the way you intend, using only the normal rules
> of search order.

Why do you mention that? I never mentioned prefixes or said you couldn't 
do that. I imagine that other Forth systems that handle prefixes do the 
same as you.

-- 
Gerry

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

#20250

In article <kh2hvp$lnd$1@dont-email.me>,
Gerry Jackson  <gerry@jackson9000.fsnet.co.uk> wrote:
>On 04/03/2013 12:47, Albert van der Horst wrote:
>> In article <kh1upe$939$1@dont-email.me>,
>> Gerry Jackson  <gerry@jackson9000.fsnet.co.uk> wrote:
>>> On 04/03/2013 09:41, Andrew Haley wrote:
>>> [...]
>>>
>>>> I take that point.  Recognizers seem to me to be a far more sensible
>>>> idea than state-smartness, however it's achieved.  I wonder if the
>>>> term "recognizer" isn't helping here, because it sounds like such a
>>>> big deal.  As I understand the idea, it's just a way to add a word to
>>>> parse a literal and another word to compile the result.
>>>>
>>>
>>> As I understand it recognizers (I prefer to spell it recognisers) can be
>>> more than that. If implemented as a recognizer stack which can be
>>> manipulated by the user in much the same way as the search order (which
>>> GForth does I think) then the concept becomes more powerful. For example:
>>>
>>> - a number recognizer could be above a word recogniser so that numbers
>>> can be handled before a dictionary search to avoid wasting time when
>>> compiling a lot of numbers
>>>
>>> - a user definition written as a recognizer can use standard parsing
>>> words on the input source, removes the need for something like GForths
>>> EXECUTE-PARSING-FILE.
>>>
>>> - [IF] can be written as a recognizer where coding is much simpler than
>>> the example given in the ANS Forth standard, including nesting of [IF]s
>>>
>>> - a user can write an error handler for the text interpreter
>>>
>>> If such a recognizer stack is used I agree a better name than recognizer
>>> is needed.
>>
>> Stack? YET ANOTHER STACK?
>
>Yas. Well if that offends you, call it a list.
>>
>> My prefixes work the way you intend, using only the normal rules
>> of search order.
>
>Why do you mention that? I never mentioned prefixes or said you couldn't
>do that. I imagine that other Forth systems that handle prefixes do the
>same as you.

Prefixes are the recognizers Anton talks about. Only with me they are
just Forth words, that are found in the dictionary.
Look up
    0x78AB
in the dictionary and find a match at 0x , because it has the prefix bit
set. Now 0x is IMMEDIATE and at execution find >IN pointing just past
0x, ready to parse the number.
The whole mechanism adds two lines in INTERPRET.

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

#20256

On 04/03/2013 19:27, Albert van der Horst wrote:
> In article <kh2hvp$lnd$1@dont-email.me>,
> Gerry Jackson  <gerry@jackson9000.fsnet.co.uk> wrote:
>> On 04/03/2013 12:47, Albert van der Horst wrote:
>>> In article <kh1upe$939$1@dont-email.me>,
>>> Gerry Jackson  <gerry@jackson9000.fsnet.co.uk> wrote:
>>>> On 04/03/2013 09:41, Andrew Haley wrote:
>>>> [...]
>>>>
>>>>> I take that point.  Recognizers seem to me to be a far more sensible
>>>>> idea than state-smartness, however it's achieved.  I wonder if the
>>>>> term "recognizer" isn't helping here, because it sounds like such a
>>>>> big deal.  As I understand the idea, it's just a way to add a word to
>>>>> parse a literal and another word to compile the result.
>>>>>
>>>>
>>>> As I understand it recognizers (I prefer to spell it recognisers) can be
>>>> more than that. If implemented as a recognizer stack which can be
>>>> manipulated by the user in much the same way as the search order (which
>>>> GForth does I think) then the concept becomes more powerful. For example:
>>>>
>>>> - a number recognizer could be above a word recogniser so that numbers
>>>> can be handled before a dictionary search to avoid wasting time when
>>>> compiling a lot of numbers
>>>>
>>>> - a user definition written as a recognizer can use standard parsing
>>>> words on the input source, removes the need for something like GForths
>>>> EXECUTE-PARSING-FILE.
>>>>
>>>> - [IF] can be written as a recognizer where coding is much simpler than
>>>> the example given in the ANS Forth standard, including nesting of [IF]s
>>>>
>>>> - a user can write an error handler for the text interpreter
>>>>
>>>> If such a recognizer stack is used I agree a better name than recognizer
>>>> is needed.
>>>
>>> Stack? YET ANOTHER STACK?
>>
>> Yas. Well if that offends you, call it a list.
>>>
>>> My prefixes work the way you intend, using only the normal rules
>>> of search order.
>>
>> Why do you mention that? I never mentioned prefixes or said you couldn't
>> do that. I imagine that other Forth systems that handle prefixes do the
>> same as you.
>
> Prefixes are the recognizers Anton talks about. Only with me they are
> just Forth words, that are found in the dictionary.
> Look up
>      0x78AB
> in the dictionary and find a match at 0x , because it has the prefix bit
> set. Now 0x is IMMEDIATE and at execution find >IN pointing just past
> 0x, ready to parse the number.
> The whole mechanism adds two lines in INTERPRET.
>

How does ciforth handle the case where BASE is set to 36 and the 
programmer wants to input a base 36 number 0x78AB or 0x78ab or 0X78AB?

Can a ciforth user define a new prefix e.g. i# for a complex number, 
without delving into the guts of ciforth?

-- 
Gerry

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

#20280

On Mar 4, 8:46 pm, Gerry Jackson <ge...@jackson9000.fsnet.co.uk>
wrote:
> On 04/03/2013 19:27, Albert van der Horst wrote:
>
>
>
>
>
>
>
>
>
> > In article <kh2hvp$ln...@dont-email.me>,
> > Gerry Jackson  <ge...@jackson9000.fsnet.co.uk> wrote:
> >> On 04/03/2013 12:47, Albert van der Horst wrote:
> >>> In article <kh1upe$93...@dont-email.me>,
> >>> Gerry Jackson  <ge...@jackson9000.fsnet.co.uk> wrote:
> >>>> On 04/03/2013 09:41, Andrew Haley wrote:
> >>>> [...]
>
> >>>>> I take that point.  Recognizers seem to me to be a far more sensible
> >>>>> idea than state-smartness, however it's achieved.  I wonder if the
> >>>>> term "recognizer" isn't helping here, because it sounds like such a
> >>>>> big deal.  As I understand the idea, it's just a way to add a word to
> >>>>> parse a literal and another word to compile the result.
>
> >>>> As I understand it recognizers (I prefer to spell it recognisers) can be
> >>>> more than that. If implemented as a recognizer stack which can be
> >>>> manipulated by the user in much the same way as the search order (which
> >>>> GForth does I think) then the concept becomes more powerful. For example:
>
> >>>> - a number recognizer could be above a word recogniser so that numbers
> >>>> can be handled before a dictionary search to avoid wasting time when
> >>>> compiling a lot of numbers
>
> >>>> - a user definition written as a recognizer can use standard parsing
> >>>> words on the input source, removes the need for something like GForths
> >>>> EXECUTE-PARSING-FILE.
>
> >>>> - [IF] can be written as a recognizer where coding is much simpler than
> >>>> the example given in the ANS Forth standard, including nesting of [IF]s
>
> >>>> - a user can write an error handler for the text interpreter
>
> >>>> If such a recognizer stack is used I agree a better name than recognizer
> >>>> is needed.
>
> >>> Stack? YET ANOTHER STACK?
>
> >> Yas. Well if that offends you, call it a list.
>
> >>> My prefixes work the way you intend, using only the normal rules
> >>> of search order.
>
> >> Why do you mention that? I never mentioned prefixes or said you couldn't
> >> do that. I imagine that other Forth systems that handle prefixes do the
> >> same as you.
>
> > Prefixes are the recognizers Anton talks about. Only with me they are
> > just Forth words, that are found in the dictionary.
> > Look up
> >      0x78AB
> > in the dictionary and find a match at 0x , because it has the prefix bit
> > set. Now 0x is IMMEDIATE and at execution find >IN pointing just past
> > 0x, ready to parse the number.
> > The whole mechanism adds two lines in INTERPRET.
>
> How does ciforth handle the case where BASE is set to 36 and the
> programmer wants to input a base 36 number 0x78AB or 0x78ab or 0X78AB?

The mechanism I use is a cascade of conversions. 0x78ab would be
converted base 36, and not recognised as the hex number 0x78ab, as the
base 36 successful conversion comes first.

>
> Can a ciforth user define a new prefix e.g. i# for a complex number,
> without delving into the guts of ciforth?

Again, for my Forth, it's simply a case of adding a words with the
signature ( addr len -- double ) to a list of "recognisers". If it
can't convert, it THROWs and the next "recogniser" is tried.

This is quite different from ciforth's mechanism of prefixes in a
dictionary. I suspect 0x78ab only has one interpretation; that of a
base 16 number, and that 0xdefg would be an error.

>
> --
> Gerry

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

#20288

In article <kh3158$mtp$1@dont-email.me>,
Gerry Jackson  <gerry@jackson9000.fsnet.co.uk> wrote:
>On 04/03/2013 19:27, Albert van der Horst wrote:
>> In article <kh2hvp$lnd$1@dont-email.me>,
>> Gerry Jackson  <gerry@jackson9000.fsnet.co.uk> wrote:
>>> On 04/03/2013 12:47, Albert van der Horst wrote:
>>>> In article <kh1upe$939$1@dont-email.me>,
>>>> Gerry Jackson  <gerry@jackson9000.fsnet.co.uk> wrote:
>>>>> On 04/03/2013 09:41, Andrew Haley wrote:
>>>>> [...]
>>>>>
>>>>>> I take that point.  Recognizers seem to me to be a far more sensible
>>>>>> idea than state-smartness, however it's achieved.  I wonder if the
>>>>>> term "recognizer" isn't helping here, because it sounds like such a
>>>>>> big deal.  As I understand the idea, it's just a way to add a word to
>>>>>> parse a literal and another word to compile the result.
>>>>>>
>>>>>
>>>>> As I understand it recognizers (I prefer to spell it recognisers) can be
>>>>> more than that. If implemented as a recognizer stack which can be
>>>>> manipulated by the user in much the same way as the search order (which
>>>>> GForth does I think) then the concept becomes more powerful. For example:
>>>>>
>>>>> - a number recognizer could be above a word recogniser so that numbers
>>>>> can be handled before a dictionary search to avoid wasting time when
>>>>> compiling a lot of numbers
>>>>>
>>>>> - a user definition written as a recognizer can use standard parsing
>>>>> words on the input source, removes the need for something like GForths
>>>>> EXECUTE-PARSING-FILE.
>>>>>
>>>>> - [IF] can be written as a recognizer where coding is much simpler than
>>>>> the example given in the ANS Forth standard, including nesting of [IF]s
>>>>>
>>>>> - a user can write an error handler for the text interpreter
>>>>>
>>>>> If such a recognizer stack is used I agree a better name than recognizer
>>>>> is needed.
>>>>
>>>> Stack? YET ANOTHER STACK?
>>>
>>> Yas. Well if that offends you, call it a list.
>>>>
>>>> My prefixes work the way you intend, using only the normal rules
>>>> of search order.
>>>
>>> Why do you mention that? I never mentioned prefixes or said you couldn't
>>> do that. I imagine that other Forth systems that handle prefixes do the
>>> same as you.
>>
>> Prefixes are the recognizers Anton talks about. Only with me they are
>> just Forth words, that are found in the dictionary.
>> Look up
>>      0x78AB
>> in the dictionary and find a match at 0x , because it has the prefix bit
>> set. Now 0x is IMMEDIATE and at execution find >IN pointing just past
>> 0x, ready to parse the number.
>> The whole mechanism adds two lines in INTERPRET.
>>
>
>How does ciforth handle the case where BASE is set to 36 and the
>programmer wants to input a base 36 number 0x78AB or 0x78ab or 0X78AB?

The numbers with lower case are rejected as not a proper numbers.
0X78AB is handled as follows:
In the ONLY wordlist there is a prefix 0
: 0
    \ Backup to point at the digit 0, this way 1..9 can be aliases
    -1 >IN +!
    (NUMBER)    \ DO the usual with decimal point etc.
    POSTPONE SDLITERAL  \ SLITERAL or DLITERAL
; PREFIX IMMEDIATE
If 0X78AB is not found until encountering the word  0 in ONLY,
then this word 0  is executed.

Had you created
"
: 0X  BASE @ >R   HEX (NUMBER) POSTPONE LITERAL R> BASE ! ;
PREFIX IMMEDIATE
"
it would take precedence, provided it is earlier in the search order
and the 0X78AB would be interpreted as a hex number.
If 0X is in a vocabulary that is not in the search order, 0X78AB
will be rejected as ERROR # 10 : NOT A WORD OR NUMBER

>
>Can a ciforth user define a new prefix e.g. i# for a complex number,
>without delving into the guts of ciforth?

That is exactly the point!

Let's say we want to have a notation
    i#123.E+4#-3.1456E0
Assume atof parses things like 123.E+4  and -3.1456E0

NAMESPACE ZLIB   \ A NAMESPACE is a wordlist with a name.

ZLIB     CONTEXT @      DEFINITIONS
   : Bessel ... ;
   : Complex_Bessel ... ;
   : i#
       NAME   \ S: "123.E+4#-3.1456E0"
       &#     \ S: "123.E+4#-3.1456E0" 0x35
       $/     \ S: "-3.1456E0"  "123.E+4"
       atof atof \ S: -  F: 123.E+4 -3.1456E0
   ...
   ; PREFIX IMMEDIATE
CONTEXT !   PREVIOUS

The complex number notation is understood if and only if
ZLIB is in the search order.
-- 
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]

#20301

On 05/03/2013 12:17, Albert van der Horst wrote:
> In article <kh3158$mtp$1@dont-email.me>,
> Gerry Jackson  <gerry@jackson9000.fsnet.co.uk> wrote:
>> On 04/03/2013 19:27, Albert van der Horst wrote:
>>> In article <kh2hvp$lnd$1@dont-email.me>,

[...]

>>>>>
>>>>> My prefixes work the way you intend, using only the normal rules
>>>>> of search order.
>>>>
>>>> Why do you mention that? I never mentioned prefixes or said you couldn't
>>>> do that. I imagine that other Forth systems that handle prefixes do the
>>>> same as you.
>>>
>>> Prefixes are the recognizers Anton talks about. Only with me they are
>>> just Forth words, that are found in the dictionary.
>>> Look up
>>>       0x78AB
>>> in the dictionary and find a match at 0x , because it has the prefix bit
>>> set. Now 0x is IMMEDIATE and at execution find >IN pointing just past
>>> 0x, ready to parse the number.
>>> The whole mechanism adds two lines in INTERPRET.
>>>
>>
>> How does ciforth handle the case where BASE is set to 36 and the
>> programmer wants to input a base 36 number 0x78AB or 0x78ab or 0X78AB?
>
> The numbers with lower case are rejected as not a proper numbers.
> 0X78AB is handled as follows:
> In the ONLY wordlist there is a prefix 0
> : 0
>      \ Backup to point at the digit 0, this way 1..9 can be aliases
>      -1 >IN +!
>      (NUMBER)    \ DO the usual with decimal point etc.
>      POSTPONE SDLITERAL  \ SLITERAL or DLITERAL
> ; PREFIX IMMEDIATE
> If 0X78AB is not found until encountering the word  0 in ONLY,
> then this word 0  is executed.
>
> Had you created
> "
> : 0X  BASE @ >R   HEX (NUMBER) POSTPONE LITERAL R> BASE ! ;
> PREFIX IMMEDIATE
> "
> it would take precedence, provided it is earlier in the search order
> and the 0X78AB would be interpreted as a hex number.
> If 0X is in a vocabulary that is not in the search order, 0X78AB
> will be rejected as ERROR # 10 : NOT A WORD OR NUMBER
>
>>
>> Can a ciforth user define a new prefix e.g. i# for a complex number,
>> without delving into the guts of ciforth?
>
> That is exactly the point!
>
> Let's say we want to have a notation
>      i#123.E+4#-3.1456E0
> Assume atof parses things like 123.E+4  and -3.1456E0
>
> NAMESPACE ZLIB   \ A NAMESPACE is a wordlist with a name.
>
> ZLIB     CONTEXT @      DEFINITIONS
>     : Bessel ... ;
>     : Complex_Bessel ... ;
>     : i#
>         NAME   \ S: "123.E+4#-3.1456E0"
>         &#     \ S: "123.E+4#-3.1456E0" 0x35
>         $/     \ S: "-3.1456E0"  "123.E+4"
>         atof atof \ S: -  F: 123.E+4 -3.1456E0
>     ...
>     ; PREFIX IMMEDIATE
> CONTEXT !   PREVIOUS
>
> The complex number notation is understood if and only if
> ZLIB is in the search order.
>

I see, ciforth is clearly non-standard in several respects then
e.g. 0X78AB is a valid base 34, 35 or 36 integer in ANS Forth yet your 
explanation implies it would be recognised as a hex number.


-- 
Gerry

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

#20303

In article <5135e271$0$26892$e4fe514c@dreader37.news.xs4all.nl>,
Albert van der Horst <albert@spenarnc.xs4all.nl> wrote:
<SNIP>
>
>Let's say we want to have a notation
>    i#123.E+4#-3.1456E0
>Assume atof parses things like 123.E+4  and -3.1456E0
>
>NAMESPACE ZLIB   \ A NAMESPACE is a wordlist with a name.
>
>ZLIB     CONTEXT @      DEFINITIONS
>   : Bessel ... ;
>   : Complex_Bessel ... ;
>   : i#
>       NAME   \ S: "123.E+4#-3.1456E0"
>       &#     \ S: "123.E+4#-3.1456E0" 0x35
>       $/     \ S: "-3.1456E0"  "123.E+4"
>       atof atof \ S: -  F: 123.E+4 -3.1456E0
>   ...
>   ; PREFIX IMMEDIATE
>CONTEXT !   PREVIOUS

Should be CURRENT @ ... CURRENT !
>
>The complex number notation is understood if and only if
>ZLIB is in the search order.
>--
>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
>
-- 
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]

#20297

On 05/03/2013 08:19, Alex McDonald wrote:
> On Mar 4, 8:46 pm, Gerry Jackson <ge...@jackson9000.fsnet.co.uk>
> wrote:
>> On 04/03/2013 19:27, Albert van der Horst wrote:
[...]
>>> Prefixes are the recognizers Anton talks about. Only with me they are
>>> just Forth words, that are found in the dictionary.
>>> Look up
>>>       0x78AB
>>> in the dictionary and find a match at 0x , because it has the prefix bit
>>> set. Now 0x is IMMEDIATE and at execution find >IN pointing just past
>>> 0x, ready to parse the number.
>>> The whole mechanism adds two lines in INTERPRET.
>>
>> How does ciforth handle the case where BASE is set to 36 and the
>> programmer wants to input a base 36 number 0x78AB or 0x78ab or 0X78AB?
>
> The mechanism I use is a cascade of conversions. 0x78ab would be
> converted base 36, and not recognised as the hex number 0x78ab, as the
> base 36 successful conversion comes first.
>
>>
>> Can a ciforth user define a new prefix e.g. i# for a complex number,
>> without delving into the guts of ciforth?
>
> Again, for my Forth, it's simply a case of adding a words with the
> signature ( addr len -- double ) to a list of "recognisers". If it
> can't convert, it THROWs and the next "recogniser" is tried.
>

Yes that is the method I will add to my system except that I don't see 
that a THROW is necesssary - possibly because I haven't done it yet.
In my first post I was trying to make the point that if the user can 
control the order in which recognisers are tried the order given in the 
standard text interpreter can be usefully overridden.

> This is quite different from ciforth's mechanism of prefixes in a
> dictionary. I suspect 0x78ab only has one interpretation; that of a
> base 16 number, and that 0xdefg would be an error.

Well it's a moot point given that the Forth 200X prefix for hex numbers 
will be $. The ciforth approach to prefixes as given in Albert's reply 
is totally non-standard anyway. The Forth standard accepts leading 0's 
as part of an integer input.

-- 
Gerry

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

#20302

On Tue, 5 Mar 2013, Gerry Jackson wrote:

> Well it's a moot point given that the Forth 200X prefix for hex numbers will 
> be $. The ciforth approach to prefixes as given in Albert's reply is totally 
> non-standard anyway. The Forth standard accepts leading 0's as part of an 
> integer input.

Actually, to continue the 0x metaphor, a leading zer0 generally indicates 
an octal constant.  MiniForth recognizes the $hex as well as 0x for base 
override in hex, but a leading zero has historically implied octal ... not 
strictly in accordance with the Forth standard, but if you add extensions, 
they should generally work as expected ... or at least be well documented. 
Tcl for example has a well known "feature" regarding time conversion with 
leading zeros passed to clock owing to literal conversion rules.

ok 0100 .
64 ok

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

#20305

Rob Sciuk <rob@controlq.com> writes:
>Actually, to continue the 0x metaphor, a leading zer0 generally indicates 
>an octal constant.  MiniForth recognizes the $hex as well as 0x for base 
>override in hex, but a leading zero has historically implied octal

What generality?  What history?  AFAIK in Unix and C a leading 0
indicates octal, but I have not come across that (IMO bad) idea
elsewhere.  IIRC the 6502 assembler used the prefix & for octal.

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

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

#20307

On Tue, 5 Mar 2013, Anton Ertl wrote:

> Date: Tue, 05 Mar 2013 17:57:25 GMT
> From: Anton Ertl <anton@mips.complang.tuwien.ac.at>
> Newsgroups: comp.lang.forth
> Subject: Re: MiniForth 0.1.18 has just been released ...
> 
> Rob Sciuk <rob@controlq.com> writes:
>> Actually, to continue the 0x metaphor, a leading zer0 generally indicates
>> an octal constant.  MiniForth recognizes the $hex as well as 0x for base
>> override in hex, but a leading zero has historically implied octal
>
> What generality?  What history?  AFAIK in Unix and C a leading 0
> indicates octal, but I have not come across that (IMO bad) idea
> elsewhere.  IIRC the 6502 assembler used the prefix & for octal.
>
> - anton

In my estimation, C is common practice, whereas the 6502 is a footnote in 
history ...

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

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

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

csiph-web