|
|
 Up |
|
|
  |
Date: Sep 8, 2007 03:34
This is no proposal but an idea.
We've seen complains about the number prefix proposal of Forth 200x
that it would need to change the text interpreter.
How about a general mechanism to hook into the text interpreter? This
was proposed I think with Win32Forth mechanism, if I remember right,
but this mechanism at my opinion was not really smart.
ANS has a way to sort words into groups and re-organize the searching
order. This way are vocabularies.
With a small extension to the vocabulary stuff, it would be possible
to very flexible hook into the text interpreter. The extension would
mean to extend the vocabularies from named words only to generic words
(as numbers) that are recognized by their structure.
So for each vocabulary there could be a FIND equivalent, that the
programmer may overwrite.
The idea simply is that every vocabulary implements it's own FIND, the
FIND that's suitable for the vocabulary.
|
| Show full article (1.24Kb) |
|
| | 113 Comments |
|
|
Author: slavaslava Date: Sep 8, 2007 19:51
> The idea simply is that every vocabulary implements it's own FIND, the
> FIND that's suitable for the vocabulary.
>
> The implementation of something like number prefixes would then mean
> to create a vocabulary and write a number prefix recognizing FIND for
> this vocabulary.
> The mechanism could be made 100%% compatible to existing ANS Forth
> implementations - well it could not be implemented in ANS without
> knowing the system.
How would a file make use of multiple vocabularies in this case?
Slava
|
| |
|
| | no comments |
|
|
Date: Sep 9, 2007 01:46
On Sep 9, 4:51 am, "sl...@ jedit.org" jedit.org> wrote:> On Sep 8, 6:34 am, hel...@ gmail.com wrote:
> >> The idea simply is that every vocabulary implements it's own FIND, the
>> FIND that's suitable for the vocabulary.
>
>> The implementation of something like number prefixes would then mean
>> to create a vocabulary and write a number prefix recognizing FIND for
>> this vocabulary.
>> The mechanism could be made 100%% compatible to existing ANS Forth
>> implementations - well it could not be implemented in ANS without
>> knowing the system.
>
> How would a file make use of multiple vocabularies in this case?
Every vocabulary has it's own FIND-like.
Say you have your vocabularies in a linked list, you'd implement it
like this way (untested of course):
VARIABLE VOCLINK
: DEFAULT-FIND ... ;
|
| Show full article (1.03Kb) |
| no comments |
|
|
Author: Alex McDonaldAlex McDonald Date: Sep 9, 2007 12:46
> On Sep 9, 4:51 am, "sl...@ jedit.org" jedit.org> wrote:
>>> On Sep 8, 6:34 am, hel...@ gmail.com wrote: >
>>> The idea simply is that every vocabulary implements it's own FIND, the
>>> FIND that's suitable for the vocabulary.
>
>>> The implementation of something like number prefixes would then mean
>>> to create a vocabulary and write a number prefix recognizing FIND for
>>> this vocabulary.
>>> The mechanism could be made 100%% compatible to existing ANS Forth
>>> implementations - well it could not be implemented in ANS without
>>> knowing the system.
>
>> How would a file make use of multiple vocabularies in this case?
>
> Every vocabulary has it's own FIND-like.
> Say you have your vocabularies in a linked list, you'd implement it
> like this way (untested of course): ...
|
| Show full article (2.13Kb) |
| no comments |
|
|
Date: Sep 9, 2007 13:35
On Sep 9, 9:46 pm, Alex McDonald rivadpm.com> wrote:
> Win32Forth must be very innovative :-)
Why not?
> This feature has existed for some time in version 6 of Win3Forth.
I use it also since some time - it's called "context" in my Forths.
> Each
> vocabulary (actually, the WORDLIST that is part of the vocabulary) has
> its own FIND implemented in SEARCH-WORDLIST as a factor. It's
> currently used to allow case sensitive and insensitive searches by
> vocabulary, mainly to support the pseudo vocabulary that interfaces
> with the case-sensitive Windows API.
I use this mechanism also for things like number recognition. It could
also be used for "foo ..." strings (I dont like it) or similar.
> Each wordlist also has its own defining word (most point at the
> standard word HEADER,
This word is inside a standard? HERE HEX and HOLD are in ANS.
> a factor of CREATE) and a word for traversing
> the wordlist (used to dump off the wordlist; the default dumps off in
> reverse insertion order).
|
| Show full article (2.25Kb) |
| no comments |
|
|
Author: Alex McDonaldAlex McDonald Date: Sep 9, 2007 13:51
> On Sep 9, 9:46 pm, Alex McDonald rivadpm.com> wrote:
>>
>> Each wordlist also has its own defining word (most point at the
>> standard word HEADER,
>
> This word is inside a standard? HERE HEX and HOLD are in ANS.
I'm sorry, I meant basic word; it's a Win32Forth word.
>
>> a factor of CREATE) and a word for traversing
>> the wordlist (used to dump off the wordlist; the default dumps off in
>> reverse insertion order).
>
> Mhm. I dont see where it is that useful. But sure, could be in some
> situations.
|
| Show full article (1.61Kb) |
| no comments |
|
|
Date: Sep 9, 2007 14:03
On Sep 9, 10:51 pm, Alex McDonald rivadpm.com> wrote:
>>> As to the proposal for numbers, I prefer Win32Forth's current
>>> mechanism of a list of number scanners.
>
>> Why if you have another way, a better way, that would allow you to use
>> standard words to sort recognition order?
>
> Not required, as there's currently no ambiguity between number
> representations, so an order is unnecessary.
There is no ambiguity with number representations currently known to
Win32Forth. I could well imagine for example date representations that
fit into 32bit but for historical reasons they are 64bit even on a
32bit system. This is only an example...
> The vocabulary way has a
> few issues, for instance, can you tick a number? Anton Ertl and
> Krishna Myneni iirc discussed numbers being full class citizens, and
> their ideas may help you. I can't find the posts using google; perhaps
> someone else can find them.
|
| Show full article (1.29Kb) |
| no comments |
|
|
Author: Alex McDonaldAlex McDonald Date: Sep 10, 2007 05:38
> On Sep 9, 10:51 pm, Alex McDonald rivadpm.com> wrote:
>>>>> As to the proposal for numbers, I prefer Win32Forth's current
>>>> mechanism of a list of number scanners.
>
>>> Why if you have another way, a better way, that would allow you to use
>>> standard words to sort recognition order?
>
>> Not required, as there's currently no ambiguity between number
>> representations, so an order is unnecessary.
>
> There is no ambiguity with number representations currently known to
> Win32Forth. I could well imagine for example date representations that
> fit into 32bit but for historical reasons they are 64bit even on a
> 32bit system. This is only an example...
That's a matter of internal representation; externally, character
strings that make up the class of numbers are (or should be)
unambiguous.
|
| Show full article (1.85Kb) |
| no comments |
|
|
Date: Sep 10, 2007 06:59
On Sep 10, 2:38 pm, Alex McDonald rivadpm.com> wrote:
Hi,>>> The vocabulary way has a
>>> few issues, for instance, can you tick a number? Anton Ertl and
>>> Krishna Myneni iirc discussed numbers being full class citizens, and
>>> their ideas may help you. I can't find the posts using google; perhaps
>>> someone else can find them.
>
>> You can tick a number at my systems. But that's very fragile since the
>> word returned can only hold one number - and that is the last number.
>
> The tick of a number (if they're found by FIND) should be an xt, that
> when executed, returns the number -- not the number itself. I.e.
>
> ' 5 execute -> 5
> : five postpone 5 ; five -> 5
And the XT is bound to something compiled. This compiled piece can
only hold one number. The question is not your example, the question
is what happens if:
|
| Show full article (1.81Kb) |
| no comments |
|
|
|
|
|
Author: Andrew HaleyAndrew Haley Date: Sep 10, 2007 07:15
> This is no proposal but an idea.
> We've seen complains about the number prefix proposal of Forth 200x
> that it would need to change the text interpreter.
Indeed we have. The number prefix proposal of Forth 200x is a bad
idea, and this is one of the many bad things about it.
> How about a general mechanism to hook into the text interpreter?
> This was proposed I think with Win32Forth mechanism, if I remember
> right, but this mechanism at my opinion was not really smart.
> ANS has a way to sort words into groups and re-organize the searching
> order. This way are vocabularies.
> With a small extension to the vocabulary stuff, it would be possible
> to very flexible hook into the text interpreter.
It would, but Forth already is a very flexible extensible language.
|
| Show full article (1.53Kb) |
| no comments |
|
|
|
|
