Re: Pointers to "why C behaves like that ?"

Joachim Durchholz <joachim_d@gmx.de> wrote:
> jacob navia wrote:
>>
>> fn(a)
>> {
>> b = a;
>> }
>>
>> How can you know what "a" is?
>
> "a" is of type ANY, or Object, or Equ, or whatever happens to be the
> most general type that allows comparisons for equality. Type inference
> will not produce a more specific definition of "a" or "b" at this
> point. Actually that's OK - there's no need to actually nail the type
> down at this point.


Depends. Do you want to be able to do separate compilation and be able
to get a shared library out of the code or no? Assuming that everybody
will have code for your library around and always does full program
compilation is extremely unscalable.


[snip]


> There are different answers.
> Some languages say it's Integer, because you'd have to write 2. or 6. to
> get a Float.
> Other languages say it's a Numeric, the common supertype of Integer,
> Float, and any of their higher-precision variants.
> (No language says it could be char, signed or unsigned; characters
> aren't Integers, multiplying a Character with a Character would be a
> meaningless operation. The conflation of characters and integers in C is
> one of the worst disservices that a programming languge did to the
> programmer communities, IMHO.)


C has no character type - it just has a (usually, as such is not
guranteed by the standards) ultra-short integer type that is called
char. There isn't much special about that type in fact many functions
that appear to be character related return or take int arguments
instead.


sizeof(long) == sizeof(int) == sizeof(short) == sizeof(char) == 64 bits
is a valid, standards-conformant (even if slightly odd) choice for
a C runtime - and one that has i think been made at least once.


--
Sander

Return to the comp.compilers page.
Search the comp.compilers archives again.