• "Robert Medeiros" <robert.medeiros utoronto.ca> Jan 31 2003
• Ilya Minkov <midiclub 8ung.at> Jan 31 2003
• "Daniel Yokomiso" <daniel_yokomiso yahoo.com.br> Feb 02 2003
• Ilya Minkov <midiclub tiscali.de> Feb 03 2003
• "Daniel Yokomiso" <daniel_yokomiso yahoo.com.br> Feb 03 2003
• Ilya Minkov <midiclub 8ung.at> Feb 04 2003
• "Ken Carpenter" <kencr shaw.ca> Feb 12 2003
• Ilya Minkov <midiclub 8ung.at> Feb 12 2003
• Daniel Yokomiso <Daniel_member pathlink.com> Feb 13 2003
• "Ken Carpenter" <kencr shaw.ca> Feb 03 2003
• Daniel Yokomiso <Daniel_member pathlink.com> Feb 04 2003
• "Ken Carpenter" <kencr shaw.ca> Feb 12 2003
• Daniel Yokomiso <Daniel_member pathlink.com> Feb 12 2003
• "Ken Carpenter" <kencr shaw.ca> Feb 13 2003
• "Walter" <walter digitalmars.com> Jan 31 2003
• Ilya Minkov <midiclub 8ung.at> Jan 31 2003
• "Walter" <walter digitalmars.com> Jan 31 2003

"Robert Medeiros" <robert.medeiros utoronto.ca> writes:

Another thought for a potential feature of D -- support for distributed
compilation as a standardized part of the compiler, which could possibly
have a daemon (D-mon?) mode letting it run as a background process/service,
or a distinct but included utility that handles networking issues and
forwards information to each local instance of the compiler. Some
interesting software that works with GCC: http://distcc.samba.org/.

Rob

Ilya Minkov <midiclub 8ung.at> writes:

Robert Medeiros wrote:
 Another thought for a potential feature of D -- support for distributed
 compilation as a standardized part of the compiler, which could possibly
 have a daemon (D-mon?) mode letting it run as a background process/service,
 or a distinct but included utility that handles networking issues and
 forwards information to each local instance of the compiler. Some
 interesting software that works with GCC: http://distcc.samba.org/.
 
 Rob
 


First, it is a compiler feature, since it doesn't add anything to a 
language. Second, it's not necessarily that all compilers need it.

On my notebook, DMC runs ten times as fast as GCC - so why should bother 
acceleraing GCC through hooking it on the network? I have 2 PCs and a 
notebook. Well, i could speed up the compilation twice - it's still no 
comparison to a well-designed compiler. I could even hook up a whole 
university network - and it still wouldn't be as fast as a normal 
compiler because too much network traffic would be involved.

That's a possibly only ill place of GCC - its speed. And this is a 
temporary workaround, which is not worth promoting. Better fix the 
underlying system, right? It certainly still makes sense for a few 
can't- imagine- how- huge projects.

I've recently bocome aware that .net is not as bad as one might think:
  - it's gonna be standardized by ECMA, so it wouldn't stay in m1cro$oft 
domain;
  - it is, unlike Java, suited well for a wide range of languages, by 
providing an IL;
  - unlike Java bytecode, the IL is much higher-level and allows for a 
wide range of compiler optimisations. Different kinds of code generators 
can be attached, including production-quality static compiling 
back-ends, or fast JIT VMs. It's much more like a common compiler/ 
interpreter/ anything infrastructure;
  - there already is a real open-source project "mono", which has a 
CPU-independant bytecode interpreter, and a good JIT x86 VM, and C# and 
VB ->IL compilers, as well as a simplified static compiler (i guess);
  - they also want to write a backend for GCC to generate IL - so that 
fast GCC frontends (like GNAT, GPK, FPK, OCaml, OpenD) can benefit from 
different code generators and instant execution, instead of waiting for 
current GCC backend to scratch its kin.

M1cro$oft would probably benefit from some applications, but they just 
have taken a step which was due for a long time. It is to assume certain 
incompatibilities if m1cro$oft products have any underwater (non-ECMA) 
parts, but who would care after "mono" is ready and having a complete 
ECMA toolset, for developers as well as for Academia? And i bet 
academics would soon give us yet better back-ends, as they have for 
Java, but of better quality since .net doesn't seem to suffer from 
Java's inherent deficiencies.

-i.

