On 20 February 2015 at 11:29, Matt Oliveri <[email protected]> wrote:
>
> Heheh. You can also decompile the metadata back into a header. And
> that's not just in principle. The javap tool does essentially that,
> for JVM modules (.class files). On .net this is supported right in
> Visual Studio, which is really handy.
>
Decompiling back to headers seems a bit of a hack to me and not really an
elegant solution, JVM is one of the examples of how not to do it for me. If
that's really what everyone wants then I can live with it. I would still
rather have read-only (immutable to the compiler - functional programmers
must like this idea right?) header files that are human written and contain
intelligent comments so that I can combine documentation with the header
file for distributing with my binary libraries. I like the idea of Knuth's
literate programming, and think any documentation outside of the source
file is by definition out of date. Comments also get out of date, by types
with meaningful names written by a programmer (most likely) do not.
> >> But arities inferred from definitions should be exported. Anyway we
> >> shouldn't get into too much detail about linking in BitC. I don't
> >> _know_ the details, and anyway it seems like another topic.
> >
> >
> > The way I see it, the arities need to be explicit in the module interface
> > definition. Hence requiring the concrete expression of arity in the type
> > signature like:
> >
> > data module A = {
> > f :: fn 'a 'a -> 'a -- arity is explicit in export
> > }
>
> That is not technically necessary. If you're arguing that the arities
> _should_ be written somewhere for human reasons, you'll have to talk
> to Shap.
Is it not? How do you know how you can call a function if the arity is not
explicit? How is it useful to make the programmer not know obviously if
their call is going to work? Making the programmer have to do arity
inference in their heads to understand how they can call the function with
maximum efficiency seems a bad thing for a systems programming language.
Keean.
_______________________________________________
bitc-dev mailing list
[email protected]
http://www.coyotos.org/mailman/listinfo/bitc-dev
