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

"Joachim Durchholz" <joachim_d@gmx.de>
3 Dec 2002 00:41:22 -0500

          From comp.compilers

Related articles
[57 earlier articles]
Re: Pointers to "why C behaves like that ?" thp@cs.ucr.edu (2002-12-01)
Re: Pointers to "why C behaves like that ?" dot@dotat.at (Tony Finch) (2002-12-01)
Re: Pointers to "why C behaves like that ?" dot@dotat.at (Tony Finch) (2002-12-01)
Re: Pointers to "why C behaves like that ?" sander@haldjas.folklore.ee (Sander Vesik) (2002-12-01)
Re: Pointers to "why C behaves like that ?" fjh@students.cs.mu.OZ.AU (Fergus Henderson) (2002-12-03)
Re: Pointers to "why C behaves like that ?" nmm1@cus.cam.ac.uk (Nick Maclaren) (2002-12-03)
Re: Pointers to "why C behaves like that ?" joachim_d@gmx.de (Joachim Durchholz) (2002-12-03)
Re: Pointers to "why C behaves like that ?" vugluskr@unicorn.math.spbu.ru (Roman Shaposhnick) (2002-12-07)
Re: Pointers to "why C behaves like that ?" vugluskr@unicorn.math.spbu.ru (Roman Shaposhnick) (2002-12-07)
Re: Pointers to "why C behaves like that ?" lex@cc.gatech.edu (Lex Spoon) (2002-12-11)
Re: Pointers to "why C behaves like that ?" joachim_d@gmx.de (Joachim Durchholz) (2002-12-11)
Re: Pointers to "why C behaves like that ?" marcov@toad.stack.nl (Marco van de Voort) (2002-12-11)
Re: Pointers to "why C behaves like that ?" marcov@toad.stack.nl (Marco van de Voort) (2002-12-11)
[4 later articles]
| List of all articles for this month |

From: "Joachim Durchholz" <joachim_d@gmx.de>
Newsgroups: comp.compilers
Date: 3 Dec 2002 00:41:22 -0500
Organization: Compilers Central
References: 02-11-095 02-11-103 02-11-128 02-11-150 02-12-026
Keywords: types
Posted-Date: 03 Dec 2002 00:41:22 EST

Sander Vesik wrote:
  > 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.


You can have generic code, and let the compiler generate
specializations as needed. It's not *that* difficult, all you have to
do is to keep enough information for that in the object files. (I hope
that modern object formats allow compilers to add their own
information to an object file.)


If you want to link with an external, not type-inferring language,
you'd need a separate run of the compiler to generate the specialized
version, but I don't think that this would be very difficult. (This
also answers Jacob Navia's assumption that generic code cannot be
efficient - of course it can, provided that enough information to
specialize it as needed in a specific situation is available.)


Regards,
Joachim


Post a followup to this message

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