"Daniel Yokomiso" <daniel_yokomiso yahoo.com.br> writes:

Hi,

    Comments embedded.

"Ilya Minkov" <midiclub 8ung.at> escreveu na mensagem
news:b1ej56$sks$1 digitaldaemon.com...
[snip]

 I've recently bocome aware that .net is not as bad as one might think:
   - it's gonna be standardized by ECMA, so it wouldn't stay in m1cro$oft
 domain;


    Kind of. Most of the libraries used in .net aren't in the ECMA standard,
and Microsoft adds a few more every other release. IIRC (my copy of the
standard may be outdated) the only libraries in it are: Base Class, Network,
Reflection, XML, Floating-Point and Extended Array. Things like GUI aren't
standard and most (if not all) applications written using Microsoft .net SDK
use something Microsoft specific.

   - it is, unlike Java, suited well for a wide range of languages, by
 providing an IL;


    This thing is source of lots of Java vs. C# debates. Provision of an IL
gives no guarantees. Java has also a byte-code format, which can be used as
an intermediate language. Of course CIL has a different set of byte-codes
than Java (e.g. tail call), and different primitives (e.g. structs,
pointers). But most of these come from the C-like languages, so it's not
like they are really providing a full range of languages. Eiffel# was
crippled to be able to compile cleanly to CIL. Mondrian.net and F# aren't
fully functional (no pun intended) too. The only non-imperative language
that compiles to CIL and isn't crippled is Mercury. There was a problem with
Python ports to .net some time ago, and Smallscript has it's issues too.

   - unlike Java bytecode, the IL is much higher-level and allows for a
 wide range of compiler optimisations. Different kinds of code generators
 can be attached, including production-quality static compiling
 back-ends, or fast JIT VMs. It's much more like a common compiler/
 interpreter/ anything infrastructure;


    In which ways CIL is "much higher-level" than Java's byte-code? I can
think of tail call and polymorphic instructions for all types (like push
instead of push int), but both are very similar.

   - there already is a real open-source project "mono", which has a
 CPU-independant bytecode interpreter, and a good JIT x86 VM, and C# and
 VB ->IL compilers, as well as a simplified static compiler (i guess);


    Check DotGNU too (www.dotgnu.org). It tries to provide a free
alternative to every single feature present in .net, while Mono is more of a
C# compiler/CVM implementation.

   - they also want to write a backend for GCC to generate IL - so that
 fast GCC frontends (like GNAT, GPK, FPK, OCaml, OpenD) can benefit from
 different code generators and instant execution, instead of waiting for
 current GCC backend to scratch its kin.

 M1cro$oft would probably benefit from some applications, but they just
 have taken a step which was due for a long time. It is to assume certain
 incompatibilities if m1cro$oft products have any underwater (non-ECMA)
 parts, but who would care after "mono" is ready and having a complete
 ECMA toolset, for developers as well as for Academia? And i bet
 academics would soon give us yet better back-ends, as they have for
 Java, but of better quality since .net doesn't seem to suffer from
 Java's inherent deficiencies.


    Again, which deficiencies are inherent to Java, but not to .net?

 -i.


    Best regards,
    Daniel Yokomiso.

"Enlightenment does not divide you, just as the moon does not break the
water. The depth of the drop is the height of the moon."
- Dogen


---
Outgoing mail is certified Virus Free.
Checked by AVG anti-virus system (http://www.grisoft.com).
Version: 6.0.449 / Virus Database: 251 - Release Date: 27/1/2003

Ilya Minkov <midiclub tiscali.de> writes:

Hello.


Daniel Yokomiso wrote:
 Hi,
 
     Comments embedded.
 
 "Ilya Minkov" <midiclub 8ung.at> escreveu na mensagem
 news:b1ej56$sks$1 digitaldaemon.com...
 [snip]
 
     Kind of. Most of the libraries used in .net aren't in the ECMA standard,
 and Microsoft adds a few more every other release. IIRC (my copy of the
 standard may be outdated) the only libraries in it are: Base Class, Network,
 Reflection, XML, Floating-Point and Extended Array. Things like GUI aren't
 standard and most (if not all) applications written using Microsoft .net SDK
 use something Microsoft specific.


Gnome project has taken care of that as well :) They have written 
"gtk#". I'll have ti take a look whether it's a mess or not. But i 
believe the purpose of the gnome project is to bring standards to modern 
Unix and the chief said it's time to get rid of a mess...

  - it is, unlike Java, suited well for a wide range of languages, by
