[MLton] A Question on Property-List

[BaoJian Hua]

    Now I've finished reading some parts of the MLton source code. For the
property list, we also want to use it in our own compiler project,
substituting our previous table-based approach. But as for the documentation
is rare on it, so I found some code are hard to understand.
    I've read the related code in the "mlton-20051202/lib/mlton/basic"
directory:
         1. het-container.sig{fun}
         2. property-list.sig{fun}
         3. property.sig{fun}

    I'm comfortable with the former two, but I am not able to understand the
third very well. Would you be so kind as to explain the functionality of the
third a little detailed? And would give some examples how to use the property,
such as the ones in "mlton/core-ml/dead-code.sig{fun}?

    Thanks!


ÔÚÄúµÄÀ´ÐÅÖÐÔø¾­Ìáµ½:
>From: Matthew Fluet <fluet at tti-c.org>
>Reply-To: 
>To: BaoJian Hua <huabj at mail.ustc.edu.cn>
>Subject: Re: [MLton] A Question on Property-List
>Date:Fri, 16 Mar 2007 09:45:41 -0500
>
>>      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.
> 
>