[MLton] Fwd: Chat with vesa.a.j.k@gmail.com and Matthew.Fluet@gmail.com

[Matthew Fluet]

Forwarding to devel list for archival purposes.


---------- Forwarded message ----------
From: vesa.a.j.k at gmail.com <vesa.a.j.k at gmail.com>
Date: Jan 15, 2008 2:23 PM
Subject: Chat with vesa.a.j.k at gmail.com
To: matthew.fluet at gmail.com


11:36 AM vesa.a.j.k: Hi Matthew!
  Do you have a couple of minutes to chat?
________________________________
31 minutes
12:08 PM Matthew.Fluet: Sorry I missed your initial chat. I've usually
got GMail up in the background, but don't always check it.
12:09 PM vesa.a.j.k: No problem.
  As you have probable noticed, I have a bunch of stuff pending to be
committed to MLton.
  FP constant folding and simplification, def-use with types, and the
overloading enhancements.
12:10 PM I got the impression from your reply that the overloading
enhancements seemed fine. IOW, they could just as well be committed?
12:11 PM Matthew.Fluet: With regards to the overloading, I thought
they were fine, but _overload has never been a documented feature, so
it hasn't been a high priority to improve it.
12:12 PM vesa.a.j.k: I understand.
  So, I guess I'll go over the patch once more and commit it.
  Ok.
12:13 PM I've implement FP constant folding for most FP primitives and
a few simplifications.
  All regressions seem to pass.
12:14 PM I have a few questions, though.
  In order to constant fold castToWord and castFromWord, there is a
dependency from REAL_X to WORD_X. I assume this is OK?
12:15 PM Matthew.Fluet: I don't think added dependencies between
REAL_X and WORD_X are a problem.
 vesa.a.j.k: Ok.
12:16 PM I haven't yet looked at this aspect in detail, but I was
wondering whether there is some fundamental reason why optimizations
such as replacing divide by constant with a shift/multiple cannot be
expressed with the current primitive stuff?
12:20 PM Matthew.Fluet: I don't think there is any fundamental reason.
Like most software, MLton is a product of the immediate demands. Most
prim-op simplifications can be specified by one primop to a single
result (variable, constant, or single primop), so that's what got
implemented. We could do more if we could return a sequence of primops
(like div/mul to shifts), but it wasn't in high demand before. I don't
know what the ramifications of extending the primApp simplifier -- the
primitives are IL agnostic, so you need some way of passing in
functions to conjure up the right type for new temporaries.
12:21 PM vesa.a.j.k: Another thing I noticed is that floating point
rounding is quite problematic on the x86. Several functions in the
Real module cannot be constant folded due to this (because they need
to go through C). I was wondering whether it would be worth it to
introduce a primitive to essentially store+load FP values to force
correct rounding. This would be used instead of calling C and could be
constant folded. On backends other than x86 it would be a nop (or
identity).
12:22 PM About divide by constant... Ok, I'll go through the code in
detail and try to implement that (sometime after committing my other
changes).
12:24 PM Matthew.Fluet: I'm not sure I understand you concern about fp
rounding on the x86. I don't believe that we go through C for
rounding, we go through C for operations that don't have primitive
counterparts.
12:25 PM vesa.a.j.k: If you look at basis-library/real/real.sml...
  You'll see many functions calling the function class.
12:26 PM Many of the functions calling class could be rewritten so
that they would simply rely on correct treatment of nans in
comparisons without having to explicitly determine the class.
12:27 PM Matthew.Fluet: Maybe. Stephen implemented most of the Real
functor/structure. He went to some trouble to make sure that we obeyed
the Basis Library on all platforms. Seems that libm doesn't behave the
same everywhere.
12:28 PM vesa.a.j.k: Ok. I might look into adding such a primitive later.
12:29 PM Matthew.Fluet: But, you are right that class forces
everything out of the x87 FP stack, and can cause 80-bit non-inf
values to become inf. However, I don't believe that spilling will ever
cause a non-nan to become a nan.
12:30 PM vesa.a.j.k: Yes.
  The effect that class has is that it distinguishes correctly between