providing an IL;


 
     This thing is source of lots of Java vs. C# debates. Provision of an IL
 gives no guarantees. Java has also a byte-code format, which can be used as
 an intermediate language. Of course CIL has a different set of byte-codes
 than Java (e.g. tail call), and different primitives (e.g. structs,
 pointers). But most of these come from the C-like languages, so it's not
 like they are really providing a full range of languages. Eiffel# was
 crippled to be able to compile cleanly to CIL. Mondrian.net and F# aren't
 fully functional (no pun intended) too. The only non-imperative language
 that compiles to CIL and isn't crippled is Mercury. There was a problem with
 Python ports to .net some time ago, and Smallscript has it's issues too.


And how is CIL worse than GCC AIL? They are C-based as well. I thought C 
itself is more or less enough to express all kinds of languages, except 
for calling convention/tail recursion/ such stuff which is fixed. C-- 
goes once below this level of abstraction, claiming to be a "universal 
assembly language" (pity it doesn't work yet well). And AFAIK CIL is 
about the same level of abstraction.

I'd like to know more of CIL limitations, and whether GCC has them as 
well or not.

     In which ways CIL is "much higher-level" than Java's byte-code? I can
 think of tail call and polymorphic instructions for all types (like push
 instead of push int), but both are very similar.


I guess that CIL tree structure can be reconstructed, allowing for all 
optimisations of static compilation. Of course, it does not necessarily 
make sense for JIT/VM, but for static compilation it does.

There have been many attempts to compile Java bytecode into native code, 
but the resulting code quality was still not the same as with 
native-compiled pogrammes, because some optimisations on structure could 
not be done.

A Java source->native binary project had better success, AFAIK. I 
thought CIL would enable the possibility of these optimisations as well.

Please don't hold what i say here for an absolute truth, i'm not very 
well informed on these subjects. I have downloaded the whole 
documentation, but i didn't have time to actually read it. I've got 
exams in a week and after that i'm free and will multiply my knowledge 
and power. And write some useful utility for D.

     Check DotGNU too (www.dotgnu.org). It tries to provide a free
 alternative to every single feature present in .net, while Mono is more of a
 C# compiler/CVM implementation.


That split again! Qt# on one side, GTK# on the other!
Well yes, i'm more interested in a VM than in the rest, since every 
already established language would bring its own librarries with it. 
Example: D.
BTW, D is still in a need of a GUI library.

     Again, which deficiencies are inherent to Java, but not to .net?


^^^ Either those, or i have to read more :>

 
     Best regards,
     Daniel Yokomiso.
 
 "Enlightenment does not divide you, just as the moon does not break the
 water. The depth of the drop is the height of the moon."
 - Dogen




-i.

"Daniel Yokomiso" <daniel_yokomiso yahoo.com.br> writes:

Hi,

    Comments embedded.

"Ilya Minkov" <midiclub tiscali.de> escreveu na mensagem
news:b1ll0n$2cf1$1 digitaldaemon.com...
 Hello.


 Daniel Yokomiso wrote:
 Hi,

     Comments embedded.

 "Ilya Minkov" <midiclub 8ung.at> escreveu na mensagem
 news:b1ej56$sks$1 digitaldaemon.com...
 [snip]

     Kind of. Most of the libraries used in .net aren't in the ECMA




 and Microsoft adds a few more every other release. IIRC (my copy of the
 standard may be outdated) the only libraries in it are: Base Class,




 Reflection, XML, Floating-Point and Extended Array. Things like GUI




 standard and most (if not all) applications written using Microsoft .net




 use something Microsoft specific.


 Gnome project has taken care of that as well :) They have written
 "gtk#". I'll have ti take a look whether it's a mess or not. But i
 believe the purpose of the gnome project is to bring standards to modern
 Unix and the chief said it's time to get rid of a mess...


    There's also QT# ( http://qtcsharp.sourceforge.net/ ), so we have choice
when using CIL. But People writing C# using Microsoft stuff will probably
depend on their implementation.

  - it is, unlike Java, suited well for a wide range of languages, by
