[bitc-dev] Opinions wanted: Infix shift operators
krismicinski at gmail.com
Fri Aug 6 14:27:14 PDT 2010
On Fri, Aug 6, 2010 at 11:33 AM, wren ng thornton <wren at freegeek.org> wrote:
> Mark P. Jones wrote:
> >>> Why not do like haskell and say
> >>> S typevar typevar
> >>> instead of S<typevar, typevar>?
> >>> Like Either Integer String
> >> I'm very much in favor of the whitespace application syntax.
> >> Because this isn't Haskell.
> >> In the BitC use domain, it is important to be able to take full
> advantage of the native calling convention. Because of this, arity is part
> of type. That is, the types:
> >> int x int -> int
> >> int -> int -> int
> >> are not the same.
> >> I would actually prefer to use the currying syntax myself, and if
> someone can show me how to make that work I think I would adopt it.
> > This seems to be confusing the syntax of the type language and the
> > syntax of the expression language.
> There are reasons to prefer curried functions by default at the
> value-level, and there's no reason that has to reflect implementation
> details. This is one of the primary failings of OCaml/SML in my opinion,
> whereas GHC has shown that compilers can be smart enough to
> automatically uncurry the implementations when appropriate. But this
> discussion is neither here nor there. What you do at the value level is
> not the same as what you do at the type level.
> At the type level, what benefit does the S<x,y> syntax offer? Even if
> you offer curried type constructors, there's no efficiency tradeoff
> between using curried vs uncurried, because the types are erased at
> runtime. Moreover, because types are erased, there are no constraints
> from native calling conventions; we can call native types whatever we
> like. 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
> Wherever possible, simpler is better.
> Live well,
> bitc-dev mailing list
> bitc-dev at coyotos.org
I agree and think that this should be the case in the type level. I think
this is a type centric manner, rather than an implementation centric manner.
What's the problem with this implementationally? Hard to generate a hard
call to a runtime function if it's curried? Why can't we stick it inside a
continuation all the same?
-------------- next part --------------
An HTML attachment was scrubbed...
More information about the bitc-dev