In the changes I've made, i have not changed the assignment meaning to
turn everything into strings. What i did is to change the evaluation
of variables. For example, when a variable is adjacent to a string, it
will be converted to a string and concatenated. So
${a}b
will turn the a variable into a string and append 'b' to it, whereas
it was previously resulting into two arguments $a and 'b'.
However, no conversion is done if there is no other character before
or after the variable.
I've also aligned quotes handling with unix where expressions between
single quotes are not evaluated.
I don't really think i've broken anything and the parsing of the first
argument is still different than following arguments, but if i did, we
need more test cases to make sure we agree on what the results should
be.
For command not founds, i think people *are* confused that no error is
thrown. I do think the shell should report an error if the command
can't be found as in any other decent shell.
On Thursday, July 16, 2009, Peter Kriens <peter.kri...@aqute.biz> wrote:
> I've read the threads about Gogo and have some remarks. At first, it made
> sense to make gogo closer to Unix. Though I think that each aspect needs to
> be argued on its merits, the fact that you have to learn a bit is imho not a
> big deal. Such thinking stifles innovation. That said, I do agree there
> should not be gratuitous differences.
>
> One example where the unix angle does not work is assignment. The TSL tries
> to be a script language with a shell feel. The biggest distinction is that it
> uses objects instead of strings. I think the variable assignment therefore
> should not assume a string. That is:
>
> $ a = hello world
>
> Is NOT a = "hello world". And I do not think it should be. In a script
> language, treating the right side as a string is silly and would surprise all
> script programmers (to use a slightly overused argument :-).
>
> I do agree that we should replace the <> with (). This makes a lot of sense
> and there are not that many filters in use anyway. We could now make filters
> <> if we want.
>
> About the removal of need for whitespace, I think this might be problematic.
> I wanted to allow the use of URLs and not require silly escaping. That is why
> the parsing rules for the first word are different than the remainder.
> Removing the need for whitespace between between arguments will mess this up
> I think.
>
> i = open http://www.aqute.biz/page$q2
>
> I have not looked in detail if the fix to remove whitespace between variables
> is killing this or not. If not then I am ok with it, otherwise I have a bit
> of a problem with it. We could add strings where variables are expanded.
>
> About the priority of | and ; ... I remember thinking long and hard about
> this but forgot why I picked this model, it still seems slightly more
> powerful because the newline acts as a ';' with a higher priority than the
> '|' but I am not opposed to switching the priority.
>
> I am not sure about throwing an error when a command is not recognized. Using
> its value seems sufficient to me and has some advantages. I do not think this
> would ever confuse me.
>
> Nice to get some discussion going! However, please note that this is an OSGi
> RFC. I will update the RFC in the coming weeks and discuss it in CPEG. I hope
> to schedule it then for inclusion in an upcoming compendium.
>
> I'd like to add one more thing. In Blueprint we spent a lot of time on type
> conversion and I like very much what we got there. I think it would be a good
> idea to use the same type converters, especially because they also handle
> generics when available.
>
> Kind regards,
>
> Peter Kriens
>
>
--
Cheers,
Guillaume Nodet
------------------------
Blog: http://gnodet.blogspot.com/
------------------------
Open Source SOA
http://fusesource.com
