[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

RE: 200alpha5



> Apologies for polluting the wide-area mailing list with my suggestion. We
> have discussed this internally and have come to a conclusion. -- Matthias

Please forgive me for responding to this, but I'm interested in the topic.
We've just been discussing this issue on c.l.s, buried in the long-running
thread "Scheme advocacy: scheme vs. perl".

The JScheme paper which Jim Bender referenced seems to be solving a general
problem in an overly specific way.  The paper begins by identifying the
problem too specifically: "The motivating problem it that *when generating
HTML* in Scheme...".  However, the problems mentioned, that quotes require
quoting, and that nested string-appends may be needed to build strings
containing dynamic content, are both general problems that can apply to any
kind of generated content.  The discussion about this on c.l.s. began
talking about embedding SQL, not HTML.  Other content types are also
possible.  Certainly, it might be possible to use <xml></xml> as a marker
regardless of the type of content, but I'm not sure how appropriate that is,
and it may lead to erroneous assumptions and unnecessary limitations.

An additional problem with the JScheme solution is the verbosity of the
tags.  Embedding Scheme code within <scheme></scheme> elements will quickly
become tedious, and in addition, XML tags do not stand out very well when
embedded in HTML or XML.

In the c.l.s thread, Bruce Lewis pointed out that much of what is needed can
be achieved simply by providing an alias for the double-quote character, as
he does in BRL.  In BRL's case, the quotation alias is "][", which
presumably wouldn't work for PLT.  Bruce has an interesting point, though,
and it may be worth examining BRL to get a feel for this in action.

David Rush pointed out that SRFI 10, the sharp-comma external form, might be
applicable.  I'm not familiar enough with it yet to evaluate that, but it
seems plausible.

David Rush prompted me to suggest a macro-like form with abitrary block
delimiters e.g.

	(template-expand end-marker
arbitrary template text goes here, with embedded code using some kind of tag
end-marker)

Felix of Chicken (don't know his last name, so he gets to be named like
William of Occam) made a suggestion which I haven't absorbed yet, for a kind
of extended read-macro.

If your decision was to add such a feature to PLT Scheme, please consider
making it more general than the JScheme solution.  It doesn't seem to be in
the Scheme spirit to be so specific, especially if one is talking about a
change which actually affects the behavior of the default reader (?)

And if you decided not to add a feature like this, well, why the heck not?
;o)

Anton