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 
. 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.

.  !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.

.  f&g ; => (andf f g)

Again, not sure this worth an abbreviation.  Of course, "and" appears often, 
but I think our curly-infix approach is more readable & more general: {f and 
g}. I notice that the wart notation doesn't support "or" (!). 

.  ~f  ; => (complement f)

Uses Arc's symbol/notation, but for a slightly different semantic.

I can sort-of see the point of a special notation for "not"; Arc does that too. 
 But the modern-expression approach actually works pretty well:
~(f()) => (~ (f))
!(f()) => (! (f))
not(f()) => (not (f))

Wart's interpreter says "Hit <enter> twice to eval."
which is our current semantic, too.  Good to see that other people come to 
similar conclusions as we do.

--- 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

Reply via email to