Re: [Haskell] Top Level <-

didn't feel right to me. But if you think about how finalisers get run I'm inclined to think we should insist that they are ACIO too. Regards -- Adrian Hey ___ Haskell mailing list Haskell@haskell.org http://www.haskell.org/mailman/listinfo/haskell

Re: [Haskell] ANNOUNCE: Generic Haskell 1.80 (Emerald)

many windows users will be keen to install cygwin and learn how to use it just so they can build GH. Thanks -- Adrian Hey ___ Haskell mailing list Haskell@haskell.org http://www.haskell.org/mailman/listinfo/haskell

Re: [Haskell] thread-local variables

ead local state, (but this does not necessarily make it evil:-) But I would say that I think I would find having to know what thread a particular bit of code was running in in order to "grok it" very strange, unless there was some obvious technical reason why the thread local st

[Haskell] StringMaps available

I'm afraid I won't be able to do much Haskelling for a few months so not much will be added in the near future. But if anybody would like to use this but finds the absence of some function or other a show stopping issue then let me know and I'll add i

Re: [Haskell] ANNOUNCE: Haddock version 0.7

Hello, Does the linking to source still work with this version? I can't get it to work anyway, but maybe I'm doing something wrong. All I get for each module is a link to whatever URL I specify, but without the actual source module name(path) attached at the end. Thanks --

Re: [Haskell] combining IntMaps

I have no idea how to do this with IntMaps so I'm not volunteering :-) My 2p.. Regards -- Adrian Hey ___ Haskell mailing list Haskell@haskell.org http://www.haskell.org/mailman/listinfo/haskell

Re: [Haskell] stack overflow - nonobvious thunks?

) GT -> Gt Of course the above code does not guarantee strictness in the value argument (a). It just guarantees that a'' is evaluated in the event that a matching key is already present. Regards -- Adrian Hey ___ Haskell mailing list Haskell@haskell.org http://www.haskell.org/mailman/listinfo/haskell

Re: [Haskell] combining IntMaps

ny concrete guidance regarding > when that should happen? The distinction between the two lists is still > vague to me. It's vague to me too :-) Though in this case the libraries list would be more appropriate I think (dunno whether or not yo

Re: [Haskell] combining IntMaps

probably true of Data.Tree.AVL of course, but I'm trying to make it more complete all the time. Anyway, please try out AVL and let me know if there's anything more missing. Regards -- Adrian Hey ___ Haskell mailing list Haskell@haskell.org http://www.haskell.org/mailman/listinfo/haskell

Re: [Haskell] combining IntMaps

et s = v0 +# v1 in if s ==# 0# then Eq Nothing else Eq (Just (IntAssoc k0 s)) GT -> Gt Regards -- Adrian Hey ___ Haskell mailing list Haskell@haskell.org http://www.haskell.org/mailman/listinfo/haskell

Re: [Haskell] line-based interactive program

to burden you with this, but I've decided to make it my mission in life to challenge such assertions (well at least whenever one of my other missions in life doesn't distract me). Regards -- Adrian Hey ___ Haskell mailing list Haskell@haskell.

[Haskell] AVL library update available.

reasonably complete (and stable) now, but it almost certainly isn't complete. So if anybody has any feature requests please let me know. I've marked the modules as being "stable", so I promise not to introduce any radical api cha

Re: [Haskell] space behaviour of lazy recursive lists

will be proportional to the first arg of nth for the reasons I indicated earlier. But I think the version using zipWith' will execute in constant space (but this doesn't mean constant cell allocation, you'll probably still see of cells used). Regards -- Adrian Hey ___

Re: [Haskell] space behaviour of lazy recursive lists

On Sunday 30 Jan 2005 7:40 pm, Adrian Hey wrote: > On Sunday 30 Jan 2005 4:00 pm, Axel Jantsch wrote: > > Hi, > > > > How can I get constant space behaviour for lazy, recursive streams? > > > > Consider: > > > gibs = 1 : 1 : (zipWith f gibs (tail gibs))

