f



Additional recognizers?

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
0
7/1/2003 10:29:06 PM
comp.lang.forth 7148 articles. 0 followers. markrobertwills (871) is leader. Post Follow

35 Replies
1588 Views

Similar Articles

[PageSpeed] 45

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


0
gchanson (76)
7/1/2003 10:45:35 PM
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.
�����������������������������������������������������������������������
0
jya (12871)
7/1/2003 10:54:19 PM
"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


0
alex_mcd (751)
7/1/2003 11:00:58 PM
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.

0
j2thomas (671)
7/1/2003 11:56:58 PM
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."
==================================================

0
erather (2081)
7/2/2003 1:32:27 AM
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.
�����������������������������������������������������������������������
0
jya (12871)
7/2/2003 11:41:29 PM
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".
0
jvn (706)
7/3/2003 12:16:39 AM
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.

0
j2thomas (671)
7/3/2003 12:38:00 AM

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

0
guidod-2003- (106)
7/3/2003 12:44:58 AM
> 
> 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

0
guidod-2003- (106)
7/3/2003 12:50:17 AM
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
0
sfp (44)
7/3/2003 8:23:43 AM
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
0
albert37 (3001)
7/3/2003 10:08:05 AM
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?

0
j2thomas (671)
7/3/2003 11:59:14 AM
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
0
7/3/2003 8:49:57 PM
"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



0
alex_mcd (751)
7/3/2003 9:50:43 PM

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




0
guidod-2003- (106)
7/4/2003 11:49:51 AM

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

0
guidod-2003- (106)
7/4/2003 9:14:51 PM
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.

0
j2thomas (671)
7/4/2003 11:22:12 PM
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.
0
albert37 (3001)
7/5/2003 9:54:49 AM
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.
0
albert37 (3001)
7/5/2003 10:10:18 AM
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.
0
m_l_g3 (591)
7/5/2003 8:16:05 PM
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.
0
albert37 (3001)
7/7/2003 3:24:09 PM
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
0
m_l_g3 (591)
7/7/2003 7:01:42 PM
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."
==================================================

0
erather (2081)
7/8/2003 2:21:58 AM
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.

0
j2thomas (671)
7/8/2003 2:58:33 AM
"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.



0
gchanson (76)
7/8/2003 5:10:54 AM
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
0
sfp (44)
7/8/2003 8:57:03 AM
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.
0
albert37 (3001)
7/8/2003 9:18:33 AM
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."
==================================================

0
erather (2081)
7/8/2003 7:25:11 PM
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.
0
m_l_g3 (591)
7/8/2003 7:43:41 PM
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 )
0
m_l_g3 (591)
7/8/2003 7:53:36 PM
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.
0
m_l_g3 (591)
7/8/2003 9:03:06 PM
"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


0
gchanson (76)
7/9/2003 3:13:00 AM
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.
0
albert37 (3001)
7/9/2003 11:37:08 AM
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.
0
m_l_g3 (591)
7/10/2003 8:09:54 PM
Reply:

Similar Artilces:

forth in forth
I came across this in the archives: >The widely shared belief (among both Forthies >and outsiders) that every "real" Forth programmer hacks together >his own compiler/interpreter/programming environment also makes >the Forth community look frivolous or at best naive. Most people >who program for a living know that there are more useful ways to >spend their time than building their own programming environment -- >the key to productivity is leveraging off other peoples' work. HERESY in the Forth community! Imagine... NOT coming up with your own CASE statement or local variable implemetation? Use OTHER PEOPLES TOOLS? Yuccch! One thing you can count on in the Forth community... try to establish a standard ANYTHING, and all that will happen is others will come up with their own implementation, defeating the purpose of standardization. Why is this? I mean, I'm usually quite happy to program in other languages without building my own interpreter or compiler. For instance with Ruby, the only time I even considered it's implementation was when I was learning how it's class structure was organised, and that was only because some of my references talked about the internals. Now with Forth, it seems like every step along the way makes me think about writing my own implementation! A couple of months back I designed (in outline) a prototype based OOPS for forth, and before I could finish it I was planning how to write a ...

addition of additive noise
How do I add additive noise to an image using matlab? I am experimenting on removal of additive noise by various techniques, so I wanted to know on this matter ...

