>> function f1( a, b, *args )
>> {
>> for (var i = 0; i < args.length; i++) {
>> a[i](a, b);
>> }
>> }
>>
>
> Where did I see this syntax? I like this one, so let's stick with
> it. I eliminates the need to assign ... to a variable, and it avoid
> implicit, hidden variables like 'arguments'.
At least Python supports it, and yes, I like it too.
>>>>I think people might find identifiers such as 'a-b' confusing (I know
>>>>it's a common naming convention in Scheme), so I would prefer 'a_b' or 'aB'.
>>>>
>>>>
>>>Since the flow language is tightly integrated with the Scheme engine
>>>underneath and with the Java language implementation, it should be
>>>possible to invoke Scheme functions, as well as Java methods. Since
>>>Scheme function names are often named using embedded minus signs, the
>>>language should provide this feature.
>>>
>>Uh, that's a good point, but perhaps our 'layer' of 'built-in' functions
>>should use 'a_b' or 'aB'. As the flow language is not Scheme, we
>>probably shouldn't allow direct access to Scheme functions, anyway. If
>>some users really want to do that, they should use Scheme directly.
>>
>
> Hm, but how about the fact that we do allow access to the Java
> language underneath?
That's a good point, but there's a slight semantic difference as the
flow language is translated to Scheme. The Java bindings provide, in a
way, what browser extensions or LiveConnect provide to ECMAScript. But
more importantly, the Java integration is probably inevitable, 'a-b'
identifiers are not :)
> But you're right, there anyways too many differences between a
> function in our language and normal functions in Scheme. And also I
> have in Scheme right now is a 'function' macro that implements the
> named arguments semantic. It can be simply extended to register a
> Scheme function to be access from the flow language.
OK, that's good.
> OK then, I'll get rid of some of the special characters in
> variables. I'd still like to have things like ? and ! available
> though, as they make for more readable names.
Hm, it might be okay for built-in type predicates, but I'm not sure that
Scheme naming conventions 'rhyme' with the flow language syntax.
(string? a)
(typeof(a) == "string")
(good?(a))
(isGood(a))
myProc!(a);
Also, as you know, '!' is commonly used to denote negation, so it might
cause some confusion.
>> > Placing spaces around operators
>>
>>>also makes for more readable programs ;-)
>>>
>>Sure, but some will forget (well, they should read the docs anyway :)
>>
>
> OK, I'll remove them.
It would be fine by me to issue a warning on 'a-b', i.e. to require
'a - b', but allowing it as an identifier might be confusing.
>> var c = { if (a > b) a; else b; };
>> var d = [ a : b, b : 1 ];
>>
>
> Yes, using [a: b, c: d] to define a dictionary is better than the
> curly braces syntax. It's very similar with the array syntax. I think
> I'll use this one.
OK, that's probably the best choice. (Python does use a[b:c] to 'slice'
an array, but I think our dictionary instantiation is different enough
not to cause confusion.)
>> var a = {
>> if (a) {
>> b;
>> } else {
>> return c;
>> }
>> }
>>
>>The issue becomes apparent with big expressions and functions: people
>>want to look for the 'return'.
>>
>
> Good point.
>
> I think in the last case the compiler can be instructed to detect it,
> and issue a warning. This might be an indication the programmer forgot
> about the implicit return. I'll think about it.
OK.
>>>I suspect the implicit return of the last expression in a function or
>>>a block will be ignored by most people. In most cases, the return
>>>value will be simply ignored in the code. I don't think people will be
>>>bothered that instead of void, the f2(2) call above returns 3.
>>>
>>Good point (although in theory someone could have 'if (f2(2))', but
>>that'd be incredibly bad programming).
>>
>
> Not only that, but it would be incorrect syntax ;-0
Incorrect in the flow language, but e.g. Python and JavaScript would
happily evaluate it to false, no questions asked :) (but this is
certainly not an issue)
> Thanks for your comments!
Glad to be of help :)
BTW, I know it's not our first priority, but one idea for the name could
be 'FlowScript'. It doesn't seem to be in wide use and has a nice sense
of 'flow of script' (although the file suffix might be FS ;).
(: A ;)
---------------------------------------------------------------------
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, email: [EMAIL PROTECTED]
