|
After some consideration, I think that, for pure usability reasons
(while you have a point below in that not doing that is actually tricky
too), disallowing initial space is the correct thing to do, mimicing
Pythons behavior. Consider the following code snippet (. denotes space): foo bar ...fie ...; The following is really really interresting :) ...naja hehe What is the most intuitive and useful interpretation? I would argue that that is (foo bar fie (naja hehe)), not (foo bar fie) followed by (naja hehe)! The user must be able to insert empty lines and comments to clarify the code. Then, given the above, it makes sense to simply disallow the following code I am not sure how the current code handles this thou... I think you need to change...foo bar ...fie...; The following is really really interresting :) ...naja hehe ((eqv? char #\newline)in readblock to consume all leading lines, and then call itself, not readblocks. Ah, yes, this works for sub-blocks, because this consumed indentation is returned together with the block to the surrounding block, and fed into the block reader for the next sibling block. But you're right that this won't work on the top-level unless read maintains per-port state :(then you have to read in the spaces before "y" to know that x and y are at the same level. But after it's returned, the space before y was _consumed_ - short of unlimited ungetc, or hidden state in read (ugh!), 'y' looks just like the beginning of a line. There isn't really a difference between unlimited ungetc and state in read - that's just implementation details. Either you implement it as a part of read (uglier, but easier) or as a layer between read and the port (cleaner but more work). /Egil --
Cell: +47 - 91 17 05 93 Phone: +47 - 21 53 69 00, Fax: +47 - 21 53 69 09 Addr: Slemdalsveien 70, PB 1 Vinderen, 0319 Oslo  Free beer costs nothing, freedom costs a fight. Free beer lasts an eavening, freedom lasts a lifetime. |
signature.asc
Description: OpenPGP digital signature
