felix-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Guillaume Nodet <gno...@gmail.com>
Subject [Gogo] Grammar and commands
Date Fri, 21 Aug 2009 15:50:53 GMT
Right, I think it makes sense to define the grammar.
But the grammar just defines ... well, the syntax, not the semantics.
I think most of the discussion is about what semantic to apply on the
grammar.

For commands, imnsho, I think we should discuss and encourage the use of
what I committed in

https://svn.apache.org/repos/asf/felix/trunk/gogo/commands/src/main/java/org/apache/felix/gogo/commands/

Those are much more powerfull than a simple method on an object, because
they allow:
  * help on the command
  * automatic parsing / conversion of arguments
  * variable number of arguments
  * command line switches

We have a bunch of commands defined in Karaf that are not specific to Karaf,
so it would make sense to move them in a command ground.
You can find some of them at:

https://svn.apache.org/repos/asf/felix/trunk/karaf/gshell/gshell-osgi/src/main/java/org/apache/felix/karaf/gshell/osgi/
The only problem is that those are slightly tied to blueprint atm.

On Fri, Aug 21, 2009 at 16:54, David Savage <dave.savage@paremus.com> wrote:

> Hi there,
>
> Seems like a good time to wade into the discussion ;) it seems like it
> could be beneficial to start looking at the TSL syntax from the point
> of view of a formal grammar specification such as ANTLR? Currently
> most of the tests are via unit tests and the parsing is done by custom
> java code. The danger is that without a formal grammar specification
> we may "fix" one part of the parser to handle one use case only to
> expose a secondary problem. Unit tests are certainly one way to catch
> this but they can only be as good as the number of tests we define,
> where as I believe a logically consistent grammar is a test in itself?
>
> Of course this may also be a fools errand (firstly as I have no
> experience with antlr grammars) and looking at this link (which I came
> at by searching for "bash antlr grammar" in google) it may not even be
> possible - though the post is very old:
>
> http://www.antlr.org/pipermail/antlr-interest/2006-May/016235.html
>
> Wondering if there are any language experts following this list who can
> comment?
>
> I'm also wondering if it may make sense to extract the shell that
> interprets the commands and the runtime that provides the commands. I
> really like the TSL impl but in the end it's just one possible way of
> running commands? One of the really nice things about RFC 132 is it
> provides a common way for developers to add commands in osgi, but how
> we refer to those commands is a secondary issue, here thinking of the
> sh,csh,bash type debate...
>
> Finally though the echo echo type debate is good for simplifying the
> problem down in unit tests in email it does depend on how we think
> echo is defined. Does echo return a value or does it write the result
> to the stream or both (?!). It seems like it would be useful to define
> a set of commands for debate that are unambiguous? I guess these could
> be abstract commands which could go on a wiki or some such? Some
> examples:
>
> nsc -> no such command
> void -> command that does nothing and returns nothing
> echo -s hello -> echo "hello" to stream
> echo -v -> echo "hello" to value
> echo -sv hello -> echo "hello" to stream and value
> array a b c -> returns [a,b,c] as an array
>
> Others?
>
> Just my 2 pence anyway...
>
> Regards,
>
> Dave
>
> On Thu, Aug 20, 2009 at 5:45 PM, Guillaume Nodet<gnodet@gmail.com> wrote:
> > On Thu, Aug 20, 2009 at 15:40, Derek Baum <derek.baum@paremus.com>
> wrote:
> >
> >>
> >> > I disagree with having eval as a command.  The reason is that is has
> two
> >> sides effects:
> >> >  * all parameters are evaluated once more, so that $xxx expansion will
> be
> >> > done once again, and it could lead to unwanted results
> >>
> >> this is offset by not implicitly evaluating the args - re-evaluation
> >> only occurs when explicitly invoking eval.
> >>
> >> >  * all parameters are converted to strings, which i think is not what
> is
> >> expected.
> >>
> >> I'm not sure this is a problem. The 3.patch eval is like eval in bash,
> >> and can be used to re-evaluate a string as a script.
> >>
> >> Derek
> >>
> >
> >
> > Well, I think this really lead to undesirable effects:
> >> x = <bundle 0>
> > ...
> >> $x toString
> > org.apache.felix.framework [0]
> >> eval $x toString
> >  Command not found *:org.apache.felix.framework
> >
> > I think both should be identical.
> > If you want to evaluate the arguments as a fully new command line, you
> could
> > use quoting
> >> eval "$x toString"
> > But the opposite can't be done.
> > So I still think we should come back to my earlier proposal about making
> it
> > a real keyword instead of a command.
> >
> > I think this is independant of wether arguments are re-parsed, though
> they
> > are related.
> >
> > I've also spotted another problem, but this looks like a different
> problem:
> >> echo "$x"
> > java.lang.Exception: Unable to convert from [org.apache.felix.framework
> [0]]
> > to java.util.List<java.lang.String>(error converting collection entry)
> >
> > I would have thought it would behave the same as
> >> echo <$x toString>
> >
> >
> > --
> > Cheers,
> > Guillaume Nodet
> > ------------------------
> > Blog: http://gnodet.blogspot.com/
> > ------------------------
> > Open Source SOA
> > http://fusesource.com
> >
>



-- 
Cheers,
Guillaume Nodet
------------------------
Blog: http://gnodet.blogspot.com/
------------------------
Open Source SOA
http://fusesource.com

Mime
  • Unnamed multipart/alternative (inline, None, 0 bytes)
View raw message