Term "Configuration"

[Mario Blazevic]

>>Brian T Rice <water@tunes.org> said:
>>
>>    
>>
>>>To return to this interesting topic (to me), what do people think about
>>>characterizing multiple-argument functions as Attributes of
>>>Configurations? This was one of the senses in which this concept occurred
>>>to me.
>>>
>>>Bring up examples from your favorite odd language that don't seem to fit
>>>it. We could judge by applicability.
>>>      
>>>
>>is this similar to the way TOM handled them? TOM used tuples to return
>>multiple values, so a function might return say (int, bool, int), and to use
>>these values one would write:
>>    
>>
>[Omitted return-multiple-values example.]
>
>Yes, that's similar, although the collection, you see, is implicit, and
>the primary return value is what is received if the caller does not
>explicitly grab the multiple values. At least, this is what happens in
>Common Lisp. I am unsure about TOM's case for handing this.
>
>What we could do in a more general sense is to not have to rely on
>arbitrary structuring. Basically, we could have a convention to take in
>and return configurations. There might be a further convention for a
>default member of the configuration. The other parts might be attributes
>of the first value, or they could be both attributes of something else
>(which is somewhat similar to an array or list). If the configuration is
>more abstract, there would need to be a meta-object relating them,
>although I suppose this could be an attribute via isMemberOf or something
>like that.
>
    I may be off track, but what you're describing here starts to 
resemble the thing I've been working on, well on-and-off, for the past 
several years. If I'm right, a configuration is a very general version 
of what I call environment. The difference is that environment is just a 
mapping from labels to terms, there's no meta-level interpretation. A 
label is a term. An environment is a term. And having two terms, you can 
combine them into a "sequence", which in case of two environments is an 
asymetric union, or a "selection" which is really the result of one term 
evaluated in the context of the other.

    Anyway, the point I'm trying to make is that the selection can be 
treated as a function call with multiple arguments, where arguments are 
attributes of the context environment, and the function is the evaluated 
term. The function can return another environment, and the caller can 
either take the whole environment or select one of its attributes as as 
the result of the call. An interesting consequence (to me anyway) of the 
system is that, if you simply use the result environment as the context 
of another selection/function call, you're threading the side-effects of 
the first function call into the second one. You don't need to know or 
care what these effects are, but you're free to either pass them on or 
select the pieces you need.

>There's also the case that the values are attributes of the computation,
>such as 'dummy locals' for "quotient" and "remainder" for integer
>division.
>
    I'm not sure what you're trying to say. Are quotient and remainder 
actual locals, unaccessible outside of the computation, or are they 
parts of the result you can ignore?

>Your multiple bindings example could be done via expressing a
>configuration of quoted terms, perhaps. I'm not sure what the correct
>analog is; perhaps the configuration itself would be quoted. Or you could
>simplify this by serializing the configuration and using a list of
>variables (attributes) to bind to them.
>
    It can also be treated as pattern matching (in the functional 
language meaning, not Perl) of the pattern (x,y,z) on the 
configuration/environment returned by the function. The requested 
attributes are extracted from the function result and the rest are 
dropped. A very good implementation could figure out that the dropped 
attributes don't need to be computed and generate an optimized version 
of the function. Is that what you meant?