Egil Möller:
>Most of [the indentation processing issues noted in Wheeler's previous email]
>are actually really problems, indeed :(
> I will try to help you the best as can, but I must warn you that I started
> working on I-expressions during 2001, and then wrote the SRFI in 2005 (I
> think), so I have forgotten most of how the sample implementation worked...
:-).
Wheeler:
>> Multiple blank lines become () in the implementation, and I believe that's
>> per spec. E.G.:
> [If the spec were] Followed to the letter, this has a bug - a non-empty,
> indented line, followed by one or more lines with only indentation (space)
> will leave multiple INDENT/DEDENT tokens, which the following rule can then
> construct empty lists from:
body ->
'()
> This should be fixed, by changing the above paragraph of the spec to read
> something along the lines of
> In the following syntax definition, this initial space, as well as
> linebreaks, is not included in the rules. Instead preceding any matching,
> empty lines and lines with only spaces are removed, then any leading space of
> each remaining line is compared to the leading space of the last remaining
> line preceeding it, and then removed. If the line is preceeded by more space
> than the last one was, the special symbol INDENT is added to the beginning of
> the line, and if it is preceeded by less space than the lastt one was, the
> special symbol DEDENT is added to the beginning of the line.
I think that's better.
I took your code and modified it to this in my sweet.scm prototype, but at the
time I had a misunderstanding of what it was doing. So you MIGHT not want to do
the same modification in yours.
>> * Sample implementation doesn't always handle inline comments correctly.
>> E.G.:
>> a ; hi
>> b ; there
>> q
>> Both with and without a blank line before "q" produces (a b q), instead of
>> the expected (a b) followed later by q.
> This is because the sample implementation does not care about comments, and
> is a bit stupid. What it does is call the original (S-expression) read
> function for repeatedly, with some indentation-sensing in between. The quotes
> actually garbles the whole thing badly, it's just that it doesn't happen to
> cause problems except in one place.
It's your implementation, you're more likely to be able to fix it. Is that
something you could fix? The "sugar.scm" that I fixed up is now in SVN, so you
can download it from there. Of course, you'll have to make it work with the
latest version of guile too :-).
>> * Spec unclear about indentation issues of INITIAL line. The
>> implementation appears to skip any spaces/tabs on the first non-empty line.
>> Then, any following lines that are indented AT ALL are considered indented -
>> so the NEXT line to see how much indentation is used for the first-level
>> indent.
> There you have the bug :P An evil one at that :P But looking at the source I
> can not see how this can be the case:
> It seems like just changing the "" default level argument to readblock-clean
> in sugar-read to (indentationlevel port) should fix the problem? *untested*
As I posted earlier, this problem is actually really subtle, and it's
reasonable to argue that this is a GOOD idea. If you read in:
x
y
z
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.
>> * The spec has loops. In particular, it has these productions...
> This really should read (it is a bug in the spec):
> head-> s-expr head
Hmm, I'll have to see if that helps.
>> * In general, is there a way to simplify the spec and/or implementation?
I wonder if it'd be easier to write the spec so that all non-initial datums and
child lines are put into a list, and then, if the list is EXACTLY one item
long, turning it into that item. I think that would have the same effect as
these more complex specifications, and any code that followed the simpler spec
should be simpler too.
> The double-enter is the same as in Python, but in Python you get a lot of
> help from the two different prompts. I never had time to implement proper
> prompting in sugar (it is rather complicated to get right actually)...
Ah. I think you're right, varying the prompt might really help people
understand what's going on.
My "sweet-expressions" are built on indentation, but I think we can completely
separate the concerns. If I built a good sweet-expression-nonindent reader,
installed it as the "read" function, and then you had a fully-working
"I-expression" reader implemented, the latter could then be installed... and
BOTH would work.
But for that to work, the I-expression reader needs to skip initial blank
lines, and handle comments correctly. In particular, I think the I-expression
implementation HAS to implement comment-skipping itself... by calling on the
underlying reader it's losing the information it needs.
--- David A. Wheeler
