commons-user mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From "Wannheden, Knut" <>
Subject RE: [Jelly] Functional Jelly Redux, was Re: Jelly and X++
Date Wed, 12 Feb 2003 08:50:49 GMT

I must have missed that thread of last december.  But thanks for the
pointer, I've been reading up on it now.

I've been thinking along similar lines myself for quite some time now.  But
I always stumble on the question of how far to go making a pure functional
language using XML syntax.  For me there is a certain impedance mismatch
between the Lisp s-exps and XML elements and attributes.  But I agree with
you that having Tags and Scripts return a value would be great!

In a purer form you would maybe even want to drop the XMLOutput in favor of
only the return value.

What I'd at the moment almost find most useful and powerful would be
something that matches Lisp's special forms (quote) and (eval) and of course
a macro facility to enhance the define tag library.  But this would already
require extensive changes to the Jelly core.

What I think would be the main benefits of a functional Jelly:

 - More consistent evaluation order.  Right now a tag implementation can
choose whether to evaluate it's body or not.  I think that is something that
should be abstracted away from the evaluator.  Of course it could still be
useful to plug in new "special forms" into the evaluator.
 - No dependencies on surrounding tags.  Right now many tags depend on their
ancestor tags because they don't have a return value.  That makes them a lot
less portable and reusable.

I have also been thinking about what I think the syntax should look like for
a functional script language like this.  Here is an example, using the
<j:invoke/> tag, of what I've come up with.  (Note that this only is an
example and don't get hung up on the fact that a method invocation can be
done much easier using a Jexl expression).

In the most compact form you'd write something like:

	<j:invoke method="foo" on="${bar}" args="${x},y"/>

where you have the variables "bar" and "x" defined.  Now imagine that you'd
want to pass the result of evaluating a Tag as an argument to the method
invocation.  Now with Jelly you would use a <j:set/> tag and a variable.  I
was thinking something like this would be nice:

	<j:invoke method="foo" on="${bar}">
		<args as="j:new" className="java.lang.String" args="y"/>

As you see the "args" attribute of <j:invoke/> (which was a comma separated
list) has been replaced with two nested <args/> elements (should they maybe
even be in a namespace like <param:args/>?).  Also note that the second
<args/> element has an "as" attribute which actually specifies the "runtime
type" of the tag and the other two attributes are for the <j:new/> tag.

Expanding a little bit on this you could also write something like this:

	<j:invoke method="foo">
		<arg as="var:x"/>
		<arg as="j:new">
			<className as="j:new"

Now the method invocation has become quite verbose although it still has the
same effect as the first example given.  Also note the extended syntax where
tags in the "var" namespace evaluate to the values of defined Jelly

If this different syntax really would be useful to a scripting language is
another question ;-)  I've just been playing with the idea.  But maybe
someone would like to comment on it...