providing an IL;



     This thing is source of lots of Java vs. C# debates. Provision of an




 gives no guarantees. Java has also a byte-code format, which can be used




 an intermediate language. Of course CIL has a different set of




 than Java (e.g. tail call), and different primitives (e.g. structs,
 pointers). But most of these come from the C-like languages, so it's not
 like they are really providing a full range of languages. Eiffel# was
 crippled to be able to compile cleanly to CIL. Mondrian.net and F#




 fully functional (no pun intended) too. The only non-imperative language
 that compiles to CIL and isn't crippled is Mercury. There was a problem




 Python ports to .net some time ago, and Smallscript has it's issues too.


 And how is CIL worse than GCC AIL? They are C-based as well. I thought C
 itself is more or less enough to express all kinds of languages, except
 for calling convention/tail recursion/ such stuff which is fixed. C--
 goes once below this level of abstraction, claiming to be a "universal
 assembly language" (pity it doesn't work yet well). And AFAIK CIL is
 about the same level of abstraction.

 I'd like to know more of CIL limitations, and whether GCC has them as
 well or not.



    All languages are equal in the Turing tarpit ;-)
    CIL has the same problems other imperative language models. The primary
parameter passing device is the stack. It supports static overloading of
methods, which is resolved statically and it's harmful for languages with
multi-methods. It doesn't has generics since day one (I know about their
research and future plans, but still it's not integrated in the class
library and type system, and generics are a big change of paradigm).
Languages with message passing (e.g. Smalltalk or Objective C) for method
calling, usually have different forms of method storing instead of vtables,
the same goes to generic dispatching mechanism (e.g. multi-dispatch and
predicative dispatch). These kind of problems. I don't know GCC AIL, but it
may have this same category of problems.


     In which ways CIL is "much higher-level" than Java's byte-code? I




 think of tail call and polymorphic instructions for all types (like push
 instead of push int), but both are very similar.


 I guess that CIL tree structure can be reconstructed, allowing for all
 optimisations of static compilation. Of course, it does not necessarily
 make sense for JIT/VM, but for static compilation it does.

 There have been many attempts to compile Java bytecode into native code,
 but the resulting code quality was still not the same as with
 native-compiled pogrammes, because some optimisations on structure could
 not be done.

 A Java source->native binary project had better success, AFAIK. I
 thought CIL would enable the possibility of these optimisations as well.

 Please don't hold what i say here for an absolute truth, i'm not very
 well informed on these subjects. I have downloaded the whole
 documentation, but i didn't have time to actually read it. I've got
 exams in a week and after that i'm free and will multiply my knowledge
 and power. And write some useful utility for D.


    Java source -> native or byte-code -> native aren't that much different,
only different forms of representing methods and objects. AFAIK the largest
class of problems in Java come from optimization of standard libraries.

     Check DotGNU too (www.dotgnu.org). It tries to provide a free
 alternative to every single feature present in .net, while Mono is more




 C# compiler/CVM implementation.


 That split again! Qt# on one side, GTK# on the other!
 Well yes, i'm more interested in a VM than in the rest, since every
 already established language would bring its own librarries with it.
 Example: D.
 BTW, D is still in a need of a GUI library.


    Both runtimes support QT# and GTK#. But DotGNU provides other things,
like a application server, a authentication server, webservices support,
etc., that aren't Mono's primary target.

     Again, which deficiencies are inherent to Java, but not to .net?


 ^^^ Either those, or i have to read more :>

     Best regards,
     Daniel Yokomiso.

 "Enlightenment does not divide you, just as the moon does not break the
 water. The depth of the drop is the height of the moon."
 - Dogen




 -i.


    Best regards,
    Daniel Yokomiso.

"1. Out of clutter, find simplicity.
 2. From discord, find harmony.
 3. In the middle of difficulty lies opportunity."
 - Albert Einstein


