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.