values that are outside the range of 64 (or 32) bit floats.
12:31 PM IOW, it treats infinities and zero (or overflows and
underflows) properly.
  A primitive to force a float out of registers (and back) would do the same.
12:32 PM IOW, after storing and loading, comparison with infinity and
zero would work correctly.
12:33 PM BTW, I noticed that if you use -ieee-real true, some of the
real/math regressions show diffs on the x86. I guess you knew that
already.
12:34 PM (Sorry, -ieee-fp not -ieee-real.)
 Matthew.Fluet: Sorry, I need to run for a meeting. I'll be back in an
hour or so. (Or send me an email.) Bottom line is that trying to force
the x87 to have IEEE semantics is probably a fruitless exercise. But,
I trust your judgment, and if you have improvements I doubt anyone
will have objections.
12:35 PM vesa.a.j.k: Ok. I'll probably be here after the meeting (if
it is just an hour).
________________________________
53 minutes
1:28 PM vesa.a.j.k: So, the last thing I wanted to ask you about is
the def-use output with types.
1:29 PM Did your read my reply to the Tycon.newString/fromString commit?
________________________________
6 minutes
1:35 PM Matthew.Fluet: Yes, I read the reply.
  But, I don't recall it off hand.
1:36 PM vesa.a.j.k: Well, for one thing, if you'd like me to add an
option to use newString (for debugging), just say so.
1:37 PM On my local copy of MLton I get, IMO, fairly readable types
now with def-use.
 Matthew.Fluet: I don't think it is a big deal either way.
 vesa.a.j.k: Ok.
1:38 PM One thing I've changed is that now (my copy of) def-use
contains all the types given for a binding.
  So, if a binding is in a functor and is used with multiple types,
