On Fri, Feb 20, 2015 at 6:43 AM, Keean Schupke <[email protected]> wrote:
> 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.
It certainly can't compete with documentation comments. And it
doesn't. There's also javadoc. Metadata ensures that you're not
excessively recompiling headers. Other than that, you can do as much
or as little with them as you want.
> If that's really what everyone wants then I can live with it.
I don't know what everyone wants, and I don't know what BitC is going
to do. I said I don't know the details of BitC linking.
> 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.
This is getting way off topic.
>> >> 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?
1. The compiler might know the arity anyway, like for a toplevel definition.
2. If it doesn't, it's still OK. That's the whole point of arity specialization.
> How is it useful to make the programmer not know obviously if
> their call is going to work?
I don't know what you think is making calls any less likely to work
than usual. The type checker will reject calls that won't 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.
There is no choice in how to call a function. It has a certain arity,
and functions with that arity are called a certain way. The language
will generate the correct calls. The rules for instantiating an
arity-abstract function type with an arity-concrete function type are
such that any allocation from applying a function is the fault of the
callee. Namely, the concrete type can't take too many arguments.
_______________________________________________
bitc-dev mailing list
[email protected]
http://www.coyotos.org/mailman/listinfo/bitc-dev