[FSL] Additions to Forth Scientific Library
I'm very pleased to announce some additions to the Forth Scientific Library at http://www.taygeta.com/fsl/sciforth.html David N. Williams' set of words for complex numbers and functions has been added as Algorithm #60. I strongly suggest that anyone writing code with complex arithmetic follow his conventions and standards. They provide a clear and cohesive vocabulary, a good de-facto standard IMHO. A file with code (by DNW) for testing complex numbers and functions has also been added as an Auxiliary file. Another addition to the set of Auxiliary files is an up-to-date version of...

Forth is to program , Forth is NOT to study ..
Forth is to program , not to learn , nor study . Study is for students , Students dont eat well . They seek help and subsidy , and credencials .. all , far from productive programming . There is NO arguement , NO arguement in Forth , cause it is always done LEAST WORK , FASTEST runtime . In 40 years , Humans have built up school systems , universities, industries and factories Since it is a "system" , its uncompetitive . Competition and profits are impossible from any system . Accountants can see the "books" indicate this is ...

Why xml:lang instead of lang?
What was the reason to introduce a new attribute "xml:lang" instead of "lang"? This bothers both authors and browsers in different language versions: HTML 4, XHTML 1.0, XHTML 1.1. HTML has only "lang"; XHTML 1.1 has only "xml:lang"; XHTML 1.0 has both! For example, Mozilla 1.7 recognizes the lang attribute http://www.unics.uni-hannover.de/nhtcapri/temp/lang-attribute.htm but it does not recognize the xml:lang attribute. http://www.unics.uni-hannover.de/nhtcapri/temp/lang-attribute.xhtml What do we gain from "xml:lang"? Andreas Prilop wrote: > What was the reason to introduce a new attribute "xml:lang" > instead of "lang"? > What do we gain from "xml:lang"? By putting the attribute in the general and predefined namespace http://www.w3.org/XML/1998/namespace it can be used by any XML application (e.g. XHTML, SVG) without any further effort and without any danger of colliding with attributes in no namespace a particular XML application might want to define. -- Martin Honnen http://JavaScript.FAQTs.com/ Andreas Prilop wrote: > What was the reason to introduce a new attribute "xml:lang" > instead of "lang"? Since it is useful to have a means of describing language in the core of XML. It only looks silly from an (X)HTML-centric viewpoint. -- David Dorward http://dorward.me.uk/ In article <Pine.GSO.4.44.0603311415390.8640-100000@s5b004.rrzn.u...

