Alpheus Madsen: > First, I'm not sure what the status of "\" is; or how it currently fits > in with the proposed GROUP, SLICE, etc semantics. (I don't fully > understand those semantics, but I suspect that they'll be cleared up in > the 0.3 Spec...if I understand correctly, though, these are the names of > how "\" has been proposed to be used.)
The "status" is in some sense easy: We're discussing that right now! There are several proposed semantics, and several proposed symbols. There are advantages to the various alternatives; now is the time to discuss them. A summary of the options is here: http://sourceforge.net/p/readable/wiki/Current/ > On the one hand, I like using "\" as a way to end a line; using it to > separate two lists seems kindof reasonable. I'm not sure if using it as > a replacement for "group" will fix things. > > On the other hand, using "\" in this overloaded way can potentially be > confusing. Since the different contexts are mostly orthogonal to each > other, this isn't likely to be too much of a problem...except that the > biggest clash will be in the fact that "\" is also Common Lisp's Escape > Character. Indeed, it is because of this that I couldn't see how to > comandeer Haskell's use of "\" as lambda. As much as I like it, I'd > more likely use Paul Graham's "fn" instead. (Like "group", I think > "lambda" is an over-handed keyword for an important, simple concept.) This is my concern with "\" as well. Alan Manuel Gloria's analysis (on 16 Jul 2012 09:31:55 +0800) suggests a mild (but not necessarily decisive to me) advantage to using "\" for several common use cases. But since "\" as an escape mechanism is widely-used, that is a big disadvantage to it. > Which gives me an idea that would further overload "\": If it isn't too > complicated, we can define \(...etc...) to be lambda! (I have the > sneaky suspicion that Common Lisp will make this too complicated, > though...) Right. If we don't have "\" mean SPLIT or GROUP, and your Lisp doesn't include slashification, you could indeed use \(...) if you wanted to. That's another argument for NOT using "\" as SPLIT or GROUP. > About a week ago, as I was thinking about the GROUP issue, I had the idea > to use an ellipses in the following manner: > > let > ... x 10 > y 12 > {x + y} > > This would be equivalent to (and compatible with) > > let > ... > x 10 > y 12 > {x + y} > > That is, the ellipses designates a group; if anything follows the > ellipses on the same line, it's considered a list in and of itself; any > sublist contained in the ellipses would be "appended" to the original > ellipses. Okay! That would just mean that GROUP="...". That's certainly a reasonable proposal. One implication is that some of the period-as-indentation proposals can't be used, but if you say that period is only indentation if followed by space or tab (my current proposal) then there's no issue. This proposal would, in fact, be really easy to implement given our current code. If you just strip away the "...", I think that'd be a 2-line change. HOWEVER, this would mean that you could not easily have "..." as a first parameter, and this *can* happen in Scheme (e.g., in macros). Yes, they can be escaped, but it's best if the notation minimizes the need for escapes. If you change the symbol to GROUP="...." (4 periods), that problem disappears. > This would be simpler to implement than the other idea I proposed, which > was to have a series of ellipses, like so: > > let > ... x 10 > ... y 12 > {x + y} Agreed. Also, inserting the ellipses on *each* line would be a pain when doing it by hand, so I don't like this one as much. > The reason this is a concern with me, is that one of the reasons I > consider GROUP to be "heavy-handed" (besides being a long name) was that > it introduced an extra line that I consider unnecessary. > > Of course, this semantic would work just as well with GROUP, or ".", or > even "\", or perhaps even something like "::", as it would for ellipses; > I'm just partial to using ellipses myself. Fair enough. Actually, though, changing symbols makes sense. > Second, one of the thoughts I've been having lately, is a concern about > the attempt to be compatible with as many Lisps as possible. While I > think this is a useful concern--indeed, it allows sweet-expressions to be > tested in a variety of environments--it can also hamper a good idea, if > not used cautiously. For example, if using "\" in its various contexts > is a good idea, the fact that Common Lisp hampers it by using "\" as an > escape character shouldn't result in its complete rejection. (It may, > however, be one of several valid reasons to eventually reject the > character for something different.) ... > Indeed, since no two Lisp variants are strictly compatible with each > other, trying to come up with a sweet-expression spec that's fully > compatible between every variant may even be impossible! That may be true. However, I think it's best to strive for that goal, and then back off as necessary. > Third, I'm not sure I like the idea of using "." for indentation. While > it helps to clarify the structure, it can also clutter the visual > presentation of the source code. I like the fact that word processors > allows for ways to toggle visual whitespace (certainly Kate, and probably > Vi and Emacs); and sometimes I'll do a formal search and replace between > " " and "--|" and back, when I need a better handle on the > structure...but those are editing functions, and I'm not sure if it would > be a good idea to have these things formally in the source code. My original reason for provisionally accepting it was because lots of people are having trouble *seeing* the indentation. The lining-up idea came later. Let's see where we stand after looking at the options. --- 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
