Groups | Search | Server Info | Keyboard shortcuts | Login | Register [http] [https] [nntp] [nntps]
Groups > comp.arch.embedded > #18900 > unrolled thread
| Started by | Don Y <this@is.not.me.com> |
|---|---|
| First post | 2014-10-22 12:14 -0700 |
| Last post | 2014-10-25 21:11 -0400 |
| Articles | 4 on this page of 44 — 12 participants |
Back to article view | Back to comp.arch.embedded
Parsers for extensible grammars? Don Y <this@is.not.me.com> - 2014-10-22 12:14 -0700
Re: Parsers for extensible grammars? Don Y <this@is.not.me.com> - 2014-10-22 12:17 -0700
Re: Parsers for extensible grammars? Tim Wescott <seemywebsite@myfooter.really> - 2014-10-22 15:13 -0500
Re: Parsers for extensible grammars? Don Y <this@is.not.me.com> - 2014-10-22 22:54 -0700
Re: Parsers for extensible grammars? Stefan Reuther <stefan.news@arcor.de> - 2014-10-23 18:36 +0200
Re: Parsers for extensible grammars? Don Y <this@is.not.me.com> - 2014-10-23 12:10 -0700
Re: Parsers for extensible grammars? Tim Wescott <seemywebsite@myfooter.really> - 2014-10-23 13:45 -0500
Re: Parsers for extensible grammars? Don Y <this@is.not.me.com> - 2014-10-23 12:15 -0700
Re: Parsers for extensible grammars? jim.brakefield@ieee.org - 2014-10-24 07:05 -0700
Re: Parsers for extensible grammars? Don Y <this@is.not.me.com> - 2014-10-24 08:04 -0700
Re: Parsers for extensible grammars? Clifford Heath <no.spam@please.net> - 2014-10-23 08:22 +1100
Re: Parsers for extensible grammars? Don Y <this@is.not.me.com> - 2014-10-22 23:25 -0700
Re: Parsers for extensible grammars? George Neuner <gneuner2@comcast.net> - 2014-10-23 04:45 -0400
Re: Parsers for extensible grammars? Don Y <this@is.not.me.com> - 2014-10-23 04:14 -0700
Re: Parsers for extensible grammars? George Neuner <gneuner2@comcast.net> - 2014-10-23 16:49 -0400
Re: Parsers for extensible grammars? Don Y <this@is.not.me.com> - 2014-10-24 07:38 -0700
Re: Parsers for extensible grammars? George Neuner <gneuner2@comcast.net> - 2014-10-26 03:47 -0400
Re: Parsers for extensible grammars? Don Y <this@is.not.me.com> - 2014-10-26 08:41 -0700
Re: Parsers for extensible grammars? George Neuner <gneuner2@comcast.net> - 2014-10-26 14:36 -0400
Re: Parsers for extensible grammars? Don Y <this@is.not.me.com> - 2014-10-26 12:37 -0700
Re: Parsers for extensible grammars? George Neuner <gneuner2@comcast.net> - 2014-10-26 18:54 -0400
Re: Parsers for extensible grammars? Simon Clubley <clubley@remove_me.eisner.decus.org-Earth.UFP> - 2014-10-25 02:02 +0000
Re: Parsers for extensible grammars? Don Y <this@is.not.me.com> - 2014-10-25 01:56 -0700
Re: Parsers for extensible grammars? Simon Clubley <clubley@remove_me.eisner.decus.org-Earth.UFP> - 2014-10-25 11:15 +0000
Re: Parsers for extensible grammars? Don Y <this@is.not.me.com> - 2014-10-25 10:21 -0700
Re: Parsers for extensible grammars? Simon Clubley <clubley@remove_me.eisner.decus.org-Earth.UFP> - 2014-10-26 01:05 +0000
Re: Parsers for extensible grammars? Don Y <this@is.not.me.com> - 2014-10-25 19:37 -0700
Re: Parsers for extensible grammars? Andrew Smallshaw <andrews@sdf.lonestar.org> - 2014-10-23 20:04 +0000
Re: Parsers for extensible grammars? Les Cargill <lcargill99@comcast.com> - 2014-10-23 22:30 -0500
Re: Parsers for extensible grammars? rickman <gnuarm@gmail.com> - 2014-10-25 13:36 -0400
Re: Parsers for extensible grammars? Les Cargill <lcargill99@comcast.com> - 2014-10-25 13:14 -0500
Re: Parsers for extensible grammars? rickman <gnuarm@gmail.com> - 2014-10-25 14:23 -0400
Re: Parsers for extensible grammars? Les Cargill <lcargill99@comcast.com> - 2014-10-26 00:50 -0500
Re: Parsers for extensible grammars? albert@spenarnc.xs4all.nl (Albert van der Horst) - 2014-10-26 19:21 +0000
Re: Parsers for extensible grammars? rickman <gnuarm@gmail.com> - 2014-10-26 15:29 -0400
Re: Parsers for extensible grammars? Paul E Bennett <Paul_E.Bennett@topmail.co.uk> - 2014-10-24 09:56 +0100
Re: Parsers for extensible grammars? Don Y <this@is.not.me.com> - 2014-10-24 07:46 -0700
Re: Parsers for extensible grammars? Don Y <this@is.not.me.com> - 2014-10-25 19:54 -0700
Re: Parsers for extensible grammars? Simon Clubley <clubley@remove_me.eisner.decus.org-Earth.UFP> - 2014-10-26 12:15 +0000
Re: Parsers for extensible grammars? Don Y <this@is.not.me.com> - 2014-10-26 09:02 -0700
Re: Parsers for extensible grammars? rickman <gnuarm@gmail.com> - 2014-10-26 12:13 -0400
Re: Parsers for extensible grammars? rickman <gnuarm@gmail.com> - 2014-10-25 13:35 -0400
Re: Parsers for extensible grammars? Paul E Bennett <Paul_E.Bennett@topmail.co.uk> - 2014-10-26 01:29 +0100
Re: Parsers for extensible grammars? rickman <gnuarm@gmail.com> - 2014-10-25 21:11 -0400
Page 3 of 3 — ← Prev page 1 2 [3]
| From | rickman <gnuarm@gmail.com> |
|---|---|
| Date | 2014-10-26 12:13 -0400 |
| Message-ID | <m2j6k3$tpt$1@dont-email.me> |
| In reply to | #18963 |
On 10/26/2014 12:02 PM, Don Y wrote:
> On 10/26/2014 5:15 AM, Simon Clubley wrote:
>> On 2014-10-26, Don Y <this@is.not.me.com> wrote:
>>> On 10/24/2014 7:46 AM, Don Y wrote:
>>>>
>>>> I'll have to think real hard on that. If the "typical" sorts
>>>> of things "look mildly familiar", then it might be possible
>>>> to slip it in under the radar (without religious issues biasing
>>>> the decision/acceptance). OTOH, if things start to look too
>>>> funky, then it just gives people an excuse to dislike it. :-/
>>>
>>> Wow! I was *amazed* at the intensity of the reactions to this
>>> suggestion when I circulated it among colleagues! In hindsight,
>>> I wish I had presented the suggestion as "a generic scripting
>>> language" instead of "Forth" as many of the replies seemed to
>>> *choke* on the mention of Forth! <frown> Despite the fact
>>> that several of us use Open Firmware.
>>
>> Do any of these people use RPN calculators ?
>
> I'm sure they/we all have in the past (I don't use a calculator).
>
> And, several of us "regularly" use Forth in configuring, for example,
> SPARCstations, etc. (OpenFirmware)!
>
> But, it's not something that is done *often* so there's always
> a relearning experience involved. Forth is quirky -- remembering
> which words serve which functionality, etc. (what word displays
> my IP address? how do I remove an alias from NVRAMrc? etc.)
>
> By contrast, they/we have probably used a BASIC dialect even
> LESS recently than OFW -- yet, I would imagine all of us could
> craft a little BASIC "script" in a matter of seconds... and, be
> assured it would work first time.
>
> <shrug> Dunno. I'm only guessing as to the source of the
> "resistance" (resentment?). As I said, I tried to shift the
> discussion away from Forth, per se, to see if the idea of a
> procedural language was the issue ("We don't need that level
> of functionality -- just parse COMMANDS!") or the proposed
> language...
>
> I'll revisit it, later (just for my own edification) but
> won't chase that approach after this sort of "reception" :-/
What exactly is the environment for this command parser? Will it run as
a program under an OS? As a command processor for the OS? At the same
level as OpenFirmware? If it runs as an app, then any Forth for that OS
is a nearly instant solution. You can just ignore the added
capabilities. The memory foot print of any Forth I have used is very
small compared to the OS. As to the comment, "We don't need that level
> of functionality -- just parse COMMANDS!", Forth largely *is* a
command parser.
I can't explain why you can remember how to display an IP address in
BASIC but not in Forth. That would seem to be a personal problem. How
do you "remove an alias from NVRAMrc?" using BASIC? Is that really a
program you can write in seconds and have work the first time? I'm not
sure what that even means, lol.
--
Rick
[toc] | [prev] | [next] | [standalone]
| From | rickman <gnuarm@gmail.com> |
|---|---|
| Date | 2014-10-25 13:35 -0400 |
| Message-ID | <m2gn14$lpv$1@dont-email.me> |
| In reply to | #18931 |
On 10/24/2014 4:56 AM, Paul E Bennett wrote: > Don Y wrote: > >> Hi, >> >> [I probably should direct this at George... :> ] >> >> I'm writing a command parser. Some set of commands are "common". >> But, other instances of the parser are augmented with additional >> commands/syntax. >> >> [These additions are known at compile time, not "dynamic"] >> >> Ideally, I want a solution that allows folks developing those >> "other" commands to just "bolt onto" what I have done. E.g., >> creating a single "grammar definition" (lex/yacc) is probably >> not a good way to go (IME, most small parsers tend to be ad hoc). >> >> [Note: I can't even guarantee that the extensions will be >> consistent or "harmonious" with the grammar that I implement] >> >> A naive approach (?) might be for my code to take a crack at >> a particular "statement"/command and, in case of FAIL, invoke >> some bolt-on parser to give it a chance to make sense out of >> the input. If *it* FAILs, then the input is invalid, etc. >> >> This sounds like an incredible kluge. Any better suggestions? > > Hi Don, > > Have you looked at Forth? What you are describing sounds like the problem > that Forth solved back in 1968. It is the sort of thing that Forth > programmers have been doing for nearly 50 years and it works very > successfully for us. > > See <http://www.mpeforth.com/> and <http://www.forth.com/> Don is a hard person to suggest things to. I'm actually surprised that his response was as positive as it was. I have had great success at solving many problems with Forth. There are text file formats can be read by treating various words as commands, defining those words in Forth to execute while reading the file and storing the numeric data where it needs to be stored. Easy peasy. Not quite the same thing as what Don is likely doing, but very similar. Don may be looking for something that will let him check the input for the correct syntax, number of values, etc. But as usual he has not really defined the problem he is trying to solve. -- Rick
[toc] | [prev] | [next] | [standalone]
| From | Paul E Bennett <Paul_E.Bennett@topmail.co.uk> |
|---|---|
| Date | 2014-10-26 01:29 +0100 |
| Message-ID | <cb2tjjFcqd1U1@mid.individual.net> |
| In reply to | #18949 |
rickman wrote: > On 10/24/2014 4:56 AM, Paul E Bennett wrote: >> Don Y wrote: >> >>> Hi, >>> >>> [I probably should direct this at George... :> ] >>> >>> I'm writing a command parser. Some set of commands are "common". >>> But, other instances of the parser are augmented with additional >>> commands/syntax. >>> >>> [These additions are known at compile time, not "dynamic"] >>> >>> Ideally, I want a solution that allows folks developing those >>> "other" commands to just "bolt onto" what I have done. E.g., >>> creating a single "grammar definition" (lex/yacc) is probably >>> not a good way to go (IME, most small parsers tend to be ad hoc). >>> >>> [Note: I can't even guarantee that the extensions will be >>> consistent or "harmonious" with the grammar that I implement] >>> >>> A naive approach (?) might be for my code to take a crack at >>> a particular "statement"/command and, in case of FAIL, invoke >>> some bolt-on parser to give it a chance to make sense out of >>> the input. If *it* FAILs, then the input is invalid, etc. >>> >>> This sounds like an incredible kluge. Any better suggestions? >> >> Hi Don, >> >> Have you looked at Forth? What you are describing sounds like the problem >> that Forth solved back in 1968. It is the sort of thing that Forth >> programmers have been doing for nearly 50 years and it works very >> successfully for us. >> >> See <http://www.mpeforth.com/> and <http://www.forth.com/> > > Don is a hard person to suggest things to. I'm actually surprised that > his response was as positive as it was. > > I have had great success at solving many problems with Forth. There are > text file formats can be read by treating various words as commands, > defining those words in Forth to execute while reading the file and > storing the numeric data where it needs to be stored. Easy peasy. Not > quite the same thing as what Don is likely doing, but very similar. > > Don may be looking for something that will let him check the input for > the correct syntax, number of values, etc. But as usual he has not > really defined the problem he is trying to solve. I don't know if Don has tried playing with Forth or not, I just made a suggestion that what he was seeking to do sounded somewhat Forth-like in nature. With somewhat more difficulty he could probably look at re-creating a MSDOS type environment which would also suit the bill (new commands in batch files etc or added programmes in the COMMAND directory). You are probably right about a lack of Clear, Concise, Correct, Coherent, Complete & Confirmable (Testable) specification of the requirements. -- ******************************************************************** Paul E. Bennett IEng MIET.....<email://Paul_E.Bennett@topmail.co.uk> Forth based HIDECS Consultancy.............<http://www.hidecs.co.uk> Mob: +44 (0)7811-639972 Tel: +44 (0)1235-510979 Going Forth Safely ..... EBA. www.electric-boat-association.org.uk.. ********************************************************************
[toc] | [prev] | [next] | [standalone]
| From | rickman <gnuarm@gmail.com> |
|---|---|
| Date | 2014-10-25 21:11 -0400 |
| Message-ID | <m2hhoe$b8r$1@dont-email.me> |
| In reply to | #18953 |
On 10/25/2014 8:29 PM, Paul E Bennett wrote: > rickman wrote: >> >> Don may be looking for something that will let him check the input for >> the correct syntax, number of values, etc. But as usual he has not >> really defined the problem he is trying to solve. > > I don't know if Don has tried playing with Forth or not, I just made a > suggestion that what he was seeking to do sounded somewhat Forth-like in > nature. With somewhat more difficulty he could probably look at re-creating > a MSDOS type environment which would also suit the bill (new commands in > batch files etc or added programmes in the COMMAND directory). > > You are probably right about a lack of Clear, Concise, Correct, Coherent, > Complete & Confirmable (Testable) specification of the requirements. It sounds like you are setting the bar a bit higher than I was looking for. I'd just like to get an idea of what he is doing. There is a long history of Don's posts asking for info on a very specific item. When people ask him for details which are often where the crux of the problem lies, he shares sparingly... but only in the sense of info, while being very prolific with words. As people try to suggest he is decomposing the problem in an odd way which makes the problem harder to solve he throws out more details that seem to justify a rather unique approach. In the end those who are trying to help get frustrated because of the difficulty and Don gets frustrated because people seem to be argumentative rather than helpful. I think his original post on this was something along the lines of, "How long is a piece of string?" or maybe a better analogy is, "Where can I get some string that will be long enough to do my job and strong enough to not break on the job but will break when I want to break it." I haven't read all the chit-chat that has evolved from that. I was going to suggest Forth might be useful and saw your post. -- Rick
[toc] | [prev] | [standalone]
Page 3 of 3 — ← Prev page 1 2 [3]
Back to top | Article view | comp.arch.embedded
csiph-web