Hi!

Has anyone ever experimented with adding additional recognizers in the
main Forth loop?

Traditionally (as I understand it) a word coming on the input stream
is checked against the dictionary. If it doesn't match any words, it's
sent to NUMBER (a recognizer) instead. If it's not a number then you
get a syntax error. However... What if you could plug in additional
checkers after NUMBER (or before, I'm not picky). Then you could do
REBOL style tricks like handle dates as first class data types. E.g.,

ok> : DATE  ( string -- y m d t | string f) 
  >   dup " /" swap string-find  if date-convert true else false then
;
ok> ' DATE parse-install
ok> 2003/07/04  .s
2003 7 4

Or, maybe another thing would be to compose something like Lisp style
macros on the fly... I was thinking of something like this for object
property access:

ok> : OBJECT-PROPERTY  ( string -- property object t | string f)
  >    dup " ::" swap string-find  
  >    if  object-reference-explode true  else  false  then ;
ok> ' OBJECT-PROPERTY parse-install
ok> class: Test  property: Charm 12 ;property ;class
ok> new Test  .s
<object of type 'Test'>
ok> constant test-object
ok> test-object::Charm .s
"Charm" <address of 'test-object'>
ok> test-object::Charm o@ .
12
ok> 73 test-object::Charm o!

Actually, a better macro thing would actually rewrite the object
reference as code (perhaps thisForth does something like this?):

ok> : OBJECT-PROPERTY  ( string -- t | string f)
  >    dup " ::" swap string-find 
  >    if  object-reference-decode-back-to-input-stream true  
  >    else  false then ;

This one doesn't actually put anything on the stack, it rewrites the
stream as required, so:

ok> test-object::Charm o?

Rewrites to:

ok> " Charm" test-object o?

With the stream pointer reset as needed.

Anyway, you get the idea. Basically it would let you have your cake
(simple Forth syntax and implementation) and eat it too (flexible
parsing of compound names). I don't think that it really implies too
much overhead, even on a simple system, since you're never really
using it except when loading source code or dealing with the
interactive commmand line. The main problem I can see is that you're
going a bit abstract, but many modern Forths use peephole optimizers
and hardwired cliche's and I don't know what all else, so I don't see
this as being too big a deal either.

I'm working with a system where I have users used to Python object
access syntax. I'd like to maintain that same interface for them,
which is why I came around to this idea.

Any comments?

Thanks!

Jos'h

"oofoe" <joshfuller@operamail.com> wrote in message 
news:45577133.0307011429.7d7f9213@posting.google.com...
> Hi!
>
> Has anyone ever experimented with adding additional recognizers in the
> main Forth loop?
>
> Traditionally (as I understand it) a word coming on the input stream
> is checked against the dictionary. If it doesn't match any words, it's
> sent to NUMBER (a recognizer) instead. If it's not a number then you
> get a syntax error. However... What if you could plug in additional
> checkers after NUMBER (or before, I'm not picky). Then you could do
> REBOL style tricks like handle dates as first class data types. E.g.,

    This is how I handle strings and undefined words in Quest32.  I think it 
would be hard to do in a "standard" way though.

-- 

-GJC
-Software Consultant (Embedded systems and Real Time Controls)
-gchanson@mvps.org

-War is the last resort of the incompetent.

Gary Chanson wrote:
> 
> "oofoe" <joshfuller@operamail.com> wrote in message
> news:45577133.0307011429.7d7f9213@posting.google.com...
> > Hi!
> >
> > Has anyone ever experimented with adding additional recognizers in the
> > main Forth loop?
> >
> > Traditionally (as I understand it) a word coming on the input stream
> > is checked against the dictionary. If it doesn't match any words, it's
> > sent to NUMBER (a recognizer) instead. If it's not a number then you
> > get a syntax error. However... What if you could plug in additional
> > checkers after NUMBER (or before, I'm not picky). Then you could do
> > REBOL style tricks like handle dates as first class data types. E.g.,
> 
>     This is how I handle strings and undefined words in Quest32.  I think it
> would be hard to do in a "standard" way though.
> 
> --
> 
> -GJC
> -Software Consultant (Embedded systems and Real Time Controls)
> -gchanson@mvps.org
> 
> -War is the last resort of the incompetent.

Isn't that basically how floating-point extensions are implemented? If I
remember what I did, I trapped the '?' routine in the compiler of one
Forth to deal with FP after adding a slooow calculator chip to my Z-80
hardware.

Jerry
-- 
Engineering is the art of making what you want from things you can get.
�����������������������������������������������������������������������

"oofoe" <joshfuller@operamail.com> wrote in message
news:45577133.0307011429.7d7f9213@posting.google.com...
> Hi!
>
> Has anyone ever experimented with adding additional recognizers in the
> main Forth loop?
>
> Traditionally (as I understand it) a word coming on the input stream
> is checked against the dictionary. If it doesn't match any words, it's
> sent to NUMBER (a recognizer) instead. If it's not a number then you
> get a syntax error. However... What if you could plug in additional
> checkers after NUMBER (or before, I'm not picky). Then you could do
> REBOL style tricks like handle dates as first class data types. E.g.,
>
> ok> : DATE  ( string -- y m d t | string f)
>   >   dup " /" swap string-find  if date-convert true else false then
> ;
> ok> ' DATE parse-install
> ok> 2003/07/04  .s
> 2003 7 4
>
> Or, maybe another thing would be to compose something like Lisp style
> macros on the fly... I was thinking of something like this for object
> property access:
>
> ok> : OBJECT-PROPERTY  ( string -- property object t | string f)
>   >    dup " ::" swap string-find
>   >    if  object-reference-explode true  else  false  then ;
> ok> ' OBJECT-PROPERTY parse-install
> ok> class: Test  property: Charm 12 ;property ;class
> ok> new Test  .s
> <object of type 'Test'>
> ok> constant test-object
> ok> test-object::Charm .s
> "Charm" <address of 'test-object'>
> ok> test-object::Charm o@ .
> 12
> ok> 73 test-object::Charm o!
>
> Actually, a better macro thing would actually rewrite the object
> reference as code (perhaps thisForth does something like this?):
>
> ok> : OBJECT-PROPERTY  ( string -- t | string f)
>   >    dup " ::" swap string-find
>   >    if  object-reference-decode-back-to-input-stream true
>   >    else  false then ;
>
> This one doesn't actually put anything on the stack, it rewrites the
> stream as required, so:
>
> ok> test-object::Charm o?
>
> Rewrites to:
>
> ok> " Charm" test-object o?
>
> With the stream pointer reset as needed.
>
> Anyway, you get the idea. Basically it would let you have your cake
> (simple Forth syntax and implementation) and eat it too (flexible
> parsing of compound names). I don't think that it really implies too
> much overhead, even on a simple system, since you're never really
> using it except when loading source code or dealing with the
> interactive commmand line. The main problem I can see is that you're
> going a bit abstract, but many modern Forths use peephole optimizers
> and hardwired cliche's and I don't know what all else, so I don't see
> this as being too big a deal either.
>
> I'm working with a system where I have users used to Python object
> access syntax. I'd like to maintain that same interface for them,
> which is why I came around to this idea.
>
> Any comments?
>
> Thanks!
>
> Jos'h

Win32Forth has a list of recognisers that can be added to and subtracted
from; the list of words is executed until one of them recognises and deals
with the word. This is used for Windows constants, which are looked up in an
external DLL; for loating point; for non-standard numbers such as 0x1234.

-- 
Regards
Alex McDonald

oofoe wrote:

> Has anyone ever experimented with adding additional recognizers in the
> main Forth loop?

Yes.  For example, Pygmy Forth checks for characters, preceded by a '. 
   You can add anything you like into the interpreter of many Forth 
systems.  But unfortunately there's no standard way to do it.  So you 
can study your own Forth system and see how to do it but you can't do it 
portably, switch to another Forth and you'll have to figure out how to 
do it there.  And your code that does that won't be portable, you can't 
run it on any other Forth system until you figure out how to.

This isn't a terrible thing but it's enough of an inconvenience that I 
don't see a lot of code that uses such things.

My Pygmy code that has $ in front of hex numbers and ' in front of 
character literals is less portable than it could be, because of that.

Alex McDonald wrote:

> "oofoe" <joshfuller@operamail.com> wrote in message
> news:45577133.0307011429.7d7f9213@posting.google.com...
> 
>>Hi!
>>
>>Has anyone ever experimented with adding additional recognizers in the
>>main Forth loop?
....
> 
> 
> Win32Forth has a list of recognisers that can be added to and subtracted
> from; the list of words is executed until one of them recognises and deals
> with the word. This is used for Windows constants, which are looked up in an
> external DLL; for loating point; for non-standard numbers such as 0x1234.

SwiftForth has a similar mechanism, also used for Windows constants,
floating point, and SWOOP objects (among other things).  As Gary
points out, it's straightforward to do as a system implementor, but
far from being standardizable.

Cheers,
Elizabeth

-- 
==================================================
Elizabeth D. Rather   (US & Canada)   800-55-FORTH
FORTH Inc.                         +1 310-491-3356
5155 W. Rosecrans Ave. #1018  Fax: +1 310-978-9454
Hawthorne, CA 90250
http://www.forth.com

"Forth-based products and Services for real-time
applications since 1973."
==================================================

oofoe wrote:
> 
> jonah thomas <j2thomas@cavtel.net> wrote in message news:<3F021FCA.7060700@cavtel.net>...
> > oofoe wrote:
> >
> > systems.  But unfortunately there's no standard way to do it.  So you
> 
> That's interesting. Pretty much everybody has said, basically, "yes,
> we do it, it's useful... and it's nonstandard." Perhaps this is
> something that should be standardized, or at least 'guideline-ized'.
> It seems to me that it can make a big difference in the usability and
> friendliness of the language. Obviously, it violates the idea of the
> 'pure' interpreter, where the only exceptions are numbers. However, if
> it violates the 'pure' (Brodie!) model, it at least does it in an
> orthagonal and extendable way.

  ...
> 
The problem is that the right way to hook into the the compiler depends
on the implementation, and that making any mechanism standard dictates
how part of the compile is to be implemented. I think that asking
providers to document how it is best done with their particular Forth is
the most that it is reasonable to request.

Jerry
-- 
Engineering is the art of making what you want from things you can get.
�����������������������������������������������������������������������

oofoe wrote:
> 
> Hi!
> 
> Has anyone ever experimented with adding additional recognizers in the
> main Forth loop?
> 
> Traditionally (as I understand it) a word coming on the input stream
> is checked against the dictionary. If it doesn't match any words, it's
> sent to NUMBER (a recognizer) instead. If it's not a number then you
> get a syntax error. However... What if you could plug in additional
> checkers after NUMBER (or before, I'm not picky). Then you could do
> REBOL style tricks like handle dates as first class data types. E.g.,
> 
> ok> : DATE  ( string -- y m d t | string f)
>   >   dup " /" swap string-find  if date-convert true else false then
> ;
> ok> ' DATE parse-install
> ok> 2003/07/04  .s
> 2003 7 4
> 
> Or, maybe another thing would be to compose something like Lisp style
> macros on the fly... I was thinking of something like this for object
> property access:
> 
> ok> : OBJECT-PROPERTY  ( string -- property object t | string f)
>   >    dup " ::" swap string-find
>   >    if  object-reference-explode true  else  false  then ;
> ok> ' OBJECT-PROPERTY parse-install
> ok> class: Test  property: Charm 12 ;property ;class
> ok> new Test  .s
> <object of type 'Test'>
> ok> constant test-object
> ok> test-object::Charm .s
> "Charm" <address of 'test-object'>
> ok> test-object::Charm o@ .
> 12
> ok> 73 test-object::Charm o!
> 
> Actually, a better macro thing would actually rewrite the object
> reference as code (perhaps thisForth does something like this?):
> 
> ok> : OBJECT-PROPERTY  ( string -- t | string f)
>   >    dup " ::" swap string-find
>   >    if  object-reference-decode-back-to-input-stream true
>   >    else  false then ;
> 
> This one doesn't actually put anything on the stack, it rewrites the
> stream as required, so:
> 
> ok> test-object::Charm o?
> 
> Rewrites to:
> 
> ok> " Charm" test-object o?
> 
> With the stream pointer reset as needed.
> 
> Anyway, you get the idea. Basically it would let you have your cake
> (simple Forth syntax and implementation) and eat it too (flexible
> parsing of compound names). I don't think that it really implies too
> much overhead, even on a simple system, since you're never really
> using it except when loading source code or dealing with the
> interactive commmand line. The main problem I can see is that you're
> going a bit abstract, but many modern Forths use peephole optimizers
> and hardwired cliche's and I don't know what all else, so I don't see
> this as being too big a deal either.
> 
> I'm working with a system where I have users used to Python object
> access syntax. I'd like to maintain that same interface for them,
> which is why I came around to this idea.
> 
> Any comments?
> 
> Thanks!
> 
> Jos'h

Why not just use EVALUATE ? That _is_ portable.

-- 
Julian V. Noble
Professor Emeritus of Physics
jvn@spamfree.virginia.edu
    ^^^^^^^^^
http://galileo.phys.virginia.edu/~jvn/

   "Science knows only one commandment: contribute to science."
   -- Bertolt Brecht, "Galileo".

oofoe wrote:
> jonah thomas <j2thomas@cavtel.net> wrote
>>oofoe wrote:

>>systems.  But unfortunately there's no standard way to do it.  So you 

> That's interesting. Pretty much everybody has said, basically, "yes,
> we do it, it's useful... and it's nonstandard." Perhaps this is
> something that should be standardized, or at least 'guideline-ized'.

I remember the subject coming up late in the standards effort.  No doubt 
it had come up early also.  The time I remember, a senior member of the 
committe said something very much like, "If a junior member of my apps 
team told me he needed to change the interpreter I'd tell him he needed 
to look for a job.".

I didn't ask in detail, but the implication I took from it was that 
standard code should expect to run on a standard interpreter and should 
expect to have a standard interpreter to run on.  When the point of the 
standard is to encourage portability of code, this makes very good sense.

The standard says nothing about how the interpreter actually operates, 
but it makes sense that it should first parse a word, then find the word 
in the dictionary if it's there, then interpret it as a number, and then 
do whatever else it does.  So it makes sense to me that you should be 
able to add an xt after the number interpreter, that receives a number 
and count for a word, and that does whatever you want.

Something like:

ADD-TO-INTERPRETER ( xt -- ) execute xt when the interpreter cannot 
interpret a string.  xt should do

( c-addr n -- c-addr n 0 | i*n true )

This means, if the routine fails to interpret the string it returns the 
original string with a false flag.

If the routine succeeds, it returns whatever it returns on the stack and 
also returns a true flag.  The interpreter will leave all but the true 
flag on the stack for later interpreted words to act on.


PRISTINE-INTERPRETER ( -- ) remove all modifications, leaving a standard
     interpreter.
RESTORE-INTERPRETER ( -- ) return the interpreter to its state before
    the last change to the interpreter was made, either by
    ADD-TO-INTERPRETER OR BY PRISTINE-INTERPRETER .

So you could always get a standard interpreter and restore whatever the 
user is used to when you're done.

You could first get a standard interpreter and then add the specific 
changes you need, and restore it to the previous state by repeated 
PRISTINE-INTERPRETER .

There should be some limits to what a system that claims to implement 
this should be required to do.  Perhaps a maximum of 8 xt's added, and 
perhaps a maximum nesting of 8 changed states.  You could reduce the 
chance that you'd reach the limit by creating a single word that does 
all the interpreting you want, so you can provide a single xt to the system.

My first thought for implementing the saving-restoring would be like the 
usual way for exceptions.  Store the old values on the return stack 
along with the return-stack location for the next oldest values, and 
store the new resturn-stack value in some defined place in memory.

But you'd have to clear the state before you do any return-stack 
operations that are under it.  So if you did it inside a command you'd 
have to undo it inside the same command.  And some systems might use the 
return stack doing blocks or files etc.  So it might not always work.

You could have an array of 64 execution tokens, and maybe 8 counts. 
You'd only check one line of them when the interpreter had otherwise 
already failed.

I don't see why this would be hard to implement but the details would 
have to vary from system to system.

If we were considering changes to the stanadard this would probably be a 
candidate for the Tools Extension wordset.

---------------

Now I'll present a second method.

Since a standard system is allowed to do anything at all after an input 
string has failed to be found in the dictionary and failed to be parsed 
as a number, the system doesn't become less standard when a new parsing 
method is added after number.

And if you get to add your own method at the beginning of the extra 
methods, then your code won't be bothered by other methods added 
previously.  If your method catches it then fine.  If your method does 
not catch it then you have a problem anyway.

So you could have just ADD-TO-INTERPRETER and have it become the first 
method, and you can ignore any other new methods.

And for utter simplicity we could allow say 8 new methods total, and if 
you want to eliminate all of them you just do ' NOOP ADD-TO-INTERPRETER 
8 times and you're guaranteed to clear everything out.

This doesn't have quite the functionality of the first suggestion, you 
can't always restore a previous state.  But it's extremely simple, easy 
to implement and easy to use.

------------

Now here's a third method.

Have a single data-space location that holds an xt.  You can @ or ! to 
that location.  You can save the old state by @ing the value and 
restoring it later.  You can add your new extension either with

:NONAME
    ['] new-xt EXECUTE 0= IF
      ['] old-xt EXECUTE ELSE
      TRUE THEN
; location !

Or put them in the opposite order.

There's no limit to the number of extensions you can add.

You could get the address to put the xt with the environment string 
+INTERPRETER which would return ( false | a-addr true )

I expect various Forths have an address like this, but they give them 
different names.  This would provide a standard way to get the address 
independent of the names.
-------------

So here are three approaches.  I expect others can come up with 
something even better.

Julian V. Noble schrieb:
> oofoe wrote:
> 
>>Hi!
>>
>>Has anyone ever experimented with adding additional recognizers in the
>>main Forth loop?
>>
>>Traditionally (as I understand it) a word coming on the input stream
>>is checked against the dictionary. If it doesn't match any words, it's
>>sent to NUMBER (a recognizer) instead. If it's not a number then you
>>get a syntax error. However... What if you could plug in additional
>>checkers after NUMBER (or before, I'm not picky). Then you could do
>>REBOL style tricks like handle dates as first class data types. E.g.,
>>
>>ok> : DATE  ( string -- y m d t | string f)
>>  >   dup " /" swap string-find  if date-convert true else false then
>>;
>>ok> ' DATE parse-install
>>ok> 2003/07/04  .s
>>2003 7 4
>>

Be reminded of the openboot habit with short "prefix<space>datasyntax",
to place a hexadecimal is as easy as writing "H# DEADBEEF". You can do
the same here, just write "AD 2003/07/04" and be sure to let your word
: AD PARSE-WORD DATE ; ... the only thing that needs inline syntax
extensions is for everything you want to teach quickly to users not
quite familiar with forth but then you'd have problems with explaining
string literal syntax anyway which is simply offensive to people of
this century...

-- guido                                               http://PFE.sf.net

> 
> So here are three approaches.  I expect others can come up with 
> something even better.
> 
Common systems mostly use some kind of "list"s for various tasks
including xt lists of hooks. Lists are the natural memorization
type of forth. The actual hook list mechanics is not standardized.
After a few dead ends, I came to use hooklists being compatible
with wordlists allowing to reuse a few procedures for that type.

-- cheers, guido                             http://PFE.sf.net

On 1 Jul 2003 15:29:06 -0700, joshfuller@operamail.com (oofoe) wrote:

>Has anyone ever experimented with adding additional recognizers in the
>main Forth loop?
>
>Traditionally (as I understand it) a word coming on the input stream
>is checked against the dictionary. If it doesn't match any words, it's
>sent to NUMBER (a recognizer) instead. If it's not a number then you
>get a syntax error. However... What if you could plug in additional
>checkers after NUMBER (or before, I'm not picky).

Mitch Bradley published an article on factoring the Forth interpreter
and compiler. I've forgotten the reference.

Nearly all fat Forths permit this in some way or other. BUT ... new
recognisers are usually very system dependent and as others have
shown, you will end up adding a significant number of standardised
words for little standardisable benefit - if you require carnal
knowledge for your recongnisers you gain very little by standardising
how you insert them.

Depending on the legacy code the system was designed to support, most
Forth systems come down to INTERPRET and/or EVALUATE. IMHO the best
solution is then:
  DEFER EVALUATE
and/or
  DEFER INTERPRET

which of course all comes down to standardising the friends of
DEFER such as IS and BEHAVIOUR. Standardising DEFER will have much
wider benefit.

Stephen

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

In article <45577133.0307011429.7d7f9213@posting.google.com>,
oofoe <joshfuller@operamail.com> wrote:

>ok> test-object::Charm o?
>
>Rewrites to:
>
>ok> " Charm" test-object o?
>
>With the stream pointer reset as needed.

Neat but writing in the input stream is not needed.
You should find and execute Charm , then find and execute test-object
(or the other way around) and leave the interpreter point after
testobject.
Much less chance of having any unpleasant side effect, and
what do you think of the user who gets the message

error on line 71 in file "pupu.fs"
       Charm"  test-object
               ^^^^^^^^^^^
ERROR #12 :   Word `` test-object '' is not known.

Leads to a lot of hear pulling, closing all editor windows, then *all*
windows, then Windows. Then to reading the manual. Yes it is there in
page 17 of appendix A.

   Some object orientation words may lead to <DESCRIBE THIS EFFECT>.
   This leads to a time loss, never to be recovered by using an
   object orientation toolkit.

<SNIP>
>
>Any comments?
You called for it.
>
>Thanks!
>
>Jos'h

Groetjes Albert.
-- 
Albert van der Horst,Oranjestr 8,3511 RA UTRECHT,THE NETHERLANDS
Q.: Where is Bin? A.: With his ma. Q.: That makes the Saudi's
terrorists, then?  A.: No, George already owns their oil.
albert@spenarnc.xs4all.nl     http://home.hccnet.nl/a.w.m.van.der.horst

Michael L Gassanenko wrote:

> Indeed interpreter hooking is needed not so much often.

> Namely, it is needed when you want to port code written
> for a different in-house standard. This mostly relates
> such literal notations as $10 #16 &1010 @100 'c' 10h
> 30-12-2002 2-12-85-06 $1234_5678_9abc_def0 1000_000_000
> and FP numbers.

> It is also useful when you want to gather some statistics about
> the code. So to say, "in meta-applications".

> Portability of this kind of stuff is not an urgent need now,
> but it would be a plus.

It isn't a need so much as an opportunity.

You could, for eample, treat dictionary words in special ways when they 
have particular prefixes or suffixes.  This could make it a bit easier 
to translate code from other languages.  It isn't something we need but 
we might have a use for it.  The difference between 0X_ABCD and 0X ABCD 
is onlyl a minor irritant.  But I see no reason not to provide a 
standard hook, if it can be done easily.

> jonah thomas wrote:

>>ADD-TO-INTERPRETER ( xt -- ) execute xt when the interpreter cannot
>>interpret a string.  xt should do

>>( c-addr n -- c-addr n 0 | i*n true )

> ( i*x c-addr n -- i*x c-addr n 0 | j*x true )

Oops!  Thank you.

>>This means, if the routine fails to interpret the string it returns the
>>original string with a false flag.

>>If the routine succeeds, it returns whatever it returns on the stack and
>>also returns a true flag.  The interpreter will leave all but the true
>>flag on the stack for later interpreted words to act on.

> There are following places that may be hooked:

> 1) after parsing the name
> 2) after searching for the name
> 3) after trying to interpret the name as a number

Those are all valuable and I was thinkng about only #3.  I suppose #2 
might be better for my purposes, then you could handle things that 
otherwise would be gobbled by #> .  You could for example get it 
established how 1.5 would be interpreted.

And #1 is better still, you could massage the string before passing it 
on to the dictionary.

I suppose you could add

0) before parsing the name

also.  Then you could for example parse Fortran or C code that lack 
spaces where Forth would want them.

Of course, the opposing argument is that it's so easy to write Forth 
interpreters, why not just make a new one?  But then we have the 
problems of restarting it on error conditions etc, all of which can be 
solved using a sufficiently fat Forth.

>>PRISTINE-INTERPRETER ( -- ) remove all modifications, leaving a standard
>>     interpreter.
>>RESTORE-INTERPRETER ( -- ) return the interpreter to its state before
>>    the last change to the interpreter was made, either by
>>    ADD-TO-INTERPRETER OR BY PRISTINE-INTERPRETER .

> A word  RESTORE-* implies presence of SAVE-* and the use of ( x1 .. xn n
> ).

That's a good way to do it.

> I would prefer a GET-* ( -- xt ) / SET-* ( xt -- ) pair.

That too.

> Now I remember what the problem with interpreter hooking was.

> 1) counted string or ( addr len ) ?

I said ( addr len ) .  My original reasoning was that it's easier for an 
implementation to do COUNT if it has a counted string and needs to 
supply stuff to a hook (and not bother if the hook is empty) than to 
create a counted string if it wasn't doing that already.

I guess the alternative argument is that if you do need a counted string 
it's easier for the implementor to provide it than for you to make it 
yourself, and you can always do COUNT if you don't need it.  And what 
you'd need it for is particularly FIND which we can't get rid of.  I 
still incline toward address-and-length but I could be persuaded.

> 2) should the hooks only convert data or also conpile/interpret them?

What new environmental dependencies would we discover if it can also 
compile/interpret?

Guido Draheim <guidod-2003-@gmx.de> wrote in message news:<bdvu71$8l0$07$1@news.t-online.com>...
> Julian V. Noble schrieb:
> > oofoe wrote:
> >>
> >>Has anyone ever experimented with adding additional recognizers in the
> >>main Forth loop?
> 
> Be reminded of the openboot habit with short "prefix<space>datasyntax",
> to place a hexadecimal is as easy as writing "H# DEADBEEF". You can do
> the same here, just write "AD 2003/07/04" and be sure to let your word
> : AD PARSE-WORD DATE ; ... the only thing that needs inline syntax

This was actually the first thing that I considered. However, it fails
during compilation:

\ Works fine!
ad 2003/07/01 .date 

\ Whoops! The date isn't compiled! 
\ If ad is 'normal', we get an error at the '2003/07/01'.
\ If ad is immediate, it's just left on the stack!
: print-a-date ad 2003/07/01 .date ;

If I want this to work correctly during compilation, then I have to
make AD an immediate word and supply an (AD) word to be compiled in. I
have done this, certainly, but it seems yucky (state smart! Ewww!)
compared to just getting the interpreter to 'do the right thing' with
the input stream. That way you get something that's directly
compilable, So...

Suppose 2003/07/01 recognizes to 2003 7 1, which can be naturally
compiled as three numeric constants. Should you not have the 'AD'
recognizer available when porting to another system, then you can
always bypass it by just specifying the year, month and day as simple
numbers. (This might be more complicated if you convert to UNIX time,
but you get the idea.)

While this might offend a purist, he doesn't have to use it --
specifying stuff in a stack friendly manner works just fine and
there's no parse overhead for him. The more casual user gains the
benefit of a more 'natural' way to express certain data. I think that
I would greatly prefer it myself, speaking as a middlin' dilletante
level Forth programmer...

> string literal syntax anyway which is simply offensive to people of

Indeed. This is primarily so that I can provide my users with a simple
and fast macro language. I don't want to have to explain things like
using '.(' outside a definition and '."' inside... I'd rather they
just use a string and then type it -- dealing with both situations in
the same general way. Pluggable recognizers let me extend the same
courtesy with respect to more interesting data types and limit the
complexity of the mental model that they'll have to build to use the
language.

Jos'h

"Michael L Gassanenko" <m_l_g3@yahoo.com> wrote in message
news:3F03C4BC.C2DDDE45@yahoo.com...

> To all: can you please tell us how your Forth does this?
>

Win32Forth:

( Generalised chain handling words )
: do-chain  / run through an execution chain, executing each xt in turn
: chain-add / add to a chain at end
: chain-add-before / add to the front of a chain
: new-chain / create a chain

new-chain        number?-chain  \ chain of number conversion options
: new-number?   ( a1 n1 f1 -- d1 TRUE | a1 n1 FALSE ) \ example number
conversion
number?-chain chain-add new-number?  \ add item in NUMBER? chain

: SUPER-NUMBER? FALSE TO DOUBLE? FALSE NUMBER?-CHAIN DO-CHAIN ;

invoked from INTERPRET (via several DEFERed words). Each number?-chain xt
has the stack signature ( a1 n1 f1 -- d1 TRUE | a1 n1 FALSE ). If (f1=TRUE),
the routine exits. If there's a FALSE, it attempts conversion. All the xt's
in the chain are executed regardless; they must check for their
predecessor's success or failure. Note the returned stack is always depth
3 -- a successful conversion returns a double number. If it's truly a
double, then the flag DOUBLE? can be set to indicate that's the case.

NUMBER, checks DOUBLE? and does either one (false) or two (true) [COMPILE]
LITERALs.

Overly complex.

-- 
Regards
Alex McDonald

oofoe schrieb:
> Guido Draheim <guidod-2003-@gmx.de> wrote in message news:<bdvu71$8l0$07$1@news.t-online.com>...
> 
>>Julian V. Noble schrieb:
>>
>>>oofoe wrote:
>>>
>>>>Has anyone ever experimented with adding additional recognizers in the
>>>>main Forth loop?
>>>
>>Be reminded of the openboot habit with short "prefix<space>datasyntax",
>>to place a hexadecimal is as easy as writing "H# DEADBEEF". You can do
>>the same here, just write "AD 2003/07/04" and be sure to let your word
>>: AD PARSE-WORD DATE ; ... the only thing that needs inline syntax
> 
> 
> This was actually the first thing that I considered. However, it fails
> during compilation:
> 
> \ Works fine!
> ad 2003/07/01 .date 
> 
> \ Whoops! The date isn't compiled! 
> \ If ad is 'normal', we get an error at the '2003/07/01'.
> \ If ad is immediate, it's just left on the stack!
> : print-a-date ad 2003/07/01 .date ;
> 
> If I want this to work correctly during compilation, then I have to
> make AD an immediate word and supply an (AD) word to be compiled in. I
> have done this, certainly, but it seems yucky (state smart! Ewww!)
> compared to just getting the interpreter to 'do the right thing' with
> the input stream. That way you get something that's directly
> compilable, So...

why do you think that hooking the interpreter does not need your
routine to be state-smart? Or to register two routines for the
two cases of exec/comp-mode? *bang*

have fun, guido                                   http://PFE.sf.net

oofoe schrieb:
> Hi!
> 
> 
>>>If I want this to work correctly during compilation, then I have to
>>>make AD an immediate word and supply an (AD) word to be compiled in. I
>>>have done this, certainly, but it seems yucky (state smart! Ewww!)
>>>compared to just getting the interpreter to 'do the right thing' with
>>>the input stream. That way you get something that's directly
>>>compilable, So...
>>
>>why do you think that hooking the interpreter does not need your
>>routine to be state-smart? Or to register two routines for the
>>two cases of exec/comp-mode? *bang*
> 
> 
> The way I envision it working would be during the intial parse and
> search for word. So if the current main loop is something like this
> (grossly simplified and probably misremembered):
> 
> begin
>    bl word
>    dup find 
>    if  swap drop  state @ if compile else execute  then 
>    else  number  state @ if literal then
>    then
> again
> 
> What I'm thinking of would work more like this:
> 
> : ad ( word -- f|t IS:yyyy mm dd) 
>    \ Parse word into date. Prepends expansion to input stream.
>    \ If word can't be parsed, returns false, no rewrite.
>    \ Magic input stream rewrite is happening here... ;-)
> ;
> 
> begin
>    bl word
>    dup find 
>    if  swap drop  state @ if  compile else execute  then
>    else  dup number  
>       if  swap drop  state @  if literal then 
>       else  dup ad  not if error then
>       then
>    then
> again
> 
> So a visualization of this in action (more for my benefit):
> 
> S: Empty. IS: "2003-07-20 1+ .date"
> \bl word (typical)
> S: 2003-07-20 IS: "1+ .date"
> \ find fails.
> \ number fails.
> \ ad succeeds:
> S: Empty. IS: "2003 7 20 1+ .date"
> \ find fails.
> \ number succeeds, parses date elements, puts on stack.
> S: 2003 7 20 IS: "1+ .date"
> \ find succeeds, looks up and executes '1+'
> S: 2003 7 21 IS: ".date"
> \ find fails (word '.date' isn't defined yet!).
> \ number fails.
> \ ad fails.
> S: Empty. IS: ""
> ?ERROR: Unknown word '.date'!
> 
> That would be the simple nasty way to do it, just to handle dates.
> Obviously, a more flexible scheme could be worked out to handle many
> different recognizers. There have been some neat proposals so far!
> 
> We're not requiring anything to be state smart (that I see), nor are
> we having to set up one word for interpret and another for compile.
> The worst thing that I'm doing is tampering with the input stream.
> 
> The best part (for me) is that this stuff is only used when working
> interactively (or loading source). When you compile, it can all get
> reduced to the most basic form inside the definition:
> 
> RAM: HERE  IS: ": test 2003-07-02 .date ;"
> RAM: [word] 'test' HERE  IS: "2003-07-02 .date ;"
> RAM: [word] 'test' HERE  IS: "2003 7 2 .date ;"
> RAM: [word] 'test' (lit) 2003 (lit) 7 (lit) HERE  IS: ".date ;"
> RAM: [word] 'test' (lit) 2003 (lit) 7 (lit) 2 <.date> HERE  IS: ""
> 
> The above is therefore directly equivalent to:
> 
> : test 2003 7 2 .date ;
> 
> So it seems that a benefit is that your compiled form is already
> reduced. There's no further interpretation of anything required... For
> this simple date thingy at least.
> 
> Does that make sense?
> 

Don't use evaluate. That's what you are effectivly doing, even
that you are lucky with transforming an input string into another
string carrying number literals. In the usual case, there is no
definite way of precognition the ORDER context. So that makes your
style pretty much limited to numbers. And in fact, I might need to
say that your example might be a better target for preprocessor.

You did say that "not requiring to be state smart" and "the worst
thing you do is tampering the input stream". Jesus, have you been
been brainwashed lately? It seems you have a certain fear on
anything being "state smart". Note that Anton's treatment simply
suggests that you disintegrate statesmart words into one being
compile-only and the other being execute-only. In other words,
only the outer interpreter has a state-smart wrapper like this:

  begin
     bl word
     state @ if
       compile-find if compile else
       number if literal else error then then
     else
       execute-find if execute else
       number if else error then then
     then
  again

IOW, there you do not need any word being state-smart in itself,
simply by handing over the state-smartness to the system loop.

Coming back to the interpreter hooks, it is certainly dangerous
to do some evaluate in itself, but at the same time all those
stringomatics are probably ineffective, slow and cpu consuming.
You have to write the special parser anyway, now just go ahead
and compile it for your compile-only word. No need to fill up
somewhere and go again through the blackbox of outer interpreter
parser and search-wordlists stuff. That can be as simple as

: AD ( input --- x y z ) .... ; interpret-only
: AD ( input -- ) [ ' AD COMPILE, ] lit lit lit ; compile-only

sorry if I got that wrong about interpret/compile-only stuff,
I don't use those type of a system, ye know, but it should be
something similar, I guess.

Oh, and don't forget to chain the two words on the hooklist
for your outer interpreter which is still system dependent
as we know. So, after all, no need to worry if doing it for
a gforthish system or a system using statesmart words anyway
all around, it'll get lots of ifdefs anyway  :-)=)

--have fun, guido                            http://PFE.sf.net

Albert van der Horst wrote:
> jonah thomas  <j2thomas@cavtel.net> wrote:

> <SNIP>

>>Something like:

>>ADD-TO-INTERPRETER ( xt -- ) execute xt when the interpreter cannot
>>interpret a string.  xt should do

> Why not just have a special wordlist to which to add, and that
> will always looked into, or have a flag in the header (compare
> IMMEDIATE) Both are mechanism already present.

> VOCABULARY DENOTATIONS   DEFINITIONS : $ ... ; ONLY FORTH DEFINITION
>    or
> : $ ... ; DENOTATION

> Both require no mechanism we don't have already.

They also give us no results we don't have already.  If you want to use 
some other delimiter than BL you're out of luck with the Forth 
interpreter, unless you write a parsing word (delimited with BL) that 
does it for something up to the rest of the line.  (Maybe you can use 
REFILL etc to get your special parser to keep going until at some point 
QUIT dumps you back into the Forth interpreter.)

If you have a date or time or phone number or any special formatting you 
have to put a command in front of it to parse it.  Or you can write your 
own interpreter, but if you use standard code so you can port it, you'll 
be limited to FIND or SEARCH-WORDLIST etc.

If you could patch your own input routines into the standard Forth 
interpreter then you could do whatever you wanted for your own custom 
interpreter and (so long as you wrote in standard Forth, without GUI 
etc) you could port it all whenever you switch Forth systems.

This would be useful for me.  But it isn't useful for Forth vendors. 
They do better if you use the interfaces they provide rather than 
anything you build yourself, so you'll be used to their systems and 
nobody else's.  And if you do add to their system they're better off if 
there's no easy way to do the same things with somebody else's system.

So, while this is potentially useful for users it has no value at all 
for vendors.

>>( c-addr n -- c-addr n 0 | i*n true )

>>This means, if the routine fails to interpret the string it returns the
>>original string with a false flag.

> I don't think this is needed. The word may assume that the IN-pointer
> is pointing to its first non- blank character. Then it does its
> thing and leaves the IN-pointer after itself, or after whatever
> it pleases to parse.

If one interpreter routine doesn't apply to the string, it passes the 
string to the next one.  Just like FIND passes it on to the number routine.

> With this approach
>       "THIS is not parsed by ""THIS "" or ""THIS"" "
>       (a single string with embedded spaces and double quotes)
> can be easily added.

What do you do with double quotes?  You have to do something like

[CHAR] " WORD

which has no standard way to add to the standard interpreter.  Or is 
"THIS a parsing word?

I get the feeling I'm missing your point.

In article <45577133.0307031249.21d08cce@posting.google.com>,
oofoe <joshfuller@operamail.com> wrote:
>Guido Draheim <guidod-2003-@gmx.de> wrote in message news:<bdvu71$8l0$07$1@news.t-online.com>...
>> Julian V. Noble schrieb:
>> > oofoe wrote:
>> >>
>> >>Has anyone ever experimented with adding additional recognizers in the
>> >>main Forth loop?
>>
>> Be reminded of the openboot habit with short "prefix<space>datasyntax",
>> to place a hexadecimal is as easy as writing "H# DEADBEEF". You can do
>> the same here, just write "AD 2003/07/04" and be sure to let your word
>> : AD PARSE-WORD DATE ; ... the only thing that needs inline syntax
>
>This was actually the first thing that I considered. However, it fails
>during compilation:
>
>\ Works fine!
>ad 2003/07/01 .date
>
>\ Whoops! The date isn't compiled!
>\ If ad is 'normal', we get an error at the '2003/07/01'.
>\ If ad is immediate, it's just left on the stack!
>: print-a-date ad 2003/07/01 .date ;
>
>If I want this to work correctly during compilation, then I have to
>make AD an immediate word and supply an (AD) word to be compiled in. I
>have done this, certainly, but it seems yucky (state smart! Ewww!)
>compared to just getting the interpreter to 'do the right thing' with
>the input stream. That way you get something that's directly
>compilable, So...

You got it. This is the whole point of having number denotations.
Numbers are state smart and this is acceptable because they are
so simple and known at compile time.
Not having to do
: test [ 1234.56 ] LITERAL all the time ;

This is why I want 'DROP . It is a number.
        123 CONSTANT AAP
        : AAP 123 ;
instead of
        123 CONSTANT AAP
        : AAP [ 123 ] LITERAL ;
and


        'DROP CONSTANT AAP
        : AAP 'DROP ;
instead of
        ' DROP CONSTANT AAP
        : AAP [ ' DROP ] LITERAL ;
or (ukh! would never use this!)
        : AAP ['] DROP LITERAL ;
(or was this
        : AAP ['] DROP ;
I never use it, so I have problems remembering it.)

And no. It is not dangerous.

Nobody writes
           POSTPONE 'DROP
anymore than
           POSTPONE  12345

Groetjes Albert.


>
>Jos'h
-- 
Albert van der Horst,Oranjestr 8,3511 RA UTRECHT,THE NETHERLANDS
        One man-hour to invent,
                One man-week to implement,
                        One lawyer-year to patent.

In article <45577133.0307041239.34cd8790@posting.google.com>,
oofoe <joshfuller@operamail.com> wrote:
<SNIP>
>
>We're not requiring anything to be state smart (that I see), nor are
>we having to set up one word for interpret and another for compile.

Numbers *are* state smart. This is accepted practice and standard.
Any special number denotations of your own making, like for the
date must be state smart to be usable without undue surprises.

Long ago Forth's would accept 2003/01/13 18:00:17
2003-01-13  as double numbers.
Then any double number would be a date, to be figured by
100 /mod 's .
You want your date's to behave in the same numberlike way
'cause It Just Is The Right Way (tm).

>RAM: HERE  IS: ": test 2003-07-02 .date ;"
>RAM: [word] 'test' HERE  IS: "2003-07-02 .date ;"
>RAM: [word] 'test' HERE  IS: "2003 7 2 .date ;"
>RAM: [word] 'test' (lit) 2003 (lit) 7 (lit) HERE  IS: ".date ;"
>RAM: [word] 'test' (lit) 2003 (lit) 7 (lit) 2 <.date> HERE  IS: ""
>
>The above is therefore directly equivalent to:
>
>: test 2003 7 2 .date ;

Formerly it would be
        : test 2003/07/02. .date ;
and its execution time behaviour would be the same as:
        2003/07/02 .date
or for that matter
        20/02070/2
        ( or even  20/03:0,7.0:2 )

>
>Jos'h
-- 
Albert van der Horst,Oranjestr 8,3511 RA UTRECHT,THE NETHERLANDS
        One man-hour to invent,
                One man-week to implement,
                        One lawyer-year to patent.

jonah thomas wrote:
> > 2) should the hooks only convert data or also conpile/interpret them?
> 
> What new environmental dependencies would we discover if it can also
> compile/interpret?

I think we will never agree on the data representation encoding if
the hooks only convert data.

So, the hooks must also interpret them.
And they must be state-smart.

In article <3F060C24.6060504@cavtel.net>,
jonah thomas  <j2thomas@cavtel.net> wrote:
>Albert van der Horst wrote:
<SNIP>
>
>> I don't think this is needed. The word may assume that the IN-pointer
>> is pointing to its first non- blank character. Then it does its
>> thing and leaves the IN-pointer after itself, or after whatever
>> it pleases to parse.
>
>If one interpreter routine doesn't apply to the string, it passes the
>string to the next one.  Just like FIND passes it on to the number routine.

It need not pass anything. Just admit failure like INTERPRET admitted
failure before by not be able to parse what is at the IN pointer. is
is signalled by not incrementing the IN pointer alone.
Any failing interpreter auxiliary word or INTERPRET itself, only
increments IN pass things (not necessarily words) successfully parsed.

>> With this approach
>>       "THIS is not parsed by ""THIS "" or ""THIS"" "
>>       (a single string with embedded spaces and double quotes)
>> can be easily added.
>
>What do you do with double quotes?  You have to do something like
>
>[CHAR] " WORD
>
>which has no standard way to add to the standard interpreter.  Or is
>"THIS a parsing word?
>
>I get the feeling I'm missing your point.

The point is that this is one thing that is parsed by a special
interpreter. (that handles blanks and has embedded doubles quotes
in strings.). Only this auxiliary interpreter itself can ever tell
how far IN can be advanced.

In fact the situation is almost the same as for
S" THIS ....
Here INTERPRET leaves it to a word S" to handle the remainder.
INTERPRET wants to know which word to execute to handle the
string, but it shouldn't really want to have anything to
do with the details of things it cannot parse itself.
As we have seen in general, it just can't.

Greetings Albert.
-- 
Albert van der Horst,Oranjestr 8,3511 RA UTRECHT,THE NETHERLANDS
        One man-hour to invent,
                One man-week to implement,
                        One lawyer-year to patent.

At least, here is a solution for the state-smart vs separate
hooking:


\ with statesmart-hook defined:
: compiling-hook ( xt -- )
   >R
   :NONAME PLEASE" state @ if " R> COMPILE, PLEASE" then"
   POSTPONE ;
   statesmart-hook 
;

: interpreting-hook ( xt -- )
   >R
   :NONAME PLEASE" state @ 0= if " R> COMPILE, PLEASE" then"
   POSTPONE ;
   statesmart-hook 
;

\ with compiling-hook and interpreting-hook defined:

: statesmart-hook DUP compiling-hook interpreting-hook ;

\ Use:
: myhook state @ if ... else ... then ;
' myhook statesmart-hook

Albert van der Horst wrote:
....
>>Yes, the earliest Forths from Chuck Moore worked this
>>way, and FORTH, Inc. products have always worked this
>>way and still do.  The input number conversion routine takes
>>the following characters:  + / : . , and - (except at the left side)
>>as legal punctuation, causing the number to be converted as
>>double precision.  The result can then be further processed
>>by a routine such as M/D/Y which does the /MODs etc.
>>to make a date out of the number.
> 
> Very practical.
> 
> Only I wished that numbers containing only comma's would be single
> precision, such that they could be used to increase legability, like
> per
> 12,000,000,12 (12 million dollar and some cents)
> and
> 07FF,0000 a tricky mask in 32 bits numbers.
> 
> I guess it is too late for that now.

This convention developed in a 16-bit environment, where
single-precision numbers are small enough not to need punctuation!
There are still quite a few 16-bit Forths around (e.g. for
small microcontrollers).

Besides, it really _is_ too late, changing this rule
now would break a lot of code.

Cheers,
Elizabeth

-- 
==================================================
Elizabeth D. Rather   (US & Canada)   800-55-FORTH
FORTH Inc.                         +1 310-491-3356
5155 W. Rosecrans Ave. #1018  Fax: +1 310-978-9454
Hawthorne, CA 90250
http://www.forth.com

"Forth-based products and Services for real-time
applications since 1973."
==================================================

Albert van der Horst wrote:
> jonah thomas  <j2thomas@cavtel.net> wrote:

>>If one interpreter routine doesn't apply to the string, it passes the
>>string to the next one.  Just like FIND passes it on to the number routine.

> It need not pass anything. Just admit failure like INTERPRET admitted
> failure before by not be able to parse what is at the IN pointer. is
> is signalled by not incrementing the IN pointer alone.
> Any failing interpreter auxiliary word or INTERPRET itself, only
> increments IN pass things (not necessarily words) successfully parsed.

Very nice!  I got blinded by the usual way it splits into WORD or 
PARSE-WORD and then the FIND NUMBER etc.  When you do it the usual way 
 >IN gets incremented long before you find out whether it can be handled.

"Albert van der Horst" <albert@spenarnc.xs4all.nl> wrote in message
news:HHnv1J.9qC.1.spenarn@spenarnc.xs4all.nl...
>
> Only I wished that numbers containing only comma's would be single
> precision, such that they could be used to increase legability, like
> per
> 12,000,000,12 (12 million dollar and some cents)
> and
> 07FF,0000 a tricky mask in 32 bits numbers.
>
> I guess it is too late for that now.

    Quest32 works this way by default.

-- 

-GJC
-Software Consultant (Embedded systems and Real Time Controls)
-gchanson@mvps.org

-War is the last resort of the incompetent.

On Mon, 7 Jul 2003 15:29:42 GMT, albert@spenarnc.xs4all.nl (Albert van
der Horst) wrote:

>Only I wished that numbers containing only comma's would be single
>precision, such that they could be used to increase legability, like
>per
>12,000,000,12 (12 million dollar and some cents)
>and
>07FF,0000 a tricky mask in 32 bits numbers.

The MPE solution to this problem is to have three system
variables which hold characters used as follows:

DP-CHAR   \ holds double number separator, default ','
FP-CHAR   \ holds float separator, default '.'
IGN-CHAR  \ char to be ignored, default ':'

Setting these variables permits the same code
to handle most formats.

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

In article <ynsOa.34989$U23.8297@nwrdny01.gnilink.net>,
Gary Chanson <gchanson@NOSPAM.TheWorld.com> wrote:
>
>"Albert van der Horst" <albert@spenarnc.xs4all.nl> wrote in message
>news:HHnv1J.9qC.1.spenarn@spenarnc.xs4all.nl...
>>
>> Only I wished that numbers containing only comma's would be single
>> precision, such that they could be used to increase legability, like
>> per
>> 12,000,000,12 (12 million dollar and some cents)
>> and
>> 07FF,0000 a tricky mask in 32 bits numbers.
>>
>> I guess it is too late for that now.
>
>    Quest32 works this way by default.

ciforth does it too. I added it when addresses on the
(64 bit) Dec Alpha Forth became unreadable without them.

In view of Elizabeth Rathers comment I feel a bit
uncomfortable about it.

>-GJC
Groetjes Albert.
-- 
Albert van der Horst,Oranjestr 8,3511 RA UTRECHT,THE NETHERLANDS
        One man-hour to invent,
                One man-week to implement,
                        One lawyer-year to patent.

Michael L Gassanenko wrote:
....
>>>Yes, the earliest Forths from Chuck Moore worked this
>>>way, and FORTH, Inc. products have always worked this
>>>way and still do.  The input number conversion routine takes
>>>the following characters:  + / : . , and - (except at the left side)
>>>as legal punctuation, causing the number to be converted as
>>>double precision.  The result can then be further processed
>>>by a routine such as M/D/Y which does the /MODs etc.
>>>to make a date out of the number.
>>
>>Very practical.
> 
> This depends. E.g., here & today it is 08.07.2003 aka 08.07.03.

That would work identically, since the number routine doesn't
care what the punctuation character is.

>>Only I wished that numbers containing only comma's would be single
>>precision, such that they could be used to increase legability, like
>>per
>>12,000,000,12 (12 million dollar and some cents)
>>and
>>07FF,0000 a tricky mask in 32 bits numbers.
>>
>>I guess it is too late for that now. 
> 
> Why? It hasn't been a long while since I learned the hard way that
> this is not so attractive as it may seem.
> 
> What do you mean C,C should mean?
> The compiler thought that it meant 0xCC while I thought that I meant
> c-comma for the code space.

Since the dictionary is searched first, if C,C is defined you'll
get it.  If not, you'll only get a number if you happen to be
in hex.

> Now I have a flag, IIRC, STRICTNUMBERS , that makes the system
> reject hex numbers that begin with a letter. E.g.
> HEX $cc 0cc -- ok
> cc0 -- error
> 
> (since $ already means a number, namely, a hex number, a digit 
> is not necessary after it.)
> 
> Of course, that's not standard.

No, but if you find it useful it's a perfectly reasonable extension.

Cheers,
Elizabeth


-- 
==================================================
Elizabeth D. Rather   (US & Canada)   800-55-FORTH
FORTH Inc.                         +1 310-491-3356
5155 W. Rosecrans Ave. #1018  Fax: +1 310-978-9454
Hawthorne, CA 90250
http://www.forth.com

"Forth-based products and Services for real-time
applications since 1973."
==================================================

Albert van der Horst wrote:
> 
> In article <3F083945.F79B0684@forth.com>,
> Elizabeth D. Rather <erather@forth.com> wrote:
> >Albert van der Horst wrote:
> >
> >> Long ago Forth's would accept 2003/01/13 18:00:17
> >> 2003-01-13  as double numbers.
> >> Then any double number would be a date, to be figured by
> >> 100 /mod 's .
> >> ...
> >
> >Yes, the earliest Forths from Chuck Moore worked this
> >way, and FORTH, Inc. products have always worked this
> >way and still do.  The input number conversion routine takes
> >the following characters:  + / : . , and - (except at the left side)
> >as legal punctuation, causing the number to be converted as
> >double precision.  The result can then be further processed
> >by a routine such as M/D/Y which does the /MODs etc.
> >to make a date out of the number.
> 
> Very practical.

This depends. E.g., here & today it is 08.07.2003 aka 08.07.03.

> 
> Only I wished that numbers containing only comma's would be single
> precision, such that they could be used to increase legability, like
> per
> 12,000,000,12 (12 million dollar and some cents)
> and
> 07FF,0000 a tricky mask in 32 bits numbers.
> 
> I guess it is too late for that now.
> 

Why? It hasn't been a long while since I learned the hard way that
this is not so attractive as it may seem.

What do you mean C,C should mean?
The compiler thought that it meant 0xCC while I thought that I meant
c-comma for the code space.

Now I have a flag, IIRC, STRICTNUMBERS , that makes the system
reject hex numbers that begin with a letter. E.g.
HEX $cc 0cc -- ok
cc0 -- error

(since $ already means a number, namely, a hex number, a digit 
is not necessary after it.)

Of course, that's not standard.

Stephen Pelc wrote:
> 
> On Mon, 7 Jul 2003 15:29:42 GMT, albert@spenarnc.xs4all.nl (Albert van
> der Horst) wrote:
> 
> >Only I wished that numbers containing only comma's would be single
> >precision, such that they could be used to increase legability, like
> >per
> >12,000,000,12 (12 million dollar and some cents)
> >and
> >07FF,0000 a tricky mask in 32 bits numbers.
> 
> The MPE solution to this problem is to have three system
> variables which hold characters used as follows:
> 
> DP-CHAR   \ holds double number separator, default ','
> FP-CHAR   \ holds float separator, default '.'
> IGN-CHAR  \ char to be ignored, default ':'
> 
> Setting these variables permits the same code
> to handle most formats.

Unfortunately, sometimes I want to have multiple characters ignored,
e.g. 123_456_789 should be the same as 123,456,789 .

I would propose to standardize DEFERred words like DP-CHAR? ( c -- flag
).
(yes, I do remember that there is no currently active TC that could 
standardize at least DEFER. But there is comp.lang.forth.repository
at http://forth.sf.net )

Elizabeth D Rather wrote:
> 
> Michael L Gassanenko wrote:
> ...
> >>>Yes, the earliest Forths from Chuck Moore worked this
> >>>way, and FORTH, Inc. products have always worked this
> >>>way and still do.  The input number conversion routine takes
> >>>the following characters:  + / : . , and - (except at the left side)
> >>>as legal punctuation, causing the number to be converted as
> >>>double precision.  The result can then be further processed
> >>>by a routine such as M/D/Y which does the /MODs etc.
> >>>to make a date out of the number.
> >>
> >>Very practical.
> >
> > This depends. E.g., here & today it is 08.07.2003 aka 08.07.03.
> 
> That would work identically, since the number routine doesn't
> care what the punctuation character is.

I meant that there's an internationalization issue.

08.07.03 is 07/08/03. You would have to rewrite the code.

"Albert van der Horst" <albert@spenarnc.xs4all.nl> wrote in message 
news:HHp8Iy.LG4.1.spenarn@spenarnc.xs4all.nl...
>
> ciforth does it too. I added it when addresses on the
> (64 bit) Dec Alpha Forth became unreadable without them.
>
> In view of Elizabeth Rathers comment I feel a bit
> uncomfortable about it.

    I don't.  Any existing program will have to be ported to a 64 bit system 
and there will be very little use for double numbers (there's very little in 
a 32 bit system).  Those numbers will have to be changed anyway.

-- 

-GJC
-Software Consultant (Embedded systems and Real Time Controls)
-gchanson@mvps.org

-Abolish public schools

In article <3F0B1EED.DF00CF67@yahoo.com>,
Michael L Gassanenko  <m_l_g3@yahoo.com> wrote:
<SNIP>
>
>Why? It hasn't been a long while since I learned the hard way that
>this is not so attractive as it may seem.
>
>What do you mean C,C should mean?
>The compiler thought that it meant 0xCC while I thought that I meant
>c-comma for the code space.
>
>Now I have a flag, IIRC, STRICTNUMBERS , that makes the system
>reject hex numbers that begin with a letter. E.g.
>HEX $cc 0cc -- ok
>cc0 -- error
>
>(since $ already means a number, namely, a hex number, a digit
>is not necessary after it.)
>
>Of course, that's not standard.

Interestingly, ciforth starts out by being non-standard (means
simpler than the standard.)
It is only after
    REQUIRE DEADBEEF
that it understands hex numbers that start with one of the DEADBEEF
characters.

I have very little sympathy with a Forth that starts out non-standard
by being more complicated than a standard system.
Then adding global flags to cope with resulting problems.

I think
   0cc
should be a valid number in base `` CHAR z '' and different than
   0CC
..
-- 
Albert van der Horst,Oranjestr 8,3511 RA UTRECHT,THE NETHERLANDS
        One man-hour to invent,
                One man-week to implement,
                        One lawyer-year to patent.

Gary Chanson wrote:
> 
> "Albert van der Horst" <albert@spenarnc.xs4all.nl> wrote in message
> news:HHp8Iy.LG4.1.spenarn@spenarnc.xs4all.nl...
> >
> > ciforth does it too. I added it when addresses on the
> > (64 bit) Dec Alpha Forth became unreadable without them.
> >
> > In view of Elizabeth Rathers comment I feel a bit
> > uncomfortable about it.
> 
>     I don't.  Any existing program will have to be ported to a 64 bit system
> and there will be very little use for double numbers (there's very little in
> a 32 bit system).  Those numbers will have to be changed anyway.
> 

Imagine porting from a 16-bit to a 64-bit processor.
If the program worked on a 16-bit system (maybe for a 8-bit processor),
do you think anybody would care hos many us get wasted on the 64-bit 
processor each time the program runs? If it worked on a slow machine,
it's cheaper not to rewrite it on the fast machine. Move the mouse
while the program runs, and the effect of this rewriting is eaten.

This is what 128-bit numbers are for on a 64-bit system.