Re: [DotGNU]DotGNU policies

[Peter Minten]

Norbert Bollow wrote:
> 
> James Michael DuPont <address@hidden> wrote:
> 
> > --- Peter Minten <address@hidden> wrote:

> > > * All essential DotGNU code shall be accessible from any language
> > >   provided it can access functions written in C.
> > >
> > >   Compatibility is our business. True compatibility does not mean
> > >   assimilation (compiling everything down to one bytecode) but
> > >   integration (providing ways to access stuff from one language
> > >   from another).
> 
> This sounds good to me.  I was planning to fire off an email to the
> mailing list of SC to ask for a vote on this until I read...
> 
> > Also it means making the bytecode interpreters accessible.
> 
> If it "also means" this, then it goes too far IMHO.

I agree. However, the pure rule does not say anything about the language
functions are written in, it just says functions have to be accessible using C.
If bytecode interpreters have to be hacked than that is clearly a sign that the
functions are NOT accessible using C. Let me rephrase:

* All essential DotGNU code shall be accessible from any language provided it 
  can access functions written in C. It shall only be allowed to write such 
  essential DotGNU code in a certain language if it's possible to call functions
  in the language from C in a way that does not require modifications of the 
  language compiler or interpreter.

  Compatibility is our business. True compatibility does not mean assimilation 
  (compiling everything down to one bytecode) but integration (providing ways 
  to access stuff from one language from another). Strange hacks in compilers 
  or interpreters should not be needed however. If that is needed it's a sign
  that a language is uncapable of performing the job.

> Peter, maybe you can post a revised working of your policy proposal
> which does not have this controversial implication?

See above. The rule is a little complicated now, but it does the job.

Hacking interpreters is usually a good sign of bad design. If you need to hack
an interpreter to make it do something you want either your design is bad, the
design of the author of the interpreter is bad or the design of the language
designer is bad. (note that in C# the latter is a real possibility ;-)

Greetings,

Peter