Here are some off-the-cuff notes:
> If you say, for example,
>
> extern type c_char = int(8);
> var x:c_char;
>
> then by the time the code is generated, we get
>
> int8_t x_chpl;
>
> which causes problems in a variety of extern integration
> contexts. We want it to say rather:
>
> char x_chpl;
I agree that it would be great to resolve this long-standing
issue/approach.
> The question is - what do we need to do in order to fix it?
>
> I think that we need to do the following, but I wanted
> to ask if there is another simpler approach?
>
> - add a normalizedType* to the Type class
> - the compiler would generate 2 types where it used to do one:
> -- Type for int(8) which would have normalizedType=this
> -- Type for c_char with normalizedType = int(8)
My intuition for representing this would be different. Given that the
'*Symbol' classes are where definitions of things tend to be stored in the
Chapel compiler (e.g., a function's formals and return type are in
FnSymbol, not FnType, for better or worse), I'd be inclined to represent
the notion that 'c_char' is an alias in its 'TypeSymbol', or possibly a
subclass of 'TypeSymbol' (e.g., 'TypeDefSymbol' or 'TypeAliasSymbol'?)
rather than in the 'Type' class itself.
> - fix some or all Type* equality checks (possibly with C++ overload of ==)
> to check normalizedType instead of Type*
I have a feeling that there are going to be cases where you'll want both
queries ('is this the same type symbol?' vs. 'is this the same type
definition?') and so would suggest not overloading == in order to avoid
confusion about which case it represents.
> - make sure that function resolution instantiates with the original Type
> instead of the normalizedType (e.g. so that c_ptr(c_char) ends up
> generating as char* rather than int8_t*), even as it uses the
> normalized type when deciding how to instantiate.
>
> Note that in some cases that would mean we would need to generate
> two functions where we used to do only one:
>
> proc writeln(x) // if this is used with c_char and int(8), we need
>
> proc writeln(x:c_char)
> proc writeln(x:int(8))
I would guess that, in most cases, we wouldn't want to instantiate for
both symbols. We already have issues with generated code bloat, and I
think this is going to hurt way more than it helps anything (particularly
since there's no way in the current language definition to create
overloads on type aliases. I.e.,
proc foo(x: c_char) { ... }
proc foo(x: int(8)) { ... }
won't permit you to dispatch to different foo()s depending on what the
name of your type is. To that end, my question would be what it is about
'c_ptr' that wants to preserve names and to try and make that case the
exception rather than the rule.
-Brad
------------------------------------------------------------------------------
Dive into the World of Parallel Programming The Go Parallel Website, sponsored
by Intel and developed in partnership with Slashdot Media, is your hub for all
things parallel software development, from weekly thought leadership blogs to
news, videos, case studies, tutorials and more. Take a look and join the
conversation now. http://goparallel.sourceforge.net/
_______________________________________________
Chapel-developers mailing list
[email protected]
https://lists.sourceforge.net/lists/listinfo/chapel-developers
