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-25 19:37 -0700
Organization	Aioe.org NNTP Server
Message-ID	<m2hmpl$gap$1@speranza.aioe.org> (permalink)
References	(4 earlier) <m2f0av$ku0$1@dont-email.me> <m2foj0$34r$1@speranza.aioe.org> <m2g0oj$au3$1@dont-email.me> <m2gm65$egq$1@speranza.aioe.org> <m2hhcb$abn$1@dont-email.me>

Show all headers | View raw

On 10/25/2014 6:05 PM, Simon Clubley wrote:
> On 2014-10-25, Don Y <this@is.not.me.com> wrote:
>> On 10/25/2014 4:15 AM, Simon Clubley wrote:
>>>
>>> Commands can exist outside of the above infrastructure if one wishes;
>>> they are called foreign commands and are treated pretty much like a
>>> Unix command would be - there's no validation of options prior to
>>> the executable starting and hence there's no nicely pre-parsed options
>>> and option values ready to be read from within the program itself.
>>
>> You can *freely* mark any command as either type?  I.e., can I mark
>> a command that relies on the DCL stuff for option parsing as a FOREIGN
>> command?  And, thus, screw it up (at runtime)?
>
> Yes, but it would fail in a clean way with a status code returned from
> the CLI routine called by the program to return the (non-existent)
> pre-parsed information.

Understood.  I.e., the DCL-ed executables aren't *fed* arguments
that the front-end has testified as "valid".  Rather, it *fetches*
that information from the front end.  As such, if the front end wasn't
in place when the executable was invoked, the executable is aware of that.

> The idea behind pointing you to the DCL CLD material was to give you
> some possible ideas about how extendable CLIs with validated options
> are handled in another environment (ie: VMS).

Yes.

> Like I said at the time, it's not an exact match for your requirements
> but I thought you might be interested in seeing how a similar problem
> was handled in VMS, including the syntax used in the command definition
> file (and compare it to how the problem is fully pushed to the executable
> itself in Unix land).

Exactly!

>>> IOW, having foreign commands available as an option doesn't stop you
>>> from also having the native DCL integrated approach. If you try to run
>>> a DCL integrated executable as a foreign command, no values will be
>>> available to read from within your program so you are forced to run it
>>> via the DCL mechanism above which means you also get the DCL level
>>> validation as well.
>>
>> So, this (DCL) mechanism is meant as an *aid*/service -- not as a means
>> of ensuring software integrity (?).
>
> It's a way of expressing an expected structure for a command line which
> can be somewhat validated by DCL before the program even starts and
> provides a robust, operating system level, method for a program to
> obtain command line parameters and options in a way (and with
> functionality) that leaves getopt and friends standing in the dust.
>
> The relevance here is that I've encountered people who have never
> been exposed to the VMS way of handling this and who think that ad-hoc
> getopt style functionality is the only _possible_ way to parse command
> lines. I just wanted to make reference to another way of doing this in
> case it gave you some ideas even though there's probably nothing you
> can _directly_ use here.

Understood.  I'm not fond of the VMS syntax.  But, will be studying
the implementation to see if I can extract some ideas and apply them
to a more suitable syntax.

> Sometimes Don you leave your questions wide open, presumably in order
> to invite a wide range of options in response, including ones you had
> never even considered. The difficulty with that is that sometimes it's
> hard to understand what additional unspoken constraints might exist. :-)

I pass along the minimum constraints under which I am operating.  If I
*add* constraints, then I risk steering solutions into a specific direction
that isn't necessarily required for the problem at hand.  Or, discounting
solutions that could be viable.

I engage clients with the same sort of approach:  "Is what you are
telling me a REQUIREMENT or just your idea of how I *might* approach
the problem?"  The fewer the requirements, the more flexibility in
the solution.  This almost always leads to a more optimized solution.

By contrast, wanting extra ARTIFICIAL constraints boxes the design into
a corner.  "Why are you doing it like that?"  "Because that's how everyone
else does it!" or "Because that's how I *thought* it would be done."

In this case, I asked for a "command parser" that was "extensible".  And,
indicated that those extensions would be implemented at compile time
(so, any solution need not accommodate dynamic modifications).  I also
introduced contrived examples for folks who couldn't think entirely in
the abstract:  "Imagine these were the common commands and you wanted
to add commands LIKE these..."  Anything beyond this would change the
problem definition.

Note that I didn't ask for a "programming language" -- or even a
scripting language (yet, at least one proposed solution fits that
description AND fits my requirement!).

OTOH, if I had augmented my question as "an extensible scripting language",
I would risk YOUR solution potentially disqualifying itself.  :-/

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