On Sun, 2009-07-05 at 03:22 +0300, Abdulaziz Ghuloum wrote:
> On Jul 5, 2009, at 2:23 AM, Derick Eddington wrote:
> 
> > If run-time processing (lambda/kw and first-class ability) is going to
> > exist, it seems like it should be considered the "right" one  
> > because it
> > unavoidably has to recognize values,
> 
> Say you have
> 
>    (define/kw (f (a :default 1) . r) (list a r))
> 
>    (define (call-f-with-default-a-and-two-args b c)
>      (f b c)) ;;; use default a = 1
> 
> then, according to the "expand" semantics, you get:
> 
>    (call-f-with-default-a-and-two-args 2 3)
>    ;=> (1 (2 3))             ;; as intended
> and
>    (call-f-with-default-a-and-two-args 'a 'b)
>    ;=> (1 (a b))             ;; of course
> and
>    (call-f-with-default-a-and-two-args (:- a) 'b)
>    ;=> (1 (#[keyword a] b))  ;; ditto
> 
> but according to the "run" semantics, you need to somehow provide
> a way of distinguishing keywords that are intended to be used as
> keywords from keywords intended to be used as values.  Basically,
> the last one will be "wrong" because it would evaluate to (b ()).
> The more you disguise it (by using records instead of symbols),
> the less likely you're to trip over it, but when you do, it would
> be a spectacular failure.

Yeah, it would not be robust and would allow confusing failures.  I
think I'm shifting to thinking first-class abilities should be dropped
and only the expand-time processing should exist.  As interesting as
run-time first-class keywords abilities seem, restricting keywords to
the syntax-only level is making more sense.  Maybe I'll try to preserve
first-class abilities by having something like PLT's keyword-apply, but
I'm not sure I'm OK with it; I'll need to investigate.

> This problem comes up every time you take some value from the
> domain of all possible values and make it "special".

Yeah, I'm usually quicker to see the full extent of this problem when it
comes up, but I so wanted first-class keywords abilities which work like
normal procedures.

Thanks for the feedback,

-- 
: Derick
----------------------------------------------------------------

Reply via email to