---
Outgoing mail is certified Virus Free.
Checked by AVG anti-virus system (http://www.grisoft.com).
Version: 6.0.449 / Virus Database: 251 - Release Date: 27/1/2003

Ilya Minkov <midiclub 8ung.at> writes:

Hi.

Anyway, some way must always be found to express a high-level language 
in a machine language. C provides fairly little abstraction over the 
machine. CIL even less. Java and Java Bytecode much more.
The less intermediate abstraction, the better chances are that any 
compilable language can be translated with a justifiable effort. The 
higher the level of abstraction, the better optimisation can be done. 
AFAIK e.g. LCC IL wraps low-level representation into a higher-level, so 
two different levels of abstraction are available at once. I think CIL 
should be similar, thus allowing to compile languages that don't fit a 
bit somewhere with a small loss of efficiency.
I have heard that Java bytecode is stripped down to such extent, that 
reconstruction of higher-level representation (tree) is too complicated, 
and not low-level enough so that most languages would get a huge 
emulation penalty when expressed in it. You can't directly manipulate 
the stack in it, right? Like you would do on every normal computer.
It's really no sense complaining that the IL doesn't provide some ready 
primitive that would be good for your language, since normally you would 
be compiling into assembly and run into similar problems, if the IL 
allows a low level representation. But if it doesn't, you're sacked in.

-i.


Daniel Yokomiso wrote:
 Hi,
 
 Comments embedded.
 
 "Ilya Minkov" <midiclub tiscali.de> escreveu na mensagem 
 news:b1ll0n$2cf1$1 digitaldaemon.com...
 
 Hello.
 
 
 Daniel Yokomiso wrote:
 
 Hi,
 
 Comments embedded.
 
 "Ilya Minkov" <midiclub 8ung.at> escreveu na mensagem 
 news:b1ej56$sks$1 digitaldaemon.com... [snip]
 
 Kind of. Most of the libraries used in .net aren't in the ECMA




 standard,
 
 and Microsoft adds a few more every other release. IIRC (my copy
 of the standard may be outdated) the only libraries in it are:
 Base Class,




 Network,
 
 Reflection, XML, Floating-Point and Extended Array. Things like
 GUI




 aren't
 
 standard and most (if not all) applications written using
 Microsoft .net




 SDK
 
 use something Microsoft specific.


 Gnome project has taken care of that as well :) They have written 
 "gtk#". I'll have ti take a look whether it's a mess or not. But i 
 believe the purpose of the gnome project is to bring standards to
 modern Unix and the chief said it's time to get rid of a mess...


 
 There's also QT# ( http://qtcsharp.sourceforge.net/ ), so we have
 choice when using CIL. But People writing C# using Microsoft stuff
 will probably depend on their implementation.
 
 
 - it is, unlike Java, suited well for a wide range of
 languages, by providing an IL;


 
 This thing is source of lots of Java vs. C# debates. Provision of
 an




 IL
 
 gives no guarantees. Java has also a byte-code format, which can
 be used




 as
 
 an intermediate language. Of course CIL has a different set of




 byte-codes
 
 than Java (e.g. tail call), and different primitives (e.g.
 structs, pointers). But most of these come from the C-like
 languages, so it's not like they are really providing a full
 range of languages. Eiffel# was crippled to be able to compile
 cleanly to CIL. Mondrian.net and F#




 aren't
 
 fully functional (no pun intended) too. The only non-imperative
 language that compiles to CIL and isn't crippled is Mercury.
 There was a problem




 with
 
 Python ports to .net some time ago, and Smallscript has it's
 issues too.


 And how is CIL worse than GCC AIL? They are C-based as well. I
 thought C itself is more or less enough to express all kinds of
 languages, except for calling convention/tail recursion/ such stuff
 which is fixed. C-- goes once below this level of abstraction,
 claiming to be a "universal assembly language" (pity it doesn't
 work yet well). And AFAIK CIL is about the same level of
 abstraction.
 
 I'd like to know more of CIL limitations, and whether GCC has them
 as well or not.


 
 
 All languages are equal in the Turing tarpit ;-) CIL has the same
 problems other imperative language models. The primary parameter
 passing device is the stack. It supports static overloading of 
 methods, which is resolved statically and it's harmful for languages
 with multi-methods. It doesn't has generics since day one (I know
 about their research and future plans, but still it's not integrated
 in the class library and type system, and generics are a big change
 of paradigm). Languages with message passing (e.g. Smalltalk or
 Objective C) for method calling, usually have different forms of
 method storing instead of vtables, the same goes to generic
 dispatching mechanism (e.g. multi-dispatch and predicative dispatch).
 These kind of problems. I don't know GCC AIL, but it may have this
 same category of problems.
 
 
 
 In which ways CIL is "much higher-level" than Java's byte-code? I
 




 can
 
 think of tail call and polymorphic instructions for all types
 (like push instead of push int), but both are very similar.


 I guess that CIL tree structure can be reconstructed, allowing for
 all optimisations of static compilation. Of course, it does not
 necessarily make sense for JIT/VM, but for static compilation it
 does.
 
 There have been many attempts to compile Java bytecode into native
 code, but the resulting code quality was still not the same as with
  native-compiled pogrammes, because some optimisations on structure
 could not be done.
 
 A Java source->native binary project had better success, AFAIK. I 
 thought CIL would enable the possibility of these optimisations as
 well.
 
 Please don't hold what i say here for an absolute truth, i'm not
 very well informed on these subjects. I have downloaded the whole 
 documentation, but i didn't have time to actually read it. I've got
  exams in a week and after that i'm free and will multiply my
 knowledge and power. And write some useful utility for D.
 


 
 Java source -> native or byte-code -> native aren't that much
 different, only different forms of representing methods and objects.
 AFAIK the largest class of problems in Java come from optimization of
 standard libraries.
 
 
 Check DotGNU too (www.dotgnu.org). It tries to provide a free 
 alternative to every single feature present in .net, while Mono
 is more




 of a
 
 C# compiler/CVM implementation.


 That split again! Qt# on one side, GTK# on the other! Well yes, i'm
 more interested in a VM than in the rest, since every already
 established language would bring its own librarries with it. 
 Example: D. BTW, D is still in a need of a GUI library.


 
 Both runtimes support QT# and GTK#. But DotGNU provides other things,
  like a application server, a authentication server, webservices
 support, etc., that aren't Mono's primary target.
 
 
 Again, which deficiencies are inherent to Java, but not to .net?


 ^^^ Either those, or i have to read more :>
 
 Best regards, Daniel Yokomiso.
 
 "Enlightenment does not divide you, just as the moon does not
 break the water. The depth of the drop is the height of the
 moon." - Dogen


 :>
 
 
 -i.
 


 
 Best regards, Daniel Yokomiso.
 
 "1. Out of clutter, find simplicity. 2. From discord, find harmony. 
 3. In the middle of difficulty lies opportunity." - Albert Einstein
 
 
 --- Outgoing mail is certified Virus Free. Checked by AVG anti-virus
 system (http://www.grisoft.com). Version: 6.0.449 / Virus Database:
 251 - Release Date: 27/1/2003
 
 

"Ken Carpenter" <kencr shaw.ca> writes:

"Ilya Minkov" <midiclub 8ung.at> wrote in message
news:b1ot3f$1me2$1 digitaldaemon.com...
 Hi.

 It's really no sense complaining that the IL doesn't provide some ready
 primitive that would be good for your language, since normally you would
 be compiling into assembly and run into similar problems, if the IL
 allows a low level representation. But if it doesn't, you're sacked in.


If you only intend to program in the single language in question, then I
would agree with you.

The .NET people, however, seem to have a desire to program in several
languages at the same time.  If some of your languages treat the IL as a
sort of instruction set and others treat map their language features to it
one-to-one, then you will get a so-called "impedance mismatch" between the
languages.

Using MI in Eiffel#, for instance, requires a C# user to know additional
class names and to understand how the Eiffel# compiler "tricks" the system
into providing MI when it wasn't originally intended to.

Whenever you try to add some new feature in a way not originally intended
you are asking for trouble.  Sometimes the trouble is worth it.


Ken Carpenter

Ilya Minkov <midiclub 8ung.at> writes:

Wouldn't multiple inheritance as a generic feature of a language 
infrastructure force all the languages to support it? Besides, i haven't 
taken a deeper look at Eiffel yet (i should), their MI is said to be 
somehow "different" from C++.


Ken Carpenter wrote:
 "Ilya Minkov" <midiclub 8ung.at> wrote in message
 news:b1ot3f$1me2$1 digitaldaemon.com...
 
Hi.

It's really no sense complaining that the IL doesn't provide some ready
primitive that would be good for your language, since normally you would
be compiling into assembly and run into similar problems, if the IL
allows a low level representation. But if it doesn't, you're sacked in.


 
 If you only intend to program in the single language in question, then I
 would agree with you.
 
 The .NET people, however, seem to have a desire to program in several
 languages at the same time.  If some of your languages treat the IL as a
 sort of instruction set and others treat map their language features to it
 one-to-one, then you will get a so-called "impedance mismatch" between the
 languages.
 
 Using MI in Eiffel#, for instance, requires a C# user to know additional
 class names and to understand how the Eiffel# compiler "tricks" the system
 into providing MI when it wasn't originally intended to.
 
 Whenever you try to add some new feature in a way not originally intended
 you are asking for trouble.  Sometimes the trouble is worth it.
 
 
 Ken Carpenter

Daniel Yokomiso <Daniel_member pathlink.com> writes:

In article <b2e59p$4cd$1 digitaldaemon.com>, Ilya Minkov says...
Wouldn't multiple inheritance as a generic feature of a language 
infrastructure force all the languages to support it? Besides, i haven't 
taken a deeper look at Eiffel yet (i should), their MI is said to be 
somehow "different" from C++.


It's like saying that a infrastructure supporting arbitrary jumps and memory
access would force all languages using this architecture to support it. A
language with SI running on a MI environment could just require their users to
be explicit in type inheritance vs. code inheritance, but use a single mechanism
at runtime. Each model can simulate the other, but when you need to go through
tricks to implement a feature it probably'll be language specific.

Ken Carpenter wrote:
 "Ilya Minkov" <midiclub 8ung.at> wrote in message
 news:b1ot3f$1me2$1 digitaldaemon.com...
 
Hi.

It's really no sense complaining that the IL doesn't provide some ready
primitive that would be good for your language, since normally you would
be compiling into assembly and run into similar problems, if the IL
allows a low level representation. But if it doesn't, you're sacked in.


 
 If you only intend to program in the single language in question, then I
 would agree with you.
 
 The .NET people, however, seem to have a desire to program in several
 languages at the same time.  If some of your languages treat the IL as a
 sort of instruction set and others treat map their language features to it
 one-to-one, then you will get a so-called "impedance mismatch" between the
 languages.
 
 Using MI in Eiffel#, for instance, requires a C# user to know additional
 class names and to understand how the Eiffel# compiler "tricks" the system
 into providing MI when it wasn't originally intended to.
 
 Whenever you try to add some new feature in a way not originally intended
 you are asking for trouble.  Sometimes the trouble is worth it.
 
 
 Ken Carpenter

"Ken Carpenter" <kencr shaw.ca> writes:

"Daniel Yokomiso" <daniel_yokomiso yahoo.com.br> wrote in message
news:b1ke3d$1jd3$1 digitaldaemon.com...
 But most of these come from the C-like languages, so it's not
 like they are really providing a full range of languages. Eiffel# was
 crippled to be able to compile cleanly to CIL.


When they first brought Eiffel to .NET, it was, indeed,
crippled.  The current version, however, supports all
features of Eiffel, including mulitple inheritance.

Here's a link describing how multiple inheritance works
with Eiffel# under .NET.

  http://www.devx.com/codemag/Article/8500


Ken Carpenter

Daniel Yokomiso <Daniel_member pathlink.com> writes:

In article <b1np1e$uq3$1 digitaldaemon.com>, Ken Carpenter says...
"Daniel Yokomiso" <daniel_yokomiso yahoo.com.br> wrote in message
news:b1ke3d$1jd3$1 digitaldaemon.com...
 But most of these come from the C-like languages, so it's not
 like they are really providing a full range of languages. Eiffel# was
 crippled to be able to compile cleanly to CIL.


When they first brought Eiffel to .NET, it was, indeed,
crippled.  The current version, however, supports all
features of Eiffel, including mulitple inheritance.

Here's a link describing how multiple inheritance works
with Eiffel# under .NET.

  http://www.devx.com/codemag/Article/8500


Ken Carpenter


The major problem is that CIL doesn't provide multiple-inheritance or
genericity, so if I'm writing a class in Python# (just an example), and I want
to multiple inherit from two Eiffel for .net classes, I'll be in trouble. But If
I want to Use VB to inherit from C#, no problem. This is what I mean by
crippled.

"Ken Carpenter" <kencr shaw.ca> writes:

"Daniel Yokomiso" <Daniel_member pathlink.com> wrote in message
news:b1po0m$271h$1 digitaldaemon.com...
 The major problem is that CIL doesn't provide multiple-inheritance or
 genericity, so if I'm writing a class in Python# (just an example), and I


 to multiple inherit from two Eiffel for .net classes, I'll be in trouble.


 I want to Use VB to inherit from C#, no problem. This is what I mean by
 crippled.


I would hardly fault Eiffel# for the limitations of CIL, Python#, VB and C#.
It is certainly not Eiffel# that is crippled in that respect; it's all the
other .NET languages!


Ken Carpenter

Daniel Yokomiso <Daniel_member pathlink.com> writes:

In article <b2d150$2i6b$1 digitaldaemon.com>, Ken Carpenter says...
"Daniel Yokomiso" <Daniel_member pathlink.com> wrote in message
news:b1po0m$271h$1 digitaldaemon.com...
 The major problem is that CIL doesn't provide multiple-inheritance or
 genericity, so if I'm writing a class in Python# (just an example), and I


 to multiple inherit from two Eiffel for .net classes, I'll be in trouble.


 I want to Use VB to inherit from C#, no problem. This is what I mean by
 crippled.


I would hardly fault Eiffel# for the limitations of CIL, Python#, VB and C#.
It is certainly not Eiffel# that is crippled in that respect; it's all the
other .NET languages!


Ken Carpenter


I'm not blaming Eiffel# or trying to criticize it. If you read the thread again,
you'll see that my point is: Eiffel had to be crippled to compile cleanly into
CIL. IIRC I didn't said that Eiffel# was crippled (it being crap and the other
languages are good stuff) but it had to be crippled (other languages are less
comprehensive and Eiffel# had to give away some features).

"Ken Carpenter" <kencr shaw.ca> writes:

"Daniel Yokomiso" <Daniel_member pathlink.com> wrote in message
news:b2ekno$dup$1 digitaldaemon.com...
 I'm not blaming Eiffel# or trying to criticize it. If you read the thread


 you'll see that my point is: Eiffel had to be crippled to compile cleanly


 CIL. IIRC I didn't said that Eiffel# was crippled (it being crap and the


 languages are good stuff) but it had to be crippled (other languages are


 comprehensive and Eiffel# had to give away some features).


Your point was quite clear.  I simply pointed out that it was incorrect.

When Eiffel# was first released, there were some features missing since they
were harder to fit into the CIL model.  The current version of Eiffel#,
however, is a full implementation of Eiffel including MI and genericity.

You are certainly correct that CIL does not directly support MI, genericity
or DbC (most unfortunate ommissions IMO) , but again, that in no way
reflects on Eiffel#, so including it in your example of a Python# class is a
red herring.  If you want to write a Python# class that inherits from
multiple .NET classes you're in trouble regardless of which other .NET
language the base classes were developed in.

Anyway, since this has nothing to do with distributed compilation or D, I
will not say anymore on the subject. ;-)



