[MLton-user] type-indexed values
Stephen Weeks
sweeks at sweeks.com
Thu Aug 10 17:05:57 PDT 2006
> > * I wonder if it would be useful to combine all of the utility
> > functions (const, cross, curry, ...) onto a single wiki page, as
> > they are being used more and more across different pages.
>
> That would make sense. Any suggestions for the title of such a page?
> Suggestions: LittleUtilities, MiscUtilities, or perhaps
> CollectedUtilities.
All fine. "Utilities" is fine too. Also maybe "Combinators"?
> I like Henry's suggestion: Y. The ideas was that "T" stands for "Type"
> or "Type-index", but that is probably too generic.
Y sounds great to me.
> > * It would be nice for the array/ref stuff to handle sharing, not just
> > cycles.
...
> I would leave various improvements (sharing, pretty printing,
> optimizations) to an actual library.
Leaving extensions to an actual library is fine. I would at least
mention that only cycles are handled. I was confused at first when
reading the graph example, and I still think it would be slightly
cleaner if sharing were handled.
> What kind of syntax would you suggest for showing sharing?
The same syntax as for cycles. The first occurrence of an object is
named and all other occurrences refer to that name.
> > val recur: 'a * ('a * ('a -> 'b) -> 'b) -> 'b
> > fun recur (a, f) = let fun loop a = f (a, loop) in loop a end
> >
> > This could be used to good effect in replacing the "lp" functions.
>
> Yes. I noticed this in, IIRC, the Event implementation. It made me wonder
> whether there was some reason for not using a more traditional fixpoint
> combinator.
...
> This reminds me of named let in Scheme.
Yeah, it's certainly inspired by that (I always had a scheme macro
that let me use "recur" instead of "let") and has the same syntactic
benefits.
> > Somewhat related, would it be better to move the default exn
> > show function (using General.exnName) into the initial registration
> > for exceptions?
> >
> > regExn (fn Fail s => ...
> > | _ => C0 (concat ["<exn:", ...]))
>
> Probably not. That would mean, AFAICS, that the code implementing exn
> would then contain a hole. That is, the exn implementation would have
> to rely on the fact that there will always be at least one handler for
> any exception.
I don't understand. The initial registration (in the same module)
guarantees that with the wildcard pattern, right?
> So, I prefer the currect organization of the code.
Me too.
More information about the MLton-user
mailing list