You are viewing a plain text version of this content. The canonical link for it is here.
Posted to dev@cocoon.apache.org by Stefano Mazzocchi <st...@apache.org> on 2002/03/01 10:17:39 UTC
Re: [Schecoon] flow control layer
Ovidiu Predescu wrote:
>
> On Thu, 28 Feb 2002 16:12:14 +0100, Stefano Mazzocchi <st...@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.
> > > 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.
<st...@apache.org> Friedrich Nietzsche
--------------------------------------------------------------------
---------------------------------------------------------------------
To unsubscribe, e-mail: cocoon-dev-unsubscribe@xml.apache.org
For additional commands, email: cocoon-dev-help@xml.apache.org
Re: [Schecoon] flow control layer
Posted by Antti Koivunen <an...@users.sourceforge.net>.
Stefano Mazzocchi wrote:
> Ovidiu Predescu wrote:
<skip/>
>>>>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 :)
I would think carefully before adding datatypes to any weakly typed
language. As the flow language allows easy integration with Java, I'd
recommend using standard Java classes (e.g. 'java.util.Date' and
'java.util.Currency'), because they are the ones your custom classes are
likely to use.
(: A ;)
---------------------------------------------------------------------
To unsubscribe, e-mail: cocoon-dev-unsubscribe@xml.apache.org
For additional commands, email: cocoon-dev-help@xml.apache.org
Re: [Schecoon] flow control layer
Posted by "Piroumian, Konstantin" <KP...@flagship.ru>.
> "Piroumian, Konstantin" wrote:
> >
> > Good day!
> >
> > <skip>
> > > > > > 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)
> >
> > Hm... Money conversion can be a complex business operation depending on
> > external environment.
>
> Ok, you're right, this should probably be left to some deeper business
> logic deployed someplace (like in an EJB, WebService or external class).
>
> > >
> > > 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 :)
> >
> > What about EJB objects?
> > A DOM object would be also useful.
>
> Well, these things are already available as you can connect with java
> very easily (at least, this is what I want: flowmaps will be 'glue'
> between your business logic, nothing really fancy there).
Didn't know that Java could be connected to.
>
> So, probably, even Dates should be left out and delegated to the java
> classes (which are good already, so less things to write for us and less
> bugs to find!)
>
> > Speaking frankly, I've already seen something like this we are
discussing in
> > WebLogic Process Integrator (it's a Workflow Engine).
>
> Well, yes, a workflow is a special kind of 'flow', by definition, I
> would say :)
>
> > You can define your
> > workflow process using a GUI (it looks like a flow chart diagram) and
among
> > the other types you could define workflow variables of the following
types:
> > Object, EJBObject, XML.
>
> Yes, GUI driven authoring of flows is probably possible, just like it
> could be possible to provide a sort of GUI authoring process for
> sitemaps, but this is a separate concern.
The main idea was to have Object, XML and maybe EJBObject (or Business
objects and business operations) classes in the flow language.
>
> > Also, this is related more to other thread about XML-based selectors: in
> > WLPI you could define your selection logic using built-in functions and
you
> > could combine XML-based selection with other types, e.g.:
> >
> > <if test="XPath($userInput, '/confirmation/response')='yes' and
> > compareDate($startDate, $endDate)=0'" >...</if>
> > where $userInput is type of 'XML' (internally it could be a DOM object)
and
> > $startDate, $endDate are of 'java.util.Date'.
>
> I still believe that using the XML syntax to program flows is using the
> 'hammer' antipattern: 'when you have a hammer, everything looks like a
> nail'.
>
> Think about it.
I've thought about this for a very long time and could not find a better
solution to this. Another possibilty were to use Session Beans (or simple
JavaBeans to hold and control the state of the user process), but they would
have the same logic of: states, transitions, conditions and operations.
Don't know, maybe I'm too affected by the nature of the system I work on: it
is a highly interactive Billing & Customer Care system (it's web interface
part) and I am not an expert in pure publishing systems, so I don't take
into account others' needs.
For large sites like Yahoo or Amazon it would be, of course, too difficult
to manage all that state-graph, but is there any other alternative to it?
Regards,
Konstantin
P.S. If anybody is interested, then I can post a sample of a flow in XML
(both: our own and WLPI's).
>
> --
> Stefano Mazzocchi One must still have chaos in oneself to be
> able to give birth to a dancing star.
> <st...@apache.org> Friedrich Nietzsche
> --------------------------------------------------------------------
>
>
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: cocoon-dev-unsubscribe@xml.apache.org
> For additional commands, email: cocoon-dev-help@xml.apache.org
>
---------------------------------------------------------------------
To unsubscribe, e-mail: cocoon-dev-unsubscribe@xml.apache.org
For additional commands, email: cocoon-dev-help@xml.apache.org
Re: [Schecoon] flow control layer
Posted by Stefano Mazzocchi <st...@apache.org>.
"Piroumian, Konstantin" wrote:
>
> Good day!
>
> <skip>
> > > > > 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)
>
> Hm... Money conversion can be a complex business operation depending on
> external environment.
Ok, you're right, this should probably be left to some deeper business
logic deployed someplace (like in an EJB, WebService or external class).
> >
> > 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 :)
>
> What about EJB objects?
> A DOM object would be also useful.
Well, these things are already available as you can connect with java
very easily (at least, this is what I want: flowmaps will be 'glue'
between your business logic, nothing really fancy there).
So, probably, even Dates should be left out and delegated to the java
classes (which are good already, so less things to write for us and less
bugs to find!)
> Speaking frankly, I've already seen something like this we are discussing in
> WebLogic Process Integrator (it's a Workflow Engine).
Well, yes, a workflow is a special kind of 'flow', by definition, I
would say :)
> You can define your
> workflow process using a GUI (it looks like a flow chart diagram) and among
> the other types you could define workflow variables of the following types:
> Object, EJBObject, XML.
Yes, GUI driven authoring of flows is probably possible, just like it
could be possible to provide a sort of GUI authoring process for
sitemaps, but this is a separate concern.
> Also, this is related more to other thread about XML-based selectors: in
> WLPI you could define your selection logic using built-in functions and you
> could combine XML-based selection with other types, e.g.:
>
> <if test="XPath($userInput, '/confirmation/response')='yes' and
> compareDate($startDate, $endDate)=0'" >...</if>
> where $userInput is type of 'XML' (internally it could be a DOM object) and
> $startDate, $endDate are of 'java.util.Date'.
I still believe that using the XML syntax to program flows is using the
'hammer' antipattern: 'when you have a hammer, everything looks like a
nail'.
Think about it.
--
Stefano Mazzocchi One must still have chaos in oneself to be
able to give birth to a dancing star.
<st...@apache.org> Friedrich Nietzsche
--------------------------------------------------------------------
---------------------------------------------------------------------
To unsubscribe, e-mail: cocoon-dev-unsubscribe@xml.apache.org
For additional commands, email: cocoon-dev-help@xml.apache.org
Re: [Schecoon] flow control layer
Posted by "Piroumian, Konstantin" <KP...@flagship.ru>.
Good day!
<skip>
> > > > 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)
Hm... Money conversion can be a complex business operation depending on
external environment.
>
> 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 :)
What about EJB objects?
A DOM object would be also useful.
Speaking frankly, I've already seen something like this we are discussing in
WebLogic Process Integrator (it's a Workflow Engine). You can define your
workflow process using a GUI (it looks like a flow chart diagram) and among
the other types you could define workflow variables of the following types:
Object, EJBObject, XML.
Also, this is related more to other thread about XML-based selectors: in
WLPI you could define your selection logic using built-in functions and you
could combine XML-based selection with other types, e.g.:
<if test="XPath($userInput, '/confirmation/response')='yes' and
compareDate($startDate, $endDate)=0'" >...</if>
where $userInput is type of 'XML' (internally it could be a DOM object) and
$startDate, $endDate are of 'java.util.Date'.
Regards,
Konstantin Piroumian
>
> [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.
> <st...@apache.org> Friedrich Nietzsche
> --------------------------------------------------------------------
>
>
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: cocoon-dev-unsubscribe@xml.apache.org
> For additional commands, email: cocoon-dev-help@xml.apache.org
>
---------------------------------------------------------------------
To unsubscribe, e-mail: cocoon-dev-unsubscribe@xml.apache.org
For additional commands, email: cocoon-dev-help@xml.apache.org