Mailing-List: contact cocoon-dev-help@xml.apache.org; run by ezmlm
Precedence: bulk
Reply-To: cocoon-dev@xml.apache.org
Message-Id: <200202282218.g1SMIPH15063@orion.rgv.hp.com>
From: Ovidiu Predescu <ovidiu@cup.hp.com>
To: Stefano Mazzocchi <stefano@apache.org>
Cc: cocoon-dev@xml.apache.org
Subject: Re: [Schecoon] flow control layer 
In-Reply-To: Your message of "Thu, 28 Feb 2002 16:12:14 +0100."
             <3C7E48CD.3C18BF8C@apache.org>
MIME-Version: 1.0
Content-Type: text/plain; charset=us-ascii
Date: Thu, 28 Feb 2002 14:18:25 -0800
Sender: ovidiu@orion.rgv.hp.com

On Thu, 28 Feb 2002 16:12:14 +0100, Stefano Mazzocchi <stefano@apache.org> wrote:

> Ovidiu Predescu wrote:
> 
> > 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; };
> >  }
> 
> Hmmm, not sure I like the implicit behavior of this. Sure it makes the
> syntax more compact, but it might be harder to read. I would rewrite it
> as
> 
>  function my_func(a,b) {
>    return { 
> 	if (a > b) {
> 		return a; 
> 	} else {
> 		return b;
> 	}
>    }
>  }
> 
> [granted, the example is stupid, but you get the point]

I think I still like the concise form better, instead of the verbose
one. Most of the people will be writting using the second form, simply
ignoring the first one. But as you get more familiar with a language,
verbosity is essential. That's why you see in C and Java the construct

  a ? b : c

> > 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
> >     ...
> >  }
> 
> What I don't like about 'implicit behavior' is the fact that people must
> be aware of these rules in order to understand what's going on behind
> their backs... sure, this is no problem for you when you write the code
> since you probably know what you're doing, but yor colleages that comes
> next has much less information to learn from.
> 
> So, I'm ok for having an implicit void return (which means 'no return
> means I return nothing'), but I don't like the implicit valued return
> out of 'last variable', I think this is potentially harmful even if
> reduces verbosity.

If you think about it, there's no harm in having a block return a
value if you don't use that value. You don't even have to be aware of
the void value. So having the last expression returned by a block of
code is really no problem at all, if you don't use it. And most of the
people will not.

> > As Scheme the language has proper tail recursion. This means the
> > following code consumes no stack at runtime:
> > 
> >  function f (i, acc)
> >  {
> >    if (i == 0)
> >      acc;
> >    else
> >      f (i - 1, acc + i);
> >  }
> > 
> >  f (100000);
> 
> Cool, even if I don't see much use of big-time recursion in flow
> languages (at least, if you need it, there's too much business logic in
> your flow)

;-)

Scripting always has unexpected usages, and we can probably use the
language as a general scripting language in other parts of Cocoon as
well.

> > Built-in datatypes are numbers, arrays, dictionaries and function
> > objects. There is a special type 'void', that has a single possible
> > value named 'void'.
> 
> What about 'strings', 'dates' and the like? 

Oh, yes, those too ;-) I forgot about them.

> > With numbers there is no distinction between int, float etc. as in
> > Java. Instead, as in Scheme, the language supports a tower of numeric
> > subtypes, which allows arbitrarily large numbers, either exact or
> > inexact, in a transparent manner.
> > 
> > An array is declared using square brackets ('[' and ']'):
> > 
> >  var array = [1, 2, "abc"];
> 
> how do you access the array values?
> 
>  var a = array[1];
> 
> would be my guess, where the [*] expression indicates a positional
> indication.

Yes, you're right.

> > A dictionary is defined using comma in an expression context:
> > 
> >  var dict = {"a" = 1, "b" = 2};
> 
> how do I access the dict values?
> 
>  var a = dict["a"];
> 
> would be my guess, where the [*] expression indicates an hashmap-like
> random-access indication. (sort of an array with indirected positions)

Yes, like that, you're right on my thoughts ;-)

> > 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.
> 
> Yes, this is really powerful. I remember discovering this in BASIC when
> I was a little kid and loved it :)

Yes, that's the nice part about interpreted languages.

> > 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;
> 
> cool, I love this, it finally removes the need for classname collision
> in the same file (as for the classname Parser, which almost every
> package defines nowadays!) 
> 
> What about:
> 
>  import org.first.MyClass;
> 
>  var a = new MyClass();
> 
>  {
>    import org.second.MyClass;
>  
>    var a = new MyClass();
>  }
> 
>  a = ??
> 
> is "a" still referenced to 'org.first.MyClass'?

Yes, it does. The inner 'a' is defined in its own scope, and as soon
as that goes away, the outer scope becomes the active one, in which
variables are looked up.

> > Right now I'm trying to decide on a way to implement the translator,
> > which also allows me to introduce support for macros at a later
> > point. Macros would be an advanced feature of the language, which
> > allows one to introduce new syntaces for the language, essentially
> > extending the language syntax at runtime. This is one of the very
> > powerful features of Scheme and Lisp languages in
> > general. Particularly Scheme has a very powerful way of defining
> > macros, and I'd like to have this in the language as well. In fact, if
> > you look at Scheme, the core language has very few built-in
> > constructs, and everything else is defined in terms of these using
> > macros.
> > 
> > While programming in Python some years ago, I always missed the
> > ability to define my own syntax. 
> 
> Ahg, smells like FS to me :)

I told you, I told you :-) Don't worry, this is only some food for
thought for the long run.

> > OK, I'm not going to talk more about this feature, as I think Stefano
> > will quickly categorize it in the "flexibility syndrom" category ;-)
> 
> yep :) 

:) :)

> > I'll see instead if I can implement the translator in a way which
> > leaves the doors open.
> 
> ok, we'll see where this brings us.

Yes, definitely.


Cheers,
Ovidiu

-- 
Ovidiu Predescu <ovidiu@cup.hp.com>
http://www.geocities.com/SiliconValley/Monitor/7464/ (GNU, Emacs, other stuff)

---------------------------------------------------------------------
To unsubscribe, e-mail: cocoon-dev-unsubscribe@xml.apache.org
For additional commands, email: cocoon-dev-help@xml.apache.org