[prev in list] [next in list] [prev in thread] [next in thread] 

List:       e-lang
Subject:    Re: [e-lang] lambda-args block ejectors: beginning or end?
From:       "Mark S. Miller" <markm () cs ! jhu ! edu>
Date:       2007-01-18 4:34:06
Message-ID: 45AEF8BE.2050001 () cs ! jhu ! edu
[Download RAW message or body]

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
_______________________________________________
e-lang mailing list
e-lang@mail.eros-os.org
http://www.eros-os.org/mailman/listinfo/e-lang
[prev in list] [next in list] [prev in thread] [next in thread]