Ovidiu Predescu wrote:
> On Thu, 28 Feb 2002 14:15:32 +0200, Antti Koivunen <[EMAIL PROTECTED]>
>wrote:
>
>
>>See the comments below. I'll try to look at things like an average
>>web programmer would, so the results might look more like JavaScript
>>than Scheme (but JavaScript is a well known language and does share
>>some of the features of real functional languages).
>>
>
> Also think of what a real hacker might do with the language. Let's not
> have a language that could be used only by an average
> programmer. Familiarity is essential though, I agree.
Absolutely agree, but as we don't have many average programmers around,
it's sometimes easy to get carried away (but that's not happening here,
so hacker-mode on ;)
>>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);
}
}
>>How about setting default values in the function declaration:
>>
>> function f1( a, b = 2, c = 3 )
>> {
>> ...
>> }
>>
>>Should be easy enough to implement?
>>
>
> That too, it's just that I forgot to mention it.
OK, thought you might have.
>>I think it would be good to see at least a minimal example, so it would
>>be easier for people to understand and comment on these things.
>>
>
> OK, I'll come up with an example. It's just I need to have a minimal
> language interpreter working.
Sure, take your time... :)
>>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.
> Placing spaces around operators
> also makes for more readable programs ;-)
Sure, but some will forget (well, they should read the docs anyway :)
>>>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 ];
>>>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. 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'.
> 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).
>>>A dictionary is defined using comma in an expression context:
>>>
>>> var dict = {"a" = 1, "b" = 2};
>>>
>>OK, but the following would be equivalent (and familiar from JavaScript):
>>
>> var dict = { a: 1, b: 2 }
>>
>> var dict2 = { a: 1, b: { c: 2, d: 3 } }
>>
>
> Yes, it makes sense. I'll change the syntax accordingly.
OK.
>>>As in Scheme and JavaScript, dynamic code can be created and executed
>>>at runtime using the 'eval' function:
>>>
>>> eval("1 + 2");
>>>
>>>parses and evaluates the "1 + 2" expression. Eval makes the parser and
>>>evaluator available in the language.
>>>
>>OK, but I'm not sure that it's absolutely necessary. Using eval() is
>>generally not seen as the best programming practise.
>>
>
> Yes, but is a nice thing to have in an interpreted language.
OK, I guess many people will appreciate having it.
>>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!
(: A ;)
---------------------------------------------------------------------
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, email: [EMAIL PROTECTED]
