Le 22/12/2009 00:25, Rich Hickey a écrit :
>
> On Dec 21, 3:54 pm, Charles Oliver Nutter<[email protected]>  wrote:
>    
>> Perhaps we should take a deep breath before proceeding. Ready?
>>
>> On Mon, Dec 21, 2009 at 2:24 PM, Rich Hickey<[email protected]>  wrote:
>>      
>>> On Dec 21, 1:50 pm, Charles Oliver Nutter<[email protected]>  wrote:
>>>        
>>>> I'm not sure where reflection comes into this, unless you're referring
>>>> to one way the top-level compiler stuff would get class data (and
>>>> reflection may be a particularly poor way, since it has to *load* the
>>>> classes and requires that they be valid/complete to do so, rather than
>>>> just reading the data format). Generally we're talking about .class
>>>> data and Java-centric type structures across languages. What do you
>>>> need reflection for at compile time?
>>>>          
>>      
>>> You are missing the point. .class file *are* a data format. And
>>> everything in the Java ecosystem understands them already. APIs *are
>>> not* a data format, they are a means for live communication between
>>> program entities.
>>>        
>> Eventually a shared compiler has to work with some API against some
>> "data" to coordinate different languages and the types they consume or
>> produce. Whether that data comes from class files (a common format) or
>> just appears to the coordinator as a set of interface-implementing
>> datatypes (backed by per-language data), I don't care.
>>      
> But it's not just the coordinator, it's also the consumers (other
> compilers). And we already know how to consume type information from
> class files.
>
>    
>> But as the
>> inference case shows, it is not always possible to generate stubs in a
>> single shot.
>>
>>      
> When, how, with what granularity, and how often to generate type
> information seems to me orthogonal to how that information is
> represented. Is there any evidence that the javax.lang representation
> is more suitable for languages with type inference?
>    

If you have a type representing a type variable, it is.

[...]

> Rich
>    

Rémi


--

You received this message because you are subscribed to the Google Groups "JVM 
Languages" group.
To post to this group, send email to [email protected].
To unsubscribe from this group, send email to 
[email protected].
For more options, visit this group at 
http://groups.google.com/group/jvm-languages?hl=en.


Reply via email to