Re: [Mono-list] Mixing languages within
see CodeDOM in the MSDN/.NET documentation, might give you some ideas
e.g. have in C# special comments embedded with your HSPL language or
something like that (in C++ its maybe easier since the preprocessor allow
you to do that without using comments, but some HSPL(hsplCommandString)
macro). Then have C# compiler emit CodeDOM, then patch that CodeDOM tree
where needed with the code generated from your HSPL commands (e.g. if they
were comments you'd look at the tree for all comments and if they were
special you'd remove them and add the corresponding code from your HSPL
compiler)
or something like that...
cheers,
George
-
George Birbilis ([EMAIL PROTECTED])
MS MVP J#
http://www.kagi.com/birbilis
--
Of course, If you want to get really nuts :P,
you should probably be able to create a compiler that has plugins from
different languages and do something like this
namespace {
language C-Sharp {
}
language VisualBasic {
}
}
I mean... but then you would be really creating a new language anyway...
Inless you could find out a way to pass the specific language functions to
the appropriate compiler...
I mean thats if you just want to be really crazy!!! :)
I don't know what the .Net standard would have to
say about this
I would like to mix C# and (say) Hypothetical String
Processing Language
(HSPL) and (say) Hypothetical Data Processing
Language (HDPL) within the
same source code file. e.g.
Is this a crazy idea?
I think so. I'm not sure what someone else might say,
but my problem with this is that every compiler would
have to know about every other compiler and there
would have to be some standard for how to shift around
from one compiler to the next and pass type / symbol
information and IL code around as well.
I don't think it's feasible, and I'm pretty sure it's
not even close to being supported by the standard. I
doubt it's prohibited directly by the standard
(because, after all, you could argue that this
wouldn't be C#, but some variant of C# and so wouldn't
be bound by the standard at all), but I surely
wouldn't want to try to build the compiler for it.
___
Mono-list maillist - [EMAIL PROTECTED]
http://lists.ximian.com/mailman/listinfo/mono-list
Re: [Mono-list] Mixing languages within
Of course, If you want to get really nuts :P,
you should probably be able to create a compiler that has plugins from
different languages and do something like this
namespace {
language C-Sharp {
}
language VisualBasic {
}
}
I mean... but then you would be really creating a new language anyway...
Inless you could find out a way to pass the specific language functions to
the appropriate compiler...
I mean thats if you just want to be really crazy!!! :)
>
>> I don't know what the .Net standard would have to
>> say about this
>>
>> I would like to mix C# and (say) Hypothetical String
>> Processing Language
>> (HSPL) and (say) Hypothetical Data Processing
>> Language (HDPL) within the
>> same source code file. e.g.
>>
>
>> Is this a crazy idea?
>>
>
> I think so. I'm not sure what someone else might say,
> but my problem with this is that every compiler would
> have to know about every other compiler and there
> would have to be some standard for how to shift around
> from one compiler to the next and pass type / symbol
> information and IL code around as well.
>
> I don't think it's feasible, and I'm pretty sure it's
> not even close to being supported by the standard. I
> doubt it's prohibited directly by the standard
> (because, after all, you could argue that this
> wouldn't be C#, but some variant of C# and so wouldn't
> be bound by the standard at all), but I surely
> wouldn't want to try to build the compiler for it.
>
> Kelly
> ___
> Mono-list maillist - [EMAIL PROTECTED]
> http://lists.ximian.com/mailman/listinfo/mono-list
>
___
Mono-list maillist - [EMAIL PROTECTED]
http://lists.ximian.com/mailman/listinfo/mono-list
Re: [Mono-list] Mixing languages within
Hi What i've experenced this far with multilanguage development with the current possibiliies (cts, at assembly level) was positive. I used different projects in VS.NET. Some in c# some in vb and it was even possible to step through this code when debugging. So in my opinion it's easier to provide such IDE functions than change the compiler. My 2 cents ___ Gesendet von Yahoo! Mail - Jetzt mit 250MB Speicher kostenlos - Hier anmelden: http://mail.yahoo.de ___ Mono-list maillist - [EMAIL PROTECTED] http://lists.ximian.com/mailman/listinfo/mono-list
Re: [Mono-list] Mixing languages within
On Fri, 2004-12-10 at 14:30 +, Colin JN Breame wrote: > Jonathan Gilbert wrote: > > >Not exactly right. You're leaving out an intermediate step: an individual > >source code file can be compiled to a .netmodule, and .netmodules compiled > >with different languages can be mixed within a single assembly. > > Does this mean that a partial class (or part of a class) can be compiled > to a .netmodule? or do .netmodules have to contain a complete class? A partial class is a language feature, not an IL feature. The language compiler is responsible for merging all partial classes together into a single IL class. Consequently, you can't have part of a partial class in C# and another part in VB.NET. All parts must be in the same language. (Note: the parts must be in the same language *at compile time*. XAML uses partial classes where one of the parts is generated from an XML file, but the XAML engine is responsible for converting the XML into the appropriate language before they're compiled together.) - Jon ___ Mono-list maillist - [EMAIL PROTECTED] http://lists.ximian.com/mailman/listinfo/mono-list
Re: [Mono-list] Mixing languages within
Hello,
> I don't know what the .Net standard would have to say about this
>
> I would like to mix C# and (say) Hypothetical String Processing Language
> (HSPL) and (say) Hypothetical Data Processing Language (HDPL) within the
> same source code file. e.g.
>
> class mixed {
> string normal_c_sharp_method() {
>string ret = null;
>
>
> some HSPL...modifying ret
>
>
>
> some HDPL...modifying ret
>
>
>return ret
> }
> }
>
> Is this a crazy idea?
This can be either very simple or very hard depending on the level of
integration that you want to achieve.
On the simple end of the spectrum you might have a pre-processor that
handles the regions of HSPL and produces a new C# file that is later
compiled by the C# compiler.
On the other end of the spectrum, you might actually want to consider
extending the Mono C# compiler and instead of doing a simplistic
macro-processing job, you could probably provide integration between the
two worlds.
Miguel.
___
Mono-list maillist - [EMAIL PROTECTED]
http://lists.ximian.com/mailman/listinfo/mono-list
RE: [Mono-list] Mixing languages within
At 09:58 AM 10/12/2004 -0800, Richard Norman wrote: Jonathan, Actually this is part of the proposed spec (partial classes). As I see it from the latest information on MSDN. (http://msdn.microsoft.com/vcsharp/team/language/default.aspx) They have a PDF file with some of the proposed information (http://download.microsoft.com/download/8/1/6/81682478-4018-48fe-9e5e-f87a44af3db9/Standard.pdf) I don't know if there is a newer release of this document, but it seems that "partial" is planed to be part of the spec. Yes, of course, part of the *language* specification. That does not necessarily mean, though, that its implementation is based on a corresponding *framework* feature. To be honest, I haven't done the research, but it seems likely to me that .NET itself does not allow just part of a class to be present in a .netmodule. I could be wrong here, but on that assumption, I meant that the compiler would have to "see" all parts of the class in a single invocation. If I am right, then for a class split across file1.cs and file2.cs, "csc /target:module file1.cs" and "csc /target:module file2.cs" individually would fail, but "csc /target:module file1.cs file2.cs" would succeed. If am wrong, then .NET itself allows a class's definition to spread across multiple .netmodules. I don't have .NET 2.0, so I can't check :-) And when you refer to XAML being compiled with VB.NET or C#, you must see that this is the same concept as ASP.NET: the XAML file is translated to the actual framework language first, and then the resulting .vb or .cs file is passed to the VB.NET or C# compiler. Jonathan Gilbert ___ Mono-list maillist - [EMAIL PROTECTED] http://lists.ximian.com/mailman/listinfo/mono-list
RE: [Mono-list] Mixing languages within
This might give you some ideas: http://logix.livelogix.com/index.html It's python based so, theoretically it could also run on top of IronPython on top of mono. Rodrigo ___ Mono-list maillist - [EMAIL PROTECTED] http://lists.ximian.com/mailman/listinfo/mono-list
RE: [Mono-list] Mixing languages within
Jonathan, Actually this is part of the proposed spec (partial classes). As I see it from the latest information on MSDN. (http://msdn.microsoft.com/vcsharp/team/language/default.aspx) They have a PDF file with some of the proposed information (http://download.microsoft.com/download/8/1/6/81682478-4018-48fe-9e5e-f87a44af3db9/Standard.pdf) I don't know if there is a newer release of this document, but it seems that "partial" is planed to be part of the spec. Yes I believe that you are correct that the compiler needs to support it (a compile time issue not a runtime issue) but they are still separate code files that you compile into one. The multi-assembly namespace is available now though. XAML is just the class definitions laid out in XML. The XAML is compiled either with VB.NET or C# then the two class files are "merged" to form the executable (if my understanding is still correct from the demos). In Longhorn you should also be able to run a XAML file directly (I believe this was demoed as well) which is then compiled and ran like a normal application. But again, the particular language needs to be specified. :-) Don't you love it when these discussions go so far away from the original questions... On a MONO board at that... Anyway, I am still learning and have not been to all of the conferences and training courses yet, but I try to keep up with what I can. Mostly I believe that the above is correct. If not, forgive the ignorance... Like I said I am still learning... Richard Norman Web/Application Developer http://www.jazzynupe.net/blog/ *** Message: 8Date: Thu, 09 Dec 2004 22:43:24 -0500To: [EMAIL PROTECTED] From: "Jonathan Gilbert" <[EMAIL PROTECTED]>Subject: RE: [Mono-list] Mixing languages within At 04:58 PM 09/12/2004 -0800, Richard Norman wrote: [snip] >>>> In .NET 2.0 there is the notion of "partial" classes where for exampleXAML files describe one part of the class and say a VB file describesanother. But again the languages they are compiled with must be the same(Example:<<http://www.devx.com/dotnet/Article/22603/1954?pf=true>http://www.devx.com/dotnet/Article/22603/1954?pf=true ) <<<<<<<< I'm not certain, but I believe this is more of a compiler hack thananything supported innately by .NET. The compiler has to see all theseparate source code files before it can produce the class in IL, and theXAML is translated to C# before the real compilation starts. Jonathan Gilbert
Re: [Mono-list] Mixing languages within
Kelly Leahy wrote: (very silly thought indeed for mainstream langauges like C# and VB.NET) we should not expect such support to be useful in "real-world" applications. Not sure which "real-world" you are referring to...:) Some languages are more suited to particular tasks than others, with specialised syntax that makes life easy. e.g. I personally wouldn't use C for a task where Perl is more suited. ___ Mono-list maillist - [EMAIL PROTECTED] http://lists.ximian.com/mailman/listinfo/mono-list
Re: [Mono-list] Mixing languages within
Michal Moskal wrote: The problem is cross references -- that is if part in language A needs part in language B and vice versa. Then the compilers need to agree much more -- upon some internal APIs, which seems quite difficult in general. Not that I'm an expert, but the 'common' parts would probably be something like: - a shared symbol table - shared intermediate representation (does mcs or the vb compiler use an intermediate representation? how about ironpython and nemerle?) - shared error reporting mechnism That way, whenever the language is changed during compilation, the symbol table can be passed on, modified if needed and then returned to the 'compiler host'. The 'compiler host' could then hold all the common bits with the knowledge of how to invoke the 'secondary' compilers when the language is switched, and how to conglomerate each compilers output (IL). Perhaps I should smoke less crack... ___ Mono-list maillist - [EMAIL PROTECTED] http://lists.ximian.com/mailman/listinfo/mono-list
Re: [Mono-list] Mixing languages within
Jonathan Gilbert wrote: Not exactly right. You're leaving out an intermediate step: an individual source code file can be compiled to a .netmodule, and .netmodules compiled with different languages can be mixed within a single assembly. Does this mean that a partial class (or part of a class) can be compiled to a .netmodule? or do .netmodules have to contain a complete class? ___ Mono-list maillist - [EMAIL PROTECTED] http://lists.ximian.com/mailman/listinfo/mono-list
Re: [Mono-list] Mixing languages within
On Fri, 10 Dec 2004 14:49:44 +, Colin JN Breame <[EMAIL PROTECTED]> wrote: > Michal Moskal wrote: > > >The problem is cross references -- that is if part in language A needs > >part in language B and vice versa. Then the compilers need to agree > >much more -- upon some internal APIs, which seems quite difficult in > >general. > > > Not that I'm an expert, but the 'common' parts would probably be > something like: > - a shared symbol table > - shared intermediate representation (does mcs or the vb compiler use > an intermediate representation? how about ironpython and nemerle?) > - shared error reporting mechnism The last one seems easy :) As for the shard symbol table -- you would also need to share information about partially built types (that is without all method already compiled and so on). This could have been System.Reflection.Emit stuff, but... If I checked correctly even mcs doesn't use S.R.E.TypeBuilder as the internal class representation. This is even less the case for Nemerle, as we need type system features absent from .net 1.1 and 2.0 (like algebraic types, and function types). Dunno about IronPython. As for the intermediate representation -- mcs uses syntax trees, that are later modified during the compilation. Nemerle compiler uses 3 kinds of trees during the compilation, and 2 more are in the plans. Yet another problem is the scale -- you need to expose lots of previously internal API, which makes all your compilers one big compiler and this isn't any good. So the bottom line is: the only way to merge two existing compilers is to write them from the beginning... OTOH designing the compiler to be extensible from the beginning seems possible ;) -- : Michal Moskal ::: http://nemerle.org/~malekith/ :: GCS !tv h e>+++ b++ : ::: Logic is a nice contrast to the Real World. :: UL$ C++ E--- a? ___ Mono-list maillist - [EMAIL PROTECTED] http://lists.ximian.com/mailman/listinfo/mono-list
Re: [Mono-list] Mixing languages within
--- Colin JN Breame <[EMAIL PROTECTED]> wrote: > Michal Moskal wrote: > > > > Not that I'm an expert, but the 'common' parts would > probably be > something like: > - a shared symbol table > - shared intermediate representation (does mcs or > the vb compiler use an > intermediate representation? how about ironpython > and nemerle?) > - shared error reporting mechnism > All sounds very good to me. Again, however, my question has to be this: Are we trying to build a better compiler system for .NET compatible languages than the one MS has, or are we trying to build a cross-platform compiler that has similar (hopefully the same) features as the MS compilers? I assert the latter. If we want to build a compiler that has all kinds of neat features that the MS compiler doesn't have, that's fine, but I think it should be separate from mcs proper, as mcs proper should "act like" the MS compiler insofar as that is possible. Kelly ___ Mono-list maillist - [EMAIL PROTECTED] http://lists.ximian.com/mailman/listinfo/mono-list
Re: [Mono-list] Mixing languages within
--- Colin JN Breame <[EMAIL PROTECTED]> wrote: > Kelly Leahy wrote: > > > (very silly thought indeed for mainstream > langauges > > like C# and VB.NET) we should not expect such > support > > to be useful in "real-world" applications. > > > Not sure which "real-world" you are referring > to...:) > > Some languages are more suited to particular tasks > than others, with > specialised syntax that makes life easy. e.g. I > personally wouldn't use > C for a task where Perl is more suited. > I agree completely. One must use the best tool for the job. I'm referring the the world in which we are trying to match as closely as possible the functionality of a system over which we have no control (MS .NET C# and VB.Net compilers). In this case, it doesn't really make sense to discuss adding features to our compilers that are not going to appear in the MS compilers. If our true goal is to support cross-platform development, then IMHO the only features we should have in our compiler that are not in MS's compiler should be those features that allow access to platform specific items - not new language features that have nothing to do with platform whatsoever. Kelly ___ Mono-list maillist - [EMAIL PROTECTED] http://lists.ximian.com/mailman/listinfo/mono-list
Re: [Mono-list] Mixing languages within
Kelly Leahy wrote: (very silly thought indeed for mainstream langauges like C# and VB.NET) we should not expect such support to be useful in "real-world" applications. Not sure which "real-world" you are referring to...:) Some languages are more suited to particular tasks than others, with specialised syntax that makes life easy. e.g. I personally wouldn't use C for a task where Perl is more suited. ___ Mono-list maillist - [EMAIL PROTECTED] http://lists.ximian.com/mailman/listinfo/mono-list
Re: [Mono-list] Mixing languages within
Michal Moskal wrote: The problem is cross references -- that is if part in language A needs part in language B and vice versa. Then the compilers need to agree much more -- upon some internal APIs, which seems quite difficult in general. Not that I'm an expert, but the 'common' parts would probably be something like: - a shared symbol table - shared intermediate representation (does mcs or the vb compiler use an intermediate representation? how about ironpython and nemerle?) - shared error reporting mechnism That way, whenever the language is changed during compilation, the symbol table can be passed on, modified if needed and then returned to the 'compiler host'. The 'compiler host' could then hold all the common bits with the knowledge of how to invoke the 'secondary' compilers when the language is switched, and how to conglomerate each compilers output (IL). Perhaps I should smoke less crack... ___ Mono-list maillist - [EMAIL PROTECTED] http://lists.ximian.com/mailman/listinfo/mono-list
Re: [Mono-list] Mixing languages within
Jonathan Gilbert wrote: Not exactly right. You're leaving out an intermediate step: an individual source code file can be compiled to a .netmodule, and .netmodules compiled with different languages can be mixed within a single assembly. Does this mean that a partial class (or part of a class) can be compiled to a .netmodule? or do .netmodules have to contain a complete class? ___ Mono-list maillist - [EMAIL PROTECTED] http://lists.ximian.com/mailman/listinfo/mono-list
Re: [Mono-list] Mixing languages within
> The problem is cross references -- that is if part > in language A needs > part in language B and vice versa. Then the > compilers need to agree > much more -- upon some internal APIs, which seems > quite difficult in > general. I understand that in general, it would certainly be possible to build a set of compilers that are aware of each other to the extent that they support nested code. However, this was the problem I was most concerned with when discussing such a design, and again - I don't believe this should or ever could be done with the .NET platform and C#, without a huge effort by MS to make such a thing possible, or a very non-standard implementation of the compilers. In any case, even if we could build such a thing, why would we? Unless MS is going to do the same, or we have plans to eclipse MS in the .NET compiler business (very silly thought indeed for mainstream langauges like C# and VB.NET) we should not expect such support to be useful in "real-world" applications. After all, at the end of the day, our goal is to build a platform that allows for cross-platform compatibility with MS's .NET implementation, right? Perhaps this means they have features we don't (Win-specific features that cannot be implemented on other platforms) and perhaps this means we have features they don't, but I don't think we should make the source files incompatible. Here, I think features == run-time library stuff, not features == language functionality. If we start going a completely different direction with the language altogether, we suddenly become as obscure as MS would probably like to think we are. Kelly ___ Mono-list maillist - [EMAIL PROTECTED] http://lists.ximian.com/mailman/listinfo/mono-list
Re: [Mono-list] Mixing languages within
On Thu, 9 Dec 2004 15:38:14 -0800 (PST), Kelly Leahy <[EMAIL PROTECTED]> wrote: > That being said, the question was about mixing code in > a single source file. I don't think this should be or > would ever be possible. It is easy to mix source languages in one file -- you just need to write a simple preprocessor, that separates the content to files. This has been done with various literate programming systems. Then, if all the compilers involved support IL output, then it is easy to merge -- even if they cannot produce .netmodule, you can ildasm dlls produced, cat them together and ilasm. The problem is cross references -- that is if part in language A needs part in language B and vice versa. Then the compilers need to agree much more -- upon some internal APIs, which seems quite difficult in general. However there is also a possibility to generate language A from specialized languages B and C (that is C# from the string processing languages), and then just run the output through the A compiler. If B and C do not need much information about parts written in A, then it is quite easy -- most of the semantic checks are done by the A compiler. The drawbacks are the need for separate program, but also, which is more important, misleading error messages from the A compiler, for errors in B or C parts. Yet another possibility is to host the B and C compilers inside the A compiler -- they would use A internal representations, produce proper error messages and so on. The hard part is the embedding -- you need to know a lot about the compiler you're going to use. In most cases you'll also need the sources for it. However there are some compilers, like the Nemerle compiler, that support easy embedding of such stuff within separate plugins. I refer you to http://nemerle.org/macrouse.html#embedded-languages for some more info. :-) -- : Michal Moskal ::: http://nemerle.org/~malekith/ :: GCS !tv h e>+++ b++ : ::: Logic is a nice contrast to the Real World. :: UL$ C++ E--- a? ___ Mono-list maillist - [EMAIL PROTECTED] http://lists.ximian.com/mailman/listinfo/mono-list
RE: [Mono-list] Mixing languages within
At 04:58 PM 09/12/2004 -0800, Richard Norman wrote: [snip] In .NET 2.0 there is the notion of "partial" classes where for example XAML files describe one part of the class and say a VB file describes another. But again the languages they are compiled with must be the same (Example: http://www.devx.com/dotnet/Article/22603/1954?pf=true ) I'm not certain, but I believe this is more of a compiler hack than anything supported innately by .NET. The compiler has to see all the separate source code files before it can produce the class in IL, and the XAML is translated to C# before the real compilation starts. Jonathan Gilbert ___ Mono-list maillist - [EMAIL PROTECTED] http://lists.ximian.com/mailman/listinfo/mono-list
RE: [Mono-list] Mixing languages within
At 03:31 PM 09/12/2004 -0800, Kirk Marple wrote: >It makes sense if both languages (C# and HSPL) compiled to IL, and were both >processed by the CLR. > >You'd have to make separate assemblies which referenced each other, you >couldn't do it inline in the same class. Not exactly right. You're leaving out an intermediate step: an individual source code file can be compiled to a .netmodule, and .netmodules compiled with different languages can be mixed within a single assembly. Jonathan Gilbert ___ Mono-list maillist - [EMAIL PROTECTED] http://lists.ximian.com/mailman/listinfo/mono-list
Re: [Mono-list] Mixing languages within
At 11:18 PM 09/12/2004 +, you wrote:
>I don't know what the .Net standard would have to say about this
>
>I would like to mix C# and (say) Hypothetical String Processing Language
>(HSPL) and (say) Hypothetical Data Processing Language (HDPL) within the
>same source code file. e.g.
>
>class mixed {
> string normal_c_sharp_method() {
> string ret = null;
>
>
> some HSPL...modifying ret
>
>
>
> some HDPL...modifying ret
>
>
> return ret
>}
>}
>
>Is this a crazy idea?
You may want to check out Cw (C omega), a research language created at
Microsoft:
http://research.microsoft.com/comega/
It isn't precisely what you want, but it does merge a variety of concepts.
In particular, XML can be used inline, and is treated as a short-hand for
construction/initialization of objects, and SQL can be used on data
structures defined within the language.
Jonathan Gilbert
___
Mono-list maillist - [EMAIL PROTECTED]
http://lists.ximian.com/mailman/listinfo/mono-list
RE: [Mono-list] Mixing languages within
In the same code file would not work cause you would need to know where language A ends and language B begins. The compiler would need to parse the file and know what language to pass to based on some sort of lookup. In .NET 2.0 there is the notion of "partial" classes where for example XAML files describe one part of the class and say a VB file describes another. But again the languages they are compiled with must be the same (Example: http://www.devx.com/dotnet/Article/22603/1954?pf=true ) The other thing you have is multi-assembly namespaces. So that part of a name space is in one assembly and another part is in another assembly. So one assembly could be written in C# and another could be written in VB. but again these are separate files and separate assemblies. Richard Norman Web/Application Developer http://www.jazzynupe.net/blog/ * Message: 15Date: Thu, 9 Dec 2004 15:38:14 -0800 (PST)From: Kelly Leahy <[EMAIL PROTECTED]>Subject: RE: [Mono-list] Mixing languages withinTo: Kirk Marple <[EMAIL PROTECTED]>, 'Colin JN Breame' <[EMAIL PROTECTED]>, [EMAIL PROTECTED] Yes, its true that any .NET language should be able touse any other .NET language (in separate assemblies). This IS supported by the standard and is one of themajor motivations for the CTS (common type system), asignificant part of the CLI (common languageinfrastructure). However, it should even be possible to supportmultiple languages in the same assembly, assuming thecompilers could agree on an intermediate target orsome method for merging the assemblies. I don'tbelieve this has been done, but I think its certainlypossible (not sure it buys anything though). That being said, the question was about mixing code ina single source file. I don't think this should be orwould ever be possible. Kelly
RE: [Mono-list] Mixing languages within
Yes, its true that any .NET language should be able to
use any other .NET language (in separate assemblies).
This IS supported by the standard and is one of the
major motivations for the CTS (common type system), a
significant part of the CLI (common language
infrastructure).
However, it should even be possible to support
multiple languages in the same assembly, assuming the
compilers could agree on an intermediate target or
some method for merging the assemblies. I don't
believe this has been done, but I think its certainly
possible (not sure it buys anything though).
That being said, the question was about mixing code in
a single source file. I don't think this should be or
would ever be possible.
Kelly
--- Kirk Marple <[EMAIL PROTECTED]>
wrote:
> It makes sense if both languages (C# and HSPL)
> compiled to IL, and were both
> processed by the CLR.
>
> You'd have to make separate assemblies which
> referenced each other, you
> couldn't do it inline in the same class.
>
> Look at how IronPython compiles to IL, but it usable
> from any other .NET
> assembly.
>
> http://ironpython.com/
>
> -Original Message-
> From: [EMAIL PROTECTED]
> [mailto:[EMAIL PROTECTED] On Behalf
> Of Colin JN Breame
> Sent: Thursday, December 09, 2004 3:19 PM
> To: [EMAIL PROTECTED]
> Subject: [Mono-list] Mixing languages within
>
> I don't know what the .Net standard would have to
> say about this
>
> I would like to mix C# and (say) Hypothetical String
> Processing Language
> (HSPL) and (say) Hypothetical Data Processing
> Language (HDPL) within the
> same source code file. e.g.
>
> class mixed {
> string normal_c_sharp_method() {
>string ret = null;
>
>
> some HSPL...modifying ret
>
>
>
> some HDPL...modifying ret
>
>
>return ret
> }
> }
>
> Is this a crazy idea?
>
>
> ___
> Mono-list maillist - [EMAIL PROTECTED]
> http://lists.ximian.com/mailman/listinfo/mono-list
>
> ___
> Mono-list maillist - [EMAIL PROTECTED]
> http://lists.ximian.com/mailman/listinfo/mono-list
>
___
Mono-list maillist - [EMAIL PROTECTED]
http://lists.ximian.com/mailman/listinfo/mono-list
RE: [Mono-list] Mixing languages within
It makes sense if both languages (C# and HSPL) compiled to IL, and were both
processed by the CLR.
You'd have to make separate assemblies which referenced each other, you
couldn't do it inline in the same class.
Look at how IronPython compiles to IL, but it usable from any other .NET
assembly.
http://ironpython.com/
-Original Message-
From: [EMAIL PROTECTED]
[mailto:[EMAIL PROTECTED] On Behalf Of Colin JN Breame
Sent: Thursday, December 09, 2004 3:19 PM
To: [EMAIL PROTECTED]
Subject: [Mono-list] Mixing languages within
I don't know what the .Net standard would have to say about this
I would like to mix C# and (say) Hypothetical String Processing Language
(HSPL) and (say) Hypothetical Data Processing Language (HDPL) within the
same source code file. e.g.
class mixed {
string normal_c_sharp_method() {
string ret = null;
some HSPL...modifying ret
some HDPL...modifying ret
return ret
}
}
Is this a crazy idea?
___
Mono-list maillist - [EMAIL PROTECTED]
http://lists.ximian.com/mailman/listinfo/mono-list
___
Mono-list maillist - [EMAIL PROTECTED]
http://lists.ximian.com/mailman/listinfo/mono-list
Re: [Mono-list] Mixing languages within
> I don't know what the .Net standard would have to > say about this > > I would like to mix C# and (say) Hypothetical String > Processing Language > (HSPL) and (say) Hypothetical Data Processing > Language (HDPL) within the > same source code file. e.g. > > Is this a crazy idea? > I think so. I'm not sure what someone else might say, but my problem with this is that every compiler would have to know about every other compiler and there would have to be some standard for how to shift around from one compiler to the next and pass type / symbol information and IL code around as well. I don't think it's feasible, and I'm pretty sure it's not even close to being supported by the standard. I doubt it's prohibited directly by the standard (because, after all, you could argue that this wouldn't be C#, but some variant of C# and so wouldn't be bound by the standard at all), but I surely wouldn't want to try to build the compiler for it. Kelly ___ Mono-list maillist - [EMAIL PROTECTED] http://lists.ximian.com/mailman/listinfo/mono-list
[Mono-list] Mixing languages within
I don't know what the .Net standard would have to say about this
I would like to mix C# and (say) Hypothetical String Processing Language
(HSPL) and (say) Hypothetical Data Processing Language (HDPL) within the
same source code file. e.g.
class mixed {
string normal_c_sharp_method() {
string ret = null;
some HSPL...modifying ret
some HDPL...modifying ret
return ret
}
}
Is this a crazy idea?
___
Mono-list maillist - [EMAIL PROTECTED]
http://lists.ximian.com/mailman/listinfo/mono-list
