Hi Tomas,

probably this discussion gets too noisy for most readers of this list
(if there is anybody still following ;), so I'd like to keep it short.

> The issue of declaring the variables is something else, I think.  If I
> want to save/load the environments or send them over the wire, then they
> must be first class environments no matter if I declare the variables or
> not, mustn't they?

Yes. Or some other kind of variable-value association.

> > In "lib/form.l" in PicoLisp, the body to 'job' is the huge body of the
> > form generating code. The application level code isn't even loaded at
> > that time, and is different for each form or dialog invoked.
> I don't understand this argument.  If the application level code isn't
> even loaded, then there is nothing to be macroexpanded and compiled;-)

I see. Now I understand part of the problem! It seems we are talking
about different things. For me, "lib/form.l" and the stuff in
"myApp/gui.l" are (as I said) _libraries_. And a set of macros is not a
library for me; this may be different in the view of a CL programmer.
For me, a library is a set of pre-defined (or pre-compiled) functions,
ready to be called at runtime.

> Looking through the form.l code, it seems to me that the UI model could
> be significantly simplified.  For example, are the hidden fields
> necessary?  Is it necessary to pass binding values in url?  I don't

IIRC, yes. Why would I have otherwise gone through the trouble
implementing them?

> think so because all that information that is passed between http
> requests via query parameters in those cases is already known to the
> server.

No, it is not. These hidden values and URL parameters are needed to
identify which version of which form was posted:

   1. There may be several forms and dialogs on the page
   2. Each form has a history of previous states, which can be re-POSTed
      any time when the user goes back via the browser's "back" button,
      or re-visits a form by switching back from a different browser tab.

> Also note that macroexpansion doesn't necessary mean "code explosion",
> the expanded sexp gets compiled, possibly to a very efficient code.

OK, right. Not really an "explosion", but it means that a substantial
part of (the equivalent of) "lib/xhtml.l" and "lib/form.l" would be
expanded into every page that is loaded.

- Alex
UNSUBSCRIBE: mailto:picolisp@software-lab.de?subject=Unsubscribe

Reply via email to