[bitc-dev] Opinions wanted: Infix shift operators

[Ben Karel]

>
> The situation's not quite as bad as C++, since only arity is required, not
>> "full" type info.
>>
>
> We need full type information in any case, since we have to deal with
> calling conventions involving formal parameters that are pass-by-reference.
>

As the compiler, sure; I was thinking of requirements imposed on third-party
tools.


>  Also, in this case, the only "missing" semantic information is (I
>> think??) whether runtime closure creation may be required, and if arity
>> information becomes available later, the AST can be post-processed to
>> eliminate unnecessary chained calls.
>>
>
> Perhaps, but this is something where "later" is likely to mean "at run
> time", which is too late given BitC's other objectives.
>
> Can you articulate why it is important to be able to generate correct ASTs
> in the absence of type information? That is: why the type-based lifting
> approach is somehow undesirable?
>

It's obviously a moot point for any full-fledged BitC compiler, which must
have the type info regardless. I was thinking of source-to-source analysis
and transformation tools, and avoiding a trend towards the situation that
C++ has, where disambiguating e.g. function call vs type cast requires
knowing type information. I don't think the type-based lifting approach is
bad, in fact I think the syntactic benefits outweigh the marginal extra
difficulty for AST builders and processors.

Not using curried syntax + lifting will make code using fully curried
functions much uglier, and doing the lifting merely means that some subset
of BitC source processors would need a symbol table keeping track of
function arity, when they wouldn't otherwise. But the set seems pretty small
-- custom prettyprinters would be fine doing without, for example. Unless of
course the user wanted to prettyprint unambiguously... Offhand, I can't
think of any other analyses that would need to differentiate (f x y) from
((f x) y) that would not also need full type information.

The issue of arity-aware AST building also becomes a non-issue if you go the
clang route and provide a reusable parser library, or use a standardized
serialization format (protobufs?) for BitC ASTs.



>  Since uncurried semantics seems like the desired default for BitC, make
>> it correspond to the simpler type-level syntax. With Haskell-like syntax,
>> we'd have  add : int -> int -> int    and add_curried : int -> (int ->
>> int). Which type gets inferred would presumably depend on how the
>> function is defined, as add(x,y) = x +y   or    add_curried x y = x + y.
>>  Or perhaps with C# style lambdas, add_curried = (x) => (y) => x + y.
>>
>
> Ignoring differences in the concrete syntax, this is essentially where we
> are right now. We could certainly use sugar to make defining the curried
> form slightly easier, but if we introduce an explicit operator for curried
> application, say:
>
> add . x
>
> then I'm not sure there is much of an advantage to defining the non-curried
> form differently. The only issue at that point relates to the loss of
> genericity from the presence of arity. Switching to the tuple approach
> really doesn't change that issue.
>


What genericity is lost to arity? I don't recall seeing concrete examples
before.
-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://www.coyotos.org/pipermail/bitc-dev/attachments/20100809/33dd1380/attachment-0001.html