[bitc-dev] Opinions wanted: Infix shift operators

[Jonathan S. Shapiro]

On Fri, Aug 6, 2010 at 11:33 AM, wren ng thornton <wren at freegeek.org> wrote:

> ... GHC has shown that compilers can be smart enough to
> automatically uncurry the implementations when appropriate...


I have seen this same argument used to explain why unboxing should not be
part of the language semantics. The problem is: this argument is only sound
when uncurrying is elective. When the uncurrying is mandatory (that is:
prescriptive), it is an *error* for the compiler to *ever* emit the
uncurried form. When this is the case, the two types

   int -> int -> int
   int X int -> int

really are not the same, because the second conveys additional constraints.

Concerning, syntax, I would actually prefer the currying-style of syntax
myself. But I think it's worth noting that there is a failure of parallelism
in the Haskell syntax design: functions do not have arity as part of type,
but type constructors and value constructors *do* have arity. This is
actually fairly strange when you think about it.

OTOH, the fact that it does work suggests that perhaps the problem lies in
the arity-oblivious specification of function types rather than in the
surface syntax of application.


> At the type level, what benefit does the S<x,y> syntax offer?...
>
Once you start getting nested type expressions, things like (S (D
> x (Q y) z) are a lot easier for both human and machine to parse than
> S<D<x,Q<y>>,z>.
>

Actually, I agree with you. The problem is that C++ and C# programmers
aren't really human. :-)

More seriously, though, it was starting to look like there might be contexts
in which both the type parameters and the actual parameters might be needed
in certain function calls. If that turns out to be the case, you want the
respective bracketing syntax to be different. It would be better, of course,
to avoid this entirely.


> Even if you offer curried type constructors, there's no efficiency tradeoff
> between using curried vs uncurried, because the types are erased at
> runtime.


By the time they are erased, the code at both the call site and the receive
site has been compiled under the arity-aware assumption. The efficiency gain
has already occurred by the time erasure occurs. Another way of saying this
is that since code generation is impacted by type in an arity-aware system,
typing changes semantics, and the erasure property that results isn't quite
the same as the one that is usually cited.

But before I get into this any deeper, let me go read the G-machine paper
again.



> Moreover, because types are erased, there are no constraints
> from native calling conventions; we can call native types whatever we
> like.


That's the problem! There *need* to be constraints imposed from the native
calling conventions!


> Wherever possible, simpler is better.
>

Not quite. Wherever possible, deployable is better. Simpler is only better
subject to that constraint. We agree on the aesthetics.


shap
-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://www.coyotos.org/pipermail/bitc-dev/attachments/20100806/f1e46035/attachment.html