Re: [Haskell] space behaviour of lazy recursive lists

xs ys) zipWith' _ _ _ = [] (Haven't tried it though). Actually this kind of problem worries the me a lot. Dunno if I'm being unduly anal, but I usually end up writing strict and lazy versions of most of my HOFs to deal

Re: [Haskell] Real life examples

On Tuesday 30 Nov 2004 11:23 am, Keean Schupke wrote: > Adrian Hey wrote: > >On Sunday 28 Nov 2004 6:44 pm, Lennart Augustsson wrote: > >>But surely any device driver is parametrized on the > >>exact IO addresses? How would you be able to handle > >>multiple

Re: [Haskell] Real life examples

On Sunday 28 Nov 2004 6:44 pm, Lennart Augustsson wrote: > But surely any device driver is parametrized on the > exact IO addresses? How would you be able to handle > multiple devices otherwise? Maybe, but this won't help hardware emulation (unless you're emulating RAM). Re

Re: [Haskell] Real life examples

On Friday 26 Nov 2004 11:39 am, Keean Schupke wrote: > Adrian Hey wrote: > >Well it can be written in Haskell, but not using a module that was > >specifically designed to prevent this. > > Well, It can be written in Haskell as it stands at the moment... No it can't.

Re: [Haskell] Real life examples

t this. You've gotta make a sensible choice as to what the purpose of module you're writing really is of course. But this is always the case I think, no magic bullets here. Regards -- Adrian Hey ___ Haskell mailing list [EMAIL PROTECTED] http://www.haskell.org/mailman/listinfo/haskell

Re: Top Level TWI's again was Re: [Haskell] Re: Parameterized Show

ation. You've wrapped all the separate device drivers into a single uber device driver (world driver?) and called it the "operating system". I think this approach has it's pros and cons, but you're right that it does solve the problem. But my original monosyllabic summary o

Re: [Haskell] Real life examples

dule is to allow users to have multiple distinct (top level or otherwise) TWIs then it should be exporting an appropriate newTWI constructor which is used in the usual manner by the importing module(s).. myTWI <- newTWI myOtherTWI <- newTWI Regards -- Adrian Hey ___ Haskell mailing list [EMAIL PROTECTED] http://www.haskell.org/mailman/listinfo/haskell

Re: Top Level TWI's again was Re: [Haskell] Re: Parameterized Show

sa. :) Nope, sorry, been down this route once before and I'm sick of these arguments. Fortunately (having just had time for a quick scan of John Meachams post) it seems JM has done an excellent job of this already. (So argue with him, I'm taking the day off :-)

Re: Top Level TWI's again was Re: [Haskell] Re: Parameterized Show

an outChan <- newChan forkIO $ myDriver (inChan,outChan) state0 return (inChan,outChan) But of course this is so evil it's not worth further consideration :-) Regards -- Adrian Hey ___ Haskell mailing list [EMAIL PROTECTED] http://www.haskell.org/mailman/listinfo/haskell

Re: Top Level TWI's again was Re: [Haskell] Re: Parameterized Show

he only difference is that instead of writing.. do ... foo stdout ... ..they now have to write.. do ... stdout <- getStdout foo stdout ... I don't see why the former should be regarded as a source of great evil which is somehow eliminated by the latter. Regards -- Adrian Hey ___ Haskell mailing list [EMAIL PROTECTED] http://www.haskell.org/mailman/listinfo/haskell

Re: Top Level TWI's again was Re: [Haskell] Re: Parameterized Show

On Monday 22 Nov 2004 11:26 am, Keean Schupke wrote: > Adrian Hey wrote: > >Just repeating this again and again doesn't make it any more true. > > Ditto... I for one think the best solution is to use the language as > intended and pass the values as function arguments. I g

Re: Top Level TWI's again was Re: [Haskell] Re: Parameterized Show

ere will be an "open" flag per device.) IOW there is no possible sound solution in Haskell. I think that's a problem for a "general purpose" programming language. What if there is no OS or device driver? Shouldn't people reasonably expect