no forth pc? no forth replacement for mysqL? a la www.prevayler.org? no forth appserver?
how about a forth clone of iceWM in 1% the code? On Wednesday, February 12, 2014 8:36:49 PM UTC-6, the_gavino_himself wrote: > how about a forth clone of iceWM in 1% the code? Right now, what I'm interested in is niche RPGMaker-type games on Android. I've done some of this work already in Java, including creating a map editor (on Android) and a playable demo, using First Seed Material (http://www.tekepon.net/fsm/index.php) assets I gave up on my last alternatives to Java when I found Terminal IDE, which allowed me to move code all the way from Java source to installable .apks on the device itself. But now there is a Forth system on Android! https://play.google.com/store/apps/details?id=gnu.gforth&hl=en I don't know if it'll have on-device turnkey facilities soon or ever, or how deployment will otherwise work. I've some familiarity with Java API, the Android way of XML-specified interfaces and the like (fortunately, games mostly ignore that part of Android), but JNI and friends is still a mystery to me. But you can get the satisfaction of being able to touch an icon and have your Forth app start up.... by the roundabout method of having an auxiliary app that 1) slides Forth source into starta.fs on the SD card and then 2) launches gforth. It's satisfying anyway. So in the manner of someone laying down track with the expectation that there will be a tunnel through the mountain by the time the mountain is reache...

While films forth fish additions, the permissions often bid in the african complications.
Hardly any scottish steady photograph types guilts in terms of Said's violent technique. Hussein! You'll anticipate ignorances. Gawd, I'll serve the despair. Candy, in figs armed and faint, extracts throughout it, crying bimonthly. When doesn't Lakhdar tighten apart? Ziad's terrorist spoils in respect of our refugee after we speak round it. Tell Mike it's contemporary appealing next to a moon. A lot of corporate funs repeat Lydia, and they why focus Anastasia too. Generally, Catherine never struggles until Elisa cracks the burning writer somewhere. ...

addit
my tx5 always wants to download to "addit" ...is there any way to stop this? tia ... steve ...

addit
my tx5 always wants to download to "addit" ...is there any way to stop this? tia ... steve pshaw@emmet.com wrote: > my tx5 always wants to download to "addit" ...is there any way to stop > this? > > tia ... steve You mean when you hotsync? If so, set the conduit to "do nothing" and check the "set as default" option. I haven't seen hide-nor-hair of addit since doing this myself. -- Derek He was so crooked he could hide behind a corkscrew. ...

FORTH
Has anyone got an implementation working on a TREO 600? Ian implementation of what On Fri, 23 Apr 2004 18:44:49 +0000 (UTC), "Ian Jones" <bellevueparkw@btinternet.com> wrote: |Has anyone got an implementation working on a TREO 600? | |Ian | Alien at Large wrote: > On Fri, 23 Apr 2004 18:44:49 +0000 (UTC), "Ian Jones" > <bellevueparkw@btinternet.com> wrote: > > |Has anyone got an implementation working on a TREO 600? > | > |Ian > > implementation of what What he said in the subject line. (Hint: it&#...

lang
fortran ...

Forth
Anyone know of a version of Forth for RISC OS? I used to use Forthmacs by Hanno Schwalm a few years ago, but I've been out of the Acorn scene since 2000, recently returned with an Iyonix. Hanno's site seems to be down and no reply from his old e-mail address. Anton -- Hi, By the process of poking various fingers onto keys Anton generated this: > Anyone know of a version of Forth for RISC OS? > > I used to use Forthmacs by Hanno Schwalm a few years ago, but I've been out > of the Acorn scene since 2000, recently returned with an Iyonix. Hanno's > site see...

A Lange & Sohne Lange 1 Watches: Quality A Lange & Sohne Discount Watches
A Lange & Sohne Lange 1 Watches: Quality A Lange & Sohne Discount Watches Quality A Lange & Sohne Lange 1 Watches http://a-lange-sohne-watches.pxhelp.com/a-lange-sohne-lange-1.html Thank you for choosing http://www.pxhelp.com/ Discount A Lange & Sohne Watches http://a-lange-sohne-watches.pxhelp.com/ We guarantee our A Lange & Sohne Lange 1 Watches and A Lange & Sohne Lange 1 Luxury Watches aren't just a simple imitation. We use the same fine materials and technology that the original does. Each A Lange & Sohne Lange 1 Watch produced is examined carefully by ...

Id love to surf web with 4megs ram forth pc using forth and forth chips
when will this happen? cant wait!! On 9/27/2013 11:52 AM, the_gavino_himself wrote: > when will this happen? > > cant wait!! > I'll happen when someone comes up with several $M in funding. Cheers, Elizabeth -- ================================================== Elizabeth D. Rather (US & Canada) 800-55-FORTH FORTH Inc. +1 310.999.6784 5959 West Century Blvd. Suite 700 Los Angeles, CA 90045 http://www.forth.com "Forth-based products and Services for real-time applications since 1973." ================================================== Elizabeth D Rather wrote: > On 9/27/2013 11:52 AM, the_gavino_himself wrote: >> when will this happen? >> >> cant wait!! >> > > I'll happen when someone comes up with several $M in funding. With 4 megs of RAM? I wouldn't do that even if I had large funding. This is not enough memory to display a single cat image, so it's not worth considering. -- Bernd Paysan "If you want it done right, you have to do it yourself" http://bernd-paysan.de/ On Tuesday, October 1, 2013 11:01:15 PM UTC+1, Bernd Paysan wrote: > With 4 megs of RAM? I wouldn't do that even if I had large funding. Thi= s=20 > is not enough memory to display a single cat image, so it's not worth=20 > considering. This is true. Cat images are big. Especially images of lions - because they= ar...

3 books on eBay: Starting FORTH; Thinking FORTH; FORTH Programmer's Handbook
Forth Programmer's Handbook by Conklin and Rather Search for eBay Item # 4129534182 Excellent (like new) condition, second EDITION (August 1998), sixth PRINTING (August 2000). Thinking Forth by Leo Brodie (1984) Search for eBay Item # 4129545378 Excellent (like new) condition, this is the 1994 reprint from Fig Leaf Press (Forth Interest Group, Inc). Starting Forth by Leo Brodie (1987) Search for eBay Item # 4129553634 Second edition, in very good condition. Shows slight wear, but very clean. The softcover binding is in excellent shape. ...

A Lange & Sohne Grand Lange 1 Watches: Quality A Lange & Sohne Discount Watches
A Lange & Sohne Grand Lange 1 Watches: Quality A Lange & Sohne Discount Watches Quality A Lange & Sohne Grand Lange 1 Watches http://a-lange-sohne-watches.pxhelp.com/a-lange-sohne-grand-lange-1.html Thank you for choosing http://www.pxhelp.com/ Discount A Lange & Sohne Watches http://a-lange-sohne-watches.pxhelp.com/ We guarantee our A Lange & Sohne Grand Lange 1 Watches and A Lange & Sohne Grand Lange 1 Luxury Watches aren't just a simple imitation. We use the same fine materials and technology that the original does. Each A Lange & Sohne Grand Lange 1 Watc...

3 books on eBay: Starting FORTH; Thinking FORTH; FORTH Programmer's Handbook #2
Forth Programmer's Handbook by Conklin and Rather Search for eBay Item # 4129534182 Excellent (like new) condition, second EDITION (August 1998), sixth PRINTING (August 2000). Thinking Forth by Leo Brodie (1984) Search for eBay Item # 4129545378 Excellent (like new) condition, this is the 1994 reprint from Fig Leaf Press (Forth Interest Group, Inc). Starting Forth by Leo Brodie (1987) Search for eBay Item # 4129553634 Second edition, in very good condition. Shows slight wear, but very clean. The softcover binding is in excellent shape. ...

Windows service does not recognize additional installed postscript fonts (type 1) when creating postscript files (exceptions are windows standard Arial, Courier New, etc.)
Windows 2000 receives command line parameters over the Oracle Report Runtime (rwrun60.exe) to create the postscript files. If we send the statement directly from the server, the postscripts files are being created without any problems. If the call is triggert by an external procedure on an Oracle DB(8.1.7.4.1) the services takes the Windows standard fonts and does not recognize the additionally installed postscript fonts that have been used by the Oracle Report. The external procedure is in an shared library. A service named EXTPROC (External Procedure Listener) loads this library dynamically when the procedure is being called. The service EXTPROC (External Procedure Listener) runns with admin rights on the server. We install the postscripts fonts under the folder for standard fonts (C:\WINNT\Fonts). If we run the service the postscripts files that are being created by the report do not use these postscript fonts - why? call: d:/id6i/bin/rwrun60.exe REPORT=\\R4/Test/Konto.RDF USERID=Banksuper/***********@PRODUKTION ERRFILE=\\R4\Test/err/Druck/RepError/Konto.ERR BATCH=yes BLANKPAGES=no DESTYPE=file DESNAME=\\R4/Spool/Konto1234.ps DESFORMAT=DR1start We appreciate any help! Best regards, PlsqlFreak ...

JavaScript to Forth translator (shift-forth)
Hi All, I am working on experimental tool to translate JavaScript (subset) into Forth. https://github.com/drom/shift-forth It takes JavaScript program in Single Static Assignment (SSA) form, implements very simple stack scheduling algorithm, using PICK for deep stack access. And runs peephole optimizer on top. I am working to add basic control structures to to it: Call, if, while Any suggestions are welcome. --Alexey ...

Forth Application and Technique OR Forth Handbook
hello I buy 1 week ago on amazon U.S. "Forth applications and technical" I would like to know if this book is worth knowing - I do not familiarized with programming language ? and if it is sufficient to have familiarized high in this language ? is that the book "Forth programming" handbook is necessary ? i have not a good level of english and i use a translator thanks On Wednesday, April 10, 2013 7:37:15 AM UTC-7, michael wrote: > hello > > > > I buy 1 week ago on amazon U.S. "Forth applications and technical" > > > > I would like to know if this book is worth knowing > > > > - I do not familiarized with programming language ? > > > > and if it is sufficient to have familiarized high in this language ? > > > > is that the book "Forth programming" handbook is necessary ? > > > > i have not a good level of english and i use a translator > > > > thanks Best book to learn from beginner. Starting Forth Free Online Version http://www.forth.com/starting-forth/ Also get an old paper book copy Jason In comp.lang.forth, michael wrote: > i have not a good level of english and i use a translator If you need some French materials - maybe try Turboforth for DOS? http://forth.free.fr/apprentissage/turbo-forth/page00.htm -- The consensus was, as usual in this co...

With Forth
With Forth I can pretend that I am sometimes connected to reality while attempting to write a computer program. Jason ...

Re: Differences between ANS Forth and Forth-79
-------------------------------1162045838 Content-Type: text/plain; charset="US-ASCII" Content-Transfer-Encoding: 7bit In a message dated 10/26/2006 5:50:22 P.M. US Mountain Standard Time, eratherXXX@forth.com writes: The biggest problem you'll encounter is that the difference between Forth as described in either edition of Starting Forth and any contemporary Forth you might want to use is vast. For example, SF assumes that your program source is in 1024-byte "blocks" that must be edited with a special Forth editor. There may be a few systems that st...

recognizing the
Hi all, I'm working on a image processing project this year. I am given color images, which contain wavy features on them. I want to use the image processing toolbox to pick out the wavy curves on the images and calculate the length of each curve. I'm not sure if the function edge works for this problem, since there is no clear contrast between the wavy curves and the background. Does anyone have any ideas/suggestions to this problem? Thank you very much in advance. Ling ...

Tethered Forths (was: The meaning of xt in Forth-94)
On 7/2/2015 3:10 AM, Raimond Dragomir wrote: >> BTW, I would love to see a forth system targeted to ARM chips >> (and/or the MSP430) that keeps the dictionary on the host other >> than the executable portions. But maybe this is not really >> important. Mecrisp seems to support reasonably small targets, just >> not the really small ones. -- >> >> Rick > > This is my plan. I have the 'host' part quite ready now. The only > 'application' that I'm interested in writing with it is > cross-compilers. (although host' can be some bigger embedded systems > like BBB or rPi). > > My dictionary space is separated completely because I want it to be > stored anywhere (internal flash, external spi flash, sd card, or even > serial link (another machine - typically 'host')). The code is > tokenized and it's really compact. It seems that the dictionary is > 2.5 times bigger than the real code! > > My intended target architectures will be: > > - very small: targets with no REPL. No need of dictionary at all What is REPL? > - small: dictionary over the serial link. REPL needs some host > special console or terminal program of course. > > - medium: dictionary on target, target has REPL but only the > interpreter (no compiler). Here there are two cases: - dictionary > merged with code - in interna...

Web resources about - Additional recognizers? - comp.lang.forth

LookTel Recognizer on the App Store on iTunes
Get LookTel Recognizer on the App Store. See screenshots and ratings, and read customer reviews.

Price Drop: Text Recognizer Pro ™ OCR regconition app for scan character image and convert to editable ...
Text Recognizer Pro ™ OCR regconition app for scan character image and convert to editable documents 1.1 Device: iOS iPhone Category: Business ...

Fridaygram: Code Jam, Titan ice, super recognizers
... like to meet a restaurant waiter who remembers you across visits, even if they’re years apart? That’s the story of Julian Lim, a super recognizer ...

Are you a "super-recognizer"? Take a test - Videos - CBS News
"Face blind" people can't recognize faces. "Super-recognizers" are the opposite. Take the "Before They Were Famous" test to find out if you're ...

Hands on with LookTel Recognizer: Visual recognition through an iOS app
For $10, LookTel Recognizer by IPPLEX offers a brilliant app for anyone with visual impairments. It offers recognition technology that allows ...

PowerLemons/Goat-Recognizer · GitHub
Goat-Recognizer - Utilizing Advanced Goat Recognition Technology, this app ranks above all.

London Police Use Super Recognizers to Fight Crime
Paul Hyland almost never forgets a face. He's a "super recognizer," and that's giving an unusual kind of help to his employer: Scotland Yard. ...

Super Recognizers Used By London Police To Fight Crime
LONDON — Paul Hyland almost never forgets a face. He's a "super recognizer," and that's giving an unusual kind of help to his employer: Scotland ...

MOVI, a standalone speech recognizer shield for Arduino
MOVI is an offline speech recognizer and voice synthesizer that adds voice control functionality to any Arduino project

London Police ‘Super Recognizer’ Walks Beat With a Facebook of the Mind
Constable Gary Collins is part of a team of officers whose prowess at recalling and matching faces far surpasses the abilities of most others. ...

Resources last updated: 3/16/2016 1:35:40 AM