[e-lang] lambda-args block ejectors: beginning or end?
Mark S. Miller
markm at cs.jhu.edu
Wed Jan 17 22:34:06 CST 2007
Kevin Reid wrote:
> Context: Mark Miller and I were discussing lambda-args yesterday, and
> I pointed out that the current expansion does not allow for the
> control object to handle match failures in the blocks' patterns.
>
> At the time, we decided that each block function should have the
> first argument be an ejector.
>
> ? someControl () foo [x] [y] {}
> # expansion: someControl."foo__control/0/2"(def _ {
> #
> # method run() {
> # __makeList.run(__makeList.run(), def _ {
> #
> # method run(ej__1, sp__1, sp__2) {
> # def [x] exit ej__1 := sp__1
> # def [y] exit ej__1 := sp__2
> # null
> # }
> # })
> # }
> # }).run__control()
>
> (After having implemented this, I'd like to propose the special case
> that if there are no parameters, there should be no ejector.)
Agreed.
> However, in the case where the block has 1 parameter, this is the
> opposite of the common (specimen, ejector) argument order.
>
> In particular, I was updating the control emakers to this expansion,
> and noticed that I could implement match failure in the 'escape'
> control object to match Kernel-E:
>
> ? escape f { f(1) } catch x :String { [x] }
> # value: 1
>
> in this way:
>
> def flip(f) {
> return fn a, b { f(b, a) }
> }
>
> ...
> to run__control() :any {
> return escape ejector {
> tryFn(null, ejector)
> } catch via (flip(handlerFn)) value {
> value
> }
> }
>
> It would be nice if the 'flip' could be eliminated here.
I agree with the implied suggestion: The extra generated ejector argument
should go last in the argument list, not first, for better compatibility with
conventions elsewhere in the system, such as via functions or Guard#coerce
arguments.
--
Text by me above is hereby placed in the public domain
Cheers,
--MarkM
More information about the e-lang
mailing list