Top Level TWI's again was Re: [Haskell] Re: Parameterized Show

those operations I would like to put in the "SafeIO" monad). So is this evil too? Perhaps it is, but if so, I'd like to know how you propose to live without it and what purpose the IO monad would serve in such a situation. Regards -- Adrian Hey ___ Haskell mailing list [EMAIL PROTECTED] http://www.haskell.org/mailman/listinfo/haskell

Re: [Haskell] Re: Parameterized Show

language sounds bizarre to me. Safe beta conversion really ought to be a sacred cow. Still, at least they're not enabled by default. With any luck we won't see too many people shooting themselves in the foot because they're too lazy to pass their parameters explicitly. :-) Regar

Re: [Haskell-cafe] Re: [Haskell] Re: Global Variables and IO initializers

On Monday 08 Nov 2004 12:23 pm, Lennart Augustsson wrote: > Adrian Hey wrote: > > 4- They already exist (stdin,stout,stderr) and I don't > >recall anybody ever complaining about this. > > stdin, stdout, and stderr are not global variables. > They are just ha

Re: [Haskell] Re: Global Variables and IO initializers

the proposed SafeIO/CIO restricted monad solutions (not sure about this one though). Regards -- Adrian Hey ___ Haskell mailing list [EMAIL PROTECTED] http://www.haskell.org/mailman/listinfo/haskell

Re: [Haskell-cafe] Re: [Haskell] Re: Global Variables and IO initializers

you don't want to use <- bindings then don't. Nothing else has changed. Regards -- Adrian Hey ___ Haskell mailing list [EMAIL PROTECTED] http://www.haskell.org/mailman/listinfo/haskell

Re: [Haskell] Re: Global Variables and IO initializers

ither at the moment. BTW, I also think there are some important differences between the O'Haskell way (which I don't object to) and what you and Keaan are advocating AFAICT (which I do object to). Regards -- Adrian Hey ___ Haskell mailing list [EMAIL PROTECTED] http://www.haskell.org/mailman/listinfo/haskell

Re: [Haskell] Re: Global Variables and IO initializers

hestnut in response to this question. We've already been over that ground.] > If you could give > more details of the application someone may be able to > suggest a resonable way of refactoring. The problem is to ensure that a top level IO action cannot be executed more than once. Regards -- Adrian Hey ___ Haskell mailing list [EMAIL PROTECTED] http://www.haskell.org/mailman/listinfo/haskell

Re: [Haskell] Re: Global Variables and IO initializers

r implementation already. If so it seems to me you're using the fact that somebody has already solved the problem for you as an argument that no solution is necessary. (It would be interesting to see what the api's of the libraries you're using would look like, if they had been designed according to the principles you're advocating). Regards -- Adrian Hey ___ Haskell mailing list [EMAIL PROTECTED] http://www.haskell.org/mailman/listinfo/haskell

Re: [Haskell] Re: Global Variables and IO initializers

w me a concrete alternative in real Haskell code, other than the IMO horrible alternative which I have already suggested. If that's the only alternative available I will continue to use the unsafePerformIO hack, I'm sorry to say :-( Regards -- Adrian Hey ___

Re: [Haskell] Re: Global Variables and IO initializers

use it once). It doesn't seem very attractive to users either (considerably complicates their code and places the burden on them to "get it right"). Regards -- Adrian Hey ___ Haskell mailing list [EMAIL PROTECTED] http://www.haskell.org/mailman/listinfo/haskell

Re: [Haskell] Re: Global Variables and IO initializers

has been used. 4- -fno-cse applies to an entire module, which will be overkill in most cases. Regards -- Adrian Hey ___ Haskell mailing list [EMAIL PROTECTED] http://www.haskell.org/mailman/listinfo/haskell

Re: [Haskell] Re: Global Variables and IO initializers

to inline and also apply typing restrictions (and not to do some other optimisations too no doubt, such as CSE). Regards -- Adrian Hey ___ Haskell mailing list [EMAIL PROTECTED] http://www.haskell.org/mailman/listinfo/haskell

