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
