• Ryan Bloomfield <_sir_maniacREMOVE_ME yahoo.com> Jul 18 2008
• Ryan Bloomfield <_sir_maniacREMOVE_ME yahoo.com> Jul 18 2008
• Yigal Chripun <yigal100 gmail.com> Jul 18 2008

Ryan Bloomfield <_sir_maniacREMOVE_ME yahoo.com> writes:

Bill Baxter Wrote:

 
 I think preventing the proliferation of vendor-specific language 
 extensions is considered a feature of the current system.  There is 
 always "pragma" for non-language extensions.
 
 --bb


"pragma" won't allow a new keyword.  What if someone comes up with an
experimental feature, that later proves useful enough to become part of a
standard.  In C and C++, this happens all the time.  C exceptions are a good
example.

Ryan Bloomfield <_sir_maniacREMOVE_ME yahoo.com> writes:

Ryan Bloomfield Wrote:

 Bill Baxter Wrote:
 
 
 I think preventing the proliferation of vendor-specific language 
 extensions is considered a feature of the current system.  There is 
 always "pragma" for non-language extensions.
 
 --bb


 "pragma" won't allow a new keyword.  What if someone comes up with an
experimental feature, that later proves useful enough to become part of a
standard.  In C and C++, this happens all the time.  C exceptions are a good
example.


But alas, C99 doesn't have exceptions.  I was wrong, must of read something
wrong.  Ok, how about the "long long" type.  

Yigal Chripun <yigal100 gmail.com> writes:

Ryan Bloomfield wrote:
 Bill Baxter Wrote:
 
 I think preventing the proliferation of vendor-specific language 
 extensions is considered a feature of the current system.  There is
  always "pragma" for non-language extensions.
 
 --bb


 "pragma" won't allow a new keyword.  What if someone comes up with an
 experimental feature, that later proves useful enough to become part
 of a standard.  In C and C++, this happens all the time.  C
 exceptions are a good example.


IMHO, vendor extensions are the wrong way to add features to the
language. This promotes vendor lock-in or pollutes the code with lots of
 code like:

if compiler vendor is X
    do A
else if ...
..
else
   do Z

anyway, a much better way is to allow extensibility without the need to
write a whole compiler, via a plug-in mechanism. This also allows for
non compiler experts to add features that do not actually require
oneself to be a compiler expert. extensions for Firefox, and plug ins
for eclipse are good examples of such a mechanism that brought a lot of
innovation and new features. also the best of those addons can be added
to the main software itself, as done in Firefox (only where it makes
sense, of course)
there are other languages that already provide this.
to implement it you'd need a way to interface with the compiler via an
API and use AST macros (currently planned for D v3) or something similar
to define the new features.

This will allow you to provide language extensions as libraries instead
of requiring a specific compiler.