So: do we have a concurrence here? dwheeler? I vote "Blank comment-less line = end of expression".
Further arguments to allow this: 1. By proper design of the SPLICE-at-the-start rule, we can also define that SPLICE on a line, all by itself, followed by an expression on the **same** indent, will mean just that expression. Thus, we gain one more way to separate sub-expressions without using completely blank lines. Of course, by proper design of the SPLICE-inline rule (which would subsume the SPLICE-at-the-end rule in the absence of that rule) we have a different method of saying "I already typed the entire expression" on the REPL. viz. instead of ENTER ENTER you type in SPLICE ENTER. So we can actually decide "Blank commentless line = does NOT end expression", since we now have a method to type in one-line expressions and to finish multiline expressions at the REPL. Err. What did I vote again? On 7/4/12, Alan Manuel Gloria <[email protected]> wrote: > I say agree. I'll finalize the modification for this and put up the > modified parser spec (not the impl yet) on the list soon. Too lazy to > actually work on the day job today (T.T) > > On Wed, Jul 4, 2012 at 9:21 AM, David A. Wheeler <[email protected]> > wrote: >>> > 6. Proposal: Should ENTER ENTER no longer end an expression? >> >> I said: >>> > I don't like this one. The current behavior is to end expressions with >>> > ENTER ENTER, and I think this one is REALLY REALLY important. My >>> > earlier experiments without that showed that failure to support this >>> > was REALLY confusing. I think as long as comment-only lines (possibly >>> > preceded with indents) are completely ignored, and thus can be used to >>> > separate contents, we should be okay. >> >> Alan Manuel Gloria said: >>> Agreed. Note that a slight modification of SPLICE rules allows the >>> REPL user to use ENTER BACKSLASH ENTER ... Still, ENTER ENTER is >>> easier to turn to a mental tic than ENTER BACKSLASH ENTER. >>> >>> Haskell solves this problem (it allows empty lines within expressions) >>> by restricting the REPL to one-liner expressions (as an extension GHC >>> has a special command to input multiline expressions, which are >>> terminated by } IIRC). But Haskell focuses on purity, so functions >>> cannot be practically redefined, and is primarily a file-centric >>> language; the habit is to put any long expressions you want to test as >>> functions in the file you are testing, and to modify those functions >>> in an editor and reload the file when you want to change them. >> >> Agreed, so Haskell isn't the best model here. >> >> Python solves this problem by allowing (essentially making) interactive >> processing *inconsistent* with file processing: >> http://docs.python.org/reference/lexical_analysis.html >> http://docs.python.org/py3k/reference/lexical_analysis.html#line-structure >> But since Lisps are often used both interactively and not, having this >> kind of inconsistency seems like a problem. >> >> If we warn on the first time someone enters indented data, while >> processing indented data, that should prevent the risk of silently >> misunderstood code. >> >> By the way, I think we should start focusing on specific points, and >> change the subject line so it identifies which point we're discussing. >> Then it'll be easier to follow the discussion...! >> >> --- David A. Wheeler > ------------------------------------------------------------------------------ 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 [email protected] https://lists.sourceforge.net/lists/listinfo/readable-discuss
