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

List:       e-lang
Subject:    Re: [e-lang] Idea: generic makers for PBC
From:       "Mark S. Miller" <markm () cs ! jhu ! edu>
Date:       2007-01-18 4:36:55
Message-ID: 45AEF967.9020309 () cs ! jhu ! edu
[Download RAW message or body]

I do not yet fully understand this proposal, so I don't yet have a reaction to 
it. Unfortunately, I also don't yet know what question to ask to help clarify 
my confusion.


Kevin Reid wrote:
> On Jan 15, 2007, at 16:32, Mark S. Miller wrote:
>> Kevin Reid wrote:
>>> I therefore propose a separate loader; I have no name for it at the
>>> moment. This loader might or might not use the same source/namespace
>>> as <import>. Its distinguishing properties are:
>>>
>>>    - It is PassByCopy by way of being an exit (in Data-E terms).
>>>    - It will return a maker for any name requested.
>>>
>>> If asked for a FQN it doesn't know, it will return a 'generic'  
>>> object.
>>>
>>> def makeGeneric(uncall) {
>>>    def generic implements pbc {
>>>      to __optUncall() { return uncall }
>>>      match [verb, args] { makeGeneric([generic, verb, args]) }
>>>    }
>>> }
>> I don't understand the proposal. When the loader in question is  
>> asked for an FQN it doesn't know, it returns a 'generic' object  
>> with what uncall triple? Where does the uncall argument for the  
>> first call to makeGeneric come from?
> 
> def loaderUnderDiscussion {
>    to get(name) {
>      return if (...) {
>        ...
>      } else {
>        makeGeneric(loaderUnderDiscussion, "get", [name])
>      }
>    }
> }
> 


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