>
> Is 'group' really going to be easier to understand than enabling
> whitespace-sensitivity inside parens? I think that's a good test if
> we've decided the latter is too complex.
>
> Also, using backslash for any meaning is butt ugly.
>
I don't completely agree with your sentiments; in part, because adding
significant whitespace is bound to change the language significantly, so
adding a symbol or two here or there isn't a concern for me.
Oddly enough, I kindof like the idea of GROUP; I just don't like the
current syntax.
In my modest attempts to write my own whitespace parser, though, I find
that turning off whitespace in brackets simplifies implementation; it's
also useful for creating long lists without a "continue to next line"
character; and since a goal of the project is to preserve s-expr
compatibility, turning off whitespace significance in brackets is rather
important!
If we were designing a language from scratch, I'd be a little more open to
leaving significant whitespace on in brackets, and breaking s-expr
compatibility. But the project has an even more important goal (and one
that attracts me to this particular project): to prove the isomorphic
nature between s-exprs and sweet-expressions, particularly with
compatibility with macros. This is an important reason why operator
precedence is, in particular, something to avoid as much as possible.
Besides, I really like the simplicity of s-exprs; the way I see it, the
goal of sweet-expressions is to prove that we can have
infix-yet-syntax-free, whitespace-significant s-exprs. (With this goal in
mind, of course, sweet-expressions had better be just as elegant!)
> Arc, if I understand correctly, uses "\" to separate two lists on a line.
>
> Perhaps we're thinking about different Arcs? http://arclanguage.org is
> not whitespace sensitive at all. (It does not use backslash --
> otherwise I wouldn't be using it :)
No, we're thinking about the same Arc; it was my understanding from reading
the list that Arc uses "\" in certain contexts, and certain
sweet-expressions are trying to preserve the idioms.
I may be wrong, though: perhaps the Arc idioms in discussion are of the
form
(list 1 2 3) (list 4 5 6)
which, for sweet-expressions, would be
list 1 2 3 \ list 4 5 6
(I am probably getting even this example wrong).
Also, using backslash for any meaning is butt ugly.
>
I would partially disagree with this; but I'm willing to put up with it in
certain contexts. It's an idiom in several languages, for example,
including Bash and Python, to put a backslash at the end of a line; in
Python, though, I find it ugly enough that I usually try to wrap something
in parentheses (which turns off significant whitespace) than resort to
ending a line with a backslash.
For separating two lists on a single line, however, it isn't that bad of an
idea.
In many languages, using the backslash is a good way to escape characters;
since Common Lisp is one such language, and it's used for escaping
characters in symbols, using the backslash for other things is problematic.
And I *really* like how Haskell uses the backslash for lambda expressions!
I like it so much, I really wish we could use it in Common Lisp!
Perhaps it wouldn't be too much trouble to recognise when something is of
the form
\((x) {x + 5})
and translate it into
(lambda (x) (+ x 5))
as it is, I think that the current form,
lambda((x) {x + 5})
would be rather clunky. At the very least, Paul Graham gave us the
possibility of
fn((x) {x + 5})
> Modulo my reservations about group, this is my favorite idea so far.
> But it also screams to me that we could just use parens. It might help
> the discussion if we always use a complex example that we think
> *requires* group.
Here's an example taken from
"http://sourceforge.net/p/readable/wiki/Examples/<http://sourceforge.net/p/readable/wiki/Examples/>
".
define solve-kalotan-puzzle
lambda []
let
group
parent1 amb('m 'f)
parent2 amb('m 'f)
kibi amb('m 'f)
kibi-self-desc amb('m 'f)
kibi-lied? amb(#t #f)
assert
distinct?(list(parent1 parent2))
assert
if eqv?(kibi 'm) not(kibi-lied?) assert if
kibi-lied? xor {eqv?(kibi-self-desc 'm) and
eqv?(kibi 'f)} {eqv?(kibi-self-desc 'f) and eqv?(kibi 'm)}
assert if not(kibi-lied?) xor
{eqv?(kibi-self-desc 'm) and eqv?(kibi 'm)}
{eqv?(kibi-self-desc 'f) and eqv?(kibi 'f)} assert if
eqv?(parent1 'm)
and
eqv?(kibi-self-desc 'm) xor
{eqv?(kibi 'f) and eqv?(kibi-lied? #f)}
{eqv?(kibi 'm) and eqv?(kibi-lied? #t)} assert
if eqv?(parent1 'f)
{eqv?(kibi 'f) and eqv?(kibi-lied? #t)}
list(parent1 parent2 kibi)
solve-kalotan-puzzle()
I'll try it with whitespace-enabled parentheses:
define solve-kalotan-puzzle
lambda []
let(parent1 amb('m 'f)
parent2 amb('m 'f)
kibi amb('m 'f)
kibi-self-desc amb('m 'f)
kibi-lied? amb(#t #f))
assert
distinct?(list(parent1 parent2))
...ETC...
solve-kalotan-puzzle()
And now with ellipses:
define solve-kalotan-puzzle
lambda []
let
... parent1 amb('m 'f)
parent2 amb('m 'f)
kibi amb('m 'f)
kibi-self-desc amb('m 'f)
kibi-lied? amb(#t #f)
assert
distinct?(list(parent1 parent2))
...ETC...
solve-kalotan-puzzle()
And I think, frankly, now that I think of it, the prettiest solution would
be to do away with parentheses, ellipses, and GROUP altogether:
define solve-kalotan-puzzle
lambda []
let parent1 amb('m 'f)
parent2 amb('m 'f)
kibi amb('m 'f)
kibi-self-desc amb('m 'f)
kibi-lied? amb(#t #f)
assert
distinct?(list(parent1 parent2))
...ETC...
solve-kalotan-puzzle()
except that would require a re-write of LET, COND, and any other function
or macro that expects a list of lists; and we come back to the problem of
the syntax I originally suggested: we have to have a way to check for
double-indentation, which while I don't have a problem with it visually
(David Wheeler disagrees with me on that :-), can be a bit of a cludge
calculatingly to deal with.
To avoid re-writing the semantics of LET, we could, theoretically, insert
something between LET and PARENT1; alternatively, we could create a new
syntax <...>, which produces a list of lists, and where whitespace still
matters...which would look like this:
define solve-kalotan-puzzle
lambda []
let <parent1 amb('m 'f)
parent2 amb('m 'f)
kibi amb('m 'f)
kibi-self-desc amb('m 'f)
kibi-lied? amb(#t #f)>
assert
distinct?(list(parent1 parent2))
...ETC...
solve-kalotan-puzzle()
That, in itself, would have its own problems, I think. (I can't remember
if Closure uses angle brackets for HTML and XML generation, or if it were
just non-Lispy Scala; if not, though, I couldn't help but expect it to be a
natural thing for some intrepid Lisp programmer to do! If so, that would
be yet another factor in deciding whether or not to accept such syntax...)
At the very least, it would add yet another list syntax to worry about...
On Wed, Jul 18, 2012 at 12:09 PM, Kartik Agaram <a...@akkartik.com> wrote:
> I've been falling behind as well. I wanted to see if time would reduce
> my dislike for GROUP, but that doesn't seem to be happening. Indeed, I
> can't even bring myself to do more than skim the discussions about it.
> I've struggled to understand/articulate why this is to myself, and
> mostly failed. The best I can come up with: making a language
> indent-sensitive should never add new syntax. Certainly not syntax
> that isn't attached to existing code (like quote, parens, unquote --
> or python's colon), and absolutely not a keyword like 'group'. SRFI 49
> is utterly wrong-headed about this.
>
> Curly infix adds syntax, but it seems intuitive. Modern exps move
> parens around; that's also fine. But a pass that just makes whitespace
> sensitive is too complex if it also affects non-whitespace. I think
> that will be a non-starter. It is seriously easier to use an existing
> mechanism and just wrap the whole thing in parens.
>
> > I'm not sure if it would be a good idea to have [editing functions]
> > formally in the source code.
>
> I think your sentiment here is close to my previous paragraph.
>
> Is 'group' really going to be easier to understand than enabling
> whitespace-sensitivity inside parens? I think that's a good test if
> we've decided the latter is too complex.
>
> Also, using backslash for any meaning is butt ugly.
>
> > 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}
>
> Modulo my reservations about group, this is my favorite idea so far.
> But it also screams to me that we could just use parens. It might help
> the discussion if we always use a complex example that we think
> *requires* group.
>
> > 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!
>
> Yeah, I agree.
>
> > Arc, if I understand correctly, uses "\" to separate two lists on a line.
>
> Perhaps we're thinking about different Arcs? http://arclanguage.org is
> not whitespace sensitive at all. (It does not use backslash --
> otherwise I wouldn't be using it :)
>
------------------------------------------------------------------------------
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
