Re: Haskell and the NGWS Runtime
"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/1612254&mode=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? Isn't this just the old myth of GC being slow? -kzm -- If I haven't seen further, it is by standing in the footprints of giants
Re: Haskell and the NGWS Runtime
On 09-Aug-2000, Brent Fulgham <[EMAIL PROTECTED]> wrote: > > 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
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/1612254&mode=thread Manuel
Re: monadic source of randomness
Norman Ramsey <[EMAIL PROTECTED]> writes: > Does anybody know of work using monads to encapsulate a source of > random numbers? A quick web search suggested Haskell 98 did not take > this path. I'd be curious for any insights why, or any suggestions > about a `randomness monad'. My guess as to why Haskell 98 does not provide a stand-alone "randomness monad" is that monads are annoying (impossible in general) to combine. If you want your own randomness monad, it's pretty easy to put a random state in a state monad; that approach means that you can easily add other chunks of state as wanted. Carl Witty
Re: monadic source of randomness
> > Does anybody know of work using monads to encapsulate a source of > > random numbers? > Is the global random number generator, in section 17.3 of the Haskell > 98 library report, the sort of thing you're after? No; that appears to embed a generator in the IO monad. Not what I'd hoped for. N
monadic source of randomness
Norman Ramsey writes: > Does anybody know of work using monads to encapsulate a source of > random numbers? A quick web search suggested Haskell 98 did not take > this path. I'd be curious for any insights why, or any suggestions > about a `randomness monad'. > > > Norman Hi. Is the global random number generator, in section 17.3 of the Haskell 98 library report, the sort of thing you're after? Regards, Tom
monadic source of randomness
Does anybody know of work using monads to encapsulate a source of random numbers? A quick web search suggested Haskell 98 did not take this path. I'd be curious for any insights why, or any suggestions about a `randomness monad'. Norman
RE: Haskell and the NGWS Runtime
> 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. > 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. Plus, .NET seems to be built on top of a lot of poorly-conceived Microsoft "Technologies". One can see the dark shadows of COM in there in places, as well as other evidence of the NIH syndrome creating yet another wheel. 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. 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. I sincerely hope that the researchers on this list, and especially those at Microsoft Labs, will stand firm in the design of Haskell, and not pollute it with poorly designed add-ons to work with a poorly-conceived architecture. You will be embarking on a game of catch-up that you can never hope to win. Regards, -Brent
Re: Haskell and the NGWS Runtime
"Craig Dickson" <[EMAIL PROTECTED]> writes: [Leaving just a few random quotes, snipping lots of good and accurate technical-historical stuff] > 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# is Microsoft's attempt at a Java-killer. It isn't really all that If I may take the liberty of speculating on the political issues, this might be seen in light of a possible imminent breakup of you-know-who. Might .NET be inherited by the applications part of Microsoft, perhaps - MS could then let the OS part drift wherever it might, and secure a new monopolized base for their applications. This might actually be good news(?), since it could mean that we'd see .NET implementations for lots of architectures - although poorly documented and non-free source, of course, in order to keep tight control. Maybe. -kzm -- If I haven't seen further, it is by standing in the footprints of giants
Re: The type of zip
Wed, 9 Aug 2000 20:27:14 +0100, Claus Reinke <[EMAIL PROTECTED]> pisze:
> In the language I had in mind, I would expect to be able to "retrieve" the
> () from any product, at any position
I still prefer the list-like non-associative treatment of tuples.
It needs not type system extensions.
The only problem is that GHC and other compilers are not able to
represent such tuples compactly. Theoretically they could just do
it, these nested pairs are isomorphic to real tuples, but GHC never
unboxes polymorphic fields, for obvious reasons. It would require
either physical specialization of code for each length or ability
to extract and make variable-sized fields.
Specialization is better, the latter would have quadratic cost for
large tuples. But it's not possible in polymorphic recursion and I
can hardly imagine multiple representations of a single type.
data Pair h t = h :* !t
class ConcTuples a b c where
concTuples :: a -> b -> c
instance ConcTuples () b b where
concTuples _ b = b
instance ConcTuples b c d => ConcTuples (Pair a b) c (Pair a d) where
concTuples (a:*b) c = a :* concTuples b c
Note that () as a strict constructor argument does not need any
physical representation.
--
__("< Marcin Kowalczyk * [EMAIL PROTECTED] http://qrczak.ids.net.pl/
\__/
^^ SYGNATURA ZASTĘPCZA
QRCZAK
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: The type of zip
[a while ago]
From: Tom Pledger
> Claus Reinke writes:
> > - one would think that () simply takes its role as a unit, so that
> > (),a == a == a,()
> > but if we know x::() does that imply that x,a == a ?
> > x could be bottom, and the equations for the unit look strict in
> > their unit parameter, so probably not;
>
>
> Does that matter, if the () can't be retrieved from the product by
> pattern matching? Could Void be (reinstated and) used as the unit for
> products?
>
In the language I had in mind, I would expect to be able to "retrieve" the
() from any product, at any position (which makes it slightly useless to do
so, and also requires that we extend the theory, from associative to an
added identity). But the unit-problem is independent from the suggested
extension.
Note that, in Haskell, the typed expression e::() only promises that
*if the evaluation of expression e ever terminates successfully*, it will
give
a (). Without further proofs, there are always other options: the evaluation
of e could fail to terminate at all, or it could terminate exceptionally,
thus
failing to terminate within the expected type.. And so, the following two
program fragments are not equivalent, however tempting the similarity:
no_unit = no_unit
mainA = case no_unit::() of { () -> system }
mainB = system
You might be slightly unhappy if your compiler "improved" mainA to
mainB (it is probably not wise to rely on a compiler not being overly
optimistic wrt improvements, whatever the language definition says..).
There are at least two ways to look at this: (a) () includes two or more
values, including ()::() and _|_::(), which have to be distinguished, or
(b) () includes only one value, ()::(), but we have to make sure that we
actually get it (a is the more common view).
A transformation that noticed the cycle and *stopped* the execution
with an error message would still be invalid, strictly speaking, even
though one could argue that, in most cases, the programmer doesn't
want the cycle, so it's likely to be an error.
..[finding some route from here to the type of join;-)]..
> This is relevant to my (continuing) attempts to type a natural join.
> Starting with TREX row types like this:
>
> (foo::a, bar::b | r)
> -- Rows with a type a field labelled foo, a type b field labelled
> -- bar, and possibly some other fields
>
> I'd like to add row type constructors (||), (-), and (&&):
>
> (r || s)
> -- The catenation of r with s, which would always be predicated by
> -- r and s having no common labels
The absence of a record concatenation operation seems to be the biggest
single shortcoming of TREX. It is possible to get concatenable "records"
by the old continuation (or difference structure) trick, in this context
known as "Typing record concatenation for free" by D. Remy:
Instead of records, you use record extension functions that add fields
to their parameter, something along the lines of (the unchecked)
add_foo r = (foo=1|r)
add_bar r = (bar=2|r)
add_foo_bar = add_foo . add_bar
to_record r = r ()
Unfortunately, even though (.) serves as a record concatenation operation
here, it isn't possible to give an explicit type for the variant restricted
to
record concatenation. This kills the idea in all contexts in which you need
both explicit type declarations and record concatenation, as in type
classes, for instance..
It wasn't necessary to convince the TREX authors of the usefulness of
record concatenation, but no elegant solution to the typing issues emerged
in time to be added to the implementation.
I don't quite remember the technical issues..(one was the indexing evidence
scheme used in the current implementation - I think that could be overcome
by using a has_field predicate instead of a lacks_field predicate, but I
don't know whether that would bite elsewhere; another alternative would
be to try and define concatenation via type classes - I tried that but
bumped
into the problem mentioned above.. it would help if labels where
first-class,
but I don't remember whether that would be enough..).
> (r - s)
> -- The row type with the fields of r whose labels are not in s
Single, explicit field restriction used to be part of one of the proposals.
Wouldn't the step to implicit, multiple field restriction suffer from the
same problems as the step from single, explicit field extension to record
concatenation?
> (r && s)
> -- The row type with the fields of r whose labels are also in s,
> -- which would always be predicated by r and s having unifiable
> -- types for those fields
How would that predicate be expressed in the type?
> so that a natural join (of records) could have this type:
>
> Eq (Rec (r && s)) => Rec r -> Rec s -> Maybe (Rec (r || (s - r)))
>
> with extensions to the predicate because of the use of (&&).
Which extensions?
I recall that typing join is even trickier than typing record concatenation,
so it might b
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=2&id=39897e26-060c53e0 :-) Yours, Florian
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
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
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[2]: [ANNOUNCE] HDoc: a "javadoc for Haskell"
On Tue, 08 Aug 2000 16:53:42 -0400 you wrote: > Armin, > > Is HDoc also designed to work with the February 2000 version of Hugs98? > > Will it work under Linux and MacOS as well as under Win 32 (including Windows 2000)? > > --Benjamin L. Russell HDoc should run on any version of Hugs98 as it follows the Haskell 98 standard (except that it uses the GetOpt library, which is available in Hugs and GHC). At the moment, HDoc only understands "/" as separators for directories, so it may fail under Windows (or does Windows understand slashes, also?). BTW, what is the path separator under MacOS ? I'm only using Linux, so I didn't think of that problem and cannot try what happens under other OSes and I can't provide start scripts like hdoc.sh for Un*x :-( I'll try to make a new version available tomorrow. It is one of my aims to make HDoc run on any platform that is supported by Hugs98 or GHC. Armin.
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
