Tcl and .Net?
Eckhard Lehmann
I just stumbled about http://www.mono-project.com/Languages. It
attracted attention to me, that Tcl is missing on this list... :-(.
Has anyone investigated already in Tcl/.Net integration like "IronTcl",
a Tcl->.Net compiler or such?
Eckhard
Donal K. Fellows
> Has anyone investigated already in Tcl/.Net integration like "IronTcl",
> a Tcl->.Net compiler or such?
Not that I'm aware of offhand; what benefit would there be? We can
already talk COM with the right extension to help...
Donal.
Robert Hicks
Why did IronPython come into being? I think mostly you would get all
of the .NET stuff (forms, etc.), program in Tcl and compile down to ILC
or whatever they term it.
Robert
Eckhard Lehmann
Donal K. Fellows wrote:
> > Not that I'm aware of offhand; what benefit would there be? We can
> > already talk COM with the right extension to help...
That's not the same - When Tcl is integrated in and can be compiled for
.Net, you can
- use every component and program that is written for .Net in whatever
.Net language (C++, C#, Java, Python, VB.Net etc... there are lots of
programmers who develop cool stuff)
- write components in Tcl for .Net, that every other .Net developer can
use - by compiling Tcl modules to CIL assemblies. It would be great to
use Tcl on .Net projects (and maybe some more people get interrested in
Tcl if they can use it as .Net language ;-)
That is much, and would be helpful for many people.
Robert Hicks wrote:
> Why did IronPython come into being?
Because some smart Python developers want to have Python on .Net and
Mono ;-).
Eckhard
Don Porter
> That's not the same - When Tcl is integrated in and can be compiled for
> .Net, you can
>
> - use every component and program that is written for .Net in whatever
> .Net language (C++, C#, Java, Python, VB.Net etc... there are lots of
> programmers who develop cool stuff)
Can you spell out in more detail just what that would mean to "use .Net
components" at the Tcl level? What commands would exist? How would
they come into existence?
--
| Don Porter Mathematical and Computational Sciences Division |
| donald...@nist.gov Information Technology Laboratory |
| http://math.nist.gov/~DPorter/ NIST |
|______________________________________________________________________|
Eckhard Lehmann
Don Porter wrote:
> Can you spell out in more detail just what that would mean to "use .Net
> components" at the Tcl level? What commands would exist? How would
> they come into existence?
That's just as using library functions and classes: If you have a
package of Tcl or C code with some useful procs and (Itcl/Snit/XOtcl)
classes, you do [package require mypack]. Then you have the procs and
classes for usage in your script.
With .Net it is the same, but the package is not necessarily written in
Tcl or C, it can be written in *any* .Net language. These are languages
that can be compiled to CIL, which is the basis language for the .Net
platform (CLR). The package is then called "assembly".
Some information and links on CIL/CLI/CLR etc:
http://en.wikipedia.org/wiki/Common_Language_Infrastructure and
http://en.wikipedia.org/wiki/Common_Language_Runtime
So back to the example, you do [package require mypack] and don't care
about whether mypack is written in Python, Java, C#, etc... just
whether it is present as .Net assembly. Then you can use whatever
mypack provides, in terms of procedures, classes etc. That's the idea.
The other way: You write a package "mypack" in Tcl and compile it to
CIL for use within .Net. An IronPython developer wants to use it and
just needs to do "import mypack" or "from mypack import ..." in his
code. Then he can use whatever mypack provides.
This is possible with the CLR infrastructure. Everything that is
necessary is, that Tcl can be compiled to CIL (Common Intermediate
Language).
Eckhard
Don Porter
> Don Porter wrote:
>
>> Can you spell out in more detail just what that would mean to "use .Net
>> components" at the Tcl level? What commands would exist? How would
>> they come into existence?
>
> That's just as using library functions and classes: If you have a
> package of Tcl or C code with some useful procs and (Itcl/Snit/XOtcl)
> classes, you do [package require mypack].
Ok, so somehow you want existing units of code for the .Net environment
to make themselves known to some variant of Tcl as Tcl packages.
The [package ifneeded] command is used to make a package known to Tcl.
It registers a script that provides the package. It also requires a
package name and version. How would these bits of data -- package name,
package version, and provide script -- be discovered for some arbitrary
existing unit of code written for .Net in some unknown language?
> Then you have the procs and
> classes for usage in your script.
If the unit of code written for .Net was not originally written in Tcl,
it doesn't offer "procs". It apparently offers some CLR interface. How
does one construct Tcl commands to connect to an arbitrary example of
such an interface? How should a command name and syntax be generated to
be suitable for this task?
To what extent can one describe the task to be accomplished as one of
inventing "SWIG for .Net" ? For that matter, does SWIG already do .Net?
> This is possible with the CLR infrastructure. Everything that is
> necessary is, that Tcl can be compiled to CIL (Common Intermediate
> Language).
Years ago, some people (not me) looked over CLR and their assessment at
the time was that it was an uncomfortable fit for Tcl at best. The
concepts just don't map cleanly.
Neil Madden
...
> To what extent can one describe the task to be accomplished as one of
> inventing "SWIG for .Net" ? For that matter, does SWIG already do .Net?
I can't talk for .NET/C# but for Java the TclJava package uses Java's
built-in reflection capabilities so that you can access any Java
class/object automatically, without having to generate a specific
wrapper interface. Examples look something like:
% set a [java::new java.lang.String "Hello, World!"]
java0x1
% $a length
13
% $a substring 0 5
Hello
I imagine you could do this for .NET/C# too. http://wiki.tcl.tk/.net
hints that .NET objects are in fact just fancy COM objects, so Tcl can
probably already do this via some COM extension.
That page also mentions Jacl.NET, which might be nearer to what the
original poster was after (http://wiki.tcl.tk/13178).
-- Neil
Robert Heller
SWIG in some sense does something similar to .NET -- it interfaces some
compiled code (read: code callable from C/C++, which includes C, C++,
FORTRAN, etc.) to one of *several* scripting languaces (Tcl, Python,
Perl, etc.).
I guess if the CIL/CLR 'assembly' thingy can be converted to a shared
library object (.so/.dll/whatever), then you could create a .i file for
it, (probably from a .h file) and use SWIG to create a piece of C or
C++ code to interface between Tcl and the CIL/CLR 'assembly' thingy.
How one would use Tcl code from the .NET interface is more problematical
(at least it seems to me). What is 'CIL'? Is this some Microsoft
invented bytecode of some sort?
And does the .NET business really exist outside of MS-Windows? Or more
specifically, does anyone actually use it on platforms other them
MS-Windows?
>
> > This is possible with the CLR infrastructure. Everything that is
> > necessary is, that Tcl can be compiled to CIL (Common Intermediate
> > Language).
>
> Years ago, some people (not me) looked over CLR and their assessment at
> the time was that it was an uncomfortable fit for Tcl at best. The
> concepts just don't map cleanly.
>
--
Robert Heller -- 978-544-6933
Deepwoods Software -- Linux Installation and Administration
http://www.deepsoft.com/ -- Web Hosting, with CGI and Database
hel...@deepsoft.com -- Contract Programming: C/C++, Tcl/Tk
Darren New
> Not that I'm aware of offhand; what benefit would there be? We can
> already talk COM with the right extension to help...
Talking COM doesn't let you take advantage of .NET libraries and modules
and exception handling and threading and ....
--
Darren New / San Diego, CA, USA (PST)
"That's pretty. Where is it?"
"Channelwood."
"We should go there on vacation."
"..."
Darren New
> The [package ifneeded] command is used to make a package known to Tcl.
> It registers a script that provides the package. It also requires a
> package name and version. How would these bits of data -- package name,
> package version, and provide script -- be discovered for some arbitrary
> existing unit of code written for .Net in some unknown language?
You would look in the .NET assembly.
> If the unit of code written for .Net was not originally written in Tcl,
> it doesn't offer "procs".
Right. It offers procedures. Or classes containing procedures.
Obviously, there isn't a one-to-one mapping, any more than there's a
one-to-one mapping between Eiffel and FORTRAN, but both of those compile
down to .NET.
> It apparently offers some CLR interface. How
> does one construct Tcl commands to connect to an arbitrary example of
> such an interface?
By using the .NET routines to create such a connection. The runtime
loader takes care of it, basically.
> How should a command name and syntax be generated to
> be suitable for this task?
.NET natively does ints, floats, utf-8 strings, blobs of memory, and
class references, IIRC.
> To what extent can one describe the task to be accomplished as one of
> inventing "SWIG for .Net" ? For that matter, does SWIG already do .Net?
If you only want to invoke .NET routines from Tcl, you might be able to
do it that way. If you want to go the other way, including
cross-language exception handling, you would need to build .NET
assemblies (which you can think of as equivalent to a DLL) from Tcl.
> Years ago, some people (not me) looked over CLR and their assessment at
> the time was that it was an uncomfortable fit for Tcl at best. The
> concepts just don't map cleanly.
Lots of languages have concepts that don't map cleanly to .NET, but they
got mapped anyway. Tcl would probably have to change, possibly in
non-compatible ways with what we have now. COM is also an uncomfortable
fit for Tcl. :-)
Alternately, if Tcl got reimplemented from scratch in a .NET language
(like C#), adding support for invoking other .NET procs would probably
be no harder than using tcom.
Which is not to argue that Tcl needs it, or that it should be done. Just
discussing the facts.
Darren New
> I guess if the CIL/CLR 'assembly' thingy can be converted to a shared
> library object (.so/.dll/whatever), then you could create a .i file for
> it, (probably from a .h file) and use SWIG to create a piece of C or
> C++ code to interface between Tcl and the CIL/CLR 'assembly' thingy.
It's a little more complicated than that, methinks. There's a whole
issue of environment management (which modules are loaded, what they're
allowed to access, when they're allowed to run, etc) and exception
handling (since exceptions propagate cross-language and cross-module in
.NET).
> How one would use Tcl code from the .NET interface is more problematical
> (at least it seems to me). What is 'CIL'? Is this some Microsoft
> invented bytecode of some sort?
Common Intermediate Language. Yes, it's the MS bytecode format.
> And does the .NET business really exist outside of MS-Windows? Or more
> specifically, does anyone actually use it on platforms other them
> MS-Windows?
Yes. Check out Mono on Linux.
Eckhard Lehmann
Darren New schrieb:
> Lots of languages have concepts that don't map cleanly to .NET, but they
> got mapped anyway. Tcl would probably have to change, possibly in
> non-compatible ways with what we have now.
To be more concrete, Tcl has to be reimplemented on Top of .Net.
Including a bytecode compiler that generates CIL (Common Intermediate
Language). The [package] commands of this Tcl implementation need to be
aware of .Net assemblies and the way this is handled by the CLR
platform (Common Language Runtime). Other things as well, probably...
It's like Jacl for .Net, including the CIL compiler. I believe Mo
DeJong has even implemented a Tcl->JVM compiler already.
Hang on, there is already TclCSharp:
http://sourceforge.net/projects/tclcsharp/. This could be a starting
point...
Eckhard
Eckhard Lehmann
Robert Heller schrieb:
> > To what extent can one describe the task to be accomplished as one of
> > inventing "SWIG for .Net" ? For that matter, does SWIG already do .Net?
>
> SWIG in some sense does something similar to .NET -- it interfaces some
> compiled code (read: code callable from C/C++, which includes C, C++,
> FORTRAN, etc.) to one of *several* scripting languaces (Tcl, Python,
> Perl, etc.).
That is not "in some sense similar to .Net" - it is in *no* sense
similar. SWIG creates _wrappers_ around C/C++ etc, which results in
bindings for the interpreted language (Tcl commands, PyObjects etc.).
.Net in contrast is the runtime where compiled CIL languages run, side
by side with other compiled CIL languages. Tcl could/should be one of
these CIL languages.
> And does the .NET business really exist outside of MS-Windows? Or more
> specifically, does anyone actually use it on platforms other them
> MS-Windows?
Yes, it exists and is used on other platforms. In fact it runs very
well and is pushed by several vendors. One implementation is Mono
(www.mono-project.com), and there are others. The CLR thingy which is
the basis of .Net and Mono is an ECMA/ISO standard.
Tcl should not oversleep the signs of time...
Eckhard
Don Porter
> To be more concrete, Tcl has to be reimplemented on Top of .Net.
Ok, thanks for clarifying that. You're talking about a new project, not
about steering development of the existing C-coded Tcl in a new direction.
Darren New
> Ok, thanks for clarifying that. You're talking about a new project, not
> about steering development of the existing C-coded Tcl in a new direction.
Well, there's also "managed C++" that manages to merge both C++ and .NET
functionality in one codebase. The idea that .NET support could be
slathered on top of Tcl shouldn't be ruled out by those interested
without deeper consideration, methinks.
Don Porter
>> Ok, thanks for clarifying that. You're talking about a new project,
>> not about steering development of the existing C-coded Tcl in a new
>> direction.
Darren New wrote:
> Well, there's also "managed C++" that manages to merge both C++ and .NET
> functionality in one codebase. The idea that .NET support could be
> slathered on top of Tcl shouldn't be ruled out by those interested
> without deeper consideration, methinks.
The only thing I've ruled out is the notion that I was being asked to do
something. I'm happy to let anyone pursue this as they wish.
Eckhard Lehmann
Don Porter schrieb:
> The only thing I've ruled out is the notion that I was being asked to do
> something. I'm happy to let anyone pursue this as they wish.
Not many people are confident with how to build a Tcl interpreter or
compiler... I for myself couldn't do it without investing *much* time
(that I don't have) and learning many new things. The latter wouldn't
be a problem, but the time argument is...
Eckhard
miguel sofer
Interpreter and compiler ... and library, right?
Interpreter and compiler is "just" Tcl.n and quite a bit of
infrastructure for the builtin commands (variables, traces, namespaces,
commands, proc, ...). That does not take you very far - to see how far,
you can try
namespace delete ::
in a tclsh.
So you also need all the builtin commands. Some hook directly onto the
first part and would be "just a matter of co(d|py)ing", many others are
tied into whatever services the infrastructure provides (be that an OS,
.Net, or whatever). Event loop, channels and filesystem access are
examples.
And maybe you'll want the packaging subsystem, and adapt a few standard
packages adapted to the new underpinnings. I guess 'thread' would be a
minimum. Tk would be ... something else.
There is an ongoing project to port Tcl to parrot. I imagine there are
a few lessons to be learned from that, as well as from jacl.
Cheers
Miguel
Eckhard Lehmann
miguel sofer schrieb:
> Interpreter and compiler ... and library, right?
Not sure whether the library also needs to be ported. To some extend,
maybe, but if the compiler is working it should be possible to compile
Tcl packages as assemblies with minimal or no porting efford.
But I have no idea how complicated this compiler is...
> So you also need all the builtin commands.
That's probably right. Important are the basic control structures...
> Tk would be ... something else.
Yes - I would even leave Tk out of scope for the moment. The
"Windows.Forms" assembly could be used in the short term...
> There is an ongoing project to port Tcl to parrot. I imagine there are
> a few lessons to be learned from that, as well as from jacl.
Right, absolutely...
Eckhard
s-imai
I'm learning C++/CLI of .NET framework.
C++/CLI can mix the managed code and the unmanaged code. (C# etc can't)
I'd like to test a C++/CLI class library with Tcltest.
I already tried to use SWIG and C++/CLI.
but SWIG does not support the C++/CLI managed class. and I heard SWIG is
not going to support C++/CLI.
so I've found C++/TCL. It's maybe like a SWIG?
http://cpptcl.sourceforge.net/
now I hope a best solution.
----
Satoshi Imai
Eckhard Lehmann
s-imai wrote:
> I'd like to test a C++/CLI class library with Tcltest.
That's for sure a concrete use case for Tcl on .Net.
Eckhard
Donal K. Fellows
> it should be possible to compile
Good joke that. :-)
I don't deny in any way that it is possible to do it. I'm really
uncertain about whether it is possible to do it in a reasonable amount
of effort, and a large part of that would be in the porting of library
commands and other basic packages. There are *lots* of tricky bits
ahead. In essence, by the point when we would get to where your
statement would be true, it would be merely because such a vast amount
of effort had already been sunk into the project that all the tricky
problems had already been solved.
If someone wants to do a small proof-of-concept, that would make a
wonderful topic for a Tcl Conference paper. :-)
Donal.
Uwe Klein
out to the CLR side?
When i read across the info i find for MS .NET, mono and stuff i get the
impression this is a DysonSphere made of FlyPaper to bog down any OSS effort
valiant ( and dumb) enough to tackle or even touch it.
<wikipedia on dotgnu>
the Mono Project, is to provide 100% compatible class libraries for both the CLS specification and
with the class library currently released by Microsoft for their commercial version of .NET, which
the DotGNU project claims does not currently fully comply with the CLS specification published by ECMA.
<end>
MS .NET seems to support X86++. mono wants to support nearly every platform/architecture.
uwe
Neil Madden
The porting effort has been done once in Jacl, and someone has already
ported Jacl to .NET (http://wiki.tcl.tk/jacl.net). I gather from their
site that they simply compiled Jacl using the J#.NET compiler and made a
few tweaks.
-- Neil
Eckhard Lehmann
Donal K. Fellows wrote:
> Eckhard Lehmann wrote:
> > it should be possible to compile
> > Tcl packages as assemblies with minimal or no porting effor[t].
>
> Good joke that. :-)
Actually I didn't mean it as a joke ;-).
> I don't deny in any way that it is possible to do it. I'm really
> uncertain about whether it is possible to do it in a reasonable amount
> of effort, and a large part of that would be in the porting of library
> commands and other basic packages.
Hmm... I try to remember what I believed so far: Tcl code is (in
several steps) translated to machine code by the Tcl interpreter and
executed. That is what it boils down to, right?
So, if this works for the C implementation, I think it should be
possible to make it work for a .Net implementation too. And
furthermore, since a .Net implementation is in fact a virtual machine
(or some sort of "operating system"), it should also be possible to
compile the tokens in a Tcl script to the language, that this virtual
machine understands... ?
I mean, for the normal OS, the target language is [01], binary digits
over several layers of OS functions. On the virtual machine it's CIL,
which is in fact some high level of assembler, also eventually over
several layers of VM functions (Reflection mechanisms etc...).
On the normal OS, each Tcl script is translated to this [01] thing. On
the .Net VM, its the same - just that the target format is CIL (which
seems to be easier to generate than [01], from what I've seen).
Can we rely on this as a basis? I always thought that this part of
computer science is well established in theory and practice...
Eckhard
Eckhard Lehmann
Darren New wrote:
> Well, there's also "managed C++" that manages to merge both C++ and .NET
> functionality in one codebase. The idea that .NET support could be
> slathered on top of Tcl shouldn't be ruled out by those interested
> without deeper consideration, methinks.
Does this mean, it could be possible to compile Tcl for .Net with a
managed C++ compiler and some (major) tweaks?
Eckhard
Neil Madden
...
> Hmm... I try to remember what I believed so far: Tcl code is (in
> several steps) translated to machine code by the Tcl interpreter and
> executed. That is what it boils down to, right?
No. Tcl code is never translated to machine code. It is interpreted.
> So, if this works for the C implementation, I think it should be
> possible to make it work for a .Net implementation too. And
> furthermore, since a .Net implementation is in fact a virtual machine
> (or some sort of "operating system"), it should also be possible to
> compile the tokens in a Tcl script to the language, that this virtual
> machine understands... ?
You would need a Tcl interpreter available as part of the runtime, as
Tcl code frequently calls [eval] or an equivalent. See the TclJava
project, and in particular Jacl and TJC for what would be required of a
port. Then look at Jacl.NET (that I've mentioned twice in this thread
already) and TclCSharp (http://wiki.tcl.tk/13181) for *existing* ports
of Tcl to C#/.NET that build on the Jacl codebase.
> I mean, for the normal OS, the target language is [01], binary digits
> over several layers of OS functions. On the virtual machine it's CIL,
> which is in fact some high level of assembler, also eventually over
> several layers of VM functions (Reflection mechanisms etc...).
> On the normal OS, each Tcl script is translated to this [01] thing. On
> the .Net VM, its the same - just that the target format is CIL (which
> seems to be easier to generate than [01], from what I've seen).
Again, this isn't correct. Tcl code is not translated down to machine
code. The Tcl interpreter is compiled to machine code (or JVM bytecodes
or whatever) and it then interprets Tcl scripts. This is not the same
thing as translating Tcl scripts to machine code.
-- Neil
Donal K. Fellows
> I mean, for the normal OS, the target language is [01], binary digits
> over several layers of OS functions. On the virtual machine it's CIL,
> which is in fact some high level of assembler, also eventually over
> several layers of VM functions (Reflection mechanisms etc...).
> On the normal OS, each Tcl script is translated to this [01] thing. On
> the .Net VM, its the same - just that the target format is CIL (which
> seems to be easier to generate than [01], from what I've seen).
That's not quite accurate. From the perspective of a practical
programmer, targetting the CIL is a bit like targetting any other form
of machine code - you use a compiler to do the work for you and don't
bother about whether there is a VM or a real machine at the end of it
(otherwise you'll end up worrying about virtualization too. :-))
The real work is in making all the bits and pieces in the standard Tcl
library function correctly; it's equivalent to porting to a completely
new platform. (The other source of "real work" is if we were to choose
to use CIL as our own internal bytecode format. This is optional though
and would require much more effort. It's also what would be worth being
the subject of a paper if anyone has a go.)
Donal.
miguel sofer
> Can we rely on this as a basis? I always thought that this part of
> computer science is well established in theory and practice...
We can; I am willing to bet with you that it is possible to have Tcl
run on .Net
By the same token, Tcl can be ported to run on Brainf*ck, Whitespace,
any Turing complete language, even a bare Turing machine.
The important issues that are missing there are:
(a) why do it at all? What are we hoping to obtain?
(b) how much effort is it? How much of it is "rewrite from scratch" or
almost?
(c) is it worth it in general?
(d) is it worth *my* time in particular?
If I may put words into Don's mouth, I think he expressed my own
prejudgements on this:
(a) Don't know, you tell me. Not much to be won in terms of
portability, C really does run just about everywhere already (a lot
more places than .Net, for sure). As to code reuse, is this really so
much better than some IPC alternative? Do we want to enter a license
and patent minefield?
(b) A lot. Almost all of it.
(c) Who am I to tell?
(d) With current info, a resounding NO! There may be some powerful
arguments that I have missed. Or lots of fun and leverageable
education. Or money.
Miguel
Don Porter
> Donal K. Fellows wrote:
>
>> Eckhard Lehmann wrote:
>>> it should be possible to compile
>>> Tcl packages as assemblies with minimal or no porting effor[t].
>> Good joke that. :-)
>
> Actually I didn't mean it as a joke ;-).
>
>> I don't deny in any way that it is possible to do it. I'm really
>> uncertain about whether it is possible to do it in a reasonable amount
>> of effort, and a large part of that would be in the porting of library
>> commands and other basic packages.
>
> Hmm... I try to remember what I believed so far: Tcl code is (in
> several steps) translated to machine code by the Tcl interpreter and
> executed.
Machine code? No.
Many commands in a Tcl script (not all) get compiled to a special
for-Tcl-only bytecode which is made up of primitive instructions
tailor-made to do operations that represent Tcl concepts of evaluating
Tcl commands.
So, a significant part of the task would be to determine and implement
the mapping between the primitives of Tcl bytecode and the primitives
of CIL. This is where the mismatch of concepts [*] makes things
non-trivial. Can it be done? Probably, but it won't be a simple task.
Even solving that task, I don't think fully addresses the questions I
was raising about how non-Tcl units of code would make themselves
(apparently) available as Tcl commands within a common .Net environment.
Perhaps some variation on [::unknown] could do the task?
[*] I've heard it said that CIL supports the language C#, as well as
the language C# wearing various other language masks. C# masquerading
as Python, C# masquerading as Java, etc. Tcl is not C# in some profound
ways distinct from many other languages.
Eckhard Lehmann
miguel sofer wrote:
> The important issues that are missing there are:
>
> (a) why do it at all? What are we hoping to obtain?
More users? More efficient usage of existing code written in other .Net
languages? More future-compliance? Broader range of supported
platforms?
> (b) how much effort is it? How much of it is "rewrite from scratch" or
> almost?
I don't know, not a language specialist...
> (c) is it worth it in general?
Probably yes. The .Net technology has already a big impact and IMO this
will grow in the future. Microsoft did something right this time...
> (d) is it worth *my* time in particular?
Uhm, can't answer that question for you ;-).
> Do we want to enter a license and patent minefield?
It's not that starkly. Sure, there are parts in MS' .Net implementation
which are patented and can not go into other implementations. And MS
.Net will always be a little further than others...
But those parts and arguments *have no affect* on a .Net language.
Everything regarding the pure CLR specification is ISO standardized and
open. Otherwise, people wouldn't put effort into porting Python, LISP
or whatever to .Net.
> (d) With current info, a resounding NO! There may be some powerful
> arguments that I have missed. Or lots of fun and leverageable
> education. Or money.
If someone would pay me fulltime, I would do it for sure, and would be
*really* motivated ;-). That'd apply for everyone here, I asume...
Eckhard
Robert Heller
>
>
> Donal K. Fellows wrote:
>
> > Eckhard Lehmann wrote:
> > > it should be possible to compile
> > > Tcl packages as assemblies with minimal or no porting effor[t].
> >
> > Good joke that. :-)
>
> Actually I didn't mean it as a joke ;-).
>
> > I don't deny in any way that it is possible to do it. I'm really
> > uncertain about whether it is possible to do it in a reasonable amount
> > of effort, and a large part of that would be in the porting of library
> > commands and other basic packages.
>
> Hmm... I try to remember what I believed so far: Tcl code is (in
> several steps) translated to machine code by the Tcl interpreter and
> executed. That is what it boils down to, right?
No. There isn't a Tcl => '[real] machine code' translation (ala C).
The Tcl system translates Tcl code on an as-needed basis ('lazy
compilation') to Tcl's own (unique to Tcl) 'bytecode'. This byte code
is not saved anywhere (external to the running system, at least not
with the normal public releases of Tcl -- I think ActiveState might
have some other hackery that saves the bytecode somehow, but I am not
sure). The bytecode does not access the operating system, it accesses
function in the Tcl interpreter/library itself (functions coded in C and
compiled to native machine code).
>
> So, if this works for the C implementation, I think it should be
> possible to make it work for a .Net implementation too. And
> furthermore, since a .Net implementation is in fact a virtual machine
> (or some sort of "operating system"), it should also be possible to
> compile the tokens in a Tcl script to the language, that this virtual
> machine understands... ?
>
> I mean, for the normal OS, the target language is [01], binary digits
> over several layers of OS functions. On the virtual machine it's CIL,
> which is in fact some high level of assembler, also eventually over
> several layers of VM functions (Reflection mechanisms etc...).
> On the normal OS, each Tcl script is translated to this [01] thing. On
> the .Net VM, its the same - just that the target format is CIL (which
> seems to be easier to generate than [01], from what I've seen).
>
> Can we rely on this as a basis? I always thought that this part of
> computer science is well established in theory and practice...
Yes and no :-). In real life there are often various compromises going
on for various reasons.
>
>
> Eckhard
Eckhard Lehmann
Neil Madden wrote:
> No. Tcl code is never translated to machine code. It is interpreted.
I know... what I mean is that at the end - the tail of the interpreter
- there are instructions for the machine. No matter which steps are in
between or whether these instructions are generated by a compiler at
once or an interpreter on the fly.
Maybe this is somewhat naive, but the interpreter in it's current form
generates a bytecode already. I wonder if it can generate and save CIL
alternatively, as Donal mentioned... if this works right, you have the
Tcl->.Net compiler.
> You would need a Tcl interpreter available as part of the runtime, as
> Tcl code frequently calls [eval] or an equivalent. See the TclJava
> project, and in particular Jacl and TJC for what would be required of a
> port. Then look at Jacl.NET (that I've mentioned twice in this thread
> already) and TclCSharp (http://wiki.tcl.tk/13181) for *existing* ports
> of Tcl to C#/.NET that build on the Jacl codebase.
Yes, I am aware of them. Already said this could be a good starting
point. Just the compiler (for .Net) is missing.
Eckhard
Donal K. Fellows
> I think ActiveState might have some other hackery that saves
> the bytecode somehow, but I am not sure
They do, it's the compiler part of the TDK (and tbcload is the
corresponding bytecode loader). It doesn't speed things up in practice
though. Instead, it's purpose is to obscure commercial code so that
users won't mess with it.
Donal.
Darren New
> Maybe this is somewhat naive, but the interpreter in it's current form
> generates a bytecode already. I wonder if it can generate and save CIL
> alternatively, as Donal mentioned... if this works right, you have the
> Tcl->.Net compiler.
There are issues with this. For one, it's a fair amount of overhead to
create an assembly and load it and launch it, compared to simply
generating bytecodes (due to linking, type checking, etc.). Also, it's a
fair amount of overhead to get rid of an assembly once the code changes,
so things like OO systems that change code each time you instantiate an
instance would have trouble. One might need to distinguish between
things like objects, procs, and binding scripts, depending on how often
they change bytecode now.
On the other hand, ASP.NET (which Mono supports well) seems to have
relatively little trouble with this, so there may be subtleties about
this I don't know.
--
Darren New / San Diego, CA, USA (PST)
Scruffitarianism - Where T-shirt, jeans,
and a three-day beard are "Sunday Best."
Darren New
> non-trivial. Can it be done? Probably, but it won't be a simple task.
It's probably not any harder than using COM. CIL has surprisingly few
primitive types.
> Even solving that task, I don't think fully addresses the questions I
> was raising about how non-Tcl units of code would make themselves
> (apparently) available as Tcl commands within a common .Net environment.
Make a version of a package-like command that loads an assembly and
makes visible its routines and classes and global variables and etc.
> [*] I've heard it said that CIL supports the language C#, as well as
> the language C# wearing various other language masks.
And FORTRAN. And COBOL. And LISP. None of which are C# either.
True, if you want to be able to link to routines in a language that
supports floating-point numbers, your language needs to support
floating-point numbers. But I don't think Tcl is so far away from the
CIL concepts that there isn't any mapping possible.
It also supports dynamic replacement of procedures during runtime (e.g.,
with a flag that says "this routine has been replaced, keep going".)
It's hard to believe Tcl couldn't be ported to the CIL with appropriate
minor changes in semantics. (For example, Tcl's error throwing is
different from what the CIL supports as exceptions, so some work would
have to be done there.)
Basically, this conversation is going to go around in circles until
someone who understands the CIL and the Reflection .NET namespace sits
down and looks at each Tcl command and figures out whether it could be
ported. :-)
--
Darren New / San Diego, CA, USA (PST)
Darren New
> Does this mean, it could be possible to compile Tcl for .Net with a
> managed C++ compiler and some (major) tweaks?
I don't know for sure, but that was certainly my implication. :-)
--
Darren New / San Diego, CA, USA (PST)
Neil Madden
...
>
> Yes, I am aware of them. Already said this could be a good starting
> point. Just the compiler (for .Net) is missing.
Right, but the compiler is a nice-to-have, rather than an essential
part. Given the large amount of effort needed to create such a thing, is
it really worth it? If you just want to have Tcl running on .NET, then
it looks like the solution is already there. A compiler would be mostly
a performance optimisation.
-- Neil
Eckhard Lehmann
Neil Madden schrieb:
> Right, but the compiler is a nice-to-have, rather than an essential
> part. Given the large amount of effort needed to create such a thing, is
> it really worth it? If you just want to have Tcl running on .NET, then
> it looks like the solution is already there. A compiler would be mostly
> a performance optimisation.
It is not just a performance optimisation.
The compiler would enable to write .Net components (assemblies,
packages ...) in Tcl, usable by other (non-Tcl) .Net developers. This
would greatly enhance the acceptance and benefit of Tcl on .Net.
Eckhard
Neil Madden
You can already interoperate with other languages, as they can call
interp.eval(...) or whatever. If that's too clunky, then you can write a
wrapper facade class in C# or some other language, that translates
methods calls into evals in the Tcl interpreter. You can probably even
write a general facade-generator or use C#'s reflection capabilities to
dynamically generate such wrappers. Certainly this would be much less
work than developing a Tcl -> .NET compiler.
-- Neil
Donal K. Fellows
> The compiler would enable to write .Net components (assemblies,
> packages ...) in Tcl, usable by other (non-Tcl) .Net developers. This
> would greatly enhance the acceptance and benefit of Tcl on .Net.
It's obvious to me that you really want to write Tcl.Net. That's no
problem; please be my guest! Your first goal is probably to get enough
done to be able to run test suites written using tcltest (perhaps with
the -singleproc option though; omitting dealing with [exec] would be a
smart move for now) so that you can start to compare your
implementation against Tcl's own test suite.
Donal (I know I've not got time to help...)