felix-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From David Savage <dave.sav...@paremus.com>
Subject Re: Gogo
Date Fri, 21 Aug 2009 14:54:56 GMT
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:


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

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


Just my 2 pence anyway...



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

View raw message