Re: Usability of M$ specs [was: Haskell and the NGWS Runtime]
On 11-Sep-2000, Andrew Kennedy [EMAIL PROTECTED] wrote: Perhaps some of the non-MS .net compiler implementers would like to comment further? One serious usability problem with the Microsoft .net specs that I have seen is that Microsoft only provided them in a proprietry documentation format, which can only be browsed on a Windows system (in fact I think it even has to be W2k, IIRC). -- Fergus Henderson [EMAIL PROTECTED] | "I have always known that the pursuit WWW: http://www.cs.mu.oz.au/~fjh | of excellence is a lethal habit" PGP: finger [EMAIL PROTECTED]| -- the last words of T. S. Garp.
RE: Usability of M$ specs [was: Haskell and the NGWS Runtime]
Amongst other projects, I'm working on aspects of a GHC based Haskell compiler for .NET. We're currently at a fairly early stage, but if by "system dependent" you mean "Windows dependent", then I can happily say that it looks like a basic, functioning Haskell system should not need to access any .NET libraries that are by their nature Windows specific. Some .NET libraries do provide access to Windows specifics, of course, but not all. As for the specs - they aren't always 100% perfect, but given this product is pre-beta I reckon they're in pretty good shape by industrial standards. Many aspects are being submitted to ECMA, and I believe we can have confidence that such a standards body will only accept them when they have reached a sufficiently high level of quality. Cheers! Don Syme At the lab: Microsoft Research Cambridge St George House Cambridge, CB2 3NH, UK Ph: +44 (0) 1223 744797 http://research.microsoft.com/users/dsyme/ email: [EMAIL PROTECTED] -Original Message- From: Matthias Kilian [mailto:[EMAIL PROTECTED]] Sent: 11 September 2000 16:32 To: Andrew Kennedy Cc: Erik Meijer; Ketil Malde; [EMAIL PROTECTED]; [EMAIL PROTECTED]; Marcin 'Qrczak' Kowalczyk; [EMAIL PROTECTED] Subject: RE: Usability of M$ specs [was: Haskell and the NGWS Runtime] On Mon, 11 Sep 2000, Andrew Kennedy wrote: I agree that this construct is a touch under-specified; I've emailed the C# team with your criticism so hopefully it will get fixed. However, it seems a little harsh to conclude that the .NET runtime is to be avoided as a target. That was no conclusion but a question. If .NET is specified more carefully than C#, it should be possible to port the runtime env. to other platforms. One additional question is how .NET interacts with the remainder of ths system (file system etc.); it's clear that Microsoft is not interested in implementing any platform independent. However, if I understand what I've read already, neither C# nor the .NET runtime environment mentions any requirements to system libraries (as MFC for example). I've no idea about how much system dependend code has to be written to - implement .NET on other platforms (i.e. several unices) - implement .NET backends for Haskell and/or ML compilers at least for basic functionality (file system access, sockets) there should be not too much problems. Regards, Kili -- Auf deutschem Boden darf nie wieder ein Joint ausgehen. [Wolfgang Neuss]
RE: Usability of M$ specs [was: Haskell and the NGWS Runtime]
Matthias Kilian: But is this specification sound and complete? I'd a look at the C# speccifcation, which is a bad joke. For example, there's a section about the switch statement, which elaborates on the "fall-through" problem. I agree that this construct is a touch under-specified; I've emailed the C# team with your criticism so hopefully it will get fixed. However, it seems a little harsh to conclude that the .NET runtime is to be avoided as a target. As far as the specification of the intermediate language is concerned, I find it reasonably clear and certainly precise enough to target a compiler (we're working on an SML compiler at MS Research Cambridge). Perhaps some of the non-MS .net compiler implementers would like to comment further? - Andrew Kennedy.
Re: Haskell and the NGWS Runtime
This runtime just needs to be ported to other operating systems similarily to the Java runtime. So it's a question of either source availability - or at least a very complete specification - or Microsoft strategy. With the SDK that you can download from MS comes a 500 page specification of the runtime and the IL. So if you have a free Saturday and you want to get famous, then give that Linux implementation a try. Some interesting background on MS plans to standardize this stuff is available at http://www2.hursley.ibm.com/tc39/mins-13jul00.html#csharp. Erik
Usability of M$ specs [was: Haskell and the NGWS Runtime]
On Sat, 9 Sep 2000, Erik Meijer wrote:
With the SDK that you can download from MS comes a 500 page specification of
the runtime and the IL. So if you have a free Saturday and you want to get
famous, then give that Linux implementation a try.
But is this specification sound and complete? I'd a look at the C#
speccifcation, which is a bad joke. For example, there's a section about
the switch statement, which elaborates on the "fall-through" problem. From
my memory (I don't have the specs at home):
To prevent accidently fall-throughs by a forgotten "break", each case
has to be ended cleanly, either by an explicit "break", or by a "goto
label", or by a return statement, or by throwing an exception, or by doing
anything else the compiler can prove that the next case block isn't
reached. For example, the following is legal:
switch(foo(x)) {
case 42:
while(true) {
..
}
case 43:
...
}
From the Specs:
"Obviously, the loop in the 42-case does not terminate, so it's legal to
omit the break after the loop."
With this nice example, M$ either forces a C# compiler to solve the
halting problem (since it has to decide wether a certain piece of code
terminates or not), or makes the decision about what is legal code an
implementation depenent one. (What about the body of the loop? What about
"while(f(x)) {...}"?)
If the runtime specifications of .NET are of the same quality, there's no
way to port it to another system.
Ciao,
Kili
--
Auf deutschem Boden darf nie wieder ein Joint ausgehen.
[Wolfgang Neuss]
Re: Haskell and the NGWS Runtime
On 14-Aug-2000, Benjamin Leon Russell [EMAIL PROTECTED] wrote: Tyson Dowd [EMAIL PROTECTED] wrote: I don't believe you can teach programmers anything by trying to take tools away from them. I believe you can only teach programmers by showing them a better tool. Aha, but *which* programmers? The C/C++ programmers who will bother learning how to write safe code, or those who won't? Well, no sane C# course or book will teach the unsafe features of the language before the safe ones. So I think the vast majority of C/C++ programmers who learn C# will already know how to write safe C# code before they learn how to write unsafe C# code. The problem is that many programmers will not focus on the safe features if the unsafe ones remain. ... For example, if the C/C++ programmers are used to explicit memory management using malloc() and free(), then they are likely to keep writing all their methods using this old style, even when the running time is not crucial. This could potentially introduce more memory-related bugs than necessary. I'm not an expert on C#, so I could be wrong about this, but as I understand it, C# does not have malloc() and free(), not even in the unsafe subset. Unsafe C# is not the same as C or C++. Furthermore, "unsafe" code will have a stigma attached to it, just like "goto" does today (or perhaps more so). So I think you overestimate the danger of C/C++ programmers continuing to write much of their code using unsafe features if they switch to C#. Suppose the manager starts the project by requiring that all the programmers write all non-time-critical portions of their code in pure C#. Why wouldn't the manager require that they write all non-time-critical portions of their code in safe C# (i.e. C# without the "unsafe" keyword)? On 14-Aug-2000, Benjamin Leon Russell [EMAIL PROTECTED] wrote: Your not-quite-spoken assumption that it should be possible to write everything in one language is just something I fundamentally disagree with. The requirements of low-level kernel code are quite different from those of most user-level applications, and any single language that tries to address both sets of requirements will do so poorly. Ah, a testable hypothesis! If you are right, then you should be able to criticize some other features of the language that have suffered as a result of unsafe code in C#. Ah, a testable hypothesis! If you are right, then you should be able to provide an example of a language that meets the requirements of writing both low-level kernel code and most user applications equally well for the bulk of the programmers working with the language! Well, how about Modula II and Ada? -- Fergus Henderson [EMAIL PROTECTED] | "I have always known that the pursuit WWW: http://www.cs.mu.oz.au/~fjh | of excellence is a lethal habit" PGP: finger [EMAIL PROTECTED]| -- the last words of T. S. Garp.
Re: Haskell and the NGWS Runtime
Fergus Henderson wrote: On 14-Aug-2000, Benjamin Leon Russell [EMAIL PROTECTED] wrote: Ah, a testable hypothesis! If you are right, then you should be able to provide an example of a language that meets the requirements of writing both low-level kernel code and most user applications equally well for the bulk of the programmers working with the language! Well, how about Modula II and Ada? Or maybe even better, Modula-3? Sietse Achterop
RE: Haskell and the NGWS Runtime
I think most C++ programmers realize C++ for what it is, a poorly designed portable object oriented assembler language. Most C++ programmers use C++ because they program for windows and COM, and the only other real choices of development environments are VB and Delphi (which I do not know anything about). VB does not fully support COM development nor object-oriented programming (nor any other kind of programming really), so developers have little choice but to play with the C++ gun and hope they do not shoot themselves in the foot. We use VB when we can and C++ when we must in our shop. I think almost every Windows developer is eager to move to the safer world of C#. However, almost no one is even thinking about FP. I think NGWS will be the kiss of death for FP in the large -- OO just seems 90 degrees out of phase with FP. -Original Message- From: Benjamin Leon Russell [mailto:[EMAIL PROTECTED]] Sent: Monday, August 14, 2000 8:10 AM To: Tyson Dowd; [EMAIL PROTECTED] Cc: Craig Dickson Subject: Re: Haskell and the NGWS Runtime On Sun, 13 Aug 2000 22:36:42 +1000 Tyson Dowd [EMAIL PROTECTED] wrote: On 11-Aug-2000, Craig Dickson [EMAIL PROTECTED] wrote: Antony Courtney wrote: stuff deleted/stuff deleted will be coming from C and C++ where it is perfectly normal to do all sorts of things that the compiler cannot guarantee to be safe. This leads to all sorts of bugs such as buffer overflows, stack corruption, page faults accessing unmapped memory, etc. By making it so convenient to write unsafe code in C#, Microsoft has essentially given these C/C++ coders an excuse not to bother learning how to write safe code, and many programmers will take that excuse. I don't believe you can teach programmers anything by trying to take tools away from them. I believe you can only teach programmers by showing them a better tool. Aha, but *which* programmers? The C/C++ programmers who will bother learning how to write safe code, or those who won't? Many programmers work on teams. Suppose you have 50 programmers on a team working under a tough time limit, and most of them have just switched from C/C++ (where they were accustomed to working with unsafe code most of the time) to C#. Will they choose to learn how to write the bulk of their procedures using safe code (possibly missing the deadline in the process), or just continue writing lots of unsafe code (and possibly meeting the deadline, but also likely introducing bugs such as memory leaks in the process)? stuff deleted/stuff deleted So long as the unsafe code is clearly labelled as such, and cannot be confused with safe code why does it have to be in a different language? Why do you have to sacrifice all the features of the language you are currently using just because you need to write some unsafe code? The problem is that many programmers will not focus on the safe features if the unsafe ones remain. It takes time to learn a new skill, and if the programmers already know how to write unsafe code that they are convinced will work (even if it also potentially introduces bugs), they are not likely suddenly to change their style and to write everything using safe code whenever possible, even if it happens to be better in each situation. They are working under pressure and want to meet the deadline. So, they will use whatever they already feel most comfortable with, including unsafe code even when it is not necessary. For example, if the C/C++ programmers are used to explicit memory management using malloc() and free(), then they are likely to keep writing all their methods using this old style, even when the running time is not crucial. This could potentially introduce more memory-related bugs than necessary. stuff deleted/stuff deleted If you can implement the unsafe stuff in a way that doesn't harm the rest of the implementation, and you can partition the unsafe portion of the language from the safe portion in a way that is acceptable in software engineering terms, then the programmers can have an easier time writing or interfacing to bit-twiddling, pointer manipulation code. That's a *big* "if," though. Again, what if the programmers are undisciplined and undertrained former C/C++ programmers (most likely, a large portion of the programmers will be from this group), and most of the implementation winds up being unsafe? Then what? Suppose the manager starts the project by requiring that all the programmers write all non-time-critical portions of their code in pure C#. Suppose that the programmers are from the above group. If the language supports unsafe code, then the programmers are likely to write much of their code using unsafe code, simply because they are used to that style, even when unsafe code isn't completely necessary. If the language doesn't support unsafe code, then they are forced to learn how to write safe code, whether they want to or no
Re: Haskell and the NGWS Runtime
On Sun, 13 Aug 2000 22:36:42 +1000 Tyson Dowd [EMAIL PROTECTED] wrote: On 11-Aug-2000, Craig Dickson [EMAIL PROTECTED] wrote: Antony Courtney wrote: stuff deleted/stuff deleted will be coming from C and C++ where it is perfectly normal to do all sorts of things that the compiler cannot guarantee to be safe. This leads to all sorts of bugs such as buffer overflows, stack corruption, page faults accessing unmapped memory, etc. By making it so convenient to write unsafe code in C#, Microsoft has essentially given these C/C++ coders an excuse not to bother learning how to write safe code, and many programmers will take that excuse. I don't believe you can teach programmers anything by trying to take tools away from them. I believe you can only teach programmers by showing them a better tool. Aha, but *which* programmers? The C/C++ programmers who will bother learning how to write safe code, or those who won't? Many programmers work on teams. Suppose you have 50 programmers on a team working under a tough time limit, and most of them have just switched from C/C++ (where they were accustomed to working with unsafe code most of the time) to C#. Will they choose to learn how to write the bulk of their procedures using safe code (possibly missing the deadline in the process), or just continue writing lots of unsafe code (and possibly meeting the deadline, but also likely introducing bugs such as memory leaks in the process)? stuff deleted/stuff deleted So long as the unsafe code is clearly labelled as such, and cannot be confused with safe code why does it have to be in a different language? Why do you have to sacrifice all the features of the language you are currently using just because you need to write some unsafe code? The problem is that many programmers will not focus on the safe features if the unsafe ones remain. It takes time to learn a new skill, and if the programmers already know how to write unsafe code that they are convinced will work (even if it also potentially introduces bugs), they are not likely suddenly to change their style and to write everything using safe code whenever possible, even if it happens to be better in each situation. They are working under pressure and want to meet the deadline. So, they will use whatever they already feel most comfortable with, including unsafe code even when it is not necessary. For example, if the C/C++ programmers are used to explicit memory management using malloc() and free(), then they are likely to keep writing all their methods using this old style, even when the running time is not crucial. This could potentially introduce more memory-related bugs than necessary. stuff deleted/stuff deleted If you can implement the unsafe stuff in a way that doesn't harm the rest of the implementation, and you can partition the unsafe portion of the language from the safe portion in a way that is acceptable in software engineering terms, then the programmers can have an easier time writing or interfacing to bit-twiddling, pointer manipulation code. That's a *big* "if," though. Again, what if the programmers are undisciplined and undertrained former C/C++ programmers (most likely, a large portion of the programmers will be from this group), and most of the implementation winds up being unsafe? Then what? Suppose the manager starts the project by requiring that all the programmers write all non-time-critical portions of their code in pure C#. Suppose that the programmers are from the above group. If the language supports unsafe code, then the programmers are likely to write much of their code using unsafe code, simply because they are used to that style, even when unsafe code isn't completely necessary. If the language doesn't support unsafe code, then they are forced to learn how to write safe code, whether they want to or not, because that is the only way to write the code. There is likely to be a difference to the manager between writing much of the code in another language, and writing much of it in unsafe 100% pure C# code using the "unsafe" marker: he/she is likely to permit more of the latter than the former. In addition, the programmers are far more likely to get carried away with writing unnecessary unsafe 100% pure C# code than they are with writing code in another language when unnecessary. Your not-quite-spoken assumption that it should be possible to write everything in one language is just something I fundamentally disagree with. The requirements of low-level kernel code are quite different from those of most user-level applications, and any single language that tries to address both sets of requirements will do so poorly. Ah, a testable hypothesis! If you are right, then you should be able to criticize some other features of the language that have suffered as a result of unsafe code in C#. Ah, a testable
Re: Haskell and the NGWS Runtime
Benjamin Leon Russell wrote: Tyson Dowd [EMAIL PROTECTED] wrote: On 11-Aug-2000, Craig Dickson [EMAIL PROTECTED] wrote: stuff deleted/stuff deleted will be coming from C and C++ where it is perfectly normal to do all sorts of things that the compiler cannot guarantee to be safe. This leads to all sorts of bugs such as buffer overflows, stack corruption, page faults accessing unmapped memory, etc. By making it so convenient to write unsafe code in C#, Microsoft has essentially given these C/C++ coders an excuse not to bother learning how to write safe code, and many programmers will take that excuse. I don't believe you can teach programmers anything by trying to take tools away from them. I believe you can only teach programmers by showing them a better tool. Aha, but *which* programmers? The C/C++ programmers who will bother learning how to write safe code, or those who won't? [...] The problem is that many programmers will not focus on the safe features if the unsafe ones remain. Exactly. For example, many C programmers use "goto" habitually, even though there are better solutions even in C. I, personally, have no problem with learning new paradigms; in fact, I like it. I regard learning a new programming language as essentially getting an inside view of someone else's ideas of how programming should be done, and so I go out of my way to learn the "correct" style for that language. rant But I work with a number of people who I don't think have bothered learning any really different ideas about programming since graduating back in the mid-80s. They write C++ as if it were C, after ten years of working exclusively in C++. Sure, they call their structs "classes" now, and the classes have methods, but all their data members are public, and if they need a list of objects, they just give each object a "next" pointer instead of using a separate list class. The company's C++ style guide, when I was hired, contained pearls of wisdom such as "Declare all methods virtual" and "Never use static members". The company's chief engineer (now chief architect) habitually violates Microsoft's Windows coding guidelines left and right because she thinks it makes the code "easier to read" -- never mind that it doesn't work. I'm sorry, but I just don't think these people will, of their own volition, learn how to write "safe" C#. They'll just write unsafe C# because it's more convenient. "After all," they'll say, "my code is valid C# too, so it's just as good as yours. It's just a matter of style." /rant Now, on the other hand, if they need to work in C#, and if C# didn't have "unsafe" features, instead merely having a decent FFI, these folks might get the idea that safe code is the way to go. It takes time to learn a new skill, and if the programmers already know how to write unsafe code that they are convinced will work (even if it also potentially introduces bugs), they are not likely suddenly to change their style and to write everything using safe code whenever possible, even if it happens to be better in each situation. rant One thing I've noticed with C/C++ programmers, particularly (which is, again, the pool from which most C# programmers will be drawn), is that many of them are convinced that they can handle dangerous techniques which experience shows they can't handle. They say things such as, "I like doing my own memory management, because it gives me more control," but their code continually suffers from memory leaks and other pointer-related problems that show quite clearly that they are not to be trusted with these things that give them "more control". This, in my view, is just one more reason why "unsafe" features should not be built into mass-market languages like C#. /rant Ah, a testable hypothesis! If you are right, then you should be able to provide an example of a language that meets the requirements of writing both low-level kernel code and most user applications equally well for the bulk of the programmers working with the language! I think this is a better hypothesis to test than Tyson's. For one thing, to really be able to say what problems exist in C# as a language, and how the desire to be both a high-level applications language and a low-level kernel language plays a role in those problems, will take time and experience with C#. A lot of the things I now dislike about C++ took me a long time to really understand. I realize, of course, that it probably seems very convenient for me that I prefer the hypothesis that puts the burden of proof on the other party. Of course it is. But I think history, so far, shows that attempts to make a language that is "universal" or "good for everything" have resulted in languages that are too complicated. It may be _possible_ to use them for everything, but they aren't really all that well-suited for anything. Because of this, I tend to be suspicious when a language tries to reach too
Re: Haskell and the NGWS Runtime
On 11-Aug-2000, Craig Dickson [EMAIL PROTECTED] wrote: Antony Courtney wrote: But Java also has a way to do "rampant pointer-level optimization": You declare a method as "native" and then implement it in C. That's hardly the same thing, though. Of course an FFI allows you do to all sorts of things, but at least it's very clear, from the fact that you're using another language, that you are switching paradigms and potentially doing something dangerous. In fact, I would generalize this a bit further and say that if you want to do something that violates the paradigm of the language you're working in, you _should_ do it in another language, precisely to make the point (to anyone reading your code) that certain components aren't following the rules. I agree that you should make it clear to anyone reading (or modifying) your code that it is breaking the rules. And in fact if you are using code that breaks the rules (and that rule-breaking is not hidden behind some suitable abstraction) you should know about it. And possibly even if you are using rule-breaking code behind an abstraction, you should be able to know about it. But I disagree completely that this implies the solution is to switch language! will recognize the loss of portability, safety and abstraction when writing a native method in Java, and will only do so when absolutely necessary. The same should go for "unsafe" methods in C# [...] The difference is that C# allows you to fundamentally design an application in an unsafe way and still claim (to your manager) that your code is 100% C#. I'm not kidding; this will happen. Remember that many C# programmers It is 100% C#. It's not 100% safe. Any "grep" through the source code will reveal that since you have to use the unsafe keyword to write unsafe code. And if you don't have source code, you can verify the output code using a verifier -- unsafe code will not verify. will be coming from C and C++ where it is perfectly normal to do all sorts of things that the compiler cannot guarantee to be safe. This leads to all sorts of bugs such as buffer overflows, stack corruption, page faults accessing unmapped memory, etc. By making it so convenient to write unsafe code in C#, Microsoft has essentially given these C/C++ coders an excuse not to bother learning how to write safe code, and many programmers will take that excuse. I don't believe you can teach programmers anything by trying to take tools away from them. I believe you can only teach programmers by showing them a better tool. Remember, too, that not every program is written as an application on a PC. The requirement in Java that native methods be implemented in another language caused serious problems for the JavaOS and embedded / JVM-on-a-chip efforts. Erlang has the same requirement that code doing unsafe things has to be written in another language. It is used in a number of embedded systems; in fact, that's what it was originally intended for. So the argument that you have to have unsafe features built into the language just doesn't wash. So long as the unsafe code is clearly labelled as such, and cannot be confused with safe code why does it have to be in a different language? Why do you have to sacrifice all the features of the language you are currently using just because you need to write some unsafe code? How do you write a device driver for a memory-mapped device in 100% pure Java? You can't. And you aren't supposed to. I wouldn't want to write hardware drivers in a garbage-collected language that allocates all objects on the heap. Java is not a systems-level language; adding low-level bit-twiddling features to it would give it some of the same problems that C++ has, with the low-level features undermining the high-level features and the requirements of the high-level features interfering with the low-level features. Well that's a language design consideration. The designers of C# have obviously decided they would like people to write device drivers in C#. But that's beside the point. You can write the bit-twiddling parts in C or assembler in both languages. The point is that the memory manipulations have to be hidden from the base system at some level, because the "safe" portion of the languages (safe C#, or all of Java) is not allowed to see it. This means you have to introduce a layer to hide the unsafe stuff. In Java you have to do all this layer in some foreign language. In C# you can do a large part of this layer in C# (using "unsafe"). What does this mean? Well in Java all it means is that the implementations don't have to worry about implementing the unsafe stuff, since it isn't part of the language. But the consequence is the programmer has to do the low-level stuff purely in some foreign language, which means all the other good features in Java have to be sacrificed for this section of the code. But in C# it means that the
Re: Haskell and the NGWS Runtime
Hello, On Sun, 13 Aug 2000, Tyson Dowd wrote: will be coming from C and C++ where it is perfectly normal to do all sorts of things that the compiler cannot guarantee to be safe. This leads to all sorts of bugs such as buffer overflows, stack corruption, page faults accessing unmapped memory, etc. By making it so convenient to write unsafe code in C#, Microsoft has essentially given these C/C++ coders an excuse not to bother learning how to write safe code, and many programmers will take that excuse. I don't believe you can teach programmers anything by trying to take tools away from them. Hum. Sorry. I'm a total newbie compared to all of you here, but. yes, it is a language design question. What's encapsultation and abstract data types? What's object-oriented programming itself?... I thought that information hiding - and the related language features are known to be good. That's why I really cannot follow your point here. ? Best regards, -Sylvan -- Do, or do not. There's no 'try'. -Yoda Sylvan Ravinet: http://www.ravinet.com/sylvan/contact
Re: Haskell and the NGWS Runtime
On Fri, 11 Aug 2000 12:53:39 +0800 Lyndon While [EMAIL PROTECTED] wrote: At 6:46 pm -0400 10/8/2000, Benjamin Leon Russell wrote: Somebody once wrote that a clearly written, well-documented program that doesn't work is usually more valuable than a badly written, poorly-documented program that does work because it can easily be fixed and reused. Who wrote this? Is it just a rumour or is there a reference that I can give to my students? There is a reference, but it is in a book that I read months ago, probably while browsing through the local bookstore. I just looked through _The Practice of Programming,_ by Kernighan Pike, but apparently it wasn't in that book. Trying to find it is a little like looking for a needle in a haystack. It is probably in some other book on programming style. I'll try to look it up when I have time and let you know when I find it again. --Ben -- Benjamin L. Russell [EMAIL PROTECTED] [EMAIL PROTECTED] "Furuike ya! Kawazu tobikomu mizu no oto." --Matsuo Basho
Re: Haskell and the NGWS Runtime
On 13-Aug-2000, Sylvan Ravinet [EMAIL PROTECTED] wrote: Hello, will be coming from C and C++ where it is perfectly normal to do all sorts of things that the compiler cannot guarantee to be safe. This leads to all sorts of bugs such as buffer overflows, stack corruption, page faults accessing unmapped memory, etc. By making it so convenient to write unsafe code in C#, Microsoft has essentially given these C/C++ coders an excuse not to bother learning how to write safe code, and many programmers will take that excuse. I don't believe you can teach programmers anything by trying to take tools away from them. Hum. Sorry. I'm a total newbie compared to all of you here, but. yes, it is a language design question. What's encapsultation and abstract data types? What's object-oriented programming itself?... I thought that information hiding - and the related language features are known to be good. That's why I really cannot follow your point here. My point here is that if you refrain from adding features from your language to try to discourage programmers from using those features, they will just end up not using your language. In many cases the programmers simply need to be shown the equivalent features of your language that allow them to do what they want to do. But in the case of writing unsafe code, (my interpretation of what) Craig Dickson believes (is that) the correct approach is to not have any equivalent features, but to write it in a completely different foreign language. I believe this is "throwing the baby out with the bathwater", and you can find alternate methods that have all the power but far fewer drawbacks. I believe that doing this makes your language a stronger tool, and is therefore more likely to be used by programmers. It also makes it a more dangerous tool, but if your alternative is to write more code in a language such as C/C++, you can't get much more dangerous! -- Tyson Dowd # # Surreal humour isn't everyone's cup of fur. [EMAIL PROTECTED]# http://www.cs.mu.oz.au/~trd #
Re: GC in embedded systems (was Re: Haskell and the NGWS Runtime)
On Fri 11 Aug, George Russell wrote: However REALLY worst-time-bounded garbage collection is very expensive in CPU time. (Is there anything better than Baker's train algorithm?) In any case even if you do have garbage-collection, you will still need to demonstrate that you won't run out of memory. And if you're going to do that sort of analysis, wouldn't it be better to use something like MLKit's regions rather than garbage collection? I think this sentiment sums up my feelings pretty well. I'm not sure how the MLFix solution would fit with Haskell. Regards -- Adrian Hey
Re: GC in embedded systems (was Re: Haskell and the NGWS Runtime)
On Fri 11 Aug, Sengan wrote: I don't buy this: for a long time the embedded hard realtime people refused to use CPUs with cache because they would be "non-deterministic". (I assume "non-deterministic" in this context means we can't determine the execution time of a bit of code, even knowing the initial state of variables etc...) I think you'll find that this is still the prevailing view for most in the DSP community (and I can't think of many 'harder' real time applications). They finally gave up, What, all of them? :-) The only people I know who have tried this for DSP have come to regret it. realizing that CPU's with caches are much faster. Not necessarily. IMHO most conventional caches are a less than ideal silicon fix for what is essentially a software problem. Typically DSP's use fast internal RAM that provides the same service as a 'cache', but which bits of code and data are cached is under the control of the software, not the hardware. (Some also have an additional 'cache', but let's not get into that...) If garbage collection is relatively cheap and makes it 10x faster to make a reliable system, they'll end up using it too. I would certainly agree that automatic garbage collection is far better than the perils of using explicit allocations/deallocations from a conventional heap. But I don't do that either, in code which I know has to be reliable. If I was using a language which did not allow me the option of using static allocation and destructive updates (it used dynamic allocation and run-time GC instead) I think in practice will actually take far longer to make systems _reliable_ (having first eliminated all bugs from my own code, presumably). In fact I'm not convinced it's possible. Useful?..Yes, Cheap?..Yes, Reliable?..I'm sceptical:-( How can I ensure that such a system won't ever run out of heap space? Some kind of proof? Exhaustive testing? Non deterministic is not that important. Worst time is. Yes, I agree in principle, but how would you determine the very worst case time in a cached/GC machine? You need a _real_ worst case figure to know your system performs to spec. Regards -- Adrian Hey
Re: GC in embedded systems (was Re: Haskell and the NGWS Runtime)
On Fri 11 Aug, Byron Hale wrote: I don't mean that threads are non-deterministic, but that the execution time of a GC thread seems to be non-deterministic. Large collections need more time than small ones and the time required is some function of the store to be collected, is it not? Sort of, but I think it depends what you mean by non-deterministic. If you mean you don't know exactly how long garbage collection will take, or when and how often it will occur, then I agree with you. This probably is a serious problem for 'real time' systems, but not all embedded applications are 'real-time'. (Those written in Erlang presumably aren't, for example.) If the store to be collected is created at a greater rate than it can be collected, then a garbage-collected system would seem to be be expected to crash eventually. Yes, I think this is by far the biggest problem for any system which is required to be robust. Conking out do to lack of heap space may be acceptable (though undesirable) on a PC or workstation, but for most real world applications this is unacceptable. ML-Kit has implemented some work on compile-time memory management using regions. I wonder if that might not be more practical than garbage collection, in real-time systems. I've had a quick look at this. I would say that the approach taken is good from the point of view of saving time, but unless I'm missing something, there is still the problem of ensuring that the program will run in bounded space if you use the 'infinite' regions (as it seems you must for recursive data types). It seems it's still pretty much the programmers responsibility to ensure this. But seeing as ML is strict, it's probably much easier for the programmer to get this right than it would be in Haskell. Regards -- Adrian Hey
Re: GC in embedded systems (was Re: Haskell and the NGWS Runtime)
On Fri 11 Aug, Manuel M. T. Chakravarty wrote: Erlang applications are characterised as being soft-realtime applications: http://www.erlang.org/faq/x847.html#SOFT-REALTIME In one sentence, I would characterise this as ``it is fast enough most of the time.'' This seems to be good enough for many (most?) embedded systems. Yes, I think so, but terms like 'embedded','real time' amd 'non-deterministic' seem to mean different things to different people. I won't attempt to define them. But as far as GC is concerned, time is really a secondary issue IMHO. It's having confidence that your program can run in (known) bounded space that worries me. (If you don't mind the wait, time can be extended indefinitely, but you can't do this with memory). Real time or not, presumably systems writtem in Erlang are required not to conk out due to exhausted heap space. I don't see how Erlang users ensure this, other than by relying on programmers intuition and program testing. I see your point about insisting on finite state machines, but as the functionality expected from embedded systems increases, this ideal viewpoint will become increasingly infeasible in practice. In that case I suspect the systems we all rely on will become increasingly unreliable :-( This is probably less of a problem for strict languages because it's much easier for the programmer to think about the space behaviour of programs, but in a graph reduction implementation (of a lazy language) things aren't so easy. This worries me. Are heap profilers the answer, I wonder? Certainly they help detect space leaks, but this reliance on empirical rather than analytical methods doesn't really seem to be consistent with the goal of being able to write programs which are correct by design, and provably so (in principal at least). Just curious, but has anybody investigated how far you can go with a 'purely functional' language and still get a finite state machine implementation? What would you need to do to Haskell to achieve this? Obvious things which come to mind include outlawing recursive data types (including our beloved lists!). This seems a little drastic, maybe you could allow them but 'deforest' them out in many cases (and have the compiler warn you if it couldn't). I suppose they would be ok in (finite) constants too. Just a thought. Regards -- Adrian Hey
Re: GC in embedded systems (was Re: Haskell and the NGWS Runtime)
Adrian Hey [EMAIL PROTECTED] wrote, My objection to the use of GC (and by implication all current Haskell implementations) in embedded systems would be that if your program is sufficiently complex/powerful that it can't be implemented as some kind of _finite_ state machine, then it can never be part of a robust system (which has finite memory resources). Put simply, if you don't know how much memory you need, how can you ever be confident you have enough? Hmm, now having written that, I'm wondering how the Erlang community addressed this problem. I believe Erlang is targeted at applications which I would class as 'embedded'. Anybody know the answer? Erlang applications are characterised as being soft-realtime applications: http://www.erlang.org/faq/x847.html#SOFT-REALTIME In one sentence, I would characterise this as ``it is fast enough most of the time.'' This seems to be good enough for many (most?) embedded systems. I see your point about insisting on finite state machines, but as the functionality expected from embedded systems increases, this ideal viewpoint will become increasingly infeasible in practice. Manuel
Re: Haskell and the NGWS Runtime
On 10-Aug-2000, Brent Fulgham [EMAIL PROTECTED] wrote: You can download it here: http://msdn.microsoft.com/net/#sdk There is a C# compiler and runtime environment in the SDK. Thanks for the link! Unfortunately, its click-through license forbids disassembly, reverse engineering, and a raft of other endeavors that one should be allowed if they were truly interested in global acceptance. Unfortunately this is pretty standard stuff for proprietary software. I have certainly made it clear to Microsoft that licensing conditions are a significant impediment to them being taken seriously by academics. [stuff about poorly written C# stuff] I think most of the C# press has been written to impress VB and C++ programmers. I also find it shockingly written and hopelessly uninformed. But I'm sure the intended audience thinks it's just wonderful. Microsoft spent around $2M funding a bunch of groups working on research and industrial programming languages to give feedback on their work. (Haskell, Mercury, ML, Scheme, Oberon, Eiffel, Python, Oz, etc...) While they acknowledged from the start that getting any changes (apart from tailcall) into version 1 was pretty unlikely, they have been listening, taking notes, and even now the C# folks are getting excited about the idea of putting generics into the language. Well, that sounds good. Are you speaking from personal knowledge here? My concern is that although they may have spoken with these various teams, I really don't see much in C# that looks like they took any of the comments to heart. In fact, it looks like they took J++, changed the name, and added a few nasty things (like labeled "gotos"). They didn't really want any feedback on C#. C# was always going to be what it is, another simple object-oriented C derivative language. I'm kind of annoyed they released C# at the same time as all this other stuff, because everyone is focusing on the "new language" when the real interesting stuff is under the hood. What is underneath C# is a runtime system that can run lots of different languages. That's what they wanted the feedback on. C# is just one language that runs on it, MS will also run C++ (well a lot of it) and VB on it. Other vendors will run their own languages on it. You get cross language debugging, data-level interoperability, unified memory management, etc. It's a bit like the JVM without the insistance that it be 100% Java. Oh, yes I am speaking from personal knowledge. Mercury got some of that funding. In fact, if they were interested in learning anything, why did they solicit feedback so late in the game? There's often some sort of assumption that because they are rich and powerful, they are also omnipotent. By the time they figured out they should do this, got a budget for it, shortlisted the groups, flew around the world and explained it to 20 different groups, signed non-disclosure agreements, and gave out the work they had done so far, quite a bit of time had passed. The thing that really bothers me is that they claim that ".NET will be available on Windows (C) and other systems". But they have no reference implementations available for non-Windows (C) environments. When Sun released Java, we had Unix and Windows versions available right away, and the Linux Blackdown port shortly thereafter. Yes, but real support for Linux has been very slow in coming from Sun, as Linux is a competitor. I don't really expect MS to release a non-Windows implementation. But I wouldn't be the least bit surprised if they decide to pay someone to do a Linux version (possibly even an open source version). Thanks for your feedback, Tyson, but I'm afraid I still don't see much to recommend it. And .NET's heavy dependence on older MS technologies (such as COM objects, etc.) is especially distasteful. AFAIK there is no dependence on COM. There is builtin COM interop, in much the same way that you can have CORBA interop in Java. (You shouldn't believe everything you read on Slashdot). Of course apps might depend on COM, but that's a different issue. I'm not trying to convince anyone to use it. That's Microsoft's job. I'm mostly interested in fostering the good ideas that are in .NET and making sure they become popular and widespread. I'd love it if Sun took the good bits and put them straight into JVM 2. -- Tyson Dowd # # Surreal humour isn't everyone's cup of fur. [EMAIL PROTECTED]# http://www.cs.mu.oz.au/~trd #
Re: GC in embedded systems (was Re: Haskell and the NGWS Runtime)
Byron Hale [EMAIL PROTECTED] wrote, At 05:21 AM 8/11/2000 +0100, you wrote: On Fri 11 Aug, Byron Hale wrote: Also, garbage collection is unlikely to satisfy any need for automatic memory management in real-time systems for the foreseeable future because an extra thread on a single processor is still non-deterministic. I'm not sure this is true, doesn't it depend on the scheduling strategy? I've written a lot of code for single and multiple processor DSP systems, and typically have multiple threads (on 1 processor). But they are still entirely deterministic. I don't mean that threads are non-deterministic, but that the execution time of a GC thread seems to be non-deterministic. Large collections need more time than small ones and the time required is some function of the store to be collected, is it not? Not necessarily. In a copying collector, it can be size of live portion of the store only. Ie, by guaranteeing that your program never hangs on to too much data, you can put an upper bound on the GC time.[1] ML-Kit has implemented some work on compile-time memory management using regions. I wonder if that might not be more practical than garbage collection, in real-time systems. Realtime Java uses a kind of explicitly handled regions (not automatically inferred as in the ML implementation). However, the way they integrated the feature is IMHO very awkward. Manuel [1] Guaranteeing that your program doesn't hang on to too much data is not easy, but you essentially have to do that also when you do explicit memory management.
Re: Haskell and the NGWS Runtime
On 11-Aug-2000, Manuel M. T. Chakravarty [EMAIL PROTECTED] wrote: Ketil Malde [EMAIL PROTECTED] wrote, "Manuel M. T. Chakravarty" [EMAIL PROTECTED] writes: A good analysis of were C# fits re Java and C++ is at http://slashdot.org/article.pl?sid=00/08/09/1612254mode=thread Wherein we read: One new feature that I mentioned already was that of copy-by-value objects. This seemingly small improvement is a potentially huge performance saver! This analysis actually misses the main point. Performance is not the main reason for wanting value types. The main reason for wanting value types is that there are many types which are better modelled as values rather than as objects. Of all people, functional programmers should surely be well aware of this! Note that Eiffel, which certainly tends towards purism in its OOP zeal, originally did without value types, but the Eiffel community found that this did cause problems and so since Eiffel 3.0, Eiffel has had value types (though they call them "Expanded Objects" -- I guess so that they can still call the language "purely" object oriented ;-). For similar reasons, Sather also distinguishes between value types and object types. Likewise I believe that a request for value types is high up on the Java extensions list. Complex numbers, for instance, are an example of a type which is much better modelled as a value type than as an object type. From a modelling perspective, the most important difference between a value type and an object type is not that an object type is allocated on the heap, but that an object type has an identity. However, that said, there are cases where value types can give significant performance improvements over object types. With C++, one is regularly tempted to describe the simplest constructs as classes, and in so doing make it safer and simpler to use them. For example, a phone directory program might define a phone record as a class, and would maintain one PhoneRecord object per actual record. In Java, each and every one of those objects would be garbage collected! Now, is this really such a big problem? Is it a problem because of Java's mark-and-sweep, and if so, couldn't you apply a better GC? That's exactly what I thought. I mean why don't they read a couple of research papers? Using a better garbage collector is certainly a good idea. However, there is a limit to how good you can make the garbage collector. Often it is much more cost effective to put work into reducing the program's allocation rate rather than trying to make the garbage collector faster. From what I have heard, it sounds like MS have put quite a bit of work into their garbage collector. They use a generational mark-compact collector, with I think three generations, the first of which is sized to fit in the L0 (or was it L1?) cache, and they have several different versions for different situations, including a concurrent one for interactive use. They claim that in situations where you are frequently allocating small objects, the overhead of allocation is about 6 cycles per object (this of course does not include the collection cost), and they claim that in such situations the amortized overall cost of allocation plus collection is less than 50 cycles per object. These claims have not (to my knowledge) been independently verified, and personally I am somewhat sceptical, particular about the extent to which these figures, which are no doubt the best case figures, will extrapolate to real programs. However, I think it is fair to say that Microsoft have done their homework on this issue. I have not yet done any benchmarking of their GC yet. The reason for that is that currently the Mercury to IL code generator generates code which does many unnecessary allocations which we know how to eliminate, so benchmarking things at this point would give us very little in the way of of useful comparisons. -- Fergus Henderson [EMAIL PROTECTED] | "I have always known that the pursuit WWW: http://www.cs.mu.oz.au/~fjh | of excellence is a lethal habit" PGP: finger [EMAIL PROTECTED]| -- the last words of T. S. Garp.
Re: Haskell and the NGWS Runtime
On 02-Aug-2000, Doug Ransom [EMAIL PROTECTED] wrote: The PDC slides and white papers should be available if you dig through this site: http://commnet.pdc.mscorpevents.com/default.asp In particular http://commnet.pdc.mscorpevents.com/sessions.asp. However, as seems to be usual (%*^#*^#@!) for MS, this page is NOT written in portable HTML. Certainly it didn't work with Netscape Communicator 4.61 on Linux when I tried it. When it comes to open standards, Microsoft are good at "talking the talk", but if the way they write web pages is any indication, they have a long way to go before they'll be "walking the walk". -- Fergus Henderson [EMAIL PROTECTED] | "I have always known that the pursuit WWW: http://www.cs.mu.oz.au/~fjh | of excellence is a lethal habit" PGP: finger [EMAIL PROTECTED]| -- the last words of T. S. Garp.
Re: Haskell and the NGWS Runtime
At 4:59 pm -0230 10/8/00, Theodore Norvell wrote: With Haskell# or Mondrian: Can I use C# to create an instance of a Haskell class? Can I use Haskell to extend a C# abstract class? I suspect the answer to both these questions is currently no. If future versions of .NET and Haskell variants change that, it will be very interesting. You can create a C# class from Mondrian and vice-versa. You can extend a C# class with data fields in Mondrian, but not methods. This is a work in progress and what we will end up doing exactly is still undecided. There are lots of interesting things to consider here. Cheers, Nigel -- Nigel Perry, New Zealand
RE: Haskell and the NGWS Runtime
-Original Message- From: Fergus Henderson [mailto:[EMAIL PROTECTED]] Sent: Friday, August 11, 2000 4:18 AM ... In particular http://commnet.pdc.mscorpevents.com/sessions.asp. However, as seems to be usual (%*^#*^#@!) for MS, this page is NOT written in portable HTML. Certainly it didn't work with Netscape Communicator 4.61 on Linux when I tried it. And is Netscape Communicator 4.61 on Linux (bugs and all) a definitive test of portable HTML? :-) Nikhil
Re: Haskell and the NGWS Runtime
Antony Courtney wrote: But Java also has a way to do "rampant pointer-level optimization": You declare a method as "native" and then implement it in C. That's hardly the same thing, though. Of course an FFI allows you do to all sorts of things, but at least it's very clear, from the fact that you're using another language, that you are switching paradigms and potentially doing something dangerous. In fact, I would generalize this a bit further and say that if you want to do something that violates the paradigm of the language you're working in, you _should_ do it in another language, precisely to make the point (to anyone reading your code) that certain components aren't following the rules. In C++, this isn't much of an issue because C++ is the all-time paradigm whore of languages; there basically aren't any rules, and you can do whatever you like, which is part of why C++ sucks. With STL and some of the weirder properties of recursive templates, you even almost have a sort of half-assed functional language. I'm almost surprised that Stroustrop hasn't tried to build in a real module system, closures, and backtracking; then he'd have just about everything. Any sensible programmer Most programmers, in my experience, are not sensible. will recognize the loss of portability, safety and abstraction when writing a native method in Java, and will only do so when absolutely necessary. The same should go for "unsafe" methods in C# [...] The difference is that C# allows you to fundamentally design an application in an unsafe way and still claim (to your manager) that your code is 100% C#. I'm not kidding; this will happen. Remember that many C# programmers will be coming from C and C++ where it is perfectly normal to do all sorts of things that the compiler cannot guarantee to be safe. This leads to all sorts of bugs such as buffer overflows, stack corruption, page faults accessing unmapped memory, etc. By making it so convenient to write unsafe code in C#, Microsoft has essentially given these C/C++ coders an excuse not to bother learning how to write safe code, and many programmers will take that excuse. Remember, too, that not every program is written as an application on a PC. The requirement in Java that native methods be implemented in another language caused serious problems for the JavaOS and embedded / JVM-on-a-chip efforts. Erlang has the same requirement that code doing unsafe things has to be written in another language. It is used in a number of embedded systems; in fact, that's what it was originally intended for. So the argument that you have to have unsafe features built into the language just doesn't wash. How do you write a device driver for a memory-mapped device in 100% pure Java? You can't. And you aren't supposed to. I wouldn't want to write hardware drivers in a garbage-collected language that allocates all objects on the heap. Java is not a systems-level language; adding low-level bit-twiddling features to it would give it some of the same problems that C++ has, with the low-level features undermining the high-level features and the requirements of the high-level features interfering with the low-level features. Your not-quite-spoken assumption that it should be possible to write everything in one language is just something I fundamentally disagree with. The requirements of low-level kernel code are quite different from those of most user-level applications, and any single language that tries to address both sets of requirements will do so poorly. Craig
Re: GC in embedded systems (was Re: Haskell and the NGWS Runtime)
On Fri 11 Aug, Byron Hale wrote: Also, garbage collection is unlikely to satisfy any need for automatic memory management in real-time systems for the foreseeable future because an extra thread on a single processor is still non-deterministic. I don't buy this: for a long time the embedded hard realtime people refused to use CPUs with cache because they would be "non-deterministic". They finally gave up, realizing that CPU's with caches are much faster. If garbage collection is relatively cheap and makes it 10x faster to make a reliable system, they'll end up using it too. Non deterministic is not that important. Worst time is. Sengan
Re: Haskell and the NGWS Runtime
On 11-Aug-2000, R.S. Nikhil [EMAIL PROTECTED] wrote: -Original Message- From: Fergus Henderson [mailto:[EMAIL PROTECTED]] Sent: Friday, August 11, 2000 4:18 AM ... In particular http://commnet.pdc.mscorpevents.com/sessions.asp. However, as seems to be usual (%*^#*^#@!) for MS, this page is NOT written in portable HTML. Certainly it didn't work with Netscape Communicator 4.61 on Linux when I tried it. And is Netscape Communicator 4.61 on Linux (bugs and all) a definitive test of portable HTML? :-) The page doesn't display properly with Lynx (2.8.3dev.9) on Linux or with Opera (4.02) on Windows either. -- Fergus Henderson [EMAIL PROTECTED] | "I have always known that the pursuit WWW: http://www.cs.mu.oz.au/~fjh | of excellence is a lethal habit" PGP: finger [EMAIL PROTECTED]| -- the last words of T. S. Garp.
Re: GC in embedded systems (was Re: Haskell and the NGWS Runtime)
Sengan wrote: I don't buy this: for a long time the embedded hard realtime people refused to use CPUs with cache because they would be "non-deterministic". They finally gave up, realizing that CPU's with caches are much faster. If garbage collection is relatively cheap and makes it 10x faster to make a reliable system, they'll end up using it too. Non deterministic is not that important. Worst time is. However REALLY worst-time-bounded garbage collection is very expensive in CPU time. (Is there anything better than Baker's train algorithm?) In any case even if you do have garbage-collection, you will still need to demonstrate that you won't run out of memory. And if you're going to do that sort of analysis, wouldn't it be better to use something like MLKit's regions rather than garbage collection?
Re: GC in embedded systems (was Re: Haskell and the NGWS Runtime)
George Russell wrote: (Is there anything better than Baker's train algorithm?) Sorry, I meant "treadmill" not "train". The train algorithm is an almost-bounded garbage collection algorithm. (However it fails to be properly bounded if you have large numbers of in-pointers to a node.)
Re: Haskell and the NGWS Runtime
Replying to Fergus Henderson's complaints about non-portable HMTL in the web document at http://commnet.pdc.mscorpevents.com/sessions.asp, R. S. Nikhil writes: And is Netscape Communicator 4.61 on Linux (bugs and all) a definitive test of portable HTML? :-) No. A definitive test is to submit the page to the validator at the World Wide Web Consortium's web site (http://validator.w3.com/), which (not surprisingly) finds 455 HTML errors, beginning with the absence of a document type declaration. -- John David Stone - Lecturer in Computer Science and Philosophy Manager of the Mathematics Local-Area Network Grinnell College - Grinnell, Iowa 50112 - USA [EMAIL PROTECTED] - http://www.cs.grinnell.edu/~stone/
Re: Haskell and the NGWS Runtime
I wrote: ... http://validator.w3.com/ ... which should be http://validator.w3.org/. Sorry about that ... -- John David Stone - Lecturer in Computer Science and Philosophy Manager of the Mathematics Local-Area Network Grinnell College - Grinnell, Iowa 50112 - USA [EMAIL PROTECTED] - http://www.cs.grinnell.edu/~stone/
RE: Haskell and the NGWS Runtime
On Fri, 11 Aug 2000, R.S. Nikhil wrote: And is Netscape Communicator 4.61 on Linux (bugs and all) a definitive test of portable HTML? :-) Actually it seems to be quite readable by lynx... -Sylvan -- Do, or do not. There's no try. -Yoda Sylvan Ravinet: http://www.ravinet.com/sylvan/contact
Re: Haskell and the NGWS Runtime
Sylvan Ravinet wrote: Do, or do not. There's no try. -Yoda Pedantic not to be, but in contractions speak, does Yoda not. Is quote, "Do, or do not. There is no 'try'." Craig
Re: Haskell and the NGWS Runtime
No. A definitive test is to submit the page to the validator at the World Wide Web Consortium's web site (http://validator.w3.com/), which (not surprisingly) finds 455 HTML errors, beginning with the absence of a document type declaration. I bet you that 99% web pages on the net would not pass this test. Try http://www.haskell.org/index.html, or any other older pages out there (including mine, of course). This (and some other validators) are quite picky and do not distinquish between severe errors, (yes, yes some "fancy" *.htm pages cause my Netscapes to freeze) and innocent variations of the strict rules, such as adding p between list items to enhance its readability. Jan
Re: Haskell and the NGWS Runtime
On 11-Aug-2000, Sylvan Ravinet [EMAIL PROTECTED] wrote: On Fri, 11 Aug 2000, R.S. Nikhil wrote: And is Netscape Communicator 4.61 on Linux (bugs and all) a definitive test of portable HTML? :-) Actually it seems to be quite readable by lynx... Yes -- that's the worst part. In Lynx and Opera, it *seems* to be correctly rendered. Unfortunately it is missing all of the crucial links to the actual slides! Of course there is no easy way you could tell this, except by having seen the same site already with IE, or by examining the site's source code. -- Fergus Henderson [EMAIL PROTECTED] | "I have always known that the pursuit WWW: http://www.cs.mu.oz.au/~fjh | of excellence is a lethal habit" PGP: finger [EMAIL PROTECTED]| -- the last words of T. S. Garp.
Re: Haskell and the NGWS Runtime
On Fri, 11 Aug 2000 12:06:55 -0500 John David Stone [EMAIL PROTECTED] wrote: Replying to Fergus Henderson's complaints about non-portable HMTL in the web document at http://commnet.pdc.mscorpevents.com/sessions.asp, R. S. Nikhil writes: And is Netscape Communicator 4.61 on Linux (bugs and all) a definitive test of portable HTML? :-) No. A definitive test is to submit the page to the validator at the World Wide Web Consortium's web site (http://validator.w3.com/), which (not surprisingly) finds 455 HTML errors, beginning with the absence of a document type declaration. Perhaps a less definitive, but nevertheless still reasonable, test would be to view the page using all major browsers (and yes, Bill Gates, IE is also a browser, not just an integral component of Windows ;-) ), both Microsoft and non-Microsoft, and to see whether it displays reasonably well in them all. Of course, the whole point is that Microsoft would not design the page to look the same in all browsers, because they would want to provide incentive for people to use Microsoft products. --Benjamin L. Russell [EMAIL PROTECTED] [EMAIL PROTECTED]
Re: Haskell and the NGWS Runtime
Florian Hard [EMAIL PROTECTED] writes: How did they say on segfault.org: Microsoft plans to expand Marketese in the future, adding a pound sign to every language currently in their suite of compilers and a plus sign to every acronym currently used to describe Microsoft technology. http://www.segfault.org/story.phtml?mode=2id=39897e26-060c53e0 :-) pedant Please: # - hash / octothorp(e) £ - pound C# - C sharp Three different characters. Down with American cultural imperialism. /pedant --KW 8-) -- Keith Wansbrough [EMAIL PROTECTED] http://www.cl.cam.ac.uk/users/kw217/ Cambridge University Computer Laboratory.
RE: Haskell and the NGWS Runtime
You can download it here: http://msdn.microsoft.com/net/#sdk There is a C# compiler and runtime environment in the SDK. Thanks for the link! Unfortunately, its click-through license forbids disassembly, reverse engineering, and a raft of other endeavors that one should be allowed if they were truly interested in global acceptance. Of course, a few hops up the chain you might run across Joshua Trupin's execrable description of the C# language. Really one of the worst articles I've ever read. You will get such wisdom as: "It's [C#] a little like taking all the good stuff in Visual Basic (C) and adding it to C++, while trimming off some of the more arcane C and C++ traditions." If you're like me, you might be wondering what exactly the "good stuff" allegedly contained within Visual Basic (C) might be. Well, one such element is apparently the labeled "goto". Joshua is also quick to highlight another: "What's one of the most annoying things about working in C++? It's gotta be remembering when to use the - pointer indicator, when to use the :: for a class member, and when to use the dot." Hmm. I guess stating precisely what you mean is a bad feature for programming languages. I hope they at least get rid of the hungarian notation while they are at it. Microsoft spent around $2M funding a bunch of groups working on research and industrial programming languages to give feedback on their work. (Haskell, Mercury, ML, Scheme, Oberon, Eiffel, Python, Oz, etc...) While they acknowledged from the start that getting any changes (apart from tailcall) into version 1 was pretty unlikely, they have been listening, taking notes, and even now the C# folks are getting excited about the idea of putting generics into the language. Well, that sounds good. Are you speaking from personal knowledge here? My concern is that although they may have spoken with these various teams, I really don't see much in C# that looks like they took any of the comments to heart. In fact, it looks like they took J++, changed the name, and added a few nasty things (like labeled "gotos"). In fact, if they were interested in learning anything, why did they solicit feedback so late in the game? I understand your sentiment. Those of use working on the .NET stuff with Microsoft are also uncomfortable about the situation. However I'm sure that everyone involved is doing what they think is the best thing overall. Don't forget that many groups developed a .NET and a JVM backend at the same time using Microsoft's money! Hah! Expect your next round of funding to have more strings attached. :-) The thing that really bothers me is that they claim that ".NET will be available on Windows (C) and other systems". But they have no reference implementations available for non-Windows (C) environments. When Sun released Java, we had Unix and Windows versions available right away, and the Linux Blackdown port shortly thereafter. Thanks for your feedback, Tyson, but I'm afraid I still don't see much to recommend it. And .NET's heavy dependence on older MS technologies (such as COM objects, etc.) is especially distasteful. Regards, -Brent
Re: Haskell and the NGWS Runtime
Brent Fulgham wrote: Thanks for the link! Unfortunately, its click-through license forbids disassembly, reverse engineering, and a raft of other endeavors that one should be allowed if they were truly interested in global acceptance. Well, this _is_ Microsoft, after all. Of course, a few hops up the chain you might run across Joshua Trupin's execrable description of the C# language. Really one of the worst articles I've ever read. You will get such wisdom as: "It's [C#] a little like taking all the good stuff in Visual Basic (C) and adding it to C++, while trimming off some of the more arcane C and C++ traditions." More like "Microsoft Java", but of course they never mention Java, as if hoping that people will read all this tripe and not notice the similarities. I had a most exquisite sense of down-the-rabbit-hole a few weeks ago when I browsed through a Microsoft book on C#. I kept running into all this stuff about how C# was a revolutionary next-generation OO language, better than C++, but all the programming samples looked only trivially different from Java, which of course they never mentioned, as if the book had arrived from some parallel universe in which James Gosling was assassinated by Richard Stallman after inventing Gosling Emacs, and had thus never invented Java. I had to put the book down after a little while because I felt like I'd lose my mind if I kept going. I don't really mind them inventing a variation on Java. Either it will take off or it won't, and I don't really care either way. But I just wish they'd admit what they're doing, and stop treating us all as if we're so stupid that if they don't _tell_ us that C# is a Java derivative, we won't notice. If you're like me, you might be wondering what exactly the "good stuff" allegedly contained within Visual Basic (C) might be. Well, one such element is apparently the labeled "goto". My impression is that C#'s use of labeled gotos is extremely restricted. (I could be wrong.) The only reference to gotos that I found in a Microsoft Press book on C# is its use in jumping to the start of one case in a switch from another case in the same switch. This is actually useful, since it is a better solution than "falling through" from one case to another, as is sometimes done in C, C++, and Java (but which cannot be done in C#, since the "break" required in those languages is implicit in C# -- also a good thing). It's a better solution because (1) it doesn't look like a mistake when you see it in someone else's code; (2) it is more flexible, since the case you're going to doesn't have to be positioned directly below the case you're coming from. Now, if it turns out that C#'s goto can be used for any other purposes, I will be much less happy about it. Joshua is also quick to highlight another: "What's one of the most annoying things about working in C++? It's gotta be remembering when to use the - pointer indicator, when to use the :: for a class member, and when to use the dot." Hmm. I guess stating precisely what you mean is a bad feature for programming languages. Well, claiming that the - vs. . thing is one of the "most annoying things about working in C++" is pretty silly, but only because it's so trivial, not because "stating precisely what you mean is a bad feature". C#, like Java, doesn't need - because there's no distinction between having a reference to an object vs. having a pointer to an object. And C++ overloads so many things that it's sort of silly to complain that getting rid of the double-colon scoping operator reduces clarity. The double-colon was unnecessary to begin with. The thing that really bothers me is that they claim that ".NET will be available on Windows (C) and other systems". But they have no reference implementations available for non-Windows (C) environments. When Sun released Java, we had Unix and Windows versions available right away, and the Linux Blackdown port shortly thereafter. True, but then Sun is a Unix vendor, so of course they had to support it, and Windows is 90% of the market, so they had to support that too. Microsoft's incentive to support anything other than Windows is unclear to me, to say the least. I interpret "other systems" to mean Windows CE, and will believe otherwise only when a less ambiguous announcement is made. Craig
Re: Haskell and the NGWS Runtime
Thanks to Nigel for answering my question Tyson Dowd wrote: Microsoft indicates that C# will not support "genericity", through even anything as crude as C++'s templates, so it is unlikely that they will seek to support functional programming languages in the short term. Perhaps this limitation is part of the impetus for the Mondrian variant. That they are not supporting templates ala C++ can only be a good thing. It leaves the door open for something closer to Haskell's or ML's styles of genericity. This is certainly something that the functional language community can contribute to the world of mainstream imperative programming languages, and thence to the bulk of software development. Yes, I know it's been done; for example pizza; but pizza is not a widely adopted standard. If C# adopts parametric polymorphism and either type classes or ML style modules, and C# becomes more than a proprietary language, then it could make a contribution to getting some of the ideas developed by the functional community into the mainstream. With Haskell# or Mondrian: Can I use C# to create an instance of a Haskell class? Can I use Haskell to extend a C# abstract class? I suspect the answer to both these questions is currently no. If future versions of .NET and Haskell variants change that, it will be very interesting. Cheers, Theodore Norvell Dr. Theodore Norvell[EMAIL PROTECTED] Electrical and Computer Engineering http://www.engr.mun.ca/~theo Engineering and Applied SciencePhone: (709) 737-8962 Memorial University of Newfoundland Fax: (709) 737-4042 St. John's, NF, Canada, A1B 3X5
Re: Haskell and the NGWS Runtime
On 10-Aug-2000, Brent Fulgham [EMAIL PROTECTED] wrote: I hope they at least get rid of the hungarian notation while they are at it. Yes, thankfullly they have indeed done that. That one got a round of applause even from the (mostly) Microsoft faithful who attended PDC, when it was mentioned in one of the sessions there. Microsoft spent around $2M funding a bunch of groups working on research and industrial programming languages to give feedback on their work. (Haskell, Mercury, ML, Scheme, Oberon, Eiffel, Python, Oz, etc...) While they acknowledged from the start that getting any changes (apart from tailcall) into version 1 was pretty unlikely, they have been listening, taking notes, and even now the C# folks are getting excited about the idea of putting generics into the language. Well, that sounds good. Are you speaking from personal knowledge here? Yes, Tyson and I, as well as researchers from other groups, visited Redmond several times. Note that tailcall was in already by the time outside researchers were approached, so I don't know of any technical suggestions made by outside researchers that have yet been acted on. However, the fact that they have been asking for our suggestions and taking notes is at least an improvement. I guess the really interesting bit will be to see what goes in version two. -- Fergus Henderson [EMAIL PROTECTED] | "I have always known that the pursuit WWW: http://www.cs.mu.oz.au/~fjh | of excellence is a lethal habit" PGP: finger [EMAIL PROTECTED]| -- the last words of T. S. Garp.
Re: Haskell and the NGWS Runtime
On 10-Aug-2000, Theodore Norvell [EMAIL PROTECTED] wrote: With Haskell# or Mondrian: Can I use C# to create an instance of a Haskell class? Can I use Haskell to extend a C# abstract class? I suspect the answer to both these questions is currently no. I'm not sure either, but I think the answer is no. A related question to which I do know the answer is "Can I use Mercury to create an instance of a Haskell class, or vice versa?". And the answer to that one, despite Mercury and Haskell having a very similar concept of "class", is still no. So there's still a long way to go. -- Fergus Henderson [EMAIL PROTECTED] | "I have always known that the pursuit WWW: http://www.cs.mu.oz.au/~fjh | of excellence is a lethal habit" PGP: finger [EMAIL PROTECTED]| -- the last words of T. S. Garp.
Re: Haskell and the NGWS Runtime
What bothers me most about C# is that although, at first glance, it seems to be a
variation on Java, it doesn't follow the spirit of Java in at least one important
respect.
Specifically, one common advantage of both Haskell and Java is that they encourage
higher-order abstraction: Haskell through functional abstraction, and Java through
eliminating explicit pointers and memory management and enforcing object orientation
through the use of classes.
However, according to the C# Language Reference (at
http://msdn.microsoft.com/vstudio/nextgen/technology/csharpdownload.asp), "For
developers who are generally content with automatic memory management but sometimes
need fine-grained control or that extra iota of performance, C# provides the ability
to write unsafe code. Such code can deal directly with pointer types, and fix
objects to temporarily prevent the garbage collector from moving them." [Section 1.2]
Witness the following example [Section 1.2]:
-- quoted text begins --
using System;
class Test
{
unsafe static void WriteLocations(byte[] arr) {
fixed (byte *p_arr = arr) {
byte *p_elem = p_arr;
for (int i = 0; i arr.Length; i++) {
byte value = *p_elem;
string addr = int.Format((int) p_elem, "X");
Console.WriteLine("arr[{0}] at 0x{1} is {2}", i,
addr, value);
p_elem++;
}
}
}
static void Main() {
byte[] arr = new byte[] {1, 2, 3, 4, 5};
WriteLocations(arr);
}
}
-- quoted text ends --
Even though the method is marked "unsafe," it allows direct pointer manipulation in
iterating over the elements and writing out the index, value, and location of each.
The reference adds, "Here is one possible output of the above program:
arr[0] at 0x8E0360 is 1
arr[1] at 0x8E0361 is 2
arr[2] at 0x8E0362 is 3
arr[3] at 0x8E0363 is 4
arr[4] at 0x8E0364 is 5
Of course, the exact memory locations are subject to change." [Section 1.2]
Taken to an extreme, this ability could encourage some programmers to ignore the
spirit of higher-level abstraction and focus back on The Old Way (TOW): rampant
pointer-level optimization to squeeze out that extra iota of performance at the
expense of clarity. But wasn't the whole point of higher-level abstraction to leave
this level of optimization to more intelligent compilers so that the programmer could
focus on writing clear, reusable code? Why allow us to get TOW'ed back (pardon the
pun)?
Somebody once wrote that a clearly written, well-documented program that doesn't work
is usually more valuable than a badly written, poorly-documented program that does
work because it can easily be fixed and reused. It just seems that allowing
programmers the ability to manipulate pointers directly is virtually hiding a
Pandora's Box in C#.
--Benjamin L. Russell
[EMAIL PROTECTED]
[EMAIL PROTECTED]
On Thu, 10 Aug 2000 10:46:04 -0700
"Craig Dickson" [EMAIL PROTECTED] wrote:
stuff deleted
/stuff deleted
More like "Microsoft Java", but of course they never
mention Java, as if
hoping that people will read all this tripe and not
notice the similarities.
I had a most exquisite sense of down-the-rabbit-hole a
few weeks ago when I
browsed through a Microsoft book on C#. I kept running
into all this stuff
about how C# was a revolutionary next-generation OO
language, better than
C++, but all the programming samples looked only
trivially different from
Java, which of course they never mentioned, as if the
book had arrived from
some parallel universe in which James Gosling was
assassinated by Richard
Stallman after inventing Gosling Emacs, and had thus
never invented Java. I
had to put the book down after a little while because I
felt like I'd lose
my mind if I kept going.
I don't really mind them inventing a variation on Java.
Either it will take
off or it won't, and I don't really care either way. But
I just wish they'd
admit what they're doing, and stop treating us all as if
we're so stupid
that if they don't _tell_ us that C# is a Java
derivative, we won't notice.
stuff deleted
/stuff deleted
Re: Haskell and the NGWS Runtime
Benjamin Leon Russell wrote: However, according to the C# Language Reference, "For developers who are generally content with automatic memory management but sometimes need fine-grained control or that extra iota of performance, C# provides the ability to write unsafe code. Such code can deal directly with pointer types, and fix objects to temporarily prevent the garbage collector from moving them." [Section 1.2] I hadn't known that. Guess I didn't read far enough, or perhaps it wasn't covered in the book I was reading. I agree that this is likely to be abused. Craig
Re: Haskell and the NGWS Runtime
At 06:46 PM 8/10/2000 -0400, you wrote: What bothers me most about C# is that although, at first glance, it seems to be a variation on Java, it doesn't follow the spirit of Java in at least one important respect. Specifically, one common advantage of both Haskell and Java is that they encourage higher-order abstraction: Haskell through functional abstraction, and Java through eliminating explicit pointers and memory management and enforcing object orientation through the use of classes. However, according to the C# Language Reference (at http://msdn.microsoft.com/vstudio/nextgen/technology/csharpdownload.asp), "For developers who are generally content with automatic memory management but sometimes need fine-grained control or that extra iota of performance, C# provides the ability to write "unsafe" code. Such code can deal directly with pointer types, and fix objects to temporarily prevent the garbage collector from moving them." [Section 1.2] Taken to an extreme, this ability could encourage some programmers to ignore the spirit of higher-level abstraction and focus back on The Old Way (TOW): rampant pointer-level optimization to squeeze out that extra iota of performance at the expense of clarity. But wasn't the whole point of higher-level abstraction to leave this level of optimization to more intelligent compilers so that the programmer could focus on writing clear, reusable code? Why allow us to get TOW'ed back (pardon the pun)? Somebody once wrote that a clearly written, well-documented program that doesn't work is usually more valuable than a badly written, poorly-documented program that does work because it can easily be fixed and reused. It just seems that allowing programmers the ability to manipulate pointers directly is virtually hiding a Pandora's Box in C#. --Benjamin L. Russell [EMAIL PROTECTED] [EMAIL PROTECTED] Other issues aside, garbage collection is not the only form of automatic memory management. Also, garbage collection is unlikely to satisfy any need for automatic memory management in real-time systems for the foreseeable future because an extra thread on a single processor is still non-deterministic. Furthermore, embedded systems tend to be commodities, hence multiple processors are rare. In fact, a developer is lucky to have a general stack machine in an embedded system. Everything is typically based on the end price. So maybe it would be even better to be able to just turn off garbage collection altogether in some applications, if one had an alternative form of automatic memory management. Best Regards, Byron Hale [EMAIL PROTECTED]
Re: Haskell and the NGWS Runtime
Benjamin Leon Russell wrote: [example of an unsafe method in C#] Taken to an extreme, this ability could encourage some programmers to ignore the spirit of higher-level abstraction and focus back on The Old Way (TOW): rampant pointer-level optimization to squeeze out that extra iota of performance at the expense of clarity. But Java also has a way to do "rampant pointer-level optimization": You declare a method as "native" and then implement it in C. Any sensible programmer will recognize the loss of portability, safety and abstraction when writing a native method in Java, and will only do so when absolutely necessary. The same should go for "unsafe" methods in C#, UNSAFE modules in Modula-3, and "unsafePerformIO" in various Haskell implementations. C# simply provides a mechanism to write native methods within the C# language directly instead of dropping down to C. I haven't looked too closely at C#, but I would imagine that even unsafe C# has less "implementation defined" pitfalls than C and other features useful for systems hacking (e.g. exceptions), and therefore even "unsafe" C# might be a better language for doing the kinds of low-level systems hacking that Java only permits you to do in C. This was certainly true for "unsafe" modules in Modula-3. Remember, too, that not every program is written as an application on a PC. The requirement in Java that native methods be implemented in another language caused serious problems for the JavaOS and embedded / JVM-on-a-chip efforts. How do you write a device driver for a memory-mapped device in 100% pure Java? You can't. The "unsafe" provision in C# might make C# a more viable language for such systems. -antony -- Antony Courtney Grad. Student, Dept. of Computer Science, Yale University [EMAIL PROTECTED] http://www.apocalypse.org/pub/u/antony
Re: Haskell and the NGWS Runtime
Ketil Malde [EMAIL PROTECTED] wrote, "Manuel M. T. Chakravarty" [EMAIL PROTECTED] writes: A good analysis of were C# fits re Java and C++ is at http://slashdot.org/article.pl?sid=00/08/09/1612254mode=thread Wherein we read: One new feature that I mentioned already was that of copy-by-value objects. This seemingly small improvement is a potentially huge performance saver! With C++, one is regularly tempted to describe the simplest constructs as classes, and in so doing make it safer and simpler to use them. For example, a phone directory program might define a phone record as a class, and would maintain one PhoneRecord object per actual record. In Java, each and every one of those objects would be garbage collected! Now, is this really such a big problem? Is it a problem because of Java's mark-and-sweep, and if so, couldn't you apply a better GC? That's exactly what I thought. I mean why don't they read a couple of research papers? It is not so that they are the first to run into these problems. At a related issue, have a look at the memory management in the Realtime Java spec that Sun is just about to finalise. It seems they want to ignore the existence of generational and concurrent GC altogether *sigh* Manuel
GC in embedded systems (was Re: Haskell and the NGWS Runtime)
On Fri 11 Aug, Byron Hale wrote: Also, garbage collection is unlikely to satisfy any need for automatic memory management in real-time systems for the foreseeable future because an extra thread on a single processor is still non-deterministic. I'm not sure this is true, doesn't it depend on the scheduling strategy? I've written a lot of code for single and multiple processor DSP systems, and typically have multiple threads (on 1 processor). But they are still entirely deterministic. BTW, I've never really understood how it is that garbage collection is a separate thread in Java (as I've heard it is, but I have never used Java). The implication is that somehow Java progs keep running while garbage collection is performed concurrently. Is this true? If so how does this work? It seems to be a hard thing to do if the GC uses pointer some variant of mark-sweep and pointer reversal. I guess if reference counting and fixed cell size was used this could be possible, but this won't work with cyclic data structures. My objection to the use of GC (and by implication all current Haskell implementations) in embedded systems would be that if your program is sufficiently complex/powerful that it can't be implemented as some kind of _finite_ state machine, then it can never be part of a robust system (which has finite memory resources). Put simply, if you don't know how much memory you need, how can you ever be confident you have enough? Hmm, now having written that, I'm wondering how the Erlang community addressed this problem. I believe Erlang is targeted at applications which I would class as 'embedded'. Anybody know the answer? It seems a sad irony if the memory management techniques used to implement declarative languages (which are designed to ensure program 'correctness', aren't they?) also ensure program 'flakeyness' at run time (on real machines). Regards -- Adrian Hey
Re: Haskell and the NGWS Runtime
At 6:46 pm -0400 10/8/2000, Benjamin Leon Russell wrote: Somebody once wrote that a clearly written, well-documented program that doesn't work is usually more valuable than a badly written, poorly-documented program that does work because it can easily be fixed and reused. Who wrote this? Is it just a rumour or is there a reference that I can give to my students? -- Lyndon While Email - [EMAIL PROTECTED],-_|\ Phone - +61 8 9380 2720/ \ Fax- +61 8 9380 1089*_,-._/ Web- http://www.cs.uwa.edu.au/~lyndonv
Re: GC in embedded systems (was Re: Haskell and the NGWS Runtime)
At 05:21 AM 8/11/2000 +0100, you wrote: On Fri 11 Aug, Byron Hale wrote: Also, garbage collection is unlikely to satisfy any need for automatic memory management in real-time systems for the foreseeable future because an extra thread on a single processor is still non-deterministic. I'm not sure this is true, doesn't it depend on the scheduling strategy? I've written a lot of code for single and multiple processor DSP systems, and typically have multiple threads (on 1 processor). But they are still entirely deterministic. Regards -- Adrian Hey I don't mean that threads are non-deterministic, but that the execution time of a GC thread seems to be non-deterministic. Large collections need more time than small ones and the time required is some function of the store to be collected, is it not? If the store to be collected is created at a greater rate than it can be collected, then a garbage-collected system would seem to be be expected to crash eventually. ML-Kit has implemented some work on compile-time memory management using regions. I wonder if that might not be more practical than garbage collection, in real-time systems. Best Regards, Byron Hale [EMAIL PROTECTED]
Re: Haskell and the NGWS Runtime
Byron Hale [EMAIL PROTECTED] wrote, At 06:46 PM 8/10/2000 -0400, you wrote: What bothers me most about C# is that although, at first glance, it seems to be a variation on Java, it doesn't follow the spirit of Java in at least one important respect. Specifically, one common advantage of both Haskell and Java is that they encourage higher-order abstraction: Haskell through functional abstraction, and Java through eliminating explicit pointers and memory management and enforcing object orientation through the use of classes. However, according to the C# Language Reference (at http://msdn.microsoft.com/vstudio/nextgen/technology/csharpdownload.asp), "For developers who are generally content with automatic memory management but sometimes need fine-grained control or that extra iota of performance, C# provides the ability to write "unsafe" code. Such code can deal directly with pointer types, and fix objects to temporarily prevent the garbage collector from moving them." [Section 1.2] Other issues aside, garbage collection is not the only form of automatic memory management. Also, garbage collection is unlikely to satisfy any need for automatic memory management in real-time systems for the foreseeable future because an extra thread on a single processor is still non-deterministic. I am far from being an expert on realtime systems, but AFAIK the important thing is to be able to guarantee that a given operation executes in a given bounded time frame. In other words, it need not be deterministic as long as the indeterminism is within predictable bounds, ie, guaranteed to be sufficiently small. So by guaranteeing that the extra thread can take only a fixed amount of time, it should be possible to meet the realtime constraint, shouldn't it? Manuel
Re: Haskell and the NGWS Runtime
At 4:09 pm + 8/8/00, Marcin 'Qrczak' Kowalczyk wrote: Tue, 8 Aug 2000 09:17:15 +0200, Erik Meijer [EMAIL PROTECTED] pisze: You hit the nail right on the head wrt to Haskell and .NET. This is precisely why I am working on Mondrian, which also goes under the name Haskell#, a pure, lazy functional language that seamlessly fits the .NET type system. This is what worries me: modifying a bunch of languages to make them incompatible with the rest of the world, locking their users to the .NET platform. Embrace and extend. AFAIK this happened to Java, and is common in C/C++ (using own functions and types instead of ISO/ANSI). Slight misunderstanding here - Mondrian isn't a ".NET" only language, it is designed to mesh with OO languages "in general" (well -ish ;-)). The current compiler works with either Java or .NET (but not both at the same time, i.e. it runs on the JVM or the .NET VM). The Haskell.NET we are producing will also run on both (as it uses the same backend). [Roughly: a Mondrian "value" is a Java/.NET "object" - but of course when manipulated from Mondrian a value/object is immutable unless an "I/O" operation is performed.] Other languages which now target .NET also target JVM (well at least one but can't remember which it was offhand). Cheers, Nigel -- Nigel Perry, New Zealand
Re: Haskell and the NGWS Runtime
I've been following this discussion, but there are so many new buzzwords coming out of microsoft that it's a bit confusing for those not in the know. Is there a quick way to summarize the relationships between .NET NGWS C# (which I've discovered is intended to be pronounces C-sharp rather than C-hash) the .NET virtual machine COM Why does the world need C# when it already has Java and C++? Why does the world need a .NET virtual machine when it has dozens of Java Virtual Machines? Don't COM and Corba already provide interlanguage and network interoperability? Why is it important for Haskell to fit into .NET? I hope this isn't too far off topic. Cheers, Theodore Norvell Dr. Theodore Norvell[EMAIL PROTECTED] Electrical and Computer Engineering http://www.engr.mun.ca/~theo Engineering and Applied SciencePhone: (709) 737-8962 Memorial University of Newfoundland Fax: (709) 737-4042 St. John's, NF, Canada, A1B 3X5
Re: Haskell and the NGWS Runtime
At 11:01 am -0230 9/8/00, Theodore Norvell wrote: I've been following this discussion, but there are so many new buzzwords coming out of microsoft that it's a bit confusing for those not in the know. Is there a quick way to summarize the relationships between .NET The name for a whole set of stuff from MS NGWS An older temporary name for .NET. NGWS? Never Goes Wonderfully Sucks? I think somebody shot the marketing guy and replaced him, she then came up with ".NET" :-) C# (which I've discovered is intended to be pronounces C-sharp rather than C-hash) MS's version of a "better C", "better" is subjective of course ;-) the .NET virtual machine Under .NET compilers compile to IL, this is then JIT'ed and executed. "JIT" includes such options as "JIT at install time" (a new defn of JIT!). MS are keen to point out that IL code is never interpreted. COM I'm too young to know about COM, but I hear it was less than wonderful Why does the world need C# when it already has Java and C++? Who invented Java C++? Why does the world need a .NET virtual machine when it has dozens of Java Virtual Machines? Don't COM and Corba already The argument here is that .NET is designed from the ground up to support multiple languages, the JVM was not. So languages can interwork, share libraries, and even extend each others classes. How successful the .NET project has been awaits your (the public's) decision... provide interlanguage and network interoperability? Why is it important for Haskell to fit into .NET? It will make Haskell easily available to zillions of PC's run Windows while also allowing Haskell to call/be called/use libraries from C#, C++, Cobol, SML, Mecury, Object Pascal, etc., etc. That's the theory anyway. I hope this isn't too far off topic. Well we've wandered a bit in this thread already... Disclaimer: I don't speak for MS (or anybody if they get the option), read their PR. I'm typing this on a Mac in an MS office I'm visiting. I'm biased on everything. Etc. :-) -- Nigel Perry, New Zealand
Re: Haskell and the NGWS Runtime
Nigel Perry wrote: NGWS An older temporary name for .NET. NGWS? Never Goes Wonderfully Sucks? I think somebody shot the marketing guy and replaced him, she then came up with ".NET" :-) Next Generation Windows Services (I think), as opposed to older generations such as the Win32 APIs and COM. C# (which I've discovered is intended to be pronounces C-sharp rather than C-hash) MS's version of a "better C", "better" is subjective of course ;-) More of a "better Java", really. I haven't looked at C# in any great detail, but as a language it does seem to be a bit better than Java from MY particular subjective viewpoint, aside from its current complete lack of portability. (Somehow I doubt that Microsoft will actually create, or allow anyone else to create, a really good Mac or .*n[iu]x version of it. That would conflict with their desire to have Windows conquer the universe.) the .NET virtual machine Under .NET compilers compile to IL, this is then JIT'ed and executed. "JIT" includes such options as "JIT at install time" (a new defn of JIT!). MS are keen to point out that IL code is never interpreted. Yes, this is nice. Compiling as part of installation is a cool option. Of course, JIT at runtime is probably preferable when you're downloading web app(let)s, which I assume the .NET infrastructure is meant to support. COM I'm too young to know about COM, but I hear it was less than wonderful COM is/was Common Object Model, a language-independent (though somewhat C/C++-biased) binary-compatibility standard for object interfaces. Related terms include OLE (Object Linking and Embedding) and ActiveX, both of which are particular subclasses/extensions of COM. Working with COM is sort of a pain, and the extra levels of indirection and data transformations it requires degrade performance to a noticeable extent. There are tons of COM objects built into Windows, by the way, which may partially explain why Windows is such a pig. Why does the world need C# when it already has Java and C++? Who invented Java C++? Good answer, but let's consider the history and purpose of these things a bit... C++ was invented (by Stroustrop at Bell Labs) because he wanted to add objects to C, while retaining near-perfect backward-compatibility at the source level (i.e., nearly all legal C programs should be legal C++ as well, aside from conflicts caused by new keywords in C++ that are legal variable names in C). It has since grown to include exceptions, templates, and other capabilities that are orthogonal to object-orientation but were considered good things to have. The resulting language, in some people's opinions (mine included) is a chaotic mess of conflicting features that is hard to learn and use. Java was Gosling's attempt to make a more pure OO language than C++ while still retaining C-like syntax. He discarded what he considered "mistakes" in C++, such as multiple inheritance, backward-compatibility with C, and the "const" keyword; added some mistakes of his own; and neglected to fix a number of syntactic uglinesses inherited from C, such as the need to put "break;" at the end of every case in a switch statement. His superiors at Sun then marketed Java as a revolution in language design, which it was not, and as a Windows-killer, which it was not. What it was and is, IMHO, is a mediocre language created with minimal ingenuity and no really new ideas. C# is Microsoft's attempt at a Java-killer. It isn't really all that different from Java, but as Nigel says below, its virtual machine is intended to support more languages than just C#, whereas the JVM was designed just for Java, and getting other languages to compile to JVM can be a bit of a struggle. Syntactically, C# seems a bit cleaner than Java, but the differences don't really add up to much. Why does the world need a .NET virtual machine when it has dozens of Java Virtual Machines? Don't COM and Corba already The argument here is that .NET is designed from the ground up to support multiple languages, the JVM was not. So languages can interwork, share libraries, and even extend each others classes. And CORBA isn't a Microsoft product, nor is it supported by any Microsoft product, so Microsoft prefers to ignore it. This is not to say whether CORBA is good or bad, as I haven't worked with it. I do think, though, that Microsoft's idea of using a VM-based intermediate language, rather than a low-level binary compatibility standard such as CORBA or COM, is a better way of getting different languages to work together. Craig
Re: Haskell and the NGWS Runtime
[EMAIL PROTECTED] (Marcin 'Qrczak' Kowalczyk) writes: Tue, 8 Aug 2000 09:17:15 +0200, Erik Meijer [EMAIL PROTECTED] pisze: Haskell# This is what worries me: modifying a bunch of languages to make them incompatible with the rest of the world How did they say on segfault.org: Microsoft plans to expand Marketese in the future, adding a pound sign to every language currently in their suite of compilers and a plus sign to every acronym currently used to describe Microsoft technology. http://www.segfault.org/story.phtml?mode=2id=39897e26-060c53e0 :-) Yours, Florian
Re: Haskell and the NGWS Runtime
[discussion of benefits and otherwise of .NET, C#, ..] They have definitely managed to attract some attention, haven't they?-) If we put language and other wars aside for the moment, there are a few questions that haven't come up yet, the answers to which would interest me (and seem relevant for this list): 1. once upon a time, some fearless Haskell implementers decided that C is only almost a suitable portable assembler, and started to work on an alternative design for that purpose, named C--. Some of you have moved to Microsoft research labs, so is there any chance that your ideas and experience had any influence on the designs of .NET? Or did other parts of MS invented everything (including problems) again, from scratch? 2. several non-oo languages seem to be in the process of acquiring an implementation on top of C# or on top of the .NET VM. Most developers have expressed mixed feelings here about the suitability of the target, as far as language independence is concerned (bias towards oo and procedural languages, etc.). May I assume that any problems you've found will be fed back to the .NET developers before everything gets frozen? By announcing your various language re-targetting efforts, you provide the support that the new platform depends on. In contrast to Java, .NET advertizes language independence, your compilation efforts come early in the race, _and_ MS has quite a few researchers interested in declarative programming. So if all of you could get your weight together and publish an experts' report on how the platform could be improved so that your efforts could add value for its customers, that might have quite some influence if you do it early enough (ask the Pizza shop what it means to be late;-). Or is it too late already? It would really be a pity to have yet another (more or less portable) platform out there that featured problems for implementing functional languages by design. Claus
Re: Haskell and the NGWS Runtime
Theodore Norvell [EMAIL PROTECTED] wrote, I've been following this discussion, but there are so many new buzzwords coming out of microsoft that it's a bit confusing for those not in the know. That's part of the masterplan ;-) Is there a quick way to summarize the relationships between .NET NGWS C# (which I've discovered is intended to be pronounces C-sharp rather than C-hash) the .NET virtual machine COM Why does the world need C# when it already has Java and C++? A good analysis of were C# fits re Java and C++ is at http://slashdot.org/article.pl?sid=00/08/09/1612254mode=thread Manuel
Re: Haskell and the NGWS Runtime
On 09-Aug-2000, Brent Fulgham [EMAIL PROTECTED] wrote: Prepare for rant Hopefully that won't be the case. However, I feel uncomfortable with the whole .NET/C# situation. Like clockwork, MS releases yet another new product that they claim will change the world. Meanwhile, there is no C# implementation available, and the entire .NET framework as described in their various white papers seems so large and complex that probably only Microsoft will be capable of producing a working implementation in any reasonable amount of time. You can download it here: http://msdn.microsoft.com/net/#sdk There is a C# compiler and runtime environment in the SDK. They used to say that only proprietary companies could possibly write something so large and complex as an operating system. It could never be done, for example, by a bunch of volunteers... Microsoft indicates that C# will not support "genericity", through even anything as crude as C++'s templates, so it is unlikely that they will seek to support functional programming languages in the short term. Perhaps this limitation is part of the impetus for the Mondrian variant. They did add a tailcall instruction largely at the behest of certain functional language researchers at MSR Cambridge. They have developed a prototype C# implementation (and hence .NET runtime) with generics too. When Microsoft decides to stop playing games, and works with the rest of the developer community to build on existing standards for their products I will start to pay attention. Until then, I will not waste one minute of time working to support any of their nefarious new products whose true aim is to prevent alternative platforms from gaining widespread acceptance and use. Microsoft spent around $2M funding a bunch of groups working on research and industrial programming languages to give feedback on their work. (Haskell, Mercury, ML, Scheme, Oberon, Eiffel, Python, Oz, etc...) While they acknowledged from the start that getting any changes (apart from tailcall) into version 1 was pretty unlikely, they have been listening, taking notes, and even now the C# folks are getting excited about the idea of putting generics into the language. I understand your sentiment. Those of use working on the .NET stuff with Microsoft are also uncomfortable about the situation. However I'm sure that everyone involved is doing what they think is the best thing overall. Don't forget that many groups developed a .NET and a JVM backend at the same time using Microsoft's money! -- Tyson Dowd # # Surreal humour isn't everyone's cup of fur. [EMAIL PROTECTED]# http://www.cs.mu.oz.au/~trd #
Re: Haskell and the NGWS Runtime
Tue, 8 Aug 2000 09:17:15 +0200, Erik Meijer [EMAIL PROTECTED] pisze:
You hit the nail right on the head wrt to Haskell and .NET. This is
precisely why I am working on Mondrian, which also goes under the name
Haskell#, a pure, lazy functional language that seamlessly fits the .NET
type system.
This is what worries me: modifying a bunch of languages to make them
incompatible with the rest of the world, locking their users to the
.NET platform. Embrace and extend. AFAIK this happened to Java, and
is common in C/C++ (using own functions and types instead of ISO/ANSI).
--
__(" Marcin Kowalczyk * [EMAIL PROTECTED] http://qrczak.ids.net.pl/
\__/
^^ SYGNATURA ZASTPCZA
QRCZAK
Re: Haskell and the NGWS Runtime
"Chris Saunders" [EMAIL PROTECTED] writes: It seems to me that this .Net thingy is a runtime and therefore could potentially be as portable as anything from Java. Potentially, yes. This runtime just needs to be ported to other operating systems similarily to the Java runtime. So it's a question of either source availability - or at least a very complete specification - or Microsoft strategy. -kzm -- If I haven't seen further, it is by standing in the footprints of giants
RE: Haskell and the NGWS Runtime
It is not what language that you want on your phone that matters -- you
didn't write the software. What matters is any development team can pick
the language they prefer to use and make their software portable to your
phone or your PC.
-Original Message-
From: Nigel Perry [mailto:[EMAIL PROTECTED]]
Sent: Friday, August 04, 2000 12:54 AM
To: [EMAIL PROTECTED]
Subject: Re: Haskell and the NGWS Runtime
We're drifting a bit off Haskell here, but...
At 10:57 am +1000 4/8/00, Kevin Glynn wrote:
I don't believe this says anything about support for other OS's. I
think the devices here are hardware, (PCs, handhelds, phones, fridge
interfaces, ...) Of course Microsoft believes that some day, very
soon, all devices will run (a version of) Windows. Hence this
statement refers to Microsoft's announced plans to port .NET to all
Windows OS's, including WinCE.
Do you have another reference which is more convincing?
I haven't seen a WinCE version but at a recent conference one of the
exhibitors was offering a .NET on WindowsCE course - however when I
inquired they just said "ask MS, we don't know, we just teach the
courses" (somehow I don't think I'll be recommending them!) So that's
not too convincing!
They are talking phones - but that has to be a stripped down version.
However I'm not sure why I want Haskell on my phone ("the phone with
higher-order polymorphic lazy dialing"?)
As to others OSES...
At 10:24 pm -0400 3/8/00, Chris Saunders wrote:
It seems to me that this .Net thingy is a runtime
and therefore could potentially be as portable
as anything from Java. This runtime just needs
to be ported to other operating systems similarily
to the Java runtime.
Porting JVM is a big enough job (you find a lot of "native"
methods...) .NET has more paraphernalia than the JVM so it will be
quite a job. However I think MS is moving to "standardise" the IL
(the byte codes) which I guess is to suggest it is not a moving
target (not the the JVM really is but I hear the lack of JVM 2's has
been blamed on lack of info out of Sun - but that might be just
passing the blame)
At 5:59 pm +0200 3/8/00, Juan J. Quintela wrote:
nigel Disclaimer, as Fergus added one: I am working with Microsoft on .NET
nigel implementation, but I run Windows 2000 on my G3 PowerBook and take
it
nigel to Microsoft with me. I'm biased on everything :-)
Windows 2000 in a G3 Powerbook? I am lost here :((
Why have any other computer when you can have a Mac?
Mine runs:
DVD Movies
MacOS
JVM
Playstation games
Windows 95
Windows 2000 (a bit slugglish)
and could run:
Linux (but I have no use for it at present)
At 2:07 am +1000 4/8/00, Fergus Henderson wrote:
Note that on x86 there are only six general purpose registers,
so you very quickly run out...
Who uses the x86? Oh I remember... ;-)
Cheers,
Nigel
--
--
Dr Nigel PerryEmail: [EMAIL PROTECTED]
IIST Tel: +64 6 350 5799 2477
Massey University Fax: +64 6 350 2259
Palmerston North FTP/WWW: smis-asterix.massey.ac.nz
New Zealand
It makes as much sense to wear a "cycle" style helmet in a car as on a
bike...
Choosing to wear one on a bike but not in a car is mere inconsistency.
Refusing to wear one in a car while insisting others do so on a bike
is pure hypocrisy.
Will the new Labour government repeal the National government's hypocrisy,
or will they insult cyclists' like their predecessors?
Politics and hypocrisy before safety - the NZ Helmet Law, NZ's Shame
RE: Haskell and the NGWS Runtime
Back to the language wars then. It does seem like integration of Haskell and the NGWS is a graunch, largely because Haskell is not OO. Is there anything preventing Haskell from becoming OO and seamlessly fitting into the NGWS? Or from designing a functional language that would be a good fit into the NGWS. A major problem I see is that there is probably a standard set of container classes in NGWS which have a high impedance mismatch with the lists functional languags use for their constructions. Can we ever have functional programming "in the large" given the OO paradigm and NGWS are both here to stay? This can not happen until I can get a language which seamlessly fits into NGWS (or some similar thing on a non-windows platform). -Original Message- From: Antony Courtney [mailto:[EMAIL PROTECTED]] Sent: Sunday, August 06, 2000 3:49 PM To: Jürgen A. Erhard Cc: [EMAIL PROTECTED] Subject: Re: Haskell and the NGWS Runtime "Jürgen A. Erhard" wrote: "Manuel" == Manuel M T Chakravarty [EMAIL PROTECTED] writes: Manuel "Erik Meijer" [EMAIL PROTECTED] wrote, [...] The lab is *sponsored* by Microsoft, but definitively not *at* Microsoft. I doubt there are any Linux boxes at Microsoft :-) Manuel [...] There have also been reports of Linux boxes in the main Manuel company, but the validity of these reports is of course not But easy to believe... I mean, wouldn't you take a good look at your competition? Having spent five years doing Windows and Win32 hacking, and 10+ years doing Unix hacking before that, I can assure you there is little evidence that Microsoft are interested in learning anything whatsoever from Linux or any other Unix work-alike. Rather than re-iterate the argument, I'll simply point interested readers towards the excellent article "Working with Win32: the good, the bad and the ugly" by David G. Korn http://www.usenix.org/publications/login/1997-11/win32.html which mostly reinforces the quote: Those who do not understand Unix are condemned to reinvent it, poorly. -- Henry Spencer Now that I've gotten MY little barb in, can we PLEASE end this tangent on OS wars, and return to our regularly scheduled language wars? :-) Thanks, -Antony (haskell list lurker) -- Antony Courtney [EMAIL PROTECTED] http://www.apocalypse.org/pub/u/antony
Re: Haskell and the NGWS Runtime
"Erik Meijer" [EMAIL PROTECTED] wrote, I'm weird, but not a true 'CS' person. I run Linux -- do I need to move to NetBSD? The single Linux box we have in the Microsoft lab was severely hacked from the outside, they have moved to FreeBSD, which is supposed to be safer (I hope so). Morale: Never trust a Linux box at Microsoft :-) Manuel
Re: Haskell and the NGWS Runtime
"Erik Meijer" [EMAIL PROTECTED] wrote, The single Linux box we have in the Microsoft lab was severely hacked from the outside, they have moved to FreeBSD, which is supposed to be safer (I hope so). Morale: Never trust a Linux box at Microsoft :-) The lab is *sponsored* by Microsoft, but definitively not *at* Microsoft. I doubt there are any Linux boxes at Microsoft :-) Now define Microsoft. There definitely are Linux boxes at Microsoft Research, as we all know :-) There have also been reports of Linux boxes in the main company, but the validity of these reports is of course not easy to verify. Manuel
Re: Haskell and the NGWS Runtime
"Manuel" == Manuel M T Chakravarty [EMAIL PROTECTED] writes: Manuel "Erik Meijer" [EMAIL PROTECTED] wrote, The single Linux box we have in the Microsoft lab was severely hacked from the outside, they have moved to FreeBSD, which is supposed to be safer (I hope so). Morale: Never trust a Linux box at Microsoft :-) The lab is *sponsored* by Microsoft, but definitively not *at* Microsoft. I doubt there are any Linux boxes at Microsoft :-) Manuel Now define Microsoft. There definitely are Linux boxes at Manuel Microsoft Research, as we all know :-) Manuel There have also been reports of Linux boxes in the main Manuel company, but the validity of these reports is of course not Manuel easy to verify. But easy to believe... I mean, wouldn't you take a good look at your competition? (Of course, Linux is no competition to Windows... or rather the other 'round ;-) Bye, J -- Jürgen A. Erhard eMail: [EMAIL PROTECTED] phone: (GERMANY) 0721 27326 MARS: http://members.tripod.com/Juergen_Erhard/mars_index.html "We must learn from our mistakes, so we can make bigger and better ones." -- Bruce M Krawetz PGP signature
Re: Haskell and the NGWS Runtime
"Jürgen A. Erhard" wrote: "Manuel" == Manuel M T Chakravarty [EMAIL PROTECTED] writes: Manuel "Erik Meijer" [EMAIL PROTECTED] wrote, [...] The lab is *sponsored* by Microsoft, but definitively not *at* Microsoft. I doubt there are any Linux boxes at Microsoft :-) Manuel [...] There have also been reports of Linux boxes in the main Manuel company, but the validity of these reports is of course not But easy to believe... I mean, wouldn't you take a good look at your competition? Having spent five years doing Windows and Win32 hacking, and 10+ years doing Unix hacking before that, I can assure you there is little evidence that Microsoft are interested in learning anything whatsoever from Linux or any other Unix work-alike. Rather than re-iterate the argument, I'll simply point interested readers towards the excellent article "Working with Win32: the good, the bad and the ugly" by David G. Korn http://www.usenix.org/publications/login/1997-11/win32.html which mostly reinforces the quote: Those who do not understand Unix are condemned to reinvent it, poorly. -- Henry Spencer Now that I've gotten MY little barb in, can we PLEASE end this tangent on OS wars, and return to our regularly scheduled language wars? :-) Thanks, -Antony (haskell list lurker) -- Antony Courtney [EMAIL PROTECTED] http://www.apocalypse.org/pub/u/antony
Re: Haskell and the NGWS Runtime
I'm weird, but not a true 'CS' person. I run Linux -- do I need to move to NetBSD? The single Linux box we have in the Microsoft lab was severely hacked from the outside, they have moved to FreeBSD, which is supposed to be safer (I hope so). Erik
Re: Haskell and the NGWS Runtime
Why not Linux? Regards Chris Saunders [EMAIL PROTECTED] - Original Message - From: "Bill Halchin" [EMAIL PROTECTED] To: [EMAIL PROTECTED] Cc: [EMAIL PROTECTED] Sent: Thursday, August 03, 2000 10:49 PM Subject: Re: Haskell and the NGWS Runtime To Linux? :^) From: "Chris Saunders" [EMAIL PROTECTED] To: [EMAIL PROTECTED], "Erik Meijer" [EMAIL PROTECTED] CC: "Marcin 'Qrczak' Kowalczyk" [EMAIL PROTECTED], [EMAIL PROTECTED] Subject: Re: Haskell and the NGWS Runtime Date: Thu, 3 Aug 2000 22:24:14 -0400 It seems to me that this .Net thingy is a runtime and therefore could potentially be as portable as anything from Java. This runtime just needs to be ported to other operating systems similarily to the Java runtime. Regards Chris Saunders [EMAIL PROTECTED] - Original Message - From: "Kevin Glynn" [EMAIL PROTECTED] To: "Erik Meijer" [EMAIL PROTECTED] Cc: "Marcin 'Qrczak' Kowalczyk" [EMAIL PROTECTED]; [EMAIL PROTECTED] Sent: Thursday, August 03, 2000 8:57 PM Subject: Re: Haskell and the NGWS Runtime I don't believe this says anything about support for other OS's. I think the devices here are hardware, (PCs, handhelds, phones, fridge interfaces, ...) Of course Microsoft believes that some day, very soon, all devices will run (a version of) Windows. Hence this statement refers to Microsoft's announced plans to port .NET to all Windows OS's, including WinCE. Do you have another reference which is more convincing? k Erik Meijer writes: Not "at least" but "only". I haven't heard of plans for .NET on any non-Windows platform. Then you should listen more closely! a quote from the .NET whitepaper: Microsoft .NET proactively adapts to what you want to do, on any of your devices. This inversion of the traditional installation-dependent application model is a necessity in a world where users will enjoy the benefits of services on multiple devices. http://www.microsoft.com/net/ Erik Get Your Private, Free E-mail from MSN Hotmail at http://www.hotmail.com
RE: Haskell and the NGWS Runtime
A few comments on this (stuff after the line beneath): The C implementation isn't really that inefficient. A factor of log(n) in average of course a factor of n i worst case. This doesn't change when using a lazy language! because of the nature of quicksort. As a matter of fact you have to have a "nice" version of merge sort (there are several variants - see fx Ralf Hinze, A Data-structural Look at Sorting, 1998, I don't know if it has been published except on this list) to be sure that (hd (sort list)) runs in time O(n). But, you are right a degree in CS doesn't guarantee that you know about complexity, but neither does programming in a lazy language. Personally I'm programming large systems in Prolog (www.pdc.dk) upto 150K lines. We try to make programs readable and correct firstmost, when they are too slow we measure where and fix it. Carsten Kehler Holst Fergus wrote: I guess one could argue that the costs of most other things pale in comparison to the costs of having lazy evaluation as the default ;-) Of course, if you're the sort of person who likes to write "head (sort lst)" to get the least member of a list, then lazy evaluation is incredibly efficient. Getting used to lazy evaluation, and really learning how to use it properly, is probably really the hardest thing about Haskell for someone who has already learned how to program using strict languages. Possibly even harder than monads. Funny/sad anecdote: I once saw a senior software engineer with over 15 years of C experience and a master's degree in CS, write the following code in C to locate the least member of an array: qsort(array, sizeof(array) / sizeof(array[0]), sizeof(array[0]), comparator); least = array[0]; Essentially, this is just "head (sort lst)" in C, which, as I daresay we all know, is NOT a lazy language! I actually had to explain to her why it was inefficient. Depending how you look at it, this is either strong evidence that lazy evaluation is a more natural way to think than strict evaluation, or proof that a master's in CS doesn't necessarily mean you really know anything about programming. Craig
Re: Haskell and the NGWS Runtime
We're drifting a bit off Haskell here, but...
At 10:57 am +1000 4/8/00, Kevin Glynn wrote:
I don't believe this says anything about support for other OS's. I
think the devices here are hardware, (PCs, handhelds, phones, fridge
interfaces, ...) Of course Microsoft believes that some day, very
soon, all devices will run (a version of) Windows. Hence this
statement refers to Microsoft's announced plans to port .NET to all
Windows OS's, including WinCE.
Do you have another reference which is more convincing?
I haven't seen a WinCE version but at a recent conference one of the
exhibitors was offering a .NET on WindowsCE course - however when I
inquired they just said "ask MS, we don't know, we just teach the
courses" (somehow I don't think I'll be recommending them!) So that's
not too convincing!
They are talking phones - but that has to be a stripped down version.
However I'm not sure why I want Haskell on my phone ("the phone with
higher-order polymorphic lazy dialing"?)
As to others OSES...
At 10:24 pm -0400 3/8/00, Chris Saunders wrote:
It seems to me that this .Net thingy is a runtime
and therefore could potentially be as portable
as anything from Java. This runtime just needs
to be ported to other operating systems similarily
to the Java runtime.
Porting JVM is a big enough job (you find a lot of "native"
methods...) .NET has more paraphernalia than the JVM so it will be
quite a job. However I think MS is moving to "standardise" the IL
(the byte codes) which I guess is to suggest it is not a moving
target (not the the JVM really is but I hear the lack of JVM 2's has
been blamed on lack of info out of Sun - but that might be just
passing the blame)
At 5:59 pm +0200 3/8/00, Juan J. Quintela wrote:
nigel Disclaimer, as Fergus added one: I am working with Microsoft on .NET
nigel implementation, but I run Windows 2000 on my G3 PowerBook and take it
nigel to Microsoft with me. I'm biased on everything :-)
Windows 2000 in a G3 Powerbook? I am lost here :((
Why have any other computer when you can have a Mac?
Mine runs:
DVD Movies
MacOS
JVM
Playstation games
Windows 95
Windows 2000 (a bit slugglish)
and could run:
Linux (but I have no use for it at present)
At 2:07 am +1000 4/8/00, Fergus Henderson wrote:
Note that on x86 there are only six general purpose registers,
so you very quickly run out...
Who uses the x86? Oh I remember... ;-)
Cheers,
Nigel
--
--
Dr Nigel PerryEmail: [EMAIL PROTECTED]
IIST Tel: +64 6 350 5799 2477
Massey University Fax: +64 6 350 2259
Palmerston North FTP/WWW: smis-asterix.massey.ac.nz
New Zealand
It makes as much sense to wear a "cycle" style helmet in a car as on a bike...
Choosing to wear one on a bike but not in a car is mere inconsistency.
Refusing to wear one in a car while insisting others do so on a bike
is pure hypocrisy.
Will the new Labour government repeal the National government's hypocrisy,
or will they insult cyclists' like their predecessors?
Politics and hypocrisy before safety - the NZ Helmet Law, NZ's Shame
Re: Haskell and the NGWS Runtime
Why have any other computer when you can have a Mac? Mine runs: DVD Movies MacOS JVM Playstation games Windows 95 Windows 2000 (a bit slugglish) and could run: Linux (but I have no use for it at present) I notice that your Mac can run a lot of things, but among the things you actually run there is only one operating system (Win 2k). :) But I agree, Macs are cool. -- Lennart
Re: Haskell and the NGWS Runtime
Why have any other computer when you can have a Mac? Mine runs: DVD Movies MacOS JVM Playstation games Windows 95 Windows 2000 (a bit slugglish) and could run: Linux (but I have no use for it at present) I notice that your Mac can run a lot of things, but among the things you actually run there is only one operating system (Win 2k). :) Weird, nobody mentioned neither NetBSD nor OpenBSD... CS people are weird. :-) Cheers, Edrx http://angg.twu.net/ -- Recycle your keystrokes - http://angg.twu.net/eev-manifesto.html
Re: Haskell and the NGWS Runtime
Eduardo Nahum Ochs wrote: Why have any other computer when you can have a Mac? Mine runs: DVD Movies MacOS JVM Playstation games Windows 95 Windows 2000 (a bit slugglish) and could run: Linux (but I have no use for it at present) I notice that your Mac can run a lot of things, but among the things you actually run there is only one operating system (Win 2k). :) Weird, nobody mentioned neither NetBSD nor OpenBSD... CS people are weird. :-) I consider myself a CS person and I run NetBSD on all my machines. And I'm also weird. -- -- Lennart
RE: Haskell and the NGWS Runtime
Weird, nobody mentioned neither NetBSD nor OpenBSD... CS people are weird. :-) I consider myself a CS person and I run NetBSD on all my machines. And I'm also weird. I'm weird, but not a true 'CS' person. I run Linux -- do I need to move to NetBSD? -Brent
Re: Haskell and the NGWS Runtime
GOO is not a Microsoft invention, and nor is it part of Microsoft's .NET stuff. GOO is an intermediate language that was, AFAIK, invented by the Mondrian group. It might be described in the following paper: Erik Meijer and Koen Claessen. The Design and Implementation of Mondrian. In Proc. Haskell Workshop, 1997. To follow on and answer Fergus' comments: GOO originally was simply a Haskell AST of a simplification of Java/C#, nothing more, nothing less. It was used inside one version of the Mondrain compiler, and it migrated into GHC as part of the .NET effort. The GHC version of GOO quickly moved away for the Mondrain version, as development continued (specifically, the GHC GOO was typed, so it could support the unboxed types used deep inside GHC) So, GOO was just a name for an intermediate language. It was used as part of the .NET effort, but was an internal to Haskell thing, not a MS thing. I think that GOO was broadly equivalent to the low level intermediate language in the Mercury compiler; a nice language to generate just before dumping out code. At least Haskell has interesting names for its intermediate languages :-) Andy Gill Haskell Compiler Hacker
Re: Haskell and the NGWS Runtime
Well Erik Fergus seem to be into a "my language/implementation" is better than yours battle ;-) while some others are confused as to what they're talking about. Not to prolong it, but let's see if I can clarify a few issues (ROTW: I wrote the Mondrian - C# bit [and other odds'n'endz]) At 6:48 pm +1000 2/8/00, Fergus Henderson wrote: On 02-Aug-2000, Erik Meijer [EMAIL PROTECTED] wrote: The compiler hooks into GHC by translating Core into GOO and then after some source to source transformations it can spit out either C# or Java. Hmm... am I right to presume you mean that it will support Haskell? What about ghc's extensions, such as unboxed types? Will it support those? Unboxed: from Haskell's point of view yes. Explanation: constants are unboxed in GOO and GOO provides unboxed parameter passing. However (ssh!) the GOO VM currently does a hidden box/unbox behind the scenes when parameters are passed. It doesn't *need* to do this, but there are reasons for the current choice. Depending on performance this may get changed. I understand that point, but if doing that means that you need to implement the basic things like argument passing and procedure calling yourself, using your own virtual machine, rather than by using the underlying runtime's argument passing and procedure calling mechanisms, then I'd say that it is looking more like putting a round peg in a square hole than a good fit. Passing arguments on a separate stack is pretty lightweight. It's there to support currying. If you call a function with its arguments we could use the .NET stack. Such an optimisation falls out of a typical (well out of the one I developed and used in Massey Hope+C anyway) usage analysis (which gives you other things as well). I expect such an optimisation will be added as the system is developed and more engineering (as opposed to research) is done. snip a lot about glue code (Note that currently you _do_ need to write glue code when calling other languages from Mercury. But you don't need to write glue code when calling Mercury from other languages. We also plan to automate the generation of glue code when calling other languages from Mercury, so that you won't need to write any of it manually.) Well from this it seems you have the opposite of what we have at the moment - calling other languages from Mondrian is automatic, the other way you currently have to write the glue. Of course it should be done both ways - pity we're not working on the same language as we both seem to have 50% done... Indeed. But will your implementation even meet the specification for a CLS consumer? Almost does already I think - we don't support enumerated types or arrays directly in Mondrian but you could call another language function which returned them and then pass them onto other external functions which did something to them. Otherwise you can create objects access the member functions, fields and properties. You can all a method which takes unboxed values and Mondrian's boxed ones will be automagically unboxed. It's pretty hard not to be a CLS consumer modulo a few types. Haskell.NET is still a work-in-progress, but's its coming along (it uses the same code generator and runtime as Mondrian.NET) As to those of you completely confused a quick translation guide: .NET = JVM with support for stack allocated structures and any language you like - provided you can make it look like Java (sorry C#), C# = Java with all your old favourite C heiroglyphics (bet I spelt that wrong!) and some added extras (like "const" and "read only" modes) to help you obfuscate your code. More seriously as a number of languages are being produced to run over .NET along with a whole slew of libraries it provides a good platform to target your favourite research language at (for Windows platforms at least). This may help get your research language used (e.g. Haskell in this case). However like the JVM it is fundamentally OO so you may need to develop derivatives of your language designed to better interoperate in an OO world (aka. Mondrian/Haskell# in this case) - unless your research language is Object Pascal (produced for .NET by Queensland). Disclaimer, as Fergus added one: I am working with Microsoft on .NET implementation, but I run Windows 2000 on my G3 PowerBook and take it to Microsoft with me. I'm biased on everything :-) Cheers, Nigel -- -- Nigel Perry, New Zealand
Re: Haskell and the NGWS Runtime
"nigel" == Nigel Perry [EMAIL PROTECTED] writes: nigel Disclaimer, as Fergus added one: I am working with Microsoft on .NET nigel implementation, but I run Windows 2000 on my G3 PowerBook and take it nigel to Microsoft with me. I'm biased on everything :-) Windows 2000 in a G3 Powerbook? I am lost here :(( Later, Juan. -- In theory, practice and theory are the same, but in practice they are different -- Larry McVoy
Re: Haskell and the NGWS Runtime
On 03-Aug-2000, Nigel Perry [EMAIL PROTECTED] wrote: I understand that point, but if doing that means that you need to implement the basic things like argument passing and procedure calling yourself, using your own virtual machine, rather than by using the underlying runtime's argument passing and procedure calling mechanisms, then I'd say that it is looking more like putting a round peg in a square hole than a good fit. Passing arguments on a separate stack is pretty lightweight. Well, I'm not sure that's true. Consider what you pay: - If you only have one stack, then the stack needs to be a stack of Object, and so for every argument that you put on the stack you need to - box it before putting it on the stack (if it is not already boxed) - downcast it to the right type after taking it off the stack - unbox it (if the type is an unboxed type) (If you use more than one stack, this can reduce such costs; but doing that increases the complexity of the approach significantly, and there are some significant costs in terms of performance from using multiple stacks that need to be weighed against the potential benefits.) - To get efficient access to your stack, you need to use at least one extra register to hold your stack pointer, or (quite likely) two extra registers, one for the array base and one for the offset. Note that on x86 there are only six general purpose registers, so you very quickly run out... Alternatively, if these are not in registers, then the cost of accessing the stack will be higher. - By not using the system stack, you reduce locality. This shows up in the greater register pressure (see above), and can also lead to more cache misses or cache collisions. - If the stack is an array, then (at least for verified code) every push and pop needs a bounds check. - Because of aliasing issues, the .NET runtime is very unlikely to optimize away the pushes and pops to your stack when it inlines methods. And indeed it will treat these pushes and pops as more expensive than ordinary argument passing (since they are!), and so it will be less inclined to inline such methods in the first place. Of course, doing a good job of inlining in the Haskell compiler will help reduce the damage here, but the Haskell compiler can't do cross-language inlining, and can't do JIT-time inlining across different assemblies or of dynamically loaded code, so you will still lose out in some scenarios. However, I guess it depends on what you mean by "light-weight". I guess one could argue that the costs of most other things pale in comparison to the costs of having lazy evaluation as the default ;-) -- Fergus Henderson [EMAIL PROTECTED] | "I have always known that the pursuit WWW: http://www.cs.mu.oz.au/~fjh | of excellence is a lethal habit" PGP: finger [EMAIL PROTECTED]| -- the last words of T. S. Garp.
Re: Haskell and the NGWS Runtime
Fergus wrote: I guess one could argue that the costs of most other things pale in comparison to the costs of having lazy evaluation as the default ;-) Of course, if you're the sort of person who likes to write "head (sort lst)" to get the least member of a list, then lazy evaluation is incredibly efficient. Getting used to lazy evaluation, and really learning how to use it properly, is probably really the hardest thing about Haskell for someone who has already learned how to program using strict languages. Possibly even harder than monads. Funny/sad anecdote: I once saw a senior software engineer with over 15 years of C experience and a master's degree in CS, write the following code in C to locate the least member of an array: qsort(array, sizeof(array) / sizeof(array[0]), sizeof(array[0]), comparator); least = array[0]; Essentially, this is just "head (sort lst)" in C, which, as I daresay we all know, is NOT a lazy language! I actually had to explain to her why it was inefficient. Depending how you look at it, this is either strong evidence that lazy evaluation is a more natural way to think than strict evaluation, or proof that a master's in CS doesn't necessarily mean you really know anything about programming. Craig
Re: Haskell and the NGWS Runtime
Thu, 3 Aug 2000 17:06:54 +0200, Nigel Perry [EMAIL PROTECTED] pisze:
More seriously as a number of languages are being produced to run
over .NET along with a whole slew of libraries it provides a good
platform to target your favourite research language at (for Windows
platforms at least).
Not "at least" but "only". I haven't heard of plans for .NET on any
non-Windows platform.
--
__(" Marcin Kowalczyk * [EMAIL PROTECTED] http://qrczak.ids.net.pl/
\__/
^^ SYGNATURA ZASTPCZA
QRCZAK
Re: Haskell and the NGWS Runtime
Not "at least" but "only". I haven't heard of plans for .NET on any non-Windows platform. Then you should listen more closely! a quote from the .NET whitepaper: Microsoft .NET proactively adapts to what you want to do, on any of your devices. This inversion of the traditional installation-dependent application model is a necessity in a world where users will enjoy the benefits of services on multiple devices. http://www.microsoft.com/net/ Erik
Re: Haskell and the NGWS Runtime
nigel Disclaimer, as Fergus added one: I am working with Microsoft on .NET nigel implementation, but I run Windows 2000 on my G3 PowerBook and take it nigel to Microsoft with me. I'm biased on everything :-) Windows 2000 in a G3 Powerbook? I am lost here :(( No, Nigel is not breaking an NDA by accident and revealing that MS has ported W2K to the PowerPC. He uses VirtualPC (which effectively *is* a port of W2K to the PowerPC in some sense). Erik
Re: Haskell and the NGWS Runtime
Thu, 3 Aug 2000 22:53:45 +0200, Erik Meijer [EMAIL PROTECTED] pisze:
http://www.microsoft.com/net/
I still have not found anything suggesting that tools needed for
working with that (e.g. the common runtime) will be available for
non-Windows OSes. Who will make them? Microsoft?
--
__(" Marcin Kowalczyk * [EMAIL PROTECTED] http://qrczak.ids.net.pl/
\__/
^^ SYGNATURA ZASTPCZA
QRCZAK
Re: Haskell and the NGWS Runtime
I agree.
Bill Halchin
From: [EMAIL PROTECTED] (Marcin 'Qrczak' Kowalczyk)
To: [EMAIL PROTECTED]
Subject: Re: Haskell and the NGWS Runtime
Date: 3 Aug 2000 22:01:36 GMT
Thu, 3 Aug 2000 22:53:45 +0200, Erik Meijer [EMAIL PROTECTED] pisze:
http://www.microsoft.com/net/
I still have not found anything suggesting that tools needed for
working with that (e.g. the common runtime) will be available for
non-Windows OSes. Who will make them? Microsoft?
--
__(" Marcin Kowalczyk * [EMAIL PROTECTED] http://qrczak.ids.net.pl/
\__/
^^ SYGNATURA ZASTÊPCZA
QRCZAK
Get Your Private, Free E-mail from MSN Hotmail at http://www.hotmail.com
Re: Haskell and the NGWS Runtime
I don't believe this says anything about support for other OS's. I think the devices here are hardware, (PCs, handhelds, phones, fridge interfaces, ...) Of course Microsoft believes that some day, very soon, all devices will run (a version of) Windows. Hence this statement refers to Microsoft's announced plans to port .NET to all Windows OS's, including WinCE. Do you have another reference which is more convincing? k Erik Meijer writes: Not "at least" but "only". I haven't heard of plans for .NET on any non-Windows platform. Then you should listen more closely! a quote from the .NET whitepaper: Microsoft .NET proactively adapts to what you want to do, on any of your devices. This inversion of the traditional installation-dependent application model is a necessity in a world where users will enjoy the benefits of services on multiple devices. http://www.microsoft.com/net/ Erik
Re: Haskell and the NGWS Runtime
It seems to me that this .Net thingy is a runtime and therefore could potentially be as portable as anything from Java. This runtime just needs to be ported to other operating systems similarily to the Java runtime. Regards Chris Saunders [EMAIL PROTECTED] - Original Message - From: "Kevin Glynn" [EMAIL PROTECTED] To: "Erik Meijer" [EMAIL PROTECTED] Cc: "Marcin 'Qrczak' Kowalczyk" [EMAIL PROTECTED]; [EMAIL PROTECTED] Sent: Thursday, August 03, 2000 8:57 PM Subject: Re: Haskell and the NGWS Runtime I don't believe this says anything about support for other OS's. I think the devices here are hardware, (PCs, handhelds, phones, fridge interfaces, ...) Of course Microsoft believes that some day, very soon, all devices will run (a version of) Windows. Hence this statement refers to Microsoft's announced plans to port .NET to all Windows OS's, including WinCE. Do you have another reference which is more convincing? k Erik Meijer writes: Not "at least" but "only". I haven't heard of plans for .NET on any non-Windows platform. Then you should listen more closely! a quote from the .NET whitepaper: Microsoft .NET proactively adapts to what you want to do, on any of your devices. This inversion of the traditional installation-dependent application model is a necessity in a world where users will enjoy the benefits of services on multiple devices. http://www.microsoft.com/net/ Erik
Re: Haskell and the NGWS Runtime
To Linux? :^) From: "Chris Saunders" [EMAIL PROTECTED] To: [EMAIL PROTECTED], "Erik Meijer" [EMAIL PROTECTED] CC: "Marcin 'Qrczak' Kowalczyk" [EMAIL PROTECTED], [EMAIL PROTECTED] Subject: Re: Haskell and the NGWS Runtime Date: Thu, 3 Aug 2000 22:24:14 -0400 It seems to me that this .Net thingy is a runtime and therefore could potentially be as portable as anything from Java. This runtime just needs to be ported to other operating systems similarily to the Java runtime. Regards Chris Saunders [EMAIL PROTECTED] - Original Message - From: "Kevin Glynn" [EMAIL PROTECTED] To: "Erik Meijer" [EMAIL PROTECTED] Cc: "Marcin 'Qrczak' Kowalczyk" [EMAIL PROTECTED]; [EMAIL PROTECTED] Sent: Thursday, August 03, 2000 8:57 PM Subject: Re: Haskell and the NGWS Runtime I don't believe this says anything about support for other OS's. I think the devices here are hardware, (PCs, handhelds, phones, fridge interfaces, ...) Of course Microsoft believes that some day, very soon, all devices will run (a version of) Windows. Hence this statement refers to Microsoft's announced plans to port .NET to all Windows OS's, including WinCE. Do you have another reference which is more convincing? k Erik Meijer writes: Not "at least" but "only". I haven't heard of plans for .NET on any non-Windows platform. Then you should listen more closely! a quote from the .NET whitepaper: Microsoft .NET proactively adapts to what you want to do, on any of your devices. This inversion of the traditional installation-dependent application model is a necessity in a world where users will enjoy the benefits of services on multiple devices. http://www.microsoft.com/net/ Erik Get Your Private, Free E-mail from MSN Hotmail at http://www.hotmail.com
Re: Haskell and the NGWS Runtime
[EMAIL PROTECTED] (Marcin 'Qrczak' Kowalczyk) wrote, Thu, 3 Aug 2000 22:53:45 +0200, Erik Meijer [EMAIL PROTECTED] pisze: http://www.microsoft.com/net/ I still have not found anything suggesting that tools needed for working with that (e.g. the common runtime) will be available for non-Windows OSes. Who will make them? Microsoft? I guess, it will be like COM. Sure, in theory it could work on other OSes, but that's not in MS's interest, so why should they make it happen (or even allow that others make it happen). Manuel PS: I know that there is some obscure port of COM, but I never heard that it made any impact.
RE: Haskell and the NGWS Runtime
Erik Meijer [EMAIL PROTECTED] wrote: ^^ Yes, that refers to the computer lab sponsored by MSR Cambridge and MS Netherlands in Utrecht. The plan is to have the release out the door by September 1st. Will that release support Haskell, or just Mondrian? The compiler hooks into GHC by translating Core into GOO and then after some source to source transformations it can spit out either C# or Java. I'm afraid I have to disagree on that point. Basically you translate quite a few things by implementing your own virtual machine on top of the .NET runtime. For example, argument passing is done with explicit pushes and pops on your own virtual machine stack, rather than by using the .NET runtime's argument passing. This approach makes the compiler is fairly simple, but the generated code is not what _I_ would call elegant. As I explained the translation has to implement the features that the .NET runtime does not provide itself. Hence, must implement lazy evaluation and you must implement currying yourself. The same is true for Mercury. Since the .NET runtime does not support backtracking, you are simulating that by passing extra continuation arguments around. Don't you currently encode tail calls too? By exploiting tail-calls, which we don't do yet, you can use the underlying argument passing mechanism if you call a known function by calling one of its fast entry points. So you don't pay for currying and HO functions if you don't use them. The same is true for laziness btw. And what about type classes and polymorphism? By the time you reached Core, type classes are compiled away by the dictionary translation. To implement polymorphism for Haskell there is no need to carry around types at runtime. Also, as I understand it, Haskell/Mondrian programs that don't make use of currying -- e.g. those in which all functions have only one argument -- still get encoded, rather than being mapped directly. So the encoding is not done in way that you only pay for it when you use those features. This makes interoperability with other languages more difficult. Not true. It is extremely easy to interoperate with other languages. Yes, you do have to do some marshalling and unmarshalling, but again, you *must* do that to match up the semantic differences between the language of the caller and the callee. To call out from Haskell, you use a trivial wrapper function that pops the arguments from the stack (which is there to support currying), evaluate them to WHNF (because in Haskell the caller does not do that) and then directly calls the external function. In the current implementation there is no need to unmarshall the result. To call into Haskell, you use a trivial wrapper function that pushes the arguments on the stack and calls the underlying Haskell function. Or you call the function directly trough its fast entry point. Hmm, the "full" adjective here sounds like it might be a bit of an overstatement. Does that mean that I can call Mercury code from Haskell, have it all statically type checked, and not have to write any additional interface definitions or glue code? Including procedures which are polymorphic and/or use type classes? If so, I would be very surprised! I think the current level of interop supported is still a LONG way from what I would describe as "full" interoperability. Come on Fergus! You will never achieve interoperability on that level except when your semantic domains match exactly or when you have an extremely complicated intermediate language. For example, most languages don't make the distinction between values and computations as Haskell does, and I don't expect or want for example VB programmers to do that either. But it does mean that whenever I call a VB function, I must write a little glue code to compensate for the difference in semantics. The same is true for calling nondeterministic or multi-moded Mercury predicate. With "full" I mean that modulo the required semantic impedance matching you can call So, could you elaborate on what sense you mean when you say we have "full" bidirectional interop? For example, which of the various CLS (Common Language Specification) categories does the Haskell and/or Mondrian implementation comply with? In addition, I think your compiler also needs to support attributes? Aha, finally you hit a real issue. To be a CLS extender would require a lot of language extensions to a lot of languages, even to OO languages like Java! But for Haskell the situation is even more severe. Because Haskell does not have a notion of class (as in C#), there is no way that you can expect that Haskell can extend a class. Yet again, an extra level of indirection does the trick Since you can call Haskell from say C#, you just write a little wrapper class in C# whose methods are implemented in Haskell. On the Haskell side you call its constructor passing it the methods as arguments. This is essentially what we
Re: Haskell and the NGWS Runtime
On 02-Aug-2000, Erik Meijer [EMAIL PROTECTED] wrote: The plan is to have the release out the door by September 1st. Will that release support Haskell, or just Mondrian? The compiler hooks into GHC by translating Core into GOO and then after some source to source transformations it can spit out either C# or Java. Hmm... am I right to presume you mean that it will support Haskell? What about ghc's extensions, such as unboxed types? Will it support those? I'm afraid I have to disagree on that point. Basically you translate quite a few things by implementing your own virtual machine on top of the .NET runtime. For example, argument passing is done with explicit pushes and pops on your own virtual machine stack, rather than by using the .NET runtime's argument passing. This approach makes the compiler is fairly simple, but the generated code is not what _I_ would call elegant. As I explained the translation has to implement the features that the .NET runtime does not provide itself. Hence, must implement lazy evaluation and you must implement currying yourself. I understand that point, but if doing that means that you need to implement the basic things like argument passing and procedure calling yourself, using your own virtual machine, rather than by using the underlying runtime's argument passing and procedure calling mechanisms, then I'd say that it is looking more like putting a round peg in a square hole than a good fit. The same is true for Mercury. Since the .NET runtime does not support backtracking, you are simulating that by passing extra continuation arguments around. That's true. However, the way we map nondeterminism is a quite high-level approach, suitable for direct use from other languages. Note that in our original compiler for Mercury, which goes via GNU C, we handle nondeterminism using a low-level approach where we implement our own virtual machine on top of C. But for targetting the .NET platform, we completely rewrote the compiler back-end, using a new and much higher-level approach that leads to a much more direct mapping. The approach that you've taken to implementing currying using your own argument-passing stack looks to me like a fairly low-level approach. As a programmer, if I want to interface to Haskell code, I'd prefer it to be as high-level and as automatic as possible; I'd rather not write any glue code if I can avoid it, and if I do have to write glue code, I'd much rather it if I didn't have to muck around with low-level details like pushing arguments on stacks -- that's what compilers are for. Also, as I understand it, Haskell/Mondrian programs that don't make use of currying -- e.g. those in which all functions have only one argument -- still get encoded, rather than being mapped directly. So the encoding is not done in way that you only pay for it when you use those features. This makes interoperability with other languages more difficult. Not true. It is extremely easy to interoperate with other languages. Yes, you do have to do some marshalling and unmarshalling, but again, you *must* do that to match up the semantic differences between the language of the caller and the callee. Not necessarily. There need not be any such semantic differences. Certainly in many cases there will be, and in such cases marshalling will be required, but in many other cases the language that you are interfacing with will have some direct equivalent of all of the features used by the function that you are exporting. For example, if I have a Mercury function :- func foo(int) = int. then this could correspond directly with the ghc function -- this makes use of ghc's unboxed types extension foo :: Int# - Int# If I want to call the Mercury function from ghc code, using that prototype, then ideally there should be no need to write any wrapper, glue code, or interface definition. Of course when calling code that uses unboxed types from code that uses boxed types, you need to write some code to unbox the values, and that could quite fairly be called glue code. But that glue code is not language interop glue code, it is boxed type - unboxed type glue code. As a ghc programmer, I don't need to know anything about the properties of the implementation or of the language that I'm interfacing with to write such glue code, I just need to know about the ghc language, specifically ghc's unboxed types. To call into Haskell, you use a trivial wrapper function that pushes the arguments on the stack and calls the underlying Haskell function. Or you call the function directly trough its fast entry point. Well, these fast entry points definitely sound like an improvement. They're not mentioned on the Mondrian web page whose URL was posted earlier in this thread. Are these something you're planning to include in the Sept 1 release? Hmm, the "full" adjective here sounds like it might be a bit of an
Re: Haskell and the NGWS Runtime
On 02-Aug-2000, Carl R. Witty [EMAIL PROTECTED] wrote: Fergus Henderson [EMAIL PROTECTED] writes: The compiler hooks into GHC by translating Core into GOO and then after some source to source transformations it can spit out either C# or Java. Is there any publically available technical information on what you guys are talking about? I've been doing web searches, and searches on the Microsoft web site, and I can't find anything on GOO, IL, or "Common Language Specification". Technical information about this stuff (IL, the CLS, etc.) was included on the CDs that MS gave to the 6000-odd participants of their recent PDC (Professional Developers Conference) in Florida last month. So if you can find one of those, you might be in luck. But I don't think Microsoft have put anything about it up on the web. GOO is not a Microsoft invention, and nor is it part of Microsoft's .NET stuff. GOO is an intermediate language that was, AFAIK, invented by the Mondrian group. It might be described in the following paper: Erik Meijer and Koen Claessen. The Design and Implementation of Mondrian. In Proc. Haskell Workshop, 1997. -- Fergus Henderson [EMAIL PROTECTED] | "I have always known that the pursuit WWW: http://www.cs.mu.oz.au/~fjh | of excellence is a lethal habit" PGP: finger [EMAIL PROTECTED]| -- the last words of T. S. Garp.
Re: Haskell and the NGWS Runtime
Erik Meijer [EMAIL PROTECTED] wrote: ^^ [someone wrote:] Does anyone know where there is some information on Haskell integration with the Microsoft NGWS runtime, which provides cross language integration and a common system for memory managment, library functions etc. I am curious to see if the haskell integration is a good fit or a graunch (square peg into a round hole). I know some work is being done on haskell in this regard, but exactly what I do not know. The plan is to have the release out the door by September 1st. Will that release support Haskell, or just Mondrian? The translation is quite elegant IMHO, I'm afraid I have to disagree on that point. Basically you translate quite a few things by implementing your own virtual machine on top of the .NET runtime. For example, argument passing is done with explicit pushes and pops on your own virtual machine stack, rather than by using the .NET runtime's argument passing. This approach makes the compiler is fairly simple, but the generated code is not what _I_ would call elegant. it only encodes those features that Haskell has, but the .NET runtime lacks, that is lazy evaluation and currying (what else can you expect). Don't you currently encode tail calls too? And what about type classes and polymorphism? Also, as I understand it, Haskell/Mondrian programs that don't make use of currying -- e.g. those in which all functions have only one argument -- still get encoded, rather than being mapped directly. So the encoding is not done in way that you only pay for it when you use those features. This makes interoperability with other languages more difficult. As we demo-ed at the PDC, we have full bidirectional interop between Haskell and other .NET languages. Hmm, the "full" adjective here sounds like it might be a bit of an overstatement. Does that mean that I can call Mercury code from Haskell, have it all statically type checked, and not have to write any additional interface definitions or glue code? Including procedures which are polymorphic and/or use type classes? If so, I would be very surprised! I think the current level of interop supported is still a LONG way from what I would describe as "full" interoperability. So, could you elaborate on what sense you mean when you say we have "full" bidirectional interop? For example, which of the various CLS (Common Language Specification) categories does the Haskell and/or Mondrian implementation comply with? The fact that there is a common runtime is a really great thing. In the old days for example, you had to implement your own so called ActiveX scripting engine to host Haskell programs in HTML pages, ASP pages, or WSH. Now you only have to target to IL and get those goodies already paid for, ie you can write ASP+ pages in Haskell, COBOL, Mercury, Perl, Phyton, APL, Smalltalk, Scheme, Component Pascal, Eiffel, Oberon, ... (The corresponding thing for Java would be that if I compile Haskell to Java, I get Haskelletes already paid for). Actually that's not really true; compiling to IL is not enough. To support ASP+ for a given language, you also need to implement a certain API. Now my information on this is mostly second-hand, but as I understand it, this API pretty much assumes that your language is a fairly typical imperative language, with constructs like loops, etc. So it is fairly easy to implement this API for imperative languages, but not nearly so easy to implement it for functional languages or other non-traditional languages. In addition, I think your compiler also needs to support attributes? P.S. My research group has received substantial funding from MS, so my opinion on these issues may not be entirely objective. -- Fergus Henderson [EMAIL PROTECTED] | "I have always known that the pursuit WWW: http://www.cs.mu.oz.au/~fjh | of excellence is a lethal habit" PGP: finger [EMAIL PROTECTED]| -- the last words of T. S. Garp.