one can now see all the types (rather than just one, possibly
incorrect, type.
 Matthew.Fluet: You mean, if the binding is instantiated multiple
times (as part of the body of a functor), you see each of the types?
That makes sense, if we aren't recording the type at use.
1:39 PM vesa.a.j.k: In the output the types are separated with "andalso".
  Yes.
  So, you might see, for example, "int -> int andalso word -> word".
  The shortest name is shown first.
1:40 PM Matthew.Fluet: That seems good.
 vesa.a.j.k: I also realized what caused the display of names such as
"int32" rather than "int".
1:41 PM Matthew.Fluet: That would seem to be grabbing an internal name
rather than an external name. Or, peeking through too many type
synonyms/abstractions.
 vesa.a.j.k: It is visibility. To get better type names, one has to
make sure that the mlb file leaves the used libraries visible (i.e.
not wrapped inside local ... in.
1:42 PM Matthew.Fluet: Oh. And "int32" is always implicitly in scope
via the pervasive primitive environment?
 vesa.a.j.k: I guess so.
1:44 PM Matthew.Fluet: I think it is a hard problem to pick really
good display types. Because the def-use info is processed after
elaboration, everything is with respect to the final basis environment
(and, failing that, some primitive type name).
1:45 PM vesa.a.j.k: That is true, but having the libraries in scope
improves type names significantly.
 Matthew.Fluet: One would really like to see the type of a variable
with respect to the environment at that variable -- but it seemed like
that would be prohibitively expensive. And, possibly, sensitive to
inferencce.
  But, with the library in scope, doesn't that change the meaning of the .mlb?
1:46 PM vesa.a.j.k: At any rate, I think that it also basically makes
sense to display type names relative to top-level in def-use info,
because even though a definition might be inside some deeply nested
structure, you might looking at a use site that is somewhere else.
1:47 PM True. What I've done with the mlb files is that I've changed
the application mlb files. Not the library mlb files.
1:48 PM Matthew.Fluet: Oh, I see. You could just re-import all of the
used library .mlbs, making all their types visible in the final
environment. Names can still be confused by shadowing, but you get
most of them.
1:50 PM vesa.a.j.k: So, in my reply I mentioned changing the way
module paths were shown with types in functors arguments. Any feelings
about that?
1:53 PM Matthew.Fluet: With regards to the "?." prefix, I seem to
recall that that was the MLton convention in a signature for
"selfification" of types. That is, to indicate that the type is equal
to its own signature type. That is different from using "?." for
shadowing (which, I know is what SML/NJ does). I don't recall what we
do for shadowing. Maybe it makes more sense to differentiate the
selfification from the shadowing.
1:56 PM vesa.a.j.k: The ?. prefixes in signatures don't appear in
def-use output. I'll probably reconsider that later.
 Matthew.Fluet: I wasn't sure what you meant by: "change the pretty
printing of functors so that the functor formal parameter name in the
output matches the name in the (where type) constraints for the formal
parameter signature."
1:58 PM vesa.a.j.k: In elaborate-env.fun the string "S: " is
implicitly used for functor arguments.
2:02 PM I think I tried to change the "ZZZNewStridZZZ" to something
else (I think
"Arg"), but it caused regressions. I'm not entirely sure what caused that.
  (IIRC!)
2:04 PM Well, I guess that the change to not to add the ?. prefix when
setTyconNames is called from top-level shouldn't cause any extra
ambiquity.
2:05 PM Matthew.Fluet: Probably not. And there are various things that
could be improved with regards to functors.
2:08 PM vesa.a.j.k: Right. Thanks for the feedback! I think I'll go
ahead and commit most of my changes to def-use output (and FP
primitives and overloading) tomorrow.
2:10 PM BTW, you asked about generic read at Freiburg. I've now
implemented an initial version of it. (There are still a few
improvements I'm going to try.)
2:11 PM The next thing I'm probably going to work on is to finally
write a fuller Parsec library and implement a tool for extracting
documentation from libraries.
2:14 PM Matthew.Fluet: I wanted to mention with regards to FP constant
folding, that we emit floating point constants that gcc interprets.
Right now, we just pass a floating point constant from the front end
(as a string) all the way to the codegen. We can emit constant folded
FP expressions in the same way, but we then rely on gcc to interpret
the constant in the same way. This doesn't really change things that
much, it's just that one tends to write down "small" fp constants. A
constant folded FP expression might be sensitive to the low order bits
in the IEEE representation, so we are relying on gcc/as to interpret
the constant with the same accuracy as the gdtoa library.
  It isn't a big deal, and if you haven't seen any regressions, then
things ought to be fine.
2:15 PM Generic read, Parsec, and an extract-doc tool all sound cool.
2:16 PM vesa.a.j.k: At least no regressions from MLton regression tests.
  I don't have many FP intensive applications to try with and the ones
that I have don't really exercise any corner cases.
2:17 PM Assuming gcc interprets the constants properly, I think that
the constant folding stuff should be safe.
2:19 PM Matthew.Fluet: I tend to agree that things should be safe with
gcc. Or, at least, no worse than the semantics one gets just using
gcc.
2:20 PM You might ask Sean McLaughlin (CMU) if he as any applications
that could be used for regression testing. He turned up a lot of the
corner cases with MLton's treatment of FP.
2:21 PM vesa.a.j.k: Good idea. I'll send him an e-mail.
2:23 PM Ok. Again, thanks for the feedback! I'm going to get some
sleep now (it is 22:23 local time).
2:24 PM Matthew.Fluet: No problem. And, I really appreciate you
keeping MLton active. I don't get nearly as much time to work on it as
I'd like. And, please do keep using the MLton-devel list -- I think it
is the best place to keep high level discussions, and I'll try to be
more timely with replies.
2:25 PM vesa.a.j.k: Oh, BTW, I have no objection to forwarding this
conversation to the MLton developers list if you like.
  I could do that tomorrow. Ok with you?
 Matthew.Fluet: Sure. It's a good way to archive it.
2:26 PM vesa.a.j.k: Ok. Bye!
 Matthew.Fluet: Bye!