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.sav...@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<gno...@gmail.com> wrote: > > On Thu, Aug 20, 2009 at 15:40, Derek Baum <derek.b...@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