Re: [Haskell] Re: Global Variables and IO initializers

se from IO monad oneShotIO :: IO a -> IO (IO a) oneShotIO io = liftSafeIO $ oneShotSafeIO io userInit :: IO userInit <- oneShotSafeIO realInit Though this could be simplified if SafeIO could be made a sub-type of IO I guess (but I don&#

Re: [Haskell] Re: Global Variables and IO initializers

ided by existing libraries. So the fact that these things exist (and can be used quite safely) but the language provides no way for the programmer to safely create them seems a bit strange. Regards -- Adrian Hey ___ Haskell mailing list [EMAIL PROTECTED] http://www.haskell.org/mailman/listinfo/haskell

Re: [Haskell] Re: Global Variables and IO initializers

ad approach, provided there's an escape to IO monad (typically needed for FFI related initialisations). I also think we need something like.. CIOtoIO :: CIO a -> IO a so that CIO constructors can be used normal IO code too. Regards -- Adrian Hey ___

Re: Module Initialisation? (was Re: [Haskell] (no subject))

On Sunday 17 Oct 2004 4:45 am, Wolfgang Thaller wrote: > Adrian Hey wrote: > > I'm puzzled about this idea of "module init action" in a declarative > > language. Perhaps, if it's desirable to have some module initialisation > > applied to a module if any

Module Initialisation? (was Re: [Haskell] (no subject))

#x27;d probably have.. myThing :: Thing myThing <- safeNewThing safeNewThing :: SafeIO Thing safeNewThing = mdo ... newThing :: IO Thing newThing = liftSafeIO safeNewThing Now that all seems so simple, I'm certain I must have overlooked something :-( Regards -- Adrian Hey ___ Haskell mailing list [EMAIL PROTECTED] http://www.haskell.org/mailman/listinfo/haskell

Re: [Haskell] threading mutable state through callbacks

ports is not a discipline Haskellers are used to. If this is the case with John's proposal, it seems like it could cause trouble in the long run :-( Regards -- Adrian Hey ___ Haskell mailing list [EMAIL PROTECTED] http://www.haskell.org/mailman/listinfo/haskell

Re: [Haskell] threading mutable state through callbacks

M pointed out) there's no problem with actually using such things at the top level (assuming we had some magic that enabled their creation). Regards -- Adrian Hey ___ Haskell mailing list [EMAIL PROTECTED] http://www.haskell.org/mailman/listinfo/haskell

Re: [Haskell] threading mutable state through callbacks

On Tuesday 12 Oct 2004 10:47 pm, Marcin 'Qrczak' Kowalczyk wrote: > Adrian Hey <[EMAIL PROTECTED]> writes: > > The only real insanity with the current situation is the loss of > > referential transparency implied by the use of unsafePerformIO, > > which is

Re: [Haskell] threading mutable state through callbacks

fortunately, in this case the whole point of what people are trying to do with unsafePerformIO is to allow these things to be visible at the top level :-) Regards -- Adrian Hey ___ Haskell mailing list [EMAIL PROTECTED] http://www.haskell.org/mailman/listinfo/haskell

Re: [Haskell] threading mutable state through callbacks

On Tuesday 12 Oct 2004 6:28 pm, Jules Bean wrote: > On 12 Oct 2004, at 14:08, Adrian Hey wrote: > >> x <- someAction > >> y <- someAction(x) > > > > I would say keep things as they currently are with the unsafePerformIO > > solution, I.E. Order unsp

Re: [Haskell] threading mutable state through callbacks

On Tuesday 12 Oct 2004 1:44 pm, Vincenzo Ciancia wrote: > On Tuesday 12 October 2004 12:23, Adrian Hey wrote: > > I don't know what more > > general-purpose extension you have in mind, but couldn't you just > > borrow from do syntax at the top level > > I thi

Re: [Haskell] threading mutable state through callbacks

