Re: Scheming over a PHP replacement

[Per Bothner]

Bruce Korb wrote:

> I'm inclined to think it a good idea:  make easy things as easy as
> possible 'cuz the complex stuff isn't used as much.
> Like RISC technology...


Ah yes, I remember RISC technology.  And I agree it is a good
example of something that isn't used as much ... Or maybe that
isn't what you meant??

> ??  Ultimately, you have to glue strings together no matter what
> you do.


Yes and no.  What you glue together are "document fragments",
which are structured *trees*, not strings.  In my implementation
(and I'm sure others) these fragments are passed to a Consumer
(using an interface that is a more abstract version of SAX).
The ultimate Consumer is typically a file, or a socket output buffer,
but it could be a database, or even some browser-specific binary
encoding.


> The alternative being you only have string literals?


That is one option, if you just want to work at the text level.
In XQuery you have "element constructor expressions" which you can
think of as "node literals" (which aren't quite literals, since
there is an "unquote" operation).

> It seems you would be advocating adding the programming
> logic necessary for managing additional embedded string literals,
> instead of removing that clutter from the (hopefully minimized)
> programming project.


I'm agnostic on autogen as a general file-munging tool, though I
think my arguments also apply there.  However, I'm focusing
on the specific domain of generating html or xml.


> And you wouldn't normally be doing that, either.
> If you do want to process the html through some
> scheme code before emitting it, I would expect
> it to be done within a single generation expression.


But the output you generate might depend on data sitting
in a xml file.  If you work at the text level, you have a tool
that is quite limited.  You're viewing html as a pure output
format.  The whole point of the xml hype is to use xml for
data storage. data output, and data transmission.  It is fine
to not want to do that, but if you can do these things while
keeping it very easy to generate output, you have a much more
powerful tool, one taht is not a dead-end.


> Reprocessing/reparsing text is ugly and hard.
> Ultimately, though, you really do have to glue it all
> together no matter how you compute the text.


Lisp/Scheme people know that trees are easier to work
with than text.


> This:  http://autogen.sourceforge.net
> has another feature:  it is working now.  :-)

Well, so does Qexo (Kawa-XQuery).  At least I'm now using it
to manage my digital photos.  The idea is to have an index.xml
file that describes a group of pictures, and then I run an
XQuery program on it to get an overview page plus a bunch of
cross-linked pages.  The alternative would be to have a template
file in place of index.xml, but then you are mixing data and logic,
which is less flexible.
--
        --Per Bothner
address@hidden   http://www.bothner.com/per/