Ken Carpenter

"Walter" <walter digitalmars.com> writes:

"Robert Medeiros" <robert.medeiros utoronto.ca> wrote in message
news:b1ed6q$gi1$1 digitaldaemon.com...
 Another thought for a potential feature of D -- support for distributed
 compilation as a standardized part of the compiler, which could possibly
 have a daemon (D-mon?) mode letting it run as a background


 or a distinct but included utility that handles networking issues and
 forwards information to each local instance of the compiler. Some
 interesting software that works with GCC: http://distcc.samba.org/.


DMC++ offers "netbuild" which distributes compiles across machines attached
to a network. This was a good idea 10 years ago when machines were slow, but
the computers are so much faster now that any speed gain from separate
compilation will be more than offset by the vastly slower network traffic.

DMC is also the fastest compiler available.

DMD is based on the same technology, but the D language is also designed to
be much faster to compile than C is. The end result is I don't see a need
for a D netbuild.

Ilya Minkov <midiclub 8ung.at> writes:

My point. ;)

Walter wrote:
 "Robert Medeiros" <robert.medeiros utoronto.ca> wrote in message
 news:b1ed6q$gi1$1 digitaldaemon.com...
 
Another thought for a potential feature of D -- support for distributed
compilation as a standardized part of the compiler, which could possibly
have a daemon (D-mon?) mode letting it run as a background


 process/service,
 
or a distinct but included utility that handles networking issues and
forwards information to each local instance of the compiler. Some
interesting software that works with GCC: http://distcc.samba.org/.


 
 DMC++ offers "netbuild" which distributes compiles across machines attached
 to a network. This was a good idea 10 years ago when machines were slow, but
 the computers are so much faster now that any speed gain from separate
 compilation will be more than offset by the vastly slower network traffic.
 
 DMC is also the fastest compiler available.
 
 DMD is based on the same technology, but the D language is also designed to
 be much faster to compile than C is. The end result is I don't see a need
 for a D netbuild.

"Walter" <walter digitalmars.com> writes:

"Ilya Minkov" <midiclub 8ung.at> wrote in message
news:b1f4at$1dn8$1 digitaldaemon.com...
 My point. ;)


You're right.