Re: [Readable-discuss] I-expressions issues

[Egil Möller]

Title: FreeCode Signature

Hi everyone! Now that Egil Möller is on the list, he can perhaps explain why they aren't problems (just misunderstandings or disagreements), or if they ARE, help fix them. Most of them are actually realy 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... * Multiple blank lines become () in the implementation, and I believe that's per spec. E.G.: The spec is very unclear on this: In the following syntax definition, this initial space, as well as linebreaks, is not included in the rules. Instead, preceding any matching, the leading space of each line is compared to the leading space of the last non-empty 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. 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. * 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. a1 ; hi b2 ; there a3 The red numbers mark the positions where the S-_expression_ (read) function is called, and unfortunately, where it returns. As can be seen, no indentation is left for sugar at all! * Spec unclear about indentation issues of INITIAL line. The spec hides indentation issues into the indentation tokens, glossing over some stuff. Which can lead to some surprises. The sample implementation maps this: a b c d into (a b (c d)), and NOT into the possibly-expected pair of lists (a b) followed later by (c d). This is not according to the spec, and the spec. is pretty clear about that in my opinion, so that is a pure bug in the sample impl.: expr -> head INDENT body DEDENT and 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. Since both lines have the same indentation in your example, there should be no INDENT/DEDENT tokens around the second 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* * The spec has loops. In particular, it has these productions: expr -> head and head-> expr head-> expr head This really should read (it is a bug in the spec): head-> s-expr head * In general, is there a way to simplify the spec and/or implementation? I'd like the spec AND the implementation to be "obviously correct", so that people will be willing to trust it. * Is there any way to make it even more compatible with existing files or to make it easier to use immediately on the command line? Currently, on the command line it is easy to get "out of sync" (you press Enter and see the results from a PREVIOUS command). Adding support for blank lines (Enter Enter) would help, but additional improvements in either attribute would be great. 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)... Best regards, Egil -- Konsulent, Fri Programvare / Free Software Consultant 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