Am 15.11.2013 15:29, schrieb David A. Wheeler:
> (Replying briefly privately, since it was sent privately - I'd be happy
> to discuss this further publicly.)
Replying publicly.
>> Here an example. I have so many of them ("grep begin *.xml" indicates
>> 162 in a single directory) that I'm asking myself where it would be
>> worth convince you that there should be a switch to disable the "initial
>> indent cancels indent processing".
>>
>> <xsl:template name="current-selection">
>> <d:copy-of select="#CONTENT">
>> begin
>> define selected
>> form-field (gi (current-node)) (message-body msg)
>> if (or (not selected) (string-null? (data selected))) (current-node)
>> selected
>> </d:copy-of>
>> </xsl:template>
>>
>> You see: the whole (srfi-49) code is indented to match the XML indent
>> level. In practice I did not always make it match exactly. But often
>> enough I avoided to start in the left column because I felt this would
>> confuse the reader. (Maybe it would not, but who cares.)
>
> We intentionally didn't support starting full expressions in arbitrary
> columns; that turns out that there is a nasty syntactic ambiguity. See:
> http://srfi.schemers.org/srfi-110/srfi-110.html#disabling-indentation-processing-with-an-initial-indent
That ambiguity is the reason why there is always a `begin` block and no
empty line in the idiomatic use. We've been living with SRFI-49 till now.
I decided that the way of least resistance to solve this is to introduce a
new namespace and keep the backward compatible code. See also
http://askemos.org/A0cd6168e9408c9c095f700d7c6ec3224?_v=search&_id=1550 for
the XSLT/XML embedding.
> If you modify your Scheme-from-XML extraction code to look at the
> initial indent of the first line, and then remove that text sequence from
> every line of that fragment, the problem would disappear. And you
> wouldn't need to modify any contracts.
>
This would add yet another layer of complexity. If not done in the
sweet-parse, I'd have to duplicate this indent processing behind some
custom port's i/o, for which I don't see portable code any time soon.
However I have something else in mind atop. I'd like to look into mixing
markdown as a "front end syntax" and re-parse / pattern match data content
from the resulting XML syntax tree. See:
http://askemos.org/A0cd6168e9408c9c095f700d7c6ec3224?_v=search&_id=756
(Note: there's also a related remark: neither basic Scheme `read` nor
sweet-read and friends will include comments. For some reason I'd like to
be able transform source code _including_ comments into derived versions,
which will then be the new version presented for edits by human authors.
Ergo: I need those comment nodes to be retained and included with the
corresponding "write" alike operation.)
Best Regards
/Jörg
....
------------------------------------------------------------------------------
DreamFactory - Open Source REST & JSON Services for HTML5 & Native Apps
OAuth, Users, Roles, SQL, NoSQL, BLOB Storage and External API Access
Free app hosting. Or install the open source package on any LAMP server.
Sign up and see examples for AngularJS, jQuery, Sencha Touch and Native!
http://pubads.g.doubleclick.net/gampad/clk?id=63469471&iu=/4140/ostg.clktrk
_______________________________________________
Readable-discuss mailing list
Readable-discuss@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/readable-discuss
