> On Sep 10, 4:15 pm, Andrew Haley
> wrote:>>> 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.
>>
>> Not all possibilities of extended flexibility are good. Some of them,
>> such as this one, will in most cases only make programs harder to
>> read. A hookable text interpreter will support cutesy-pie syntax with
>> no proper justification, such as, for example, the number prefix
>> proposal of Forth 200x. And, indeed, each vocabulary could have a
>> different syntax for numbers. That'll help readability? Yeah, of
>> course it will.
>>
>> How about you come up with some kind of application justification for
>> such a hookable text interpreter? Not just "look at this nice
>> syntax", but a case where an application is made significantly easier
>> to write/mintain/whatever. I doubt that there is one, but I'm willing
>> to be convinced.
> I did not make a proposal for a syntax. You're not reading
> exactly. I made a simple idea description.
I know. That's why I'm asking for an example of a case where it might
actually be useful to someone trying to solve a real problem.
> So for example it helps with modularity: I dont need to design my text
> interpreter to recognize floats or doubles. These things are perfectly
> possible in modules that write the recognizers/contexts.
How is extending the text interpreter by this means easier than simply
editing then reloading the text interpreter?
A vectored NUMBER is not a totally disastrous idea, and I have seen it
used (by Forth Inc, as it happens) to supply a Forth system that can
be extended from being integer only to full floating-point support.
That made sense in the particular context of the way their own
offering was packaged, but I don't think it makes sense to be more
general than that.
> I also can make me an opinion about "foo ..." strings without to
> rewrite essential parts of my system. To test this I simply write an
> includeable source that does everything needed. That way I was also
> able to testdrive the backticks from FreeForth for my system and I did
> like it, so I included it into my system (using this mechanism, except
> for things that are CREATEd). You can turn it off if you do not like
> it ;) You would not be able to turn it off if it would not be
> implemented with the flexible mechanism. Again, I made no proposal
> here,
> I only told an idea. You dont like it. Fine. Tell me, tell reasons
> and do not write a flame only.
OK, my reason it this: it's useless. In fact, I think it's worse than
useless in that it will allow a thousand incompatible syntaxes to
bloom. If used, it will make Forth programs harder to read. Is that
a flame? I don't think so.
Andrew.