uaranteed to be aware of the semantic problems and we didn't have to rely on unsafePerformIO, NOINLINE etc hackery. I don't know what more general-purpose extension you have in mind, but couldn't you just borrow from do syntax at the top level, something like this.. &g

[Haskell] Data.COrdering & Data.Tree.AVL updated

ly with the functions provided then please let me know. Regards -- Adrian Hey ___ Haskell mailing list [EMAIL PROTECTED] http://www.haskell.org/mailman/listinfo/haskell

[Haskell] Hyperlinking problem in Haddock

lated ' character. This is with Haddock version 0.6 BTW. Thanks -- Adrian Hey ___ Haskell mailing list [EMAIL PROTECTED] http://www.haskell.org/mailman/listinfo/haskell

[Haskell] SDL binding available.

urgently so you might have to wait a while otherwise. I plan to give the graphics capabilities higher priority. Regards -- Adrian Hey ___ Haskell mailing list [EMAIL PROTECTED] http://www.haskell.org/mailman/listinfo/haskell

Re: [Haskell] Programming language shootout (completing the Haskell entry)

onclusions correctly there were several reasons for relatively poor performance on modern processors (one of which was a high rate of cache misses). I suppose we should distinguish code from heap accesses here though. Regards -- Adrian Hey ___ Haskell ma

Re: [Haskell] Programming language shootout (completing the Haskell entry)

arks :-) As someone observed the other day, the figures in the shootout are rather old and probably don't accurately reflect current Haskell (I.E. ghc I presume) performance in any case. BTW, there also seems to be a Win32 clone of the shootout here which may have more life in it.. http

Re: Calling an external command from a Haskell program

, You can use.. system :: String -> IO ExitCode in library module System.Cmd Regards -- Adrian Hey ___ Haskell mailing list [EMAIL PROTECTED] http://www.haskell.org/mailman/listinfo/haskell

Re: The Future of Haskell discussion at the Haskell Workshop

aged with suitable compiler switches or whatever, which seems to be what Simon.M. is proposing for ghc. Regards -- Adrian Hey ___ Haskell mailing list [EMAIL PROTECTED] http://www.haskell.org/mailman/listinfo/haskell

Re: The Future of Haskell discussion at the Haskell Workshop

a bit upset by such changes. If I'd written (or purchased) a text book which was now full of obsoleted code examples I wouldn't be very happy. But I guess it would be possible to do something too suit users of "old" and "new" Has

Re: The Future of Haskell discussion at the Haskell Workshop

On Tuesday 09 September 2003 13:52, Johannes Waldmann wrote: > On Tue, 9 Sep 2003, Adrian Hey wrote: > > I rarely use named fields in my Haskell progs with Haskell as it is ... > > but you sure agree records are useful for collecting heterogenous data? Yes, I would agree that e

Re: The Future of Haskell discussion at the Haskell Workshop

te liked what I saw of the "First Class Modules" paper. Is there some reason why we can't have (shouldn't have?) that. (Apart from the additional workload it places on Haskell implementors :-) Regards -- Adrian Hey ___ Haskell mailing list [EMAIL PROTECTED] http://www.haskell.org/mailman/listinfo/haskell

Re: Binary I/O in haskell.

hPutBuf & hGetBuf" threads in the archive of the libraries mailing list. Regards -- Adrian Hey ___ Haskell mailing list [EMAIL PROTECTED] http://www.haskell.org/mailman/listinfo/haskell

Re: avoiding cost of (++)

e) style probably gives more cache friendly code. Of course whether or not this really is better depends on context it's used. In your case using revJoin would undo the reversal of pre in mapWith' (which may or may not be a good thing) Regards -- Adrian Hey _

Re: Q: Forcing repeated evaluation

ith no arguments (implying no sharing allowed). > squares = \ -> [i*i| i <- [1..]] I'm not sure what the semantic consequences of this would be, or even if the concept of 'sharing' has any sensible meaning in Haskell. (There's prob

Re: Q: Forcing repeated evaluation

