Ovidiu Predescu wrote:
>
> On Thu, 28 Feb 2002 16:12:14 +0100, Stefano Mazzocchi <[EMAIL PROTECTED]> 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.
> > > 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.
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]
> > > 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.
Granted.
> > > 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 :)
[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 :-)]
--
Stefano Mazzocchi One must still have chaos in oneself to be
able to give birth to a dancing star.
<[EMAIL PROTECTED]> Friedrich Nietzsche
--------------------------------------------------------------------
---------------------------------------------------------------------
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, email: [EMAIL PROTECTED]
