Re: [Readable-discuss] wart
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 against. But the context for my statement was (http://www.mail-archive.com/readable-discuss@lists.sourceforge.net/msg00272.html): Say you're trying to track down a bug in evaluation: No matter how intuitive, we're going to run into cases where we accidentally mal-indent and need to track down the bug. It's like a stray paren or semi-colon. During debugging you have to drop down a layer of abstraction and think about the paren insertion itself. -- 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
Re: [Readable-discuss] wart
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 the
top-level page at http://readable.sourceforge.net. The reader should
be able to read that one page above the fold and have a clear sense of
how 90% of expressions are transformed.
Even in the spec, keep each bullet as short as possible. There's
already a rational page, so skip this lets you clauses. It's just a
spec of the solution. (Short rationales in the front-page
tutorial/blurb are a good idea, but they shouldn't take up full
sentences.)
We have several options of names and phrases we could use:
indentation sensitivity
whitespace sensitivity
paren insertion (from wart)
deducing parentheses
parameters of
grouped with/together
We should use as few of these as consistently as possible. I don't
like the phrase making indentation meaningful. Can we use a
different phrase that we can then keep reusing in the bullets
themselves? That would be far more clear.
I organized the details slightly differently from you. The main rules
should cover all common cases, and it seemed like empty lines are
fairly common. Details might also nail down something so obvious that
the question rarely arises. In wart I didn't even bother to say that
indent of comment lines doesn't matter.
I also tended to move to details what I still don't understand. If an
expression starts out indented, are later, more indented lines grouped
with it? My interpretation was no, but I wasn't sure.
A leading 'group' is removed but its child indented lines are still
grouped together. That still isn't clear from the description.
Where you say see the mailing list, can you link to a single post?
Now that I've started playing with the text myself, my value to this
group will start to drop for giving feedback as an outsider :)
== Tutorial
- An indented line is a parameter of its parent.
- Later terms on a line are parameters of the first term.
- A line with exactly one datum and no child lines is simply that datum.
- Empty lines end the previous expression. At the prompt type ENTER ENTER to
execute what you've typed.
== Spec
*Sweet expressions*: Includes modern-expressions, and reduces the number of
parentheses by making indentation meaningful. Rules:
- An indented line is a parameter of its parent.- Later terms on a
line are parameters of the first term.
- A line with exactly one datum and no child lines is simply that item.
- Empty lines, containing only tabs and spaces, end the previous expression;
otherwise empty lines are ignored.
- A leading quote or unquote operator followed by whitespace is applied to
the following expression.
Details:
- Lines with only a ;-comment are completely ignored - even their
indentation (if any) is irrelevant.
- A leading symbol group is quietly removed. [XXX: link to discussion]
- For backwards compatibility, an expression that starts indented
doesn't take parameters from later lines. We recommend that editors
highlight
these lines as warnings. [XXX: link to discussion]
Indentation is disabled inside ( ), [ ], and { }, prefixed or not (so you're
back to just modern-expressions).
==eof
--
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
Re: [Readable-discuss] wart
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 read that one page above the fold and have a clear sense of how 90% of expressions are transformed. Okay. Let's work on doing that in [Home], and once that looks good, copy it to readable.sourceforge.net. Even in the spec, keep each bullet as short as possible. There's already a rational page, so skip this lets you clauses. It's just a spec of the solution. (Short rationales in the front-page tutorial/blurb are a good idea, but they shouldn't take up full sentences.) Okay. I changed [Solution] based on these ideas, in particular removed most rationale in main [Solution] text. After the rules I re-added a sentence justifying each tier; that way there's a brief rationale for the whole thing, just not for each detail. We have several options of names and phrases we could use: indentation sensitivity whitespace sensitivity paren insertion (from wart) deducing parentheses parameters of grouped with/together We should use as few of these as consistently as possible. I don't like the phrase making indentation meaningful. Can we use a different phrase that we can then keep reusing in the bullets themselves? That would be far more clear. Fair point. How about deduces parentheses from indentation? I organized the details slightly differently from you. The main rules should cover all common cases, and it seemed like empty lines are fairly common. Okay, fair enough. Where you say see the mailing list, can you link to a single post? No, but I pointed to [Current] which has the same effect. Now that I've started playing with the text myself, my value to this group will start to drop for giving feedback as an outsider :) Too late! You're no longer an outsider. :-). --- 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
Re: [Readable-discuss] wart
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 Judging by the line-count savings, this is a huge win. In addition, the description in the Readme is *much* shorter and simpler. The entire section on exceptions is gone. Joining this list has 'paid' for itself on the very first day. Many thanks! Awesome! Glad we could help! --- 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
Re: [Readable-discuss] wart
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-guile worked great.
Should we change all /bin/env to /usr/bin/env? What platform are you using?
All systems I use allow either. Article
http://en.wikipedia.org/wiki/Shebang_%28Unix%29 suggests /usr/bin/env, though
it notes that nothing works absolutely EVERYWHERE.
I couldn't get sweet-guile working, perhaps because eval needs 2 args
in sugar.scm
Do I need to switch guile versions or something like that? (I'm using
guile-2.0)
That sounds likely, I'm using guile 1.8. Can you tell me a little more about
your system?
Obviously we want to track that down...!
I notice some recent examples with a leading backslash, period, etc.
But the docs so far haven't made any mention of them. Did I miss
something?
These are all proposals under active discussion on the mailing list. You can
see a summary of the topics under discussion here:
https://sourceforge.net/p/readable/wiki/Current/
There's some experimental support for the SPLICE operation and
period-as-indent, so that we can try them out.
I've seen mention of different modes. How does one switch between
them? I think modes are a bad idea. With wart I was careful to make
sure that you never had to fiddle with modes, wonder if something was
evaluated in the right mode, etc.
The only real mode is whether or not indentation processing is active.
Inside (), {}, and [], indentation processing is *deactivated*. This is really
valuable for compatibility with traditional Lisp, for example.
Are sweet exprs intended to be fully compatible with traditional lisp?
That was something I spent a lot of time thinking about -- I wanted
wart to be entirely lisp compatible, but I had that single-space
exception that I now no longer have, which makes me very happy. Is
this feature important to y'all as well?
Compatibility is important. These notations are fully compatible with
*well-formatted* Lisp, which is almost (but not *quite*) the same thing.
Having multiple tiers helps, too:
1. Curly-expressions are completely compatible, since {...} isn't in
traditional Lisp.
2. Modern-expressions are compatible for what I'd call normal formatting.
The key issue is that it changes the meaning of an opening paren after a
character other than whitespace or another opening paren. So if you're using
to saving whitespace that will be different. Basically, a(b) becomes (a b),
not a (b). There are millions of lines of Lisp code that would never see the
difference. So if you wrote a(b) expecting it to be a (b), you will need
to insert the space.
3. Sweet-expressions add indentation processing, but since indentation is
disabled inside (...), ordinary Lisp expressions immediately disable this
don't cause issues. The only problem is if you have a *top-level* expression
when more than one datum on a line *and* the line doesn't begin with space/tab.
Thus:
(a) (b)
is interpreted as two datums (a) (b) in traditional Lisp, but a single ((a)
(b)) in sweet-expressions.
You can disable sweet-expression processing with a space indent, so just
inserting a space on every line *ensures* compatibility with the
sweet-expression processing.
{This is a good question - I just added this discussion to the Rationale wiki
page.}
--- 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
Re: [Readable-discuss] wart
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 platforms do people use here? -- 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
Re: [Readable-discuss] wart
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. So: ` foo bar . nitz quux . , meow . . . cat fish == `(foo bar nitz quux ,(meow (cat fish))) 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? Have y'all considered just not supporting indentation inside backquote? That was my choice in wart. I reasoned thus: if s-expressions exist to enable macros it's reasonable for macros to make them explicit. Macros can get pretty hairy, so the less magic they involve, the better. The value proposition: familiar syntax in the common case, but drop down to s-expressions when you need macros. If you got rid of backquote support, then commas would be freed up, and I'd just be able to write: myfunction(:option1 f(a), :option2 g(b), :option3 h(c)) And as a result I wouldn't need to mess with backslash as much. I *love* keyword args, I think they're hugely underused. Contortions with backslash will only dampen their uptake. -- 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
Re: [Readable-discuss] wart
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 traditional lisp with modern-exps? No, not at all. Feel free to use traditional lisp, whenever it's suitable! It works just fine. We've been doing a lot of experimentation, and pressing various notations as far as they will go to maximize readability. So you'll certainly see us try some odd things on occasion. And in general, I find function-name-first more readable when it's actually a function call; it's traditional math notation what is used in many other programming languages. If you got rid of backquote support, then commas would be freed up, and I'd just be able to write: myfunction(:option1 f(a), :option2 g(b), :option3 h(c)) Commas already have a meaning in Lisps when at the beginning. A few people have indeed experimented with allowing , at the end of symbols (basically ignoring them) - see my older stuff if you want citations. The problem is that the commas are really hard to see when they're also at the beginning; compare: myfunction(f(a), g(b), h(c), j(d)) with: myfunction(f(a), g(b), ,h(c), j(d)) The quote-space being different from quote is inherited from Scheme SRFI-49, but I actually think it's a good idea. Here's the thing - imagine that you start with: a b c . d e . f g Now you need to quote it. By inserting quote-space in the front, you've easily quoted the whole thing: ' a b c . d e . f g Note that this is completely different from quoting just the first symbol (a), which would be: 'a b c . d e . f g The leading , rule is there for the same reasons, as well as consistency. This is something we've been discussing recently. --- 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
Re: [Readable-discuss] wart
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. 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
Re: [Readable-discuss] wart
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 they seem promising, coded them up to see how they work in practice. So anyway, I'm looking at the example: (if !user : (submit-login-warning url title showtext text) (~and (or blank.url valid-url.url) ~blank.title) Note that this is somewhat different than our current proposal. Which is just fine - we need to come up with lots of ideas so we can pick the best ones, sort of like doing mutations followed by survival of the fittest. Under the current proposal, the SPLIT marker (\ or ! or whatever we use) as leading-SPLIT is expected to work only inside indentation processing. Since ( disables indentation processing, the current proposal would consider the leading SPLIT as its normal symbol meaning (so you wouldn't need to escape it in many cases). 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. And I think having indentation be *significant* inside (...) causes lots of trouble, including massive backwards incompatibilities. So if you like : as you've defined it - great! I expect that most Lisp-like languages will add stuff that their developers find useful. But I think an ignore me symbol at the beginning of the line should only happen during indentation processing, outside any (...). Keep the ideas coming, though, I'd appreciate it! --- 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
Re: [Readable-discuss] wart
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, 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, and I currently think it's a good rule, but the whole point of this time period is to discuss stuff like this. --- 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
Re: [Readable-discuss] wart
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 fine! At least on Ubuntu, you can install guile-1.6, guile-1.8, and guile-2.0 at the same time. It defaults guile to guile-2.0, but you can invoke 1.6 and 1.8 using guile-1.6 and guile-1.8 commands. Also, 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. -- 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
Re: [Readable-discuss] wart
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 serves an orthogonal purpose: visually distinguishing tests and branches in if/cond. In this situation it's simpler to have it not interact with whitespace-sensitivity at all. So far I find it useful even if I can indent however I please. -- 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
Re: [Readable-discuss] wart
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: $ guile --version guile (GNU Guile) 2.0.5-deb+1-1 $ rm -rf .cache/guile $ ./sweet-guile .. ;;; ./modern.scm:460:14: warning: possibly wrong number of arguments to `eval' Are you building it from source or something like that? This is just debian's current default binary package. Nope, just flat Ubuntu binaries. I've tried locating the problem, and it does seem to be guile 2.0's autoload. So: if you ever see a message about ;; compiling /blah/blah, exit sweet-guile and restart it - don't clear cache (sorry, apparently my brain gave me wrong memories - it seems I *encountered* the problem *after* clearing the cache, not that it disappeared after clearing!). Once the modules get loaded from cache instead of being compiled on-the-fly, this should put you safely into sweet-expressions in guile 2.0. Ignore messages about wrong number of arguments to 'eval' - I fixed sugar.scm's primitive-load, and that's what sweet-guile uses. -- 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
Re: [Readable-discuss] wart
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 this rule in particular, but the spec as a whole seems quite complex. http://www.dwheeler.com/readable/version02.html is quite long, and it includes this wormhole to the universe of SRFI 49, which the reader must also understand. It might be a useful exercise to inline SRFI's rules into v0.3 and try to organize them to be shorter and simpler. v0.2 tries to be both a tutorial and a spec, and I think that makes it too intimidating. Lose the motivation, assume that the reader is already on board by the time (s)he gets to that page, etc., etc. --- GROUP doesn't seem worth the extra complexity required to explain it to others. If you have a list with a nested list as its first element.. just add parens. We don't need alternate syntax for every possible situation. Some of the burden of being readable must fall also to the user of our notation. If lists in function position are hard to read we need incentives to avoid them. Is sweet expressions trying to make lisp syntax familiar to non-lispers? With wart I wasn't trying to make the notation look familiar, just to make it easier to read at length. I was trying to keep my readers reading when they don't have the fluency to parse all the parens just yet. Dijkstra said we shouldn't teach novel ideas by making them seem familiar: http://www.cs.utexas.edu/~EWD/transcriptions/EWD10xx/EWD1036.html -- 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
Re: [Readable-discuss] wart
(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. The solution doesn't make reference to SRFI. Have y'all already done the inlining I was talking about? I've been reading various documents with varying levels of staleness and spiralling in on the project. But perhaps that is just the wrong approach on my part. -- 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
[Readable-discuss] wart
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 reactions, whether it's something that makes you go yuck! or something unclear in the description. Thanks, Kartik http://akkartik.name/code -- 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
Re: [Readable-discuss] wart
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 the
design choices I made at:
http://github.com/akkartik/wart#readme
I'd love feedback and reactions, whether it's something that makes you
go yuck! or something unclear in the description.
Thanks for the pointer, I really appreciate it!
Kartik: We'd really appreciate it if you'd participate with us!! In
particular, we're trying to nail down a revision of the spec by July 31, so
we'd like to hear what you think.
It's important to note a key difference between wart and readable: 'wart' is
a *specific* Lisp-like language and implementation. In contrast, the
readable group is trying to develop a *general* notation that can be picked
up by many Lisp-like languages. That said, we want to look at as many ideas
as possible now; people can come up with different conclusions, but at
*considering* alternatives is important. And we hope that people will pick
up our ideas - including wart.
Quick summary commentary: Wart has similar indentation rules, though not
quite identical (I think our rules are better, see below). It also appears
that f(x) == (f x) in wart, though that's not clear (I infer that from some
examples). Wart lacks curly-infix, which I think is a weakness in wart, but
I see no reason why wart can't easily add that. Wart uses ENTER ENTER to end
an interactive expression, just like we do. Wart has no equivalent to SPLIT.
Wart also has many other abbreviations; abbreviations can be really valuable,
but I don't think the wart ones should be added to the readable spec.
=== DETAILS ===
The initial wart code sample is (prefixing with . so everyone can see the
indentation):
. def fact(n)
. if (iso n 0)
. 1
. (* n (fact (- n 1)))
This is similar to our current readable notation, in fact, this is a valid
sweet-expression as well. If we wrote this code using the current draft
readable notation, we would probably write it like this instead:
. def fact(n)
. if iso(n 0)
. 1
. {n * fact{n - 1}}
A key is that Wart is indentation sensitive. Multi-word lines without
leading parens are
implicitly grouped with later indented lines. It seems to be basically the
same as our indentation rule (and the SFRI too). Its text says Lines with a
leading paren are never wrapped in parens - if I interpret that to mean
one-datum lines I think it *is* the same.
In Wart, indentation process still goes on EVEN INSIDE parens. I think
that's a mistake; indeed, the docs show an example of where this happens
notes that it'd be unexpected. You can disable indentation processing inside
(...): for wrapping long lists to a new line, you must indent by exactly one
space. Having a way to wrap long lists is nice enough (though our current
semantic can do it with parens).
It doesn't seem to be clearly documented, but it appears from examples that
wart accepts f(x) as equivalent to (f x), just like our modern-expressions.
Which is nice, it's also confirming that others think that makes sense.
There is *NO* capability in wart like curly-infix, or any other capability
for infix lists / infix notation. That said, it would probably trivial to
add curly-infix to wart.
Wart uses a few simple syntax rules to reduce parens further: and it lists:
. a.b ; = (a b) unless a and b are all digits; 2.4 is a number
. a. ; = (a)
I don't see these as particularly helpful.
The first case can already be expressed with (a b) and a(b), which are not
particularly longer than a.b.
The second case doesn't seem to be much better than (a) or a(), both of which
seems clear and short enough.
. a!b ; = (a 'b)
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.
Ah. This is a common idiom in Arc. In Arc, tables can be applied,
and applying a table to a single argument is equivalent to looking up
the key in the table. Thus, when doing objects in Arc, you use a
table, set up keys, and us a!b syntax. Something like:
let
\ obj
\ \ table
'key1 \ val1
'key2 \ fn (x) {x + 42}
obj!key2 obj!key1
Thus, at least in Arc, a!b syntax is considered useful.
a.b stems out of a!b syntax. Consider a.'b. Now pretend to squish
them together so that the ' lies over the . so you get a!b . So Arc
says (a b) can be expressed as a.b and that (a 'b) can be expressed as
a!b.
. !a ; = (not a)
This looks like Arc, though Arc uses ~.
. f:g ; = (compose f g)
I'm not sure this is worth a special abbreviation.
Again, an Arc-ism. Inside Arc's secret deep layers, something like this:
Re: [Readable-discuss] wart
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 applied,
and applying a table to a single argument is equivalent to looking up
the key in the table. Thus, when doing objects in Arc, you use a
table, set up keys, and us a!b syntax. Something like:
let
\ obj
\ \ table
'key1 \ val1
'key2 \ fn (x) {x + 42}
obj!key2 obj!key1
Thus, at least in Arc, a!b syntax is considered useful.
...
a.b stems out of a!b syntax
No doubt various Lisps will create abbreviations that are especially helpful
for *their* semantics, and that is a *good* thing. We certainly don't want to
be interfering with that, if we can help it; we want to let languages have
abbreviations that make their use pleasant.
But I'm hoping to create a *common* notation that can be widely adopted, at
least in principle, and then extended by various languages.
So if an abbreviation is nearly-universally useful, I think it should be
considered for our common work. Otherwise, we should try to make it possible
for people to use additional language-specific notations in their language of
choice. In particular, the sweet-filter should try to pass along symbols so
that a language's native reader will correctly interpret most abbreviations.
That said, certain Lisps are especially popular (e.g., Scheme, Common Lisp,
Clojure, Arc). We should strive to fit in cleanly with them where possible.
If we can't get them to build it into the language itself (a hard road), at
least create mechanisms so developers can use them as easily as we can make it
happen (E.G., perhaps an SRFI or similar for Scheme, perhaps ASDF for Common
Lisp, etc.). Some stuff like curly-infix is especially easy to adopt; we may
be able to get our noses into the tents in some places :-).
--- 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
Re: [Readable-discuss] wart
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 start, but they get ugly as the
tests and/or branches get more complex.
I don't see how you can say these cases are easy when you think (* a
(+ b c)) is suboptimal :) As the expressions grow complex, either the
tests and branches become harder to visually separate, or we have to
do more work to keep two columns lined up, etc. Even the examples of
cond in lisp-hints.txt are kinda all smushed together compared to say
the explicit block delimiters that non-lispers are used to.
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.
consider a complicated set of cond clauses:
cond
\
. or
. eq? foo 'bar
. eq? foo 'quux
. eq? foo 'nitz
. \ let
. . \
. . var value
. . var2 value
. . compute var var2
\
. and
. something? foo 'is-nitz
. something-else? foo 'is-bar
. \ begin
. . do-something foo
. . do-something-else foo
\
. jer jer(binks)
. \ 42
\
. #t
\ final-possible-value
So: the condition expressions have one set of . while the branch
clauses have 2. Of course, this is still herding cats, since the .
as indentation is optional.
The problem is a fundamental one: we're interleaving expressions with
very different semantics.
Well, let's see what we can get up until July 31, which is the
targeted freeze date for 0.3 spec.
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
Re: [Readable-discuss] wart
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? -- 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
Re: [Readable-discuss] wart
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 {convolve} matrix2
---
My major concern with curly infix is that it introduces an extra layer
of indirection. Say you're trying to track down a bug in evaluation:
i) Lisp is extremely direct. All the parens are visible, directly
permitting reasoning about evaluation.
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.
iii) Curly infix requires converting indentation to curly infix and
then *removing* the curly infix to convert to prefix.
I'm sure these issues have been done to death on this list, and
they're probably not on top of your todo lists before the deadline.
Feel free to point me at the mailing list archives :)
--
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
Re: [Readable-discuss] wart
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 enclosing it in backticks
or something like that. Maybe curlies?
matrix1 {convolve} matrix2
Yes, it has been discussed, in the inline default mode, you use
/operator/ to convert temporarily to an infix operator.
---
My major concern with curly infix is that it introduces an extra layer
of indirection. Say you're trying to track down a bug in evaluation:
i) Lisp is extremely direct. All the parens are visible, directly
permitting reasoning about evaluation.
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.
iii) Curly infix requires converting indentation to curly infix and
then *removing* the curly infix to convert to prefix.
I'm sure these issues have been done to death on this list, and
they're probably not on top of your todo lists before the deadline.
Feel free to point me at the mailing list archives :)
Refer to this page instead: http://www.dwheeler.com/readable/version02.html
In particular, dwheeler tried out various approaches to infix, and
soon found that, to his surprise, non-explicit infix is *less* useful.
In fact, consider a complicated expression in C:
if((cond1 cond2) || (cond3 cond4 cond5)) ...
While I know for a fact that bind tighter than ||, I won't be
comfortable writing it out as cond1 cond2 || cond3 cond4
cond5 - I still group them. So the basic insight in comparing
infix-default and curly-infix is that as infix expressions get more
complicated, you *are* going to group them anyway, so you might as
well grit your teeth and group them now while they're still simple.
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