Clean addresses this problem by defining the language semantics in terms of graph re-writing rather than lambda calculus. So, I guess Clean outlaws transformations which change the sharing of graphs. It seems a pity something similar can't be done for H

Re: Programming style question

But I wasn't too sure whether the two forms would give equally efficient code (and if not then which one was 'best'). It seems the answer depends on the compiler implementation and/or the level of optimisation selected. Regards -- Adrian Hey ___ Haskell mailing list [EMAIL PROTECTED] http://www.haskell.org/mailman/listinfo/haskell

Re: Programming style question

n which can be lifted outside one but not the other (as in this case) then it won't do the full laziness thing at all. (But don't quote me on that because it's entirely possible I misunderstood:-) Regards -- Adrian Hey ___ Haskell mailing list [EMAIL PROTECTED] http://www.haskell.org/mailman/listinfo/haskell

Programming style question

identical (and should yield identical code), but it appears that isn't so (with ghc at least). So.. Is there a semantic difference between the two? Which form is likely to result in faster code? Thanks -- Adrian Hey ___ Haskell mailing list [

Re: Another question about sharing

mean it has to be applied to a whole program in any case? (I can't think of any other reason it can't be included in a source file). Regards -- Adrian Hey ___ Haskell mailing list [EMAIL PROTECTED] http://www.haskell.org/mailman/listinfo/haskell

Re: Another question about sharing

cts the constant each time it's called, rather than having just one occurrence as a CAF.) It's typically used to inhibit sharing. I don't believe there is any such distinction in Haskell. I thought maybe there was a trick you could use in Haskell t

Another question about sharing

m back to the lambda lifting problem again). So it has to be any handy unknown variable (argument)? This presents the problem that the unknown variable may itself be quite large, and have it's lifetime unduly prolonged because it's now referenced by many paths. Any advice? Thanks -- Adrian

Re: Type checking question

s an argument (or constants) this could cause problems. Just an idea. I don't think this would help with your show example though, which as you observed, is ambiguous for a different reason. Regards -- Adrian Hey ___ Haskell mailing list [EMAIL

Type checking question

tion? Something like this perhaps.. myNothing :: Maybe dummyAdjustmentClassInstance myNothing = Nothing txt <- textNew myNothing myNothing I'm pretty sure that would do it, but it seems like an ugly solution. Is there a better way? Thanks -- Adrian Hey ___ Haskel

Re: Knight Problem

ell-cafe list if you like.) Regards -- Adrian Hey ___ Haskell mailing list [EMAIL PROTECTED] http://www.haskell.org/mailman/listinfo/haskell

First Class Modules? was Re: Are anonymous type classes the right model at all?

d somebody explain what a first class module is? How does it differ from a record? What could I do with a first class module (if Haskell provided them)? Thanks -- Adrian Hey ___ Haskell mailing list [EMAIL PROTECTED] http://www.haskell.org/mailman/listinfo/haskell

Re: Finding primes using a primes map with Haskell and Hugs98

On Sun 17 Dec, Adrian Hey wrote: > You can use a variation of this algorithm with lazy lists.. > > primes = 2:(get_primes [3,5..]) > get_primes (x:xs) = x:(get_primes (strike (x+x) (x*x) xs))

Re: Finding primes using a primes map with Haskell and Hugs98

stack, 4000K of Heap allocated). (I haven't actually tried this in Haskell 'cos I don't have a Windoze or 'nix box.) Regards -- Adrian Hey ___ Haskell mailing list [EMAIL PROTECTED] http://www.haskell.org/mailman/listinfo/haskell

Re: Preemptive thread switching in concurrent haskell??

I seem to remember reading that Concurrent Haskell only needs 1 stack, rather than 1 stack per thread. Is this true? (If so I can't see how this can be done using preemptive thread switching.) Regards -- Adrian Hey

Re: Higher-order function application

biguities caused by overloading. It makes programs harder to understand IMHO. But people who think this way seem to be in a minority, so maybe your proposal will get the approval of somebody other than me :-) Regards -- Adrian Hey

Re: The importance and relevance of FP

