[Readable-discuss] Proposal: SUBLIST (not a GROUP replacement)
Just when it's less than 2 weeks to spec freeze I once had to code this expression: force(car(force(unwrap-box(s And it's ugly. I could use I-expressions: force . car . . force . . . unwrap-box s But that wastes precious vertical space. So I propose the SUBLIST semantic. Informally: 1. If the SUBLIST symbol $ is found in the middle of a line, then it is an implied promise to insert a ( at that point with a ) automagically inserted at the end of the block (i.e. before the next line with the same or lesser indent than this one). So: force $ car $ force $ unwrap-box s is equivalent to: (force ( car ( force ( unwrap-box s The only time that the promise will not get used is if there is only a single term after the $: thus: foo $ bar is: (foo bar) ; no ( ) automagically inserted around bar FORMAL Spec: (i-expr lvl) - head hspace+ SUBLIST hspace+ (i-expr lvl) (append $1 (list $5)) 1. SUBLIST considers the rest of the line as a new expression at the same indentation level as the current line. This new expression is then used as the last member of the list being built. -- This syntax reduces the need for foo:bar syntax in Arc, BTW. : is more compact as it needs no space, and it can be used in higher-order functions, but $ is at the reader level, and does not require magic when used in head position (unlike Arc, where officially foo:bar means (compose foo bar) but (foo:bar nitz) really means (foo (bar nitz)) to make macros composable). -- 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] Proposal: SUBLIST (not a GROUP replacement)
On 7/19/12, David A. Wheeler dwhee...@dwheeler.com wrote:
Alan Manuel Gloria:
Just when it's less than 2 weeks to spec freeze
:-).
I once had to code this expression:
force(car(force(unwrap-box(s
And it's ugly.
I could use I-expressions:
force
. car
. . force
. . . unwrap-box s
But that wastes precious vertical space.
So I propose the SUBLIST semantic.
Hmm. Function composition isn't unknown, of course, but I'm skeptical about
how often this kind of construct occurs. Every new rule has a mental cost;
we need to make sure the cases are so common (or so egregious) that the
construct is worth it. Otherwise, people will reject it as being too
complicated to learn. The wrapped example you show above is actually how
many other languages *would* show it.
I also worry about using up one-character symbols; if we do anything like
this, perhaps a multi-char symbol would do? We could also pick a few
symbols to reserve for cases like this; again, it's not so bad if we
reserve multi-character symbols.
Well, we could define an o-function that does composition:
define o
case-lambda
(f) f
(f g)
lambda parms
f apply(g parms)
(f g . rest)
{{f o g} o apply(o rest)}
Then: {force o car o force o unwrap-box}(s)
(or use * or . or something less egregious than o, now that I look
at it, o looks ugly, eh?)
Of course, the lack of true currying means that a slight variant like:
foo(bar(nitz quux(meow)))
Can't use a compose chain like o above.
foo $ bar nitz $ quux meow
--
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
