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.
> 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.
> 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.
> 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.
> > What I've been thinking about is a syntax which emulates the semantic
> > of the Scheme language as close as possible, yet provide a syntax, and
> > a tight integration with Java.
>
> Well, the result will be something that shares the semantics of Scheme,
> but the goal should be to define an easy to use language well suited for
> the task. I mean, we shouldn't just duplicate Scheme using a different
> syntax, and it's okay not to include every single feature.
Sure, I agree. The language will be a mixture of Scheme, Java and
JavaScript.
> > In Scheme identifiers can contain any symbol you like, except spaces,
> > because operators, which are really functions, always appear in the
> > first position in a list. So identifiers like call/cc, send-page,
> > clear+add are perfectly valid. To be able to call normal Scheme
> > functions from the flow language, we need to have the same
> > ability. However because operators in jWebFlow are going to be infix,
> > we need to require a space before them (see further why a space is not
> > required after it). Characters like '(' ')' ',' are not allowed in
> > identifiers. Special characters like '+' '-' '"' and ' are not allowed
> > at the beginning or end of an identifier. This allows for things like
> > '-a' 'a - b' 'a++', 'f(1)' to really mean what you intend. However
> > 'a-b' is an identifier.
>
> 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. Placing spaces around operators
also makes for more readable programs ;-)
> > 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.
> > 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.
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.
If you really want void to be returned, you can use return with no
arguments.
> > 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.
> > 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.
> > The interface with Java is straightforward. You can write:
> >
> > import java.io.*;
> >
> > var a = new InputStream(new File("/tmp/a"));
> >
> > The 'import' statement is a special expression which defines, in the
> > current scope, a set of variables with the same name as the imported
> > classes. E.g. this means that the scope of an imported class name is
> > valid only in the scope in which it was defined:
> >
> > {
> > import org.MyClass;
> >
> > var a = new MyClass(); // refers to org.MyClass
> > }
> > new MyClass(); => illegal, MyClass not defined
> >
> > import com.MyClass;
> > var b = new MyClass; // refers to com.MyClass;
>
> 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.
Regards,
--
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]
