> > 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
Am Freitag, 13. Juli 2012, 21:52:27 schrieb Kartik Agaram:
> > Hi Arne, could you elaborate on this? How does one go about making
> > guile aware of sweet expressions?
>
> Never mind; I just found
> http://sourceforge.net/p/readable/wiki/Tutorial. I've been working
> through it without issues. Ver
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 t
> 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
Kartik Agaram:
> But I would rephrase my critique to say even just
> http://sourceforge.net/p/readable/wiki/Solution is quite subtle, just
> the Proposed Rules until the mention of [Rationale]. It fits on a
> screen, but still feels dense.
>
> I realize this isn't constructive criticism. Still thi
Alan Manuel Gloria:
> As an aside, one thing we *still* don't support very well is CL's
> loop. You're pretty much constrained to use parens for that to get
> any readability.
Miracle-working takes extra work :-). CL's loop is remarkably ugly in any
form. You're probably better off defining a
Kartik Agaram:
> Perhaps let inside the bindings of another let is enough of a corner
> case that we shouldn't try to support it? As long as we have curly
> infix and modern exps inside (...) is life not pretty good?
Absolutely!! That would just be "modern expressions" - which by the current
def
Kartik Agaram:
> The solution doesn't make reference to SRFI. Have y'all already done
> the inlining I was talking about?
Yes, at least I *tried* to. I stopped referring to the SRFI because we're not
planning to implement exactly what the SRFI does, but instead, to implement a
variant. For exa
But I would rephrase my critique to say even just
http://sourceforge.net/p/readable/wiki/Solution is quite subtle, just
the Proposed Rules until the mention of [Rationale]. It fits on a
screen, but still feels dense.
I realize this isn't constructive criticism. Still thinking about how
to improve
On Sun, Jul 15, 2012 at 10:02 AM, Kartik Agaram wrote:
>> GROUP is critically important.. you could just use (...) for a nested list
>> of lists.. But since it *DISABLES* indentation processing, you lose all
>> indentation support inside..
>
> Perhaps let inside the bindings of another let is en
>> http://www.dwheeler.com/readable/version02.html is quite long
>
> I've marked it (and several other html documents on my web page) as being
> obsolete and have them pointing to http://readable.sourceforge.net. Sorry
> for the confusion if you thought they were current.
Not at all, I was awar
> http://www.dwheeler.com/readable/version02.html is quite long
I've marked it (and several other html documents on my web page) as being
obsolete and have them pointing to http://readable.sourceforge.net. Sorry for
the confusion if you thought they were current.
--- David A. Wheeler
(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
>
> GROUP is critically important.. you could just use (...) for a nested list of
> lists.. But since it *DISABLES* indentation processing, you lose all
> indentation support inside..
Perhaps let inside the bindings of another let is enough of a corner
case that we shouldn't try to support it? As
Kartik Agaram:
> > 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
> > s
On Sun, Jul 15, 2012 at 8:13 AM, Kartik Agaram wrote:
>> 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,
Alan Manuel Gloria:
> > if you ever see a message about
> > ;; compiling /blah/blah
> > exit sweet-guile and restart it - don't clear cache
I've modified the tutorial to mention this.
In the long term, we all want it to "just work". Until that happens,
documenting workarounds is at least a st
> 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'
> if you ever see a message about
> ;; compiling /blah/blah
> exit sweet-guile and restart it - don't clear cache
Ah, that worked!
--
Live Security Virtual Conference
Exclusive live event will cover all the ways today's
On Sun, Jul 15, 2012 at 7:31 AM, Kartik Agaram 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:
>
> $ guile
> 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
> 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:
$ guile --version
guile (GNU Guile) 2.0.5-deb+1-1
$ rm -rf .cache/g
On Sun, Jul 15, 2012 at 1:50 AM, Kartik Agaram 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 fine!
At least
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-a
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 t
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. Discuss
Kartik Agaram
...
> > 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 traditional li
> 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))
Have y'all been trying to avoid mixing traditional lisp with modern-exps?
-
>> 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 proce
> You know, one completely knocks-the-socks-off-your-nose idea (due to
> dwheeler) is to use "." for indentation whitespace.
>
> And I think at least some of the problems of keeping multiple columns
> lined up is mitigated by this idea.
A variant of this is now in wart:
http://github.com/akkartik/
> > 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
> 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 fine!
> 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
pl
On Sat, Jul 14, 2012 at 8:06 PM, David A. Wheeler wrote:
>> 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 syste
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-
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/332
Kartik Agaram:
> 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. May
Am Freitag, 13. Juli 2012, 23:53:21 schrieb Arne Babenhauserheide:
> Am Freitag, 13. Juli 2012, 09:36:59 schrieb Kartik Agaram:
> > http://github.com/akkartik/wart#readme
>
> I read parts of your readme, and I have the feeling that wart steps quite a
> deal short of readable: Readable/swe
> Refer to this page instead: http://www.dwheeler.com/readable/version02.html
Ok, I'm done going through it and I went through the tutorial as well.
curly-infix.cl works great with sbcl.
I had to change the shebang in sweet-guile and modern-guile to
/usr/bin/env rather than /bin/env. Aside from
> Hi Arne, could you elaborate on this? How does one go about making
> guile aware of sweet expressions?
Never mind; I just found
http://sourceforge.net/p/readable/wiki/Tutorial. I've been working
through it without issues. Very cool!
--
> Readable/sweet expressions is an extension to existing
> interpreters which for example actually allows to use the full power of guile
> with whitespace aware lisp.
Hi Arne, could you elaborate on this? How does one go about making
guile aware of sweet expressions?
-
> 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
Judging by the l
On Sat, Jul 14, 2012 at 9:12 AM, Kartik Agaram 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 enclosing it in b
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 {convo
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?
-
> You know, one completely knocks-the-socks-off-your-nose idea (due to
> dwheeler) is to use "." for indentation whitespace.
Interesting! I'll have to think about that one.
--
Live Security Virtual Conference
Exclusive li
On Sat, Jul 14, 2012 at 7:29 AM, Kartik Agaram 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 s
> 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 start, but they get ugly as the
tests and/or branches get more complex
Kartik Agaram
> > if
> > . {1 iso {x % 2}}
> > . \ 'odd
> > . :else
> > . \ 'even
>
> My complaint with this is that it doesn't sufficiently distinguish
> tests from branches. Especially since 'if' in arc/wart can have more
> than two branches. It also replaces 'cond' in lisp/scheme.
>
> I'm not
Hi Kartik,
My first though was: Nice! One more who sees that whitespace and lisp are a
pretty good match!
Am Freitag, 13. Juli 2012, 09:36:59 schrieb Kartik Agaram:
> http://github.com/akkartik/wart#readme
I read parts of your readme, and I have the feeling that wart steps quite a
deal short o
> if
> . {1 iso {x % 2}}
> . \ 'odd
> . :else
> . \ 'even
My complaint with this is that it doesn't sufficiently distinguish
tests from branches. Especially since 'if' in arc/wart can have more
than two branches. It also replaces 'cond' in lisp/scheme.
I'm not entirely happy with any of the ways
Ok I'm caught up on this thread, at least.
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!
> Wart's interpreter says "Hit twice to eval."
> which
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
Haven't fully digested your message, but I wanted to clarify one thing.
> It also appears that f(x) == (f x) in wart, though that's not clear (I infer
> that from some examples).
No, that's not true, but I can see how it seems that way. Wart uses
common lisp's style:
(defun foo (x) ..)
Rathe
On Sat, Jul 14, 2012 at 2:00 AM, David A. Wheeler 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 the
>> design c
On Sat, Jul 14, 2012 at 12:36 AM, Kartik Agaram wrote:
> 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:
>
>
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 the
> design choices I made at:
> http://github.com/akkartik/wart#readme
> I
57 matches
Mail list logo
