On Fri, 01 Mar 2002 19:03:07 +0200, Antti Koivunen <[EMAIL PROTECTED]>
wrote:
> >>I agree, but would point out that it's possible (to some extent) to
> >>have variable number of arguments using an implicit argument array
> >>(and a function that's aware of it), e.g. in JavaScript it's common
> >>to have functions like:
> >>
> >> function callMethods() {
> >> var a = arguments, i;
> >> for (i = 0; i < a.length; i++) {
> >> this._tmp = a[i];
> >> this._tmp();
> >> }
> >> }
> >>
> >
> > Yes, that's what I was thinking to have too. I was thinking to have a
> > special syntax to access the "rest of the arguments", similar to the C
> > one:
> >
> > function callMethods()
> > {
> > var args = ...; // ... denotes the rest of the arguments passed
> > // in the function
> > for (var i = 0; i < a.length; i++) {
> > // assume a[i] contains a function object
> > a[i](1, 2, 3);
> > }
> > }
> >
> > But maybe the special variable 'arguments' would work as well.
>
> Either one is fine, and so is the following:
>
> 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'.
> >>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?
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 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.
> > 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.
> >>>Blocks of code are declared with curly braces ('{' and '}'). A block
> >>>is really an sequential list of expressions. The value returned by the
> >>>block is the last expression in the block:
> >>>
> >>> function my_func(a, b)
> >>> {
> >>> var c = { if (a > b) a; else b; };
> >>> }
> >>>
> >>I wonder if people will find this confusing (especially if dictionaries
> >>are defined as {"a" = 1, "b" = 2}). Would it be enough to allow the
> >>following (not as 'Schemy', I know):
> >>
> >> function my_func(a, b)
> >> {
> >> var c;
> >> if (a > b) {
> >> c = a;
> >> } else {
> >> c = b;
> >> }
> >> }
> >>
> >
> > You can use either syntax you want, and most people would probably use
> > the last one. However the distinction between statements and
> > expressions is artificial, and I don't think is necessary.
>
> Well, I usually like to think that if there are two ways of doing the
> same thing, there might be one too many. It's always easier to add
> features if they're needed than it is to remove any. But my point here
> was the potentially confusing syntax:
>
> var c = { a = b; b = 1 };
> var c = { a : b, b : 1 };
> var c = { a = b; b = { a : b, b : { a = 2; } } };
>
> The code above might be acceptable, but I've listed below a few ideas
> from the top of my head to address this (I'll discuss the 'implicit
> return' issue separately further below).
>
> var f = function (a, b) { if (a > b) a; else b; };
>
> var c = call { if (a > b) a; else b; };
> var d = { a : b, b : 1 };
>
> var c = { if (a > b) a; else b; };
> var d = new { a : b, b : 1 };
>
> 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.
> >>>The 'return' special form, takes an optional expression as argument,
> >>>and terminates the execution of the current block. The value of the
> >>>block becomes the value of the 'return' expression, if any, otherwise
> >>>void is returned (see below for an explanation of void).
> >>>
> >>> function my_func(a, b)
> >>> {
> >>> if (a == 0)
> >>> return b;
> >>>
> >>> // Some lengthy computation here
> >>> ...
> >>> }
> >>>
> >>Most people might expect an explicit 'return', e.g.
> >>
> >> function f1(a) { return a + 1; };
> >> function f2(a) { a + 1; };
> >>
> >> f1(2); // 3
> >> f2(2); // void
> >>
> >
> > This makes sense, although in doing this the code becomes more
> > verbose. I'd still like to write
> >
> > var a = {if (a) b; else c;}
> >
> > It's a lot less verbose and easy to write/read IMO.
>
> That's a valid point, and I also agree that clearly stating that every
> block (expression) evaluates to the last 'statement' (nested
> expression), should be explicit enough, even though most people aren't
> used to it.
Yes, I think this too.
> However, there's something to consider; here's the same expression
> as above (ridiculously formatted on purpose):
>
> var a = {
> if (a) {
> b;
> } else {
> c;
> }
> }
>
> var a = {
> if (a) {
> return b;
> } else {
> return c;
> }
> }
>
> The latter will always work, so the question is: do we really want both?
> Otherwise I wouldn't object, but consider the following:
>
> 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.
> > 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
> >>OK, I assume this is legal:
> >>
> >> import org.MyClass;
> >> {
> >> var a = new MyClass(); // org.MyClass
> >> import com.MyClass;
> >> {
> >> var b = new MyClass(); // com.MyClass
> >> }
> >> var c = new MyClass(); // com.MyClass
> >> }
> >>
> >
> > Yes, it's exactly like this.
>
> Great!
Thanks for your comments!
Greetings,
--
Ovidiu Predescu <[EMAIL PROTECTED]>
http://www.geocities.com/SiliconValley/Monitor/7464/ (GNU, Emacs, other stuff)
---------------------------------------------------------------------
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, email: [EMAIL PROTECTED]
