> That's one issue. Another issue is that attributes can't be inferred, because the compiler does not (in general) know anything about their semantics.
Not sure what you mean In C# they are just a normal assembly types that inherit from System.Attribute that can be read from CIL , the properties are used for additional semantics so the runtime defines the attributes semantics which the compiler knows about. This either requires the compiler ( and IDE for auto completion) to read metadata or the IR/CIL of the attribute lib.. No insignificant task but you get significant benefits. >But worse than this: when attributes are used to encode type, we need a way to attach them to types and print them accordingly. In C#, an attribute cannot be introduced at a type, only at a type definition. The way you work around this is by introducing and using a typedef. The associated information is lost for pretty-printing purposes, exactly because it isn't a type. You could put the Attribute at the type variable ( if static) but C# doesn't use this , such a construction (though possible) would be ugly and need some horrible parser interaction. Im pretty sure in C# it just uses the square brackets and passes that on to the compiler who decides if it is valid after looking it up via reflection. (And the auto completion helps create it). I see now where you're going what if we want a int64 with an attribute we need to define a new type which can be done with a typdef. This IMHO is no big deal nor is c style predefined types . The issue is the functional side and todate few (any ?) functional languages use attributes , eg how do you declare one on an anonymous function , C# just says you cant.. but you can declare attributes to functions on structs . Am I right in BitC you cant have functions in structures only objects ( so c instead of C++) ? While this really shows the dichotomy I don't think this is that bad since attributes are normally used on carefully crafted interfaces/modules and then used by higher level logic. You could add them to functions as well as mentioned though it does feel weird.. Also you're going to need some sort of mechanism to do things like Alignment (especially with SSE2 needing 16 byte and SSEX may need 32 byte) Packing Field offsets ( for interop) Memory Barriers , volatile in C is an abomination you need to have more control Interop marshalling Calling options Cdecl, Pascal , fastcall or whatever else is invented. You can add NoGC/NoHeap to ensure the compiler checks there is no heap access for cases where you can run without a GC/heap Attributes help cross the barrier between a language which needs to be pure and the different architectures it runs on which is certainly not pure. In BitC you sort of use defrepr but this means the language needs to handle the worse case HW and changes in HW as we go along eg 256 bit alignment , different packing etc esp since SIMD seems to be gaining ground. In this case only the compiler and runtime lib need to change this simplifies the language but makes it more flexible. . Ben
_______________________________________________ bitc-dev mailing list bitc-dev@coyotos.org http://www.coyotos.org/mailman/listinfo/bitc-dev
