Re: Parsers for extensible grammars?

From	Don Y <this@is.not.me.com>
Newsgroups	comp.arch.embedded
Subject	Re: Parsers for extensible grammars?
Date	2014-10-24 07:38 -0700
Organization	Aioe.org NNTP Server
Message-ID	<m2do89$hh6$1@speranza.aioe.org> (permalink)
References	<m28vlb$lum$1@speranza.aioe.org> <dcV1w.320229$Hb3.258607@fx03.iad> <ki7h4atruavqscoelr69o3bkm8ubcrjp5i@4ax.com> <m2anti$mp3$1@speranza.aioe.org> <kqji4a9q0093ifp2bmk8lukbk9d2efc1j4@4ax.com>

Show all headers | View raw

Hi George,

On 10/23/2014 1:49 PM, George Neuner wrote:
> On Thu, 23 Oct 2014 04:14:09 -0700, Don Y <this@is.not.me.com> wrote:

>> What I am looking for is the ability to define a set of commands
>> that will "always" be used/useful.  Then, allow others to add
>> to that set of commands to address specific needs that are
>> necessary/unique to their environment.  (i.e., the environment
>> in which these common commands are deployed)
>>
>> Contrived example:
>>
>> :
>>
>> I.e., the "arguments" can't be easily foreseen from the perspective
>> of the first/common commands.
>
> The problem is, that also means the complete set of *functionality*
> can't be foreseen ... else you would have provided for it already.

Exactly.  Because I can't anticipate the functionality that will
be needed in the future.  E.g., the contrived example.

> Your "core" can be operated with it's provided command set, but you
> can't easily provide for new commands targeting an environment you
> know nothing about.

Yes.  And, I can't "guess" to the types of data/actions that may
need to be "encoded" in that command set.

Nor can I ensure the next guy will have the same approach to the
problem -- half the commands may "feel like mine" while the other
half "feel like his/hers".  And, neither group "feels consistent"
with the other.

Like me using infix operators and he using RPN.

> You may want to look up our (ancient) exchange about runtime parser
> generators.  You don't need that here, but the discussion about
> providing for JIT generated code to link to your device API is
> relevant.

Can't.  The (forced) "computer upgrade" cost me my mail archive
(I don't leave mail stored on server  :< )

>>> In either case, the additional parser should get the first crack at
>>> input with Don's own parser as a fallback.
>>
>> Hmmm... I had considered the opposite approach:  let me verify the
>> input is/isn't a "common command" before exposing the input to the
>> "other" parser.  The thought being:  common commands are then
>> implicitly invariant (you can't change the syntax of them) AND
>> they "always work" (even if the additional parser has bugs in its
>> implementation).
>
> You don't want to "front end" the extensions ... if one of your
> commands is redefined, it won't work if you grab it first.

That was exactly the point:  that the common commands are *common*
and always behave exactly the same.  (as well as "always working"
regardless of how much the other guy mucks with the interface).

E.g., if "run" was a common command and he wanted to "overload"
it to add/alter functionality, he'd have to create a new command
("walk_very_very_quickly") to bind to the actions he desires.
Perhaps he wants to turn on a big red light prior to activating
the mechanism ("run"-ing).  If I let him redefine "run" to do this,
I risk him forgetting to verify safety mechanisms are in place
(which other users would ASSUME when invoking "run").

It's a tough call -- assume competence in EVERYTHING?  Or, just
assume competence in their knowledge of their "extensions"??

Thread

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

csiph-web