On Sun, Aug 26, 2012 at 11:57 AM, David A. Wheeler <dwhee...@dwheeler.com> wrote: > Alan Manuel Gloria: >> >> git://github.com/AmkG/letterfall.git > > This is awesome, thanks so much for doing this. This gets us over the hump > of "only one person has tried it out". We have two programs written by two > different people, that have used sweet-expressions: > * sweeten (me), 305 non-comment, non-blank lines. Processes source files. > * letterfall (Alan Manuel Gloria), 789 non-comment, non-blank lines of Scheme > source code. GUI game. > They're not even in the same application domain, cool. > > So, questions for Alan - can I talk you into answering them?: > > 1. How did the notation work out? Do you like the result? Is it helpful to > use?
The notation worked quite well. Note that I really abused SPLIT here - notice how I implemented the monadic bind macro kdo! Basically, kdo is a monadic macro similar to Haskell's do notation. Instead of Haskellian: ! do ! ! var <- x ! ! compute var The Sweet-Scheme is: ! kdo ! ! let var \\ x ! ! compute var Which is quite sweet, and makes monads very sweet to express in Scheme. -- Why use a Monad in this case? Well, Guile's built-in continuation support is inefficient as it copies the C stack. In addition, while guile-gnome actually has an example where it uses continuations in a manner highly similar to how I use it in this game, that example has warnings all over it that effectively say "don't use it, this was done to try it out, but in theory it shouldn't work because of some weird stuff gtk does in the actual C backend, and may fail for more complex stuff". So I needed to do continuations *without* using the builtin continuation support. Now Haskell doesn't have builtin continuation support either, but it does have a Cont monad that works almost as well. The (letterfall kont) library is effectively the Scheme translation of the Haskell Cont monad. > 2. Did you find any serious flaws with the notation? If so, what? So far, no *serious* flaws. The sheer flexibility (SPLIT, SUBLIST) is almost a flaw: it's actually easy to make (some kinds of) short code sections very pretty, but which at some point in the future, when you extend them, don't look as sweet in the larger scale. I suppose some guidelines/style guides will help. This is something you really ought not to do for example: define foo(bar) $ let ((var (comp bar))) use bar Pretty much only cond should be put there. Also, remember that SUBLIST only works outside of parens - (foo $ bar nitz) doesn't work. LOL. That bit me once. > 3. Any "lessons learned" on useful patterns you'd suggest others should use? I really like SUBLIST. Protip: use SUBLIST as much as possible to keep yourself out of the neoteric-domain. This is very good especially when you need to extend later. > 4. Would you use it again? Definitely! Get off my lawn s-expressions!! Sincerely, AmkG ------------------------------------------------------------------------------ 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
