Parsers for extensible grammars?

This is one implementation.

Other systems just look up the word in the dictionary. If it matches, it is executed. Numbers are handled by accepting an incomplete match, i.e. the word "1" accepts all numbers starting with 1.

(I see two advantages. You can have strings as easy as numbers, and the system is extensible.)

Although it is stated in the Standard that TO is required to parse, it has been discovered that one can't write a standard program to test this. So implementations of TO are possible that do not parse at all and are standard compliant. That is not to say that parsing words are not possible or useful. One of my favorites is the defining word OS-IMPORT : "/usr/bin/ee" OS-IMPORT my-favorite-editor

This defines a word my-favorite-editor with a path as given.

my-favorite-edit a b c

generates a string "/usr/bin/ee a b c" and passes it to SYSTEM.

I'm inclined to say that a stack works purely sequential, and and infix notation with high priority operators and brackets. give much more of a visual clue about what is intended. a*b+c*d (after training) groups things together. For a b * c d * + the question "what is the first term of the addition?" is indeed slightly harder to answer. You have to think, the visual system doesn't help you here.

Groetjes Albert.

--
Albert van der Horst, UTRECHT,THE NETHERLANDS 
Economic growth -- being exponential -- ultimately falters. 
 Click to see the full signature
Reply to
Albert van der Horst
Loading thread data ...

Really? You can't see the bias from your early education where you learned to use parentheses? I can clearly pick out the terms from your example. If you asked about a more complex equation, then yes, postfix would not be as clear. But that is a very tiny part of Forth and I have yet to find it to be a problem. When I have an equation much more complex than the example you give I usually break it down into simpler pieces anyway no matter the language.

--

Rick
Reply to
rickman

I have to provide some of these features to get ANY system configured, etc. I can do this as a completely independant "service" and require others to invent their own solution to THEIR problems (the customizations that they may implement).

*Or*, I can put facilities in place that encourage them to "do as I have done" in the hopes of a tighter, more consistent implementation. I expect people to be inherently lazy and opt to *modify* something that is proven as "working" rather than trying to create something new, from scratch.

But, in doing so, I have to make a decent attempt at anticipating the sorts of things they *may* want/need to do.

(e.g., expecting everything to be VERB NOUN pairs might rub some folks the wrong way)

That's true of all tools. How many folks avoid dynamic memory allocation in the belief that it is (inherently!) unsafe? Or, recursive implementations ("what happens if the recursion never stops?" "Well, same thing if your iteration never stops!")

I don't know as I can't envision the varieties of hardware (and software) that will be globbed on. E.g., I had not envisioned the need for a conditional operation -- yet, in hindsight, it seems like it could be extremely useful! ("Do this -- unless you CAN'T! In which case, do this OTHER thing!")

But, how far do you take this before you begin to delve into the realm of "just add it to the executable directly"?

[When I offered the "C interpreter" as an alternative to Forth -- to see if the resistance was due to the language or the mechanism -- this was the reply! "If you're going to write code, then why create another means of writing code OUTSIDE the system??"]

Or, a lack of patience -- as exemplified by wanting to write code "on day one" (before they even know where that code is *headed*).

My experiences with lex/yacc were far less "pleasant" than writing arbitrarily complex code in a procedural/object language! Too much head scratching as there were interactions "across" the grammar that were only apparent in hindsight. The way I thought of the various constructs "as a human being" was very different from the way the tools NEEDED me to think of them. This doesn't appear in *most* languages (aside from unfortunate issues like "foo =- 2;")

There tends to be far more abstraction involved. People seem to have a problem with abstraction -- always wanting to know "why do you want to do that" or "what are you trying to do".

"Timmy has three apples. Mary has one. How many apples would Timmy have to give to Mary in order for them to each have the same number of apples?"

"Why should Timmy have to give her ANY? Why couldn't *Mary* bring the right number of apples to school??"

[Of course, the correct answer is that Timmy should quickly EAT two of his apples and the problem then disappears! :> ]

Check your mail. I think the solution I proposed will be *so* tempting to others that they'll just "cut and paste; edit to taste". I figured easier to take this offlist than deal with the inevitable complaints about "lengthy posts"... :>

But even big systems often have "regions" in which severe constraints are placed on the implementation. E.g., many of those "big Linux implementation" compress the kernel to economize on FLASH/ROM -- this suggests an unwillingness to add "unnecessary resources" for a one-time event (decompressing the kernel/system on IPL). The same sorts of arguments can apply to "setting configuration options" ("Can't we just set some bitmaps in a hidden corner of FLASH?")

Or, things like delivering options in BOOTP packets, etc. Sometimes you just can't "do what you want" (or what would be "ideal")

Reply to
Don Y

That shows a lack of imagination. The reason for providing a scripting language is obvious - assuming there is any possible use for scripting in the 1st place.

You would have had a much different experience with a recursive decent LL tool. You still would have had problems until you understood the grammar model, but your errors would have been somewhat easier to locate. Some tools like Antlr (particularly using the Antlrworks GUI) are really helpful for locating problems.

Mary has 5 kittens. If she gives 2 kittens to Timmy, how many kittens will Mary have?

5! Mary won't give Timmy any kittens.

Your point re: abstraction is valid ... but the response to it is that the abstraction of a formal grammar is the entire point of using a parser generator.

True. But Linux tries to be all things to all people. In the "normal" desktop/server environment, there really is no reason for the kernel to be compressed - it's only ~100KB and damn few distributions will even start in less than 256MB. Besides which, the uncompressed kernel is there on the disk too - used for paging kernel code if that is enabled.

And how often is compiling for a small system done *on* the small system? That's what cross-development is for and I think you can count on small developers to understand that (at least for the foreseeable future).

George

Reply to
George Neuner

ElectronDepot website is not affiliated with any of the manufacturers or service providers discussed here. All logos and trade names are the property of their respective owners.