View mode: basic / threaded / horizontal-split · Log in · Help
July 18, 2008
Re: Porting D2 code to D1
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.
July 18, 2008
Re: Porting D2 code to D1
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.
July 18, 2008
Re: Porting D2 code to D1
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.
Top | Discussion index | About this forum | D home