Kartik Agaram: > Ok, I'm done going through it and I went through the tutorial as well. > > curly-infix.cl works great with sbcl.
Great, I've noted that in the tutorial. > I had to change the shebang in sweet-guile and modern-guile to > /usr/bin/env rather than /bin/env. Aside from that modern-guile worked great. Should we change all /bin/env to /usr/bin/env? What platform are you using? All systems I use allow either. Article http://en.wikipedia.org/wiki/Shebang_%28Unix%29 suggests /usr/bin/env, though it notes that nothing works absolutely EVERYWHERE. > I couldn't get sweet-guile working, perhaps because eval needs 2 args > in sugar.scm.... > Do I need to switch guile versions or something like that? (I'm using > guile-2.0) That sounds likely, I'm using guile 1.8. Can you tell me a little more about your system? Obviously we want to track that down...! > I notice some recent examples with a leading backslash, period, etc. > But the docs so far haven't made any mention of them. Did I miss > something? These are all proposals under active discussion on the mailing list. You can see a summary of the topics under discussion here: https://sourceforge.net/p/readable/wiki/Current/ There's some experimental support for the SPLICE operation and period-as-indent, so that we can try them out. > I've seen mention of different modes. How does one switch between > them? I think modes are a bad idea. With wart I was careful to make > sure that you never had to fiddle with modes, wonder if something was > evaluated in the right mode, etc. The only real "mode" is whether or not indentation processing is active. Inside (), {}, and [], indentation processing is *deactivated*. This is really valuable for compatibility with traditional Lisp, for example. > Are sweet exprs intended to be fully compatible with traditional lisp? > That was something I spent a lot of time thinking about -- I wanted > wart to be entirely lisp compatible, but I had that single-space > exception that I now no longer have, which makes me very happy. Is > this feature important to y'all as well? Compatibility is important. These notations are fully compatible with *well-formatted* Lisp, which is almost (but not *quite*) the same thing. Having multiple tiers helps, too: 1. Curly-expressions are completely compatible, since {...} isn't in traditional Lisp. 2. Modern-expressions are compatible for what I'd call "normal" formatting. The key issue is that it changes the meaning of an opening paren after a character other than whitespace or another opening paren. So if you're using to saving whitespace that will be different. Basically, a(b) becomes "(a b)", not "a (b)". There are millions of lines of Lisp code that would never see the difference. So if you wrote "a(b)" expecting it to be "a (b)", you will need to insert the space. 3. Sweet-expressions add indentation processing, but since indentation is disabled inside (...), ordinary Lisp expressions immediately disable this & don't cause issues. The only problem is if you have a *top-level* expression when more than one datum on a line *and* the line doesn't begin with space/tab. Thus: (a) (b) is interpreted as two datums "(a) (b)" in traditional Lisp, but a single "((a) (b))" in sweet-expressions. You can disable sweet-expression processing with a space indent, so just inserting a space on every line *ensures* compatibility with the sweet-expression processing. {This is a good question - I just added this discussion to the "Rationale" wiki page.} --- 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 Readable-discuss@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/readable-discuss
