On Thu, 3 Jan 2002 14:31:09 -0600, Judson Lester <[EMAIL PROTECTED]> wrote:
> > I don't think we can have a distinction between an exit page and a
> > "normal" page. In fact you can have pages that have both exit
> > links, and returning links. The distinction between the pages in
> > not in the way they are invoked (send-page vs. send-exit-page),
> > but in the information encoded in the page, which is and _should
> > be_ external to the control flow logic.
>
> I agree with this, mostly, but I suspect that either you've
> misunderstood the distinction I'm making, my understanding of the
> distinction is shifting as I understand these ideas better, or I was
> unclear in my position.
>
> Certainly, a send-page(...) might never return, but a
> send-exit-page(...) <emp>will</emp> never return. And while this
> is encoded in the page that's sent quite clearly, this hardly helps
> when reading the code. From the standpoint of someone reading this
> code, it's difficult to say whether a send-page(...) correctly
> terminates a flow of execution, whereas a send-exit-page(...) does
> this exactly. Consider the gcc error about an execution flow
> without a return value...I think this behavior would be very
> valuable to emulate, but very difficult to do without an equivalent
> contruct to "return expr;". In fact, since any Transformer in the
> pipeline might suddenly decide to add a back-to-flow link, you can't
> really guarantee that a specific send-page(...) won't come back.
> From the standpoint of a flowmap checker, how can I tell that a
> flowmap is correct if send-page(...) is at the end of a flow?
I see your point. send-exit-page() is not only an indication to the
developer, but an enforcement of the fact that the function never
returns, guaranteed by the system.
This is equivalent to invalidating the continuation of
send-exit-page() as soon as it's created. In fact the continuation is
never registered in the system, so this function could be written like
this (compare it with the send-page() in my previous email, added here
for convenience):
(define send-exit-page
(lambda (page pipeline object-model)
(cocoon/process page pipeline object-model)
(suicide)))
(define send-page
(lambda (page pipeline object-model)
(call/cc
(lambda (k)
(let ((url (k->url k)))
(hash-put object-model 'k-url url)
(hash-put current-continuations url k)
(cocoon/process page pipeline object-model)
(suicide))))))
> I didn't mean that a developer should worry about send-page(...)
> returning. I think the language designer(s) should worry about
> this. I just think it would be particularly nettlesome, for
> instance, if the flow language gives access to resource allocation
> and send-page(...) makes it impossible to deallocate. The best
> solution I can see is that somewhere the Cocoon framework releases
> those resources when the user's session expires. That could be very
> problematic in the case of a db connection, for instance, since you
> suddenly need several orders of magnitude more db connections than
> you did. The solution, it seems, is that the flowmap can't allocate
> database connections directly, which probably means that it can't do
> db lookups itself, or that there are blocks of some sort that forbid
> the use of send-page(...) within them.
That's right, as with today's server programming, the business logic
should obtain a resource, make use of it, and then release it, before
the program is paused.
The resource can be allocated by the flow program, directly or
indirectly, by calling methods on Java objects that deal with
resources. So even if the flow language doesn't allow resources to be
aquired, you can still have problems as the business logic can do it
and not release them after use.
> > That's why I said the model is very much different than what we
> > are used to, and may be difficult to grasp.
>
> I think this is probably the strongest possible argument for
> rethinking the usual positions we take on formal programming
> languages. The flowmap is very different from a traditional
> programming language because it solves a different problem.
>
> The fundamental difference in the problem is that the program will
> be interacting directly with a user, who will thoughtlessly shift
> our exectution point around, and wants to do repetitive tasks as
> little as possible, rather than interacting with the processor, who
> moves forward unless we say otherwise, and loves doing things over
> and over and over and...
>
> The fundamental differences in the structure of the languages then,
> it seems to me, is that where a traditional language wants closures
> and functions that return, because when you're done with this task,
> you want to go back so you can do it again, a flow language wants to
> break things up in to steps and move between them, going back
> usually only because the user want's to, and without regard to what
> effort might be lost.
Yes, I agree.
The main cause for this is the access to the continuation objects of
various points of the program. If you ignore the Web aspect of it,
invoking such a continuation means essentially jumping in different
places, already visited, of your program. This is a characteristic of
continuations based programming.
> > That's right. Nevertheless, I think it's much harder to come up
> > with a restricted language which has everything you need to do
> > _only_ business logic, than to have a powerful language. For the
> > later, it's enough to translate that language to Scheme. For the
> > former, you need quite a bit of work to remove the "unnecessary"
> > functionality out of the language. But then how do you know you're
> > not limiting the expressiveness and power of the language by doing
> > so? A user using the system in a different way than you expected
> > might need that little thing you've decided is not important.
> >
>
> I think that's true only if you're starting with a specific language
> to start with. I frankly am yet to be convinced that this flow
> language needs to be any more complicated than make or ant (and the
> "we provide the flow control, actual work is done by others"
> approach of those 'little languages' is what makes me think of
> them.) With that in mind, I don't see the need for a powerful
> language, and I don't see the need to retask an existing language
> (XML or Java or ECMAScript, for instance) since the argument there
> is that "if you already program in Ada, this is easy!" Having added
> only the semantics to the language that are neccesary (and I think
> that's an easier task than stripping things out), you still only
> have the task of translating the language into Scheme (or
> interpreting for Java, or whatever.)
In a private discussion I had with Christian Queinnec, he suggested to
use a syntax familiar for the Scheme language. This means, instead of
declaring functions with:
(define (fun arg1 arg2) ...)
you have
function fun(arg1, arg2)
{
...
}
Instead of declaring variables with
(let ((var1 value1)
(var2 value2))
...)
you do
function fun(...)
{
var var1 = value1;
var var2 = value2;
...
}
The language has no lambda special forms and no macros.
This syntax translates to Scheme directly. All the functions defined
in this language become real Scheme functions. All the functions
called in this language are either defined in the language explicitly,
or are implicitly defined in Scheme. Thus, if you want, you can call
the Scheme car, cdr, pair? functions directly from this language. Not
that many people would do it ;-)
This way you have access to the full power of Scheme, as all the
functions invoked from this syntax are essentially Scheme
functions. The syntax for invoking Java objects is the same as in
Java.
> Aha, Ovidiu! I've found you out: you're one of those Scheme zealots
> trying to push your functional programming religion on the rest of
> us!
;-)
Not really, I haven't done programming in functional languages since
university, about 7 years ago (other than Emacs Lisp, but that doesn't
count ;). However I found that the concepts behind these are so
powerful, that is worth investigating them, no matter the
language. For me, learning something new is always fun, even when it
uses "unconventional" languages ;-)
> Seriously, much as I love Scheme and Lisp (such relaxing
> languages...), it seems like, from the above, that Scheme may be, as
> we say here in America, a long run for a short slide. What
> advantage is there to translating a language into Scheme to have it
> interpreted by Java? Why not interprete the language directly? As
> far as continuations go, it doesn't seem that the URL-execution
> point hash table would be overly difficult to implement directly.
Why come up with an interpreter for a language when the Scheme
interpreter is already there? Writing a translator from a language to
Scheme is much easier than writing a full interpreter for a dedicated
language. The speed of an interpreter dedicated for our language will
probably be the same as the Scheme's interpreter, which is optimized
for speed very well.
Cheers,
Ovidiu
--
Ovidiu Predescu <[EMAIL PROTECTED]>
http://orion.rgv.hp.com/ (inside HP's firewall only)
http://sourceforge.net/users/ovidiu/ (my SourceForge page)
http://www.geocities.com/SiliconValley/Monitor/7464/ (GNU, Emacs, other stuff)
---------------------------------------------------------------------
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, email: [EMAIL PROTECTED]
