[Top][All Lists]
[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
Re: [DotGNU]DotGNU policies
From: |
Peter Minten |
Subject: |
Re: [DotGNU]DotGNU policies |
Date: |
Wed, 19 Mar 2003 10:44:25 +0100 |
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