ii) An indentation-sensitive lisp like wart requires mentally
inserting parens to make sure we aren't accidentally wrapping
something we didn't mean to.
People indent even when it's *not* significant, so this turns out to be a
non-problem. The indentation ends up working with, not
I split up the sweet-expression description so that there are 2 main rules,
followed by a list of refinements.
Appended below is my stab at the sweet expressions section.
I've separated out the tutorial from the spec. I would like for
tutorial forms of the problem and solution to go right on
Kartik Agaram:
Appended below is my stab at the sweet expressions section.
Thanks!
I've separated out the tutorial from the spec. I would like for
tutorial forms of the problem and solution to go right on the
top-level page at http://readable.sourceforge.net. The reader should
be able to
Kartik Agaram:
The idea of suppressing paren-insertion inside explicit parens is a
good one. I had considered it, but I hadn't noticed that it allows me
to get rid of the single-space rule. I'm going to try that!
Ok, this change is now in: http://github.com/akkartik/wart/commit/3320d257ac
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
Should we change all /bin/env to /usr/bin/env? What platform are you using?
This was on a laptop running linux (http://www.linuxmint.com/download_lmde.php)
I've only ever seen /usr/bin/env. The wikipedia article makes no
reference to /bin/env except to say OpenServer and Unicos use it. What
Why not just myfunction(:option1 f(a), :option2 g(b), :option3 h(c))?
Or is there an issue with commas?
Yes, comma means unquote. In addition, comma-whitespace is used in
indentation processing to mean that the inner expression of the
unquote is also processed using indentation processing.
Kartik Agaram a...@akkartik.com
...
myfunction(:option1 f(a), :option2 g(b), :option3 h(c))
I'd also be ok with writing:
myfunction(:option1 (f a) :option2 (g b) :option3 (h c))
Okay, that's already a perfectly acceptable modern-expression.
Have y'all been trying to avoid mixing
Ok, you've persuaded me not to mess with commas :)
--
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.
Kartik Agaram:
A variant of this is now in wart:
http://github.com/akkartik/wart/commit/c2e6d0c6d3. What do y'all
think?
(This is 1914 - experiment: ':' as a comment token).
Interesting! By the way, this is exactly how we've been working - we've
floated ideas on the mailing list, and if
Kartik Agaram:
That seems *really* complicated. I didn't see reference to this
'escape hatch' in all my readings. Is this somehow deduced from the
three rules, or from the new proposals for v0.3?
https://sourceforge.net/p/readable/wiki/Solution/
A leading quote, comma, backquote, or comma-at,
On Sun, Jul 15, 2012 at 1:50 AM, Kartik Agaram a...@akkartik.com wrote:
I suspect that this is just strictly a problem with 2.0.
Yep, I uninstalled 2.0 (just the first one I picked last night) and
installed 1.8, and went through the rest of the tutorial with
sweet-guile. Everything works
We could have leading-SPLIT always be a comment marker, even when indentation
is disabled. But I think there's no need; once indentation processing is
disabled, you can indent however you please, and there's no need for a
special symbol.
My ':' wasn't intended to help reduce parens. It
On Sun, Jul 15, 2012 at 7:31 AM, Kartik Agaram a...@akkartik.com wrote:
I use guile-2.0 for sweet-expressions development, and it works fine -
probably just need to forcibly reload cache. I'm also on the
project's newest code base, so it might also have an effect.
I just tried 2.0 again:
https://sourceforge.net/p/readable/wiki/Solution/
A leading quote, comma, backquote, or comma-at, followed by space or tab, is
a list with that operator and the following expression.
Of course, if you think that's a bad idea, then let's discuss! This is
straight from SRFI-49..
It's not
(Send this just to David by accident; resending to all)
The spec is (currently) at:
https://sourceforge.net/p/readable/wiki/Solution/
I think you're looking at the wrong file. The version02.html file is
obsolete; that's mainly useful if you want to see historically where we came
from.
I just found out about this list (thanks Alan!) and am going to go
read through the archives. In the meanwhile I wanted to share the
whitespace-sensitive lisp I've been working on. You can read about the
design choices I made at:
http://github.com/akkartik/wart#readme
I'd love feedback and
On Sat, Jul 14, 2012 at 2:00 AM, David A. Wheeler dwhee...@dwheeler.com wrote:
Kartik Agaram:
I just found out about this list (thanks Alan!) and am going to go
read through the archives. In the meanwhile I wanted to share the
whitespace-sensitive lisp I've been working on. You can read about
I said about a!b syntax:
This is kind of interesting, but it can already be noted as (a 'b) or
a('b), and it's not clear to me that this abbreviation is worth it for
arbitrary Lisp-based systems.
Alan Manuel Gloria replied:
Ah. This is a common idiom in Arc. In Arc, tables can be
On Sat, Jul 14, 2012 at 7:29 AM, Kartik Agaram a...@akkartik.com wrote:
In a simple 2-way branch, I try to cuddle the condition right after if
where possible:
. if iso(1 {x % 2})
. . 'odd
. . 'even
Yes, I don't use the :else in that case either.
---
Your other options are fine at the
BTW I haven't ever considered adding syntax at the start of a line.
The only place I've seen this idea before is vimscript
(http://vimdoc.sourceforge.net/htmldoc/repeat.html#line-continuation).
Is a backslash at the start of each line really less alien to
non-lispers than a few extra parens?
Also, has there been discussion of the haskell approach?
a) Explicitly mark certain ops as infix. That would eliminate a lot of
curlies, and also allow any op to be infix.
b) Allow any op to be temporarily infix by enclosing it in backticks
or something like that. Maybe curlies?
matrix1
On Sat, Jul 14, 2012 at 9:12 AM, Kartik Agaram a...@akkartik.com wrote:
Also, has there been discussion of the haskell approach?
a) Explicitly mark certain ops as infix. That would eliminate a lot of
curlies, and also allow any op to be infix.
b) Allow any op to be temporarily infix by
23 matches
Mail list logo
