Re: Kawa Servlets

["Nic Ferrier" <nferrier at tapsellferrier dot co dot uk>]

>>> Per Bothner <per@bothner.com> 10-Mar-00 11:28:12 PM >>>

>Depends what you're trying to do.  For a module, it would be nice
to
>not have to wrap the entire source file in a
define-module/define-class,
>for compatibility with other Scheme's, if nothing else.

Yes... I take that back. I prefer your module syntax.


>> It would be good if it was easy to write such things in pure
Scheme
>> without the need to refer to low-level Java implementations. 

>Well, we can provide syntactic sugar for servlets on top of the
>"method declaration" mechanism - but that is a nice general
framework.

That's what I was advocating really. 

If we had SRFI0 (or any other sort of "require") we could build a
schemlet that could have lots of syntatic sugar based on the forms
imported or "required". I think that's what I'll do for Paperclips.


>Well, it is worth experimenting with different "sugars".

But I think the way I was going to do it would mean that it was more
difficult to write than your suggestions. I will probably still
provide a servlet-context that allows you to load a schemlet with a
single Java statement:

context.bindPath("/somepath","(output (request 'path-info))");

This will mean that administrators of webservers would be able to
setup a quick servlet by typing some scheme into a load-servlet admin
page. That's sugary!



>Anyway, this is just something something I've thought about,
>but haven't reached a conclusion on.  Until then, invoke
>works.

I don't have a problem with invoke. My point was more about native
scheme types, ie: types that can be manipulated by "normal" scheme
code. I would like a system where request and response (and session)
are scheme types (a proc, or list, or list of procs, or whatever).

This is, as you say, just sugar and can easily be defined using a
require or SRFI0 type syntax.


>> But how would we get the defintion for the do-get procedure in
there?
>Well, you can create IndirectJavaReference objects; just make sure
>they extend gnu.mapping.NameMap.

I'll look at this too!


>> Could a Kawa module be declared abstract?
>Perhaps.  I don't think that makes sense 

You're right. Some "require" and "import" system is better.


>This ties into two of my ideas:
>* A module that evaluates to a result value.  This isn't really a
>"module" (which is a set of exported bindings), but it's a "body"
>whose result is a concatenations of that of the sub-forms.
>* A result value given by outputing to a file/stream, rather
>like a Unix shell pipe-line.  I implemented something like this
>in Q.  See http://www.bothner.com/~per/software/index.html#Q 
>and http://home.pacbell.net/bothner/Qshell.html .

Agreed to both of those. First one isn't too hard surely?

Loosely:
  (define-macro (bodyo terms)
    `(some-out-func ,terms))

Then add a syntax-extension, eg: to provide a define-servlet that
used bodyo instead of a normal lambda.

Not sure how you'd do the second one though.


The concept of filter-ports (ie: things between pipes) is something
that I've been thinking would be kinda fun for schemlets but I'm not
even sure it could be done. Maybe with different repls.



*Abstract*
>I'm not sure whether it should be legal.  I don't think there are
any
>checks currently implemented.

I'd stick with having it illegal. I see no need for it... I was just
raising the ishyoo.



*General thankyou*
Thanks for your time with all this BTW - Paperclips is going through
major change right now and so I might as well get all the Scheme stuff
done at the same time (or at least as much of it as is feasible).
It'll save me writing a lot of JSP.

It really helps being able to work out all this stuff and know what
you're thinking re module system.




Nic