[ Pobierz całość w formacie PDF ]
.By calling Haskell 98 that name instead of Haskell, we leave the Haskell brand name freeto be applied to lots of things.Anything that has  Haskell in the name is usually pretty close;it s usually an extension of Haskell 98.I don t know anything that s called  something-Haskell58 and that doesn t include Haskell 98 at least.These aren t just random languages that happen to be branded, like JavaScript which hasnothing to do with Java.They [JavaScript] just piggy-backed on the name.They thought ifit was Java, it must be good!Do you find yourself using any of these languages?Yes.Concurrent Haskell is implemented in GHC, so if you say I m using Concurrent Haskellyou re more or less saying you re using GHC with the concurrency extension Data Parallel.Haskell is also being implemented in GHC, so many of these things are actually all implementedin the same compiler, and are all simultaneously usable.They re not distinct implementations.Distributed Haskell is a fork of GHC.Some older versions run on multiple computers con-nected only to the Internet.It started life as being only part of GHC, but you can t use it at thesame time as the concurrency extensions, or a lot of the things that are new in GHC, becauseDistributed Haskell is a  fork. It started life as the same code base but it has diverged sincethen.You can t take all of the changes that have been made in GHC and apply them to thedistributed branch of the fork  that wouldn t work.Concurrrent Clean on the other hand is completely different.It s a completely differentlanguage; it s got a completely different implementation.It existed before Haskell did andthere s a whole different team responsible, led by Rinus Plasmeijer.At one stage I hoped thatwe would be able to unify Haskell and Clean, but that didn t happen.Clean s a veryinteresting and good language.There s lots of interesting stuff in there.When did you think that the two might combine?When we first started, most of us [the Haskell committee] had small prototype languages inwhich we hadn t yet invested very much, so we were happy to give them all up to create onelanguage.I think Rinus had more invested in Concurrent Clean, however, and so chose not to[participate in Haskell].I have no qualms with that, as diversity is good and we don t want amono-culture, as then you don t learn as much.Clean has one completely distinct feature which is not in Haskell at all, which is calleduniqueness typing.This is something that would have been quite difficult to merge intoHaskell.So there was a good reason for keeping two languages.It s another thing likemodules that would have been a big change.We would have had a lot of ramifications and it snot clear that it would have been possible to persuade all of the Haskell participants that theramifications were worth paying for.It s the  do one thing well, again.That sounds like the language s aim: do one thing and do it well.Yes.That s right.We re seeing an increase in distributed programming for things like multi-core CPUsand clusters.How do you feel Haskell is placed to deal with those changes?I think Haskell in particular, but purely functional programming in general, is blazing thetrail for this.I ve got a whole one hour talk about the challenge of effects  which in this caseactually means side effects.Side effects are things like doing input/output, or just writing to amutable memory location, or changing the value of the memory location.In a normal language, like Pascal or Perl, what you do all the time is say  assign value 3to x, so if x had the value of 4 before, it has the value of 3 now.So that these locations, calledx, y & z, are the names of a location that can contain a value that can change over time.In a purely functional language, x is the name of a value that never changes.If you call aprocedure in Perl or Pascal, you might not pass the procedure any arguments and you maynot get any results, but the act of calling the procedure can cause it to write to disk, or tochange the values of many other variables.If you look at this call to the procedure, it looksinnocuous enough, but it has side effects that you don t see.These aren t visible in the call,but there are many effects of calling the procedure, which is why you called it.If there were noeffects you wouldn t call it at all.In a functional language, if you call a function f, you give it some arguments and it returns aresult.All it does is consume the arguments and deliver the result.That s all it does  it doesn t59 create any other side effects.And that makes it really good for parallel evaluation in a parallelmachine.Say if you call f of x and then you add that result to g of y in a functional language,since f doesn t have any side effects and g doesn t have any side effects, you can evaluate thecalls in parallel [ Pobierz całość w formacie PDF ]

  • zanotowane.pl
  • doc.pisz.pl
  • pdf.pisz.pl
  • drakonia.opx.pl
  • Linki