[MLton] A Question on Property-List

[Matthew Fluet]

>      I've used MLton/SML for several years. 

Great!  If you have an interesting project using MLton, please consider 
adding it to http://www.mlton.org/Users.

 > And recently I'm reading some
> MLton source code and trying to do some hacking (the so called ABCD
> optimization pass on the SSA IL).

That would be great.  We have a very simple bounds-check eliminator, but 
I'm sure that ABCD would be more effective.

>      But the extensive use of property list in MLton make me a little
> confused, especially the "name space" problem. Consider the following
> code:
> 
> (* Suppose there are two structures S1 and S2,
>  * and in S1, some property P is added on the property list L of 
>  * a variable, say x, and next, in structure S2, we want to update
>  * or peek the property P. Obviously, this kind of information
>  * propogation is common.
>  *)
> structure S1 : SIG1 =
> struct
>   (* generate a new property, which is retrieved by "peek1"
>    *)
>   val {peek = peek1, ...} = Plist.newProperty ()
>   ...
> end
> 
> structure S2 : SIG2 =
> struct
>   (* here, we want to peek the property added in structure S1
>    *)
>   val P = S1.peek1 (plist)
> end
> 
>    But the problem is: if we don't want to include the definition
> of "peek1" in signature SIG1, or even we don't want to mention the
> SIG1£¬the function "peek1" is not visiable in S2, then how should
> we peek the property P in S2?

The only way to access the property created by Plist.newProperty is via 
the returned peek, add, and remove functions.  So, if those functions 
are not accessible in some other piece of code, then neither will the 
property.

I'm not sure why you want to hide the functions of S1 from S2.  If there 
is some dependency of S2 upon S1, then it will be expressed by S2 using 
functions of S1.

For example, you may want to separate the analysis portion of an 
optimization from the transformation portion.  Clearly, the 
transformation needs to access the results of the analysis.  It would be 
appropriate to use properties to compute the analysis.  The 
transformation pass will need to use functions exported by the analysis 
pass to access the results of the analysis.  So, you may not expose the 
properties directly, but you will expose functions that access the 
properties.

Maybe if you explain in more detail how you see the two structures being 
used, we can suggest another way of factoring them.

>    I'm not sure whether I've misundertood the functionality of
> property list or there is some way to do this kind of hacking.

One thing I will point out is that one rarely, if ever, needs to 
directly use the structure Plist : PLIST.  The structure Property : 
PROPERTY is a better way of associating properties with objects 
(variables, labels, functions, etc.); internally, Property uses Plist, 
but it nicely wraps up all the peek, add, and remove functions.

If you look at the SSA optimization passes, you'll never see an explicit 
use of Plist, but many, many uses of Property.