Groups | Search | Server Info | Keyboard shortcuts | Login | Register [http] [https] [nntp] [nntps]

Groups > comp.arch.embedded > #18962

Re: Parsers for extensible grammars?

Show all headers | View raw

Hi George,

On 10/26/2014 12:47 AM, George Neuner wrote:
> On Fri, 24 Oct 2014 07:38:12 -0700, Don Y <this@is.not.me.com> wrote:
>> On 10/23/2014 1:49 PM, George Neuner wrote:
>>
>>> 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.
>
> I like Simon's idea re: DCL.  I only used VMS briefly in school and I
> wasn't aware that DCL could be extended in that way.  It's a nice way
> to regularize at least the argument input.

I'm looking into the implementation to see which ideas I can borrow.
I think I have a "prettier" way of creating the syntax.

> If all you want is to regularize input, another way might be to borrow
> from the HTML fast-cgi interface.  It doesn't guarantee anything about
> interoperability per se, but it does arrange that programs get their
> arguments in recognizable key:value pairs.
>
>> The (forced) "computer upgrade" cost me my mail archive
>> (I don't leave mail stored on server  :< )
>
> Ouch. I don't leave anything on provider servers either, but my own
> IMAP server is backed up regularly.

I move my mail archive to a little server that does my DNS, TFTP,
font, DHCP, etc. services periodically.  Lets me view it as mail
(instead of as a raw "mailbox").  That box is the only thing
that runs 24/7/365, here so it's the destination for just about
everything!

[It's more of an appliance than a server]

In my eagerness to get rid of kit before the annual equipment
upgrade cycle, I opted to replace that box -- it had been running for
several years (uptime was over 1000 days) so I felt it "deserved"
to be replaced.

I moved everything onto a *smaller*, faster, less power-hungry box.
Life was good.  Another bit of kit into the bin!  :>

Unfortunately, the box only lasted a few weeks before the disk
(apparently) spun a bearing.  Current thinking is it wasn't a
suitable orientation to *mount* the disk and/or too close to
the main heatsink (the box is REALLY small!  had to shoehorn the
2.5" disk in there just to get it to fit!).

Anyway, easy to recreate everything for which I had sources -- even
my databases!  Mail archive has never been something I considered
"precious" so that was *the* backup (aside from what was on my
MUA at the time).

Rather than risk another disk in the "new" appliance (which was never
intended to have a physical disk drive within), I replaced *that*
with another appliance that *does* accommodate a disk drive (even
having a fan just for the drive).

<shrug>  Moral:  "If it ain't broke, don't fix it!"

When the box that hosts the MUA went down, I took the opportunity
to replace it (preserving the mail that *was* on it at the time).

So, I managed to get rid of some kit -- and the most recent chunk of
my mail archive in the process.  <frown>

> What I was thinking about is less important given compile time parser
> generation ... we were talking about providing API object and entry
> point addresses to runtime generated code.
>
> The relevance (if any) depends on whether you want to allow grammar
> extensions direct access to your device API:  i.e. whether the
> extensions should be allowed to manipulate your (part of the) device
> or whether they have to go through your provided language to do it.

The goal is for people to be able to extend the "system" -- in whichever
directions THEY choose -- and provide a simple way of configuring those
enhancements (software/hardware/systems).  It's a "low value" operation
and, as such, doesn't merit lots of resources.  OTOH, it shouldn't
require "surgery" to tweek variables deep in the sources (these sorts
of "selections" should be very visible without detailed inspection).

I've considered it in the context of "settings" -- almost like twiddling
envars -- except it need not be.  I.e., the "commands" could initiate
*actions* if so desired.

I *hadn't* considered it as a "programming/scripting language" (which
is why I called it a "command parser" and presented command line
argument parsing and configuration file parsing as the examples to
illustrate its intent.

There *could* be some value to a real procedural language, there.
But, when I conveyed the "Forth" suggestion to colleagues, it didn't
fare well (I suspect that had more to do with "Forth" than the
"programming language aspect" of the idea -- almost provincial!

[No desire to take on THAT fight, thankyouverymuch!]

>>>>> 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).
>
> That's the safe approach, but it's not terribly friendly ...

That's why they were called "common commands" -- things that you can
*rely* upon regardless of implementation.

> particularly in the case of a reusable component where you don't have
> any say in the use.  A new developer may want to completely change the
> approach to the command set.

Well, he can always rewrite the subsystem!  :>  I doubt it will take
me more than a week or two to put it in place (though in this first
instance, there are two other subsystems that I want to add/modify
in the process for a more integrated experience)

>> It's a tough call -- assume competence in EVERYTHING?  Or, just
>> assume competence in their knowledge of their "extensions"??
>
> It's reasonable to expect that many developers will have little
> experience with _formal_ parsing methods and tools ... quite a lot of
> applications can get by with RegEx or even just separator tokenization
> and have no need of any formal grammar.

Exactly.  That was my (upthread) observation of what I've encountered
in config file parsers, command line option parsing, etc.  When you
consider how "rich" some of those environments are (options, etc.),
it's a wonder that so much ad hoc parsing is done!  I can see
"evolution"/feeping creaturism explaining some of it (i.e., "it wasn't
this complex when we started") but I doubt that's the real cause.

I suspect it's more one of familiarity:  you write "generic code"
everyday.  So, writing something to extract a numeric value from
the "second whitespace-delimited field" in a statement is trivial.
OTOH, writing a formal grammar so that a *tool* can do this for
you AUTOMATICALLY probably means you spend more time relearning the
tool than you would have spent writing the code!

<shrug>

Back to comp.arch.embedded | Previous | Next — Previous in thread | Next in thread | Find similar | Unroll thread

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