- Haskell-Cafe - Haskell.org

Re: let/where
by Norman Ramsey 20 Sep '01

20 Sep '01

> There was some debate about which to have - it's a matter of personal > preference and style. The problem is that if you have both let and where > in the expression syntax, then > > let a in b where c > > is ambiguous unless you make an arbitrary decision about the precedence, Was it not considered to forbid such ambiguous expressions, requiring explicit parentheses to resolve the ambiguity? Norman, who sometimes wishes `where' were a postfix `let', and not part of the declaration syntax (though he does not wish to give up scoping over multiple guards).

2 1

let/where
by Mark Carroll 20 Sep '01

20 Sep '01

There seem to be a few situations where it's not clear to me when to use "let" and when "where". For instance, in this little example I was playing with to work out what syntax works, main = putStr (show (if maybe_index == Nothing then DP_Unknown else DP_Number index) ++ "\n") where maybe_index = maybe_read word (Just index) = maybe_index or... main = let maybe_index = maybe_read word (Just index) = maybe_index in putStr (show (if maybe_index == Nothing then DP_Unknown else DP_Number index) ++ "\n") Does anyone care? At the moment I use "where" so that at a first glance you get an overall idea of things, then you can read further for details if you like. I was disappointed to find that I don't seem to be able to write things like, main = let maybe_index = maybe_read word in putStr (show (if maybe_index == Nothing then DP_Unknown else DP_Number index) ++ "\n") where (Just index) = maybe_index BTW, is the above a sane way of getting the 'index' 'out of' the "Just"? I often seem to be using a "where (Just foo) = bar" type of idiom. (Of course, there is that special "let" stuff for "do" notation too which doesn't seem to use "in".) I hope all that was somewhat coherent, anyway, or at least sheds light on some of the confusion of newcomers to Haskell! -- Mark

3 2

Subscribe
by John Miller 18 Sep '01

18 Sep '01

ProClarity Corporation John Miller Research & Development <mailto:jmiller@proclarity.com> jmiller(a)proclarity.com (208)344-1630 ext. 111

1 0

Re: Multiple applications of a function
by Marcin 'Qrczak' Kowalczyk 16 Sep '01

16 Sep '01

Sun, 16 Sep 2001 10:52:07 -0400 (EDT), Mark Carroll <mark(a)chaos.x-philes.com> pisze: > To multiply apply a function, I'm currently using: > > multiplyApply f n a = (iterate f a) !! n > > ...is there a Prelude function I've missed that already does this? Unfortunately not. > Could I be doing this better? I think an explicit recursion would make it easier to compile efficiently, and it can give a better error message for n < 0. -- __("< Marcin Kowalczyk * qrczak(a)knm.org.pl http://qrczak.ids.net.pl/ \__/ ^^ SYGNATURA ZASTÊPCZA QRCZAK

1 0

Multiple applications of a function
by Mark Carroll 16 Sep '01

16 Sep '01

To multiply apply a function, I'm currently using: multiplyApply f n a = (iterate f a) !! n ...is there a Prelude function I've missed that already does this? Could I be doing this better? -- Mark

1 0

Re: Application letters at the Haskell workshop: suggestion
by Ashley Yakeley 16 Sep '01

16 Sep '01

At 2001-09-15 08:31, Mark Carroll wrote: >AFAICS a simple way to get >out of this is to only have one exception type that carries no information >instead of different ones so we can't distinguish one exception from >another, but that's obviously not great. Isn't that what 'bottom' is? -- Ashley Yakeley, Seattle WA

2 1

Re: controlling resource usage
by D. Tweed 12 Sep '01

12 Sep '01

On Fri, 7 Sep 2001, Richard Uhtenwoldt wrote: > Finally, are we all in agreement that it would be a great thing if > someone invented a Haskell-like language as good as Haskell at hiding > resource usage when resource usage is unimportant, but that made it > easier to control resource usage than Haskell does when resource usage > is important? Of course it's not just in functional languages that performance demands can require rewriting shorter, more comprehensible code in less obvious ways. (My favourite example of something so completely non-intuitive is the Intel example from within a Sieve of Eratosthenes program that for(i=0;i<lim/step;++i){ prime[i*step]=0; } can on some processor setups be slower than for(i=0;i<lim/step;++i){ if(prime[i*step]!=0){ prime[i*step]=0; } } due to cache coherency issues.) In that context, there was an old suggestion of Don Knuth's that program source code should in the idealized future not just contain the final, optimized code (with perhaps the original code in comments) but as a kind of set of layers each representing the same semantic program but with increasing orders of optimisation, and links between `things' annotated with a label placed by the programmer explaining why the transformation between an unoptimised version `thing' and an optimised `thing'. The nice bit about this would be that the development environment would be equipped with a subsystem that could almost always establish (possibly using the the label on the link) if the two things had the same semantic effect, and a naive system that could try and produce (maybe using brute force pattern modification) the changes to the optimised version corresponding to changes to the unoptimised version. The nice thing about this is that it would allow changes to the code (due to say changing requirements, or ideas for better algorithms) to be made first to the simple version and then the areas of the optimised version that needed changing would be automatically brought to the programmers attention. (The system for trying to change the optimised code automatically is just there to stop the system becoming really annoying every time you do something something like int i=1; _______\ int i=2; int j=2; / int j=1; to the unoptimised code. The reason I think this would be a good idea is because I don't really object that much to having to optimise code that's performance critical, I just dislike the way that I never manage to keep both the original and optimised version in sync and so end up having to maintain the optimised code directly. I suspect that such a system is still at least 25 years away from feasiblity though :-( ___cheers,_dave________________________________________________________ www.cs.bris.ac.uk/~tweed/pi.htm |tweed's law: however many computers email: tweed(a)cs.bris.ac.uk | you have, half your time is spent work tel: (0117) 954-5250 | waiting for compilations to finish.

4 7

Reproducing lazy evaluation in Scheme
by David Barton 11 Sep '01

11 Sep '01

All right, I know this is a stupid question. I know the models of evaluation in call by name and call by value languages; however, I am kind of puzzled by trying to reproduce call by name in a call by value language using force and delay. If I put a delay around the right side of each equation and around each expression in a function call (*all* function calls?), and a force call around each variable reference, would that get me call by name semantics? Am I completely screwed up here? Is something more necessary? I'm trying to get the gumption up to try a proof by substitution of this idea, but I cringe at the formula manipulation....... Dave Barton <*> dlb(a)averstar.com )0( http://www.averstar.com/~dlb

1 0

Pickling
by Mark Carroll 10 Sep '01

10 Sep '01

Am I right in thinking that there aren't currently any standard libraries for converting values to bitstreams and back, to be saved in files or squirted over network sockets or whatever to be resurrected later or elsewhere? I'd guess it would be hard to write, too - I've not noticed any introspection. How do people normally efficiently pass complex Haskell data structures to other co-operating Haskell processes? (I am thinking of something a bit like Java's serialisation.) -- Mark

5 6

Algebraic types and `objects'
by S.J.Thompson 06 Sep '01

06 Sep '01

To follow up Cagdas Ozgenc's message of Wednesday, I have attached a series of files which show a gradual transformation (or refactoring) of an algebraic type of shapes into a Shape type, built using type classes and existential types, which more corresponds to an OO approach. Hope this is useful. Simon

1 0