discuss-gnustep
[Top][All Lists]
Advanced

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Re: Just Curious... Why not an Obj-C runtime in the Dot NET or Dot GNU C


From: Quentin Mathé
Subject: Re: Just Curious... Why not an Obj-C runtime in the Dot NET or Dot GNU Common Language Runtimes?
Date: Fri, 25 Feb 2005 01:15:11 +0100

Le 24 févr. 05, à 16:17, Helge Hess a écrit :

On Feb 24, 2005, at 12:45, Quentin Mathé wrote:
… but .Net CLR supports Smalltalk. Do you think it doesn't support the whole Smalltalk features set ?

I don't know the .NET Smalltalk (do you have a pointer?),

http://msdn.microsoft.com/netframework/technologyinfo/overview/

where it is written :
Language compilers that support the .NET Framework have been announced for the following programming languages:
Supported programming languages
APL, Fortran, Pascal, C++, Haskell, Perl, C#, Java Language, Python, COBOL, Microsoft JScript®, RPG, Component Pascal, Mercury, Scheme, Curriculum, Mondrian, SmallTalk, Eiffel, Oberon, Standard ML, Forth, Oz, Microsoft Visual Basic®

http://www.refactory.com/Software/SharpSmalltalk/
http://www.smallscript.net/

but of course you can build another runtime _on top_ of the CLR object runtime. In this case you loose all the interoperability features though. The point of CLR is that you can reuse a class written in C# in VB and C++ (and other "true" CLR languages) without any wrapping.

Right.
When you read the previous links, we can observe there are workarounds for issues like metaclasses.

Two major things are missing in CLR:
- the ability to patch existing classes (categories)
- the "hook" to catch unimplemented methods (-forward::)
Posing of course also doesn't work. The worst problem for me is actually the missing categories. I have some ideas on how that could be worked around (by on-the-fly generation of new classes), but all that is quite hackish and wouldn't fit perfectly well into the CLR object system.

yep, there are many problems, to take an another example there are doing on the fly class generation for Smalltalk blocks, but that's doesn't work perfectly.


For Mono CLR, the things are a bit different, because it is still lacking support for dynamic languages like Python etc. (Smalltalk, Objective-C are dynamic languages too, then no luck currently).

Could you elaborate? What exactly is missing in Mono from an CLR point of view?

I don't know precisely, but within this web page http://www.mono-project.com/contributing/todo.html in the todo list, you have the following task :
Compilers for dynamic languages
Write a IL compiler and runtime support for dynamic languages like Python (Done: see IronPython), Perl, Ruby, PHP.
Medium-hard (thesis subject)
6-12 months
not assigned

May be it's time to write a really usable CLR unlike .Net/Mono ;-)

Quentin

--
Quentin Mathé
qmathe@club-internet.fr





reply via email to

[Prev in Thread] Current Thread [Next in Thread]