emory management!)? Something more fundamental perhaps? As for FP in the large (I.E. writing an entire system in a functional language) this is something which interests me a lot. But if I was doing that I wouldn't be using NGWS anyway, so there should be no problems. Regards -- Adrian Hey

Re: GC in embedded systems (was Re: Haskell and the NGWS Runtime)

ine 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)

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)

. 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)

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

GC in embedded systems (was Re: Haskell and the NGWS Runtime)

plement 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 jobs

f well. But you will have to compete with 'methodology' merchants (expert b*ll sh*tt*rs). > 4) Should I just try for a Ph.D. and wait for the rest of the country to > catch up? This is even better than unemployment. Regards -- Adrian Hey

Re: Haskell & Clean

f both Clean & Haskell at present. It isn't true of Concurrent Haskell, and I understand the Clean Team are working on extensions to allow non-deterministic concurrency. BTW, was the debate re. pure functionality of Concurrent Haskell ever resolved? (I think followers of the Clean list will remember this:-). Regards -- Adrian Hey

Re: Haskell & Clean

value (when implemented as a part of a program running in 'real time') can be regarded as inconsistent. Regards -- Adrian Hey

Re: Unevaluated worlds

s that representation does not imply execution (I think). Regards -- Adrian Hey

Re: Haskell & Clean

ned with it that can't be explained just as well without it. I feel this way about 'functions' operating on 'world values'. Regards -- Adrian Hey

Re: Haskell & Clean

:: IO a -> (a -> IO b) -> IO b (>>=) f g world = let (a,new_world) = f world in g a new_world return :: x -> IO x return x world = (x,world) Regards -- Adrian Hey

Re: Haskell & Clean

ch the horrors to the non-Haskell outside entity (the IO monad machine), not to Haskell. (I assume we forgive the performUnsafeIO or whatever it's called). BTW, I would not assert that Clean IO is horror free, but many people would. Regards -- Adrian Hey

Re: Haskell & Clean

ot so bad. Non-deterministic concurrency is more usefull IMHO. It also means we don't have to pretend IO environments are independent when in reality they rarely are. In Concurrent Haskell it is the programmers responsibility to co-ordinate different threads so that the program works as intended. Regards -- Adrian Hey

Re: Unique Types in haskell (was Re: OO in Haskell)

programmers of course, not languages). So maybe, as you say, uniqueness typing would be useful in Haskell. It seems to give Clean a speed advantage for number/array crunching at present (or so I've heard, though I must confess I've never tried it in either language). Regards -- Adrian Hey

Re: OO in Haskell

ell is good for deterministic sequentiality. Concurrent Haskell is good for non-deterministic concurrency. Regards -- Adrian Hey

Re: OO in Haskell

sed :-) Regards -- Adrian Hey

Re: Haskell verification Tools?

e. You can get it here.. http://www.cs.kun.nl/~maartenm/CleanProverSystem/ Regards -- Adrian Hey

Re: OO in Haskell

well.) Also, the fact that the machine which executes values of type (IO a) is not regarded as part of Haskell is also not widely understood I think. (Well, at least I had not understood this before.) Regards -- Adrian Hey

Re: Referential Transparency

to side effect free parts of a program. They are still purely functional (except the IO monad IMHO, but I'm sure many people don't agree with me on this). Regards -- Adrian Hey

Re: Referential Transparency (was Re: OO in Haskell)

a language with what we need to write real programs, then that's OK. I don't recall anybody rejecting non-strict semantics because it invalidated a && b = b && a :-) But I would agree that we don't want to do anything that turns functions into notfunctions. That's really why I kept insisting that actions _weren't_ functions (although everyone else seems to think they are, for reasons I'm still unable to fathom.) Regards -- Adrian Hey

Re: Referential Transparency (was Re: OO in Haskell)

(but indeterminable) model of the universe and one which simply says the results of IO actions may be subject to unknown side effects. So aren't we just really arguing about words, not facts? Regards -- Adrian Hey

  1   2   >