Mailing-List: contact cocoon-dev-help@xml.apache.org; run by ezmlm
Precedence: bulk
Reply-To: cocoon-dev@xml.apache.org
Message-Id: <200203011859.g21IxvC23142@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 "Fri, 01 Mar 2002 10:17:39 +0100."
             <3C7F4733.DE20F94F@apache.org>
MIME-Version: 1.0
Content-Type: text/plain; charset=us-ascii
Date: Fri, 01 Mar 2002 10:59:57 -0800
Sender: ovidiu@orion.rgv.hp.com

On Fri, 01 Mar 2002 10:17:39 +0100, Stefano Mazzocchi <stefano@apache.org> wrote:

> Ovidiu Predescu wrote:
> > 
> > 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
> 
> No, you didn't get my point: I totally agree that reduced verbosity is a
> good thing for people that are used to a language, but I believe that
> implicit behavior (means 'nothing to indicate the behavior, not even a
> single character') is to avoid.
> 
> In the expression a ? b : c there is nothing implicit since it's the
> exact equivalent of
> 
>  if (a) { b } else { c }
> 
> which is admittedly more verbose, but for
> 
>   function my_func(a,b) {
>     var c = { (a > b) ? a : b };
>   }
> 
> there is *nothing* that tells us that something is returned from that
> expression. This is what I don't like because I think that every
> implicit syntactic construct makes a language harder to learn and to
> maintenance costs much higher, despite the reduced verbosity.
> 
> if you think 'return' is too verbose, you can have something like
> 
>   function my_func(a,b) {
>     <--[ (a > b) ? a : b ];
>   }
> 
> indicating that the result of the <--[*] expression 'exists' (thus the
> arrow pointing to the outside) the function. Just an example to show you
> a very compact syntax that doesn't sacrifice explicit-ness.

OK, I think I understand your point.

What I'm saying is that there two ways to write the code. You can use
the explicit return, in case the verbosity is clearer than the concise
version. This means that in large functions most likely people
will use return to exit from the function.

Also what I'm saying is that you'd want to use an explicit return only
when the value of the function is meaningfull, usually when the caller
expects a value to be returned from the function. I all other cases,
not putting a return in the function will not hurt the program in any
way. The implicit returned value of the last expression is simply
ignored.

In Scheme for example there is no notion of explicit return,
everything is written using functions, 'if' and recursivity. The last
evaluated expression in a function is returned as the value of the
function.

For small snippets of code where conciseness is essential however, you
don't want to use any additional keyword. I actually like 'return' as
a keyword, no need to invent something else.

> > 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.
> 
> It's a much higher concept: having semantical meanings encoded in
> syntactic implicit properties (such as 'order of appearance') is
> admittedly harder to read because it triggers two different cognitive
> flows: one that parses the syntax and one that extracts the implicit
> properties.
> 
> Unfortunately, as GUI vs. CLI have shown: explicit properties ('at least
> I can click around and try') instead of implicit properties ('what the
> hell do I type now?') create a much lower entry gap. [nothing about
> 'usability', that's a totally different concept]

The semantic will be clearly explained in the documentation, so as a
programmer, at least in theory, you should be aware of it. For
somebody new to the language, it's just a matter of adapting to a new
language, it's probably just a different way of doing things than what
he/she is used to.

If this is a problem for them to understand, what will they think of
continuations, which have a much bigger semantical impact on a
program? How will they understand that if they're not able to
understand a simpler concept?

> > > > 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.
> 
> ok, I would add 'currency', since web-oriented flow languages will sure
> have to deal with strings, dates and money. And having them explicitly
> declared in the language might allow us to obtain 'easy' transparent
> handling (say, automatic money conversion)
> 
> Are there any other 'first class concepts' that you guys might want to
> have in a flow language? IDs (as for credit-card numbers) might be
> another one, even if probably a concept too detailed... ok, your turn
> people :)

As I already replied in another message, there is no need for these
built-in data types, if they don't have a direct syntactical
representation. The language benefits from the large set of Java
classes underneath, which can be directly used.

> [snipped part in where we resonate completely, well, at least as much as
> can I resonate with somebody that likes the power of small languages
> built inside a bigger language :-)]

:-) I hope you'll find the taste for these too.


Greetings,
-- 
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