> -----Original Message-----
> From: Todd Jonker []
> Sent: Mittwoch, 12. Februar 2003 05:51
> To: Jakarta Commons Users List
> Subject: [Jelly] Functional Jelly Redux, was Re: Jelly and X++
> On 2/11/03 7:15 PM, wrote:
> > Can you briefly clarify "Functional Model" (even with just a link to
> > somewhere else) since it can be easily confused with other 
> definitions
> > of functional programming?
> > 
> > -Mark
> Good question, Mark.  I'll do my best without digging too 
> deep into the
> COMP411 archive...
> Technically, a functional programming model is one in which 
> everything is
> expressed in terms of pure functions in the mathematical 
> sense.... The old
> algebra and calculus kind of function: f(x) = y.  That is, you have
> functions, you apply them to parameters, you get results, and 
> you compose
> results in various ways.
> The functional paradigm, where you compute results by 
> composing functional
> expressions, is usually contrasted with the so-called 
> "imperative" paradigm,
> where you compute results by sequencing statements and performing
> side-effects (generally speaking, assignments to variables).
> A "Pure Functional" language can be somewhat usefully defined as those
> languages that do not have "imperative" features.  From this 
> you can observe
> that a pure functional language doesn't have variables 
> (though it will often
> have constants).  Another distinguishing characteristic is that the
> functional model says that Functions Are Values.   This 
> feature is commonly
> called "first-class functions", and lets you define functions 
> that accept
> functions as arguments, and return functions as values, and construct
> functions on the fly.  (Java's anonymous inner classes is attempt at
> approximating the value of first-class functions, but it's 
> terribly clumsy,
> verbose, and limited when compared to the real thing.)
> Many people are surprised by the fact that you can do any 
> real work that
> way, but as it turns out, you can perform _any_ computation 
> under such a
> model, you just express things differently.  (That is, the 
> functional model
> is Turing-complete.)  If this blows your mind, google for 
> "Lambda Calculus"
> and be prepared for some really mind-warping stuff.
> In the real world, however, imperative languages reign, and there are
> relatively few purely-functional languages, and not a one 
> that's commonly
> used outside of academia.  They _are_ used quite a bit in 
> academia, since
> they allow for very complete and rigorous mathematical models 
> and analyses,
> useful for things like proving correctness of programs.  The 
> Lambda Calculus
> is in fact very widely used means of defining the semantics 
> of programming
> languages, whether they by functional or imperative or "other".
> There are, however, quite a few "mostly functional" languages 
> that provide
> imperative features, but where the bulk of the  programming 
> is typically
> done in a functional way.  Lisp, Scheme, and ML all fall into this
> category... In those languges the use of an assignment is a 
> pretty rare
> sighting.
> [ Most OO languages are pretty aggressively imperative.  It's 
> damn near
> impossible to write a useful Java program without using an 
> assignment. ]
> By "functional programming", language-weenies like me usually mean
> "programming within the functional paradigm", and sometimes mean
> "programming with a functional language".  It's sometimes 
> possible, but
> usually frustrating, to do functional programming in an imperative
> langugage.
> For my money, the "big win" in the functional model is 
> actually very simple:
> eradicate the distinction between statements and expressions. 
>  If you've
> ever used Lisp or Scheme (or, more recently, Dylan) you 
> understand what this
> means and how powerful it is.  Basically, every programming language
> construct has "a value".
> The IF statement is a particularly nice example.  If you 
> write in Java,
>    if (test) { doSomething(); } else { doSomethingElse(); }
> there is no notion of the IF as a whole having "a value".  
> You can't use the
> whole thing on the right-hand-side of an assignment, for instance.
> However, the parallel construct in Scheme,
>     (if test (doSomething) (doSomethingElse))
> does in fact have a well-defined value: if the value of test 
> is true, the
> value of the if-expression is the value of it's then-clause; 
> otherwise it
> evaluates to it's else-clause.  So in the example above, the 
> value would be
> the result of calling one of the functions doSomething or 
> doSomethingElse.
> Before somebody notes that C/C++/Java do in fact have this 
> notion in the
> form of the conditional expression
>     (test ? doSomething() : doSomethingElse())
> the point is that it's extremely useful to design your 
> language so that
> *every* construct has a value... So there's no difference 
> between statements
> and expressions (ie, imperative constructs and functional constructs).
> So what does this have to do with Jelly?  I first observe 
> that the whole
> structure of XML leads itself perfectly towards a functional 
> paradigm, which
> is very big on nesting, syntactic consistency, and 
> substitutability.  But
> more convincing (to me at least) is the fact that a 
> functional model would
> enable a great deal more flexibility in our Tag Libraries, at 
> much lower
> effort.  I guess what I'm really shooting for is to extend Jelly's
> script/tag model so that it is easy to define tag libraries 
> that work in a
> purely-functional manner, an imperative manner, or anything 
> in between.  As
> some who's worked with quite a few languages in my time, I 
> recognize the
> value of using the right model for the job.  I'd like to see 
> Jelly enable
> that model so that it can be used all over the place!
> Rather than repeat my earlier proposals, I'd encourage the 
> interested reader
> to search this forum's archive for the thread "Towards Functional
> programming in Jelly scripts" that started 12/12/02.  I would 
> of course be
> happy to renew those discussions again.
> .T.
> -- 
>                  War is NOT a necessity!
> ---------------------------------------------------------------------
> To unsubscribe, e-mail:
> For additional commands, e-mail:

  • Unnamed multipart/alternative (inline, None, 0 bytes)
View raw message