[MLton] MLB file tree

[Matthew Fluet]

On Thu, 9 Feb 2006, Vesa Karvonen wrote:
> Quoting Matthew Fluet <fluet@cs.cornell.edu>:
>>> Attached is a draft patch for a new option "-stop ft" to print the "MLB
>>> file tree".
>>
>> That looks generally useful.  I wonder, though, whether the format could
>> be improved.
>
> I'm personally not entirely happy with the format, but I'm uncertain on
> how to improve it.  Let me elaborate on my requirements.

You and Stephen have made decent arguments for including both '{ }' and 
indenting.

> I think that the main problem with the current format is that it prints
> both relative and absolute paths.  I think that it would be best to only
> print absolute paths.

That ought to be quite easy to achieve.  Although, I didn't see any 
relative paths in the sample output.

>>> I implemented the option, because I wanted to know which MLB-files are
>>> actually used when MLton is compiled, so that I can go through them to
>>> better understand how much work it might require to get MLton to compile
>>> under MLKit.
>>
>> That would be very cool.  Keep us posted.  I saw your comp.lang.functional
>> posting, and it sounded like the annotations are the issue.
>
> Annotations are one of the issues.  I already made a quick hack to MLKit
> to get past non-supported annotations, but then I ran into another issue.
> MLKit doesn't currently support export filters.  Supporting them probably
> requires much more work, so before I try to implement export filters, I
> plan to workaround them and try to get MLton to compile first (to see how
> much work beyond supporting export filters might be required).

I haven't looked at the MLKit's implementation of MLBs in any depth, but 
export filters are pretty trivial to support in MLton's implementation.

> I plan to transform (either manually or with the help of some scripts) MLB
> code of the form
>
>  <--- foo.mlb --->
>  local
>     foo-bar-and-baz-and-more.sml
>  in
>     signature FOO
>     structure Bar = Baz
>     functor FooBar
>  end
>  <--- foo.mlb --->
>
> to
>
>  <--- foo.mlb --->
>  local
>     foo-bar-and-baz-and-more.sml
>  in
>     foo-filter.sml
>  end
>  <--- foo.mlb --->
>
>  <--- foo-filter.sml --->
>  signature FOO = FOO
>  structure Bar = Baz
>  functor FooBar (S: FOO) = FooBar (S)
>  <--- foo-filter.sml --->
>
> Which, AFAIU, should give the same meaning (or maybe there is some
> complication that I can't see?).  This makes me wonder about the
> importance of the export filter feature.

It should have the same meaning in most cases.  Functors are really the 
complication, as the argument signature need not be bound to a signature 
identifier and it is not necessarily true that the signature argument can 
be expressed with the basis in scope.  For example:

<--- a.sml --->
structure A = struct type t = A end
<--- a.sml --->

<--- f.sml --->
functor F(val x: A.t) = struct ... end
<--- f.sml --->

<--- foo.mlb --->
local
   local
     a.sml
   in
     f.sml
   end
in
   functor F
end
<--- foo.mlb --->

You can't transform this in the manner described above, since the functor 
argument includes the type A.t, which isn't in scope at the point of the 
export filter.

On the other hand, it would be a stylistic error if any functors in the 
mlton source tree did not have their argument signature bound to a 
signature identifier, and hiding the types of functor argument components 
would generally make the functor unusable, so I doubt that this will be an 
issue.


As to the utility of export filters (and, more generally, module 
identifier binding), they are there for convenience, not expressiveness. 
But, if you look at the MLB system as namespace management, then it makes 
sense to not have to drop down to a .sml file to do such renamings.
Essentially, if with nearly every z.mlb file you have a z-filter.sml file, 
then there is a redundancy.