On 7/24/12, David A. Wheeler <dwhee...@dwheeler.com> wrote:
> So I think this would be the (readable sweeten) module. The fact that it's
> written in sweet-expressions presents a fun bootstrapping issue :-).
(^^) Not at all. If you were to write (readable
color-of-the-bikeshed-issue) in sweet-expressions, *then* you got
bootstrapping issues o(^.^o)(o^.^)o
>> You know, I think the internal interface from sweet-read to
>> modern-read/curly-infix-read should be modified again.
>>
>> The problem is handling of multiline comments: either SRFI-30 #|
>> #|nested|# comments|# or Guile's interpretation of #!, depending on
>> the Scheme implementation's preference. (IIRC some other Schemes treat
>> #! as a line comment, not a multiline comment)
>>
>> But practically all multiline comment systems in all Schemes use # -
>> there's even a common #; extension that comments out the next term.
>> And currently process-sharp can indicate an object, *but it can't
>> indicate the **absence** of an object*.
>>
>> Perhaps, internally, modern-read, when invoked by the internal
>> function available only to sweet-read, can return either '() or
>> singleton list containing the read-in object. Let's call this
>> modern-try-read.
>>
>> Then modern-read-func simply invokes modern-try-read repeatedly until
>> it gets a non-null list, and extracts its contents.
>>
>> This internal change in interface will propagate all the way down from
>> process-sharp up to readitem I think, though.
>>
>> readblock would need to be more careful - if readitem returns null, it
>> must act as if it found a whitespace.
>
> Hmm. Once we invoke neoteric-read (nee modern-read), and it sees a nested
> comment, couldn't it just gobble it up & recurse until it *does* find
> something that's not whitespace?
Not really. Consider the following example:
foo bar
meow arf #|this got quuxed badly, fix it now|#
qux nitz
After the "arf", we invoke neoteric-read, which.... keeps going until
it sees qux. The sweet-expressions parser then thinks this is still
on the *same* line. But it's not.
----
And then here are the issues regarding multiline comments:
foo bar
#|long comment|# meow meow
#|!|# woof woof ; what's the indent here?? At woof or #?
arf arf #|what the...
...|# awooo
YAAAAAH!!
Here's my proposal:
1. Multiline comments (and other kinds of comments that are
introduced by a multi-character marker, particularly #) at the
beginning of a line (after any indent) define the indent to be
precisely at the column it starts. The effect is as if the entire
comment, including any newlines inside it, are replaced with the SPLIT
token. As an exception, multiline comments between top-level
t-expressions are simply deleted.
2. Multiline comments that start after some term has been read in are
simply deleted completely, including any newlines inside it.
So the above is:
foo bar
\\ meow meow
\\ woof woof
arf arf awooo
And then:
foo bar
meow meow
woof woof
arf arf awooo
------------------------------------------------------------------------------
Live Security Virtual Conference
Exclusive live event will cover all the ways today's security and
threat landscape has changed and how IT managers can respond. Discussions
will include endpoint security, mobile security and the latest in malware
threats. http://www.accelacomm.com/jaw/sfrnl04242012/114/50122263/
_______________________________________________
Readable-discuss mailing list
Readable-discuss@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/readable-discuss
