Re: Maximum recursion depth exceeded

I will not continue this thread further as it goes a little bit off-topic,
but:

> And a long list of languages, XSLT isn't one of them - I guess since
> it can not produce libraries or programs that conform to the CLI specs
> - without some helping code around it - that it would not meet this
> definition. Do you feel that the list is wrong?

The output of XslCompiledTransform can be a dll and this is
(certainly) a .NET dll and this is (certainly) a .NET "library of
programs".

For the people, who might not be aware of this fact, there is even a
VS2008 add-in that implements the XSLT project type, allowing the
developer to create a project of type XSLT -- bing for "IronXSLT by
Oleg Tkachenko"


--
Cheers,
Dimitre Novatchev
---------------------------------------
Truly great madness cannot be achieved without significant intelligence.
---------------------------------------
To invent, you need a good imagination and a pile of junk
-------------------------------------
Never fight an inanimate object
-------------------------------------
You've achieved success in your field when you don't know whether what
you're doing is work or play




On Tue, Jul 7, 2009 at 11:18 AM, bryan
rasmussen<rasmussen.bryan@xxxxxxxxx> wrote:
> Michael Kay said:
>
>>> I'm not sure if I would
>>> consider an XSLT compiled via XslCompiledTransform B to be a
>>> '.NET language' (I believe I used the example of C#) , I
>>> haven't really thought about it though - would you say it is?
>>
>> You're the one who introduced the term, Bryan, I think it's up to you
either
>> to explain to the rest of us what you meant by it, or to admit that it's
>> meaningless.
>
> Ok, I guess what I meant by .NET languages was a language that
> specifically had a compiler for the CLR
> http://en.wikipedia.org/wiki/Common_Language_Runtime
> which I thought was commonly understood by the term .NET language,
> even by people who don't work using .NET. That it can be used to build
> libraries that can be used by other .NET languages, for example by
> compiling to a DLL.
>
> Sure XslCompiledTransform compiles down to MSIL
> http://msdn.microsoft.com/en-us/magazine/cc163554.aspx but it doesn't
> interact with the other languages in the same way.
>
> Although if I go to Wikipedia again
> http://en.wikipedia.org/wiki/Microsoft_.NET_Languages I get:
>
> "CLI Languages are computer programming languages that are used to
> produce libraries and programs that conform to the Common Language
> Infrastructure specifications. With some notable exceptions, most CLI
> languages compile entirely to the Common Intermediate Language (CIL),
> an intermediate language that can be executed using an implementation
> of CLI such as the Common Language Runtime, a part of the Microsoft
> .NET Framework, Mono, or Portable.NET."
>
> And a long list of languages, XSLT isn't one of them - I guess since
> it can not produce libraries or programs that conform to the CLI specs
> - without some helping code around it - that it would not meet this
> definition. Do you feel that the list is wrong?
>
> another set of languages that I would think of as .NET languages would
> be those that are supported by the DLR
> http://en.wikipedia.org/wiki/Dynamic_Language_Runtime
>
> or something like this list
> http://www.dotnetpowered.com/languages.aspx B (give or take some
> languages)
>
>
> So as to whether or not it is meaningless - maybe it is because it has
> a sort of wide coverage, but it does seem to be a term that is used
> relatively frequently.
>
> ----
>
> Dmitre said:
>
>>I don't know what is your definition for a ".NET Language".
>
> See above
>
>>XslCompiledTransform is the latest .NET implementation of the XSLT 1.0
>>language. Whether XslCompiledTransform or F# are written in C# (or
>>VB.NET or any other language supported by the platform) has nothing to
>>do with the fact that they are language implementations officially
>>provided by .NET
>
> I just wanted to note that F# is a language like C# and VB.NET whereas
> XslCompiledTransform is a class allowing you to use XSLT. I'm pretty
> sure you know this but you imply that it is coequal to
> XslCompiledTransform - do you, if so why? Not being snarky, since I
> respect you quite a bit I suppose you might well have a viewpoint on
> the matter that would be different than mine and if so you would like
> to expand on that viewpoint.
>
>>> but
>>> it is annoying when I know I have a function that is properly tail
>>> recursive and it overflows anyway...(This would be a C# problem, not
>>> XSLT in System.XML.XSL)
>
>>This would be XSLT implementation problem (nothing to do with
>>recursion in C#),
>
> Well, I guess I have really atrocious communication skills but I was
> making a comment there about what I thought were commonly understood
> as .NET languages (as per the discussion above as to what I mean B by
> that) and I wasn't talking about XSLT or compiling an XSLT I was
> talking about that in C# a properly tail recursive function - written
> in C# - will have a stack overflow sooner or later and I made the
> offhand remark that of the languages that I thought of as .NET
> languages - C#, VB.NET, JScript.NET, B F#, Managed C++ being the ones
> that pop into the head immediately as belonging to this set although
> there are obviously others the only one I know of that supports
> compiler optimization of tail recursion is F#. Probably if I took the
> time to look at languages that use the DLR I might find the story to
> be far different.
>
> I probably shouldn't have made that rather lighthearted and offhanded
> comment mainly because it was somewhat off-topic as well, and since
> the topic is supposed to be XSLT I suppose I can understand you
> thinking I was saying that tail recursion (or any recursion) doesn't
> work in XSLT for .NET, obviously it does. Any implementation where it
> didn't work would be so broken as to be completely useless.
>
>
> Best Regards,
> Bryan Rasmussen