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

Reply via email to