[GHC] #1052: NCG doesn't realise shift instructions trash shifted input?
#1052: NCG doesn't realise shift instructions trash shifted input?
---+
Reporter: igloo | Owner:
Type: bug | Status: new
Priority: normal | Milestone: 6.8
Component: Compiler (NCG) | Version: 6.6
Severity: normal |Keywords:
Difficulty: Unknown |Testcase: arith011
Architecture: x86_64 (amd64) | Os: Linux
---+
It looks like the NCG on amd64/Linux doesn't realise that shifting
instructions trash the shifted input (spotted due to arith011). With this
input file:
{{{
module Main where
import Data.Bits
import GHC.Exts
main = print ((2 :: Int) `qrotate` 1)
{-# NOINLINE qrotate #-}
(I# x#) `qrotate` (I# i#) =
(I# (word2Int# (a# `or#` b#)), W# a#, W# b#)
where
x'# = int2Word# x#
i'# = word2Int# (int2Word# i# `and#` int2Word# (wsib -# 1#))
a# = x'# `uncheckedShiftL#` i'#
b# = x'# `uncheckedShiftRL#` (wsib -# i'#)
wsib = 64#
}}}
compiling with `-O -fglasgow-exts -v9` if I merge the Cmm and Asm output I
get:
{{{
R2 == rsi
R3 == rdi
_sTh = R3;movq %rdi,%rax rax=_sTh
_sTj = _sTh 63; andq $63,%rax rax=_sTj
_sTl = _sTj; rax=_sTl
_sTp = R2;movq %rsi,%rcx rcx=_sTp
movq %rcx,64(%rsp)
_sTs = 64 - _sTl; movl $64,%ecx
subq %rax,%rcx
movq 64(%rsp),%rdx
_sTu = _sTp _sTs; shrq %cl,%rdx
movq %rdx,%rcx \
movq %rcx,72(%rsp) / why?
movq %rax,%rcx
_sTx = _sTp _sTl; shlq %cl,%rdx but rdx contains _sTp _sTs!
I64[Hp + (-40)] = base_GHCziWord_Wzh_con_info;
I64[Hp + (-32)] = _sTu;
I64[Hp + (-24)] = base_GHCziWord_Wzh_con_info;
I64[Hp + (-16)] = _sTx;
_sTz = _sTx | _sTu;
_sTB = _sTz;
I64[Hp + (-8)] = base_GHCziBase_Izh_con_info;
I64[Hp + 0] = _sTB;
R1 = Hp + (-8);
R2 = Hp + (-24);
R3 = Hp + (-40);
jump (I64[Sp + 0]);
}}}
Thanks
Ian
--
Ticket URL: http://hackage.haskell.org/trac/ghc/ticket/1052
GHC http://www.haskell.org/ghc/
The Glasgow Haskell Compiler___
Glasgow-haskell-bugs mailing list
Glasgow-haskell-bugs@haskell.org
http://www.haskell.org/mailman/listinfo/glasgow-haskell-bugs
RE: [Haskell] GHC Error question
| What Claus says. What is the real type that ghc infers? It's this: forall a b . C a b = a - a | If it's really what it claims it to be, then this is definitely a bug. | And it might not be common to you, but I have several places in my | code base where I have to leave off type signatures, because the | inferred signature is not accepted. I'd love to see those examples. Can you extract them? You could add them to http://hackage.haskell.org/trac/ghc/ticket/1050 Simon ___ Glasgow-haskell-users mailing list Glasgow-haskell-users@haskell.org http://www.haskell.org/mailman/listinfo/glasgow-haskell-users
Re: Network.Socket endian problem?
On 12/13/06, Sigbjorn Finne [EMAIL PROTECTED] wrote: as you've time-consumingly discovered, Network.Socket.HostAddress is represented in network byte order (something that's not well documented, and a potential trap.) You may want to consider using Network.Socket.inet_addr as a constructor. Thanks to everyone for their help and suggestions. I agree, however, with Tomasz that the address should be in host byte order to the application. At the very least, the port value and the address should use the same byte ordering. For now, I'll use inet_addr as a constructor. Thanks again. -- Rich AIM : rnezzy ICQ : 174908475 ___ Glasgow-haskell-users mailing list Glasgow-haskell-users@haskell.org http://www.haskell.org/mailman/listinfo/glasgow-haskell-users
Re: Network.Socket endian problem?
Tomasz Zielonka [EMAIL PROTECTED] writes: On Wed, Dec 13, 2006 at 03:54:59PM -0600, Mark Hills wrote: It does expect the address to be in network byte order instead of host byte order, which is usually done using htons and htonl. This seems to do what you want (running SUSE 10.1 on an Intel box): Who agrees with me that it would be nice if network libraries used host byte order in their interface? Or at least they could use an abstract data type, whose byte order would be unobservable. Why is this trapdoor present in the C library? -- Feri. ___ Glasgow-haskell-users mailing list Glasgow-haskell-users@haskell.org http://www.haskell.org/mailman/listinfo/glasgow-haskell-users
Re: Network.Socket endian problem?
On Thu, Dec 14, 2006 at 05:22:43PM +0100, Ferenc Wagner wrote: Tomasz Zielonka [EMAIL PROTECTED] writes: On Wed, Dec 13, 2006 at 03:54:59PM -0600, Mark Hills wrote: It does expect the address to be in network byte order instead of host byte order, which is usually done using htons and htonl. This seems to do what you want (running SUSE 10.1 on an Intel box): Who agrees with me that it would be nice if network libraries used host byte order in their interface? Or at least they could use an abstract data type, whose byte order would be unobservable. Why is this trapdoor present in the C library? I don't know. Maybe for efficiency? Best regards Tomasz ___ Glasgow-haskell-users mailing list Glasgow-haskell-users@haskell.org http://www.haskell.org/mailman/listinfo/glasgow-haskell-users
[Haskell] PLAN-X 2007: Call for Participation [and Program Updates]
Call for Participation P L A N - X 2 0 0 7 Programming Language Technologies for XML An ACM SIGPLAN Workshop collocated with POPL 2007 Nice, France -- January 20, 2007 www.plan-x-2007.org || UPDATE: - Christoph Koch (U Saarland, Germany) will give the || || PLAN-X 2007 keynote speech. || || - The detailed program is available (included below). || Please join us for PLAN-X 2007, the fifth workshop in the PLAN-X series, dedicated to the interaction and integration of programming language technology and the world of XML. The XML data model and its associated languages add interesting twists to programming language practice as well as theory. Just like its four predecessors, the PLAN-X 2007 workshop turns the spotlight on how programming language technology can embrace and explain streaming XML transformations, types for XPath and XML updates, web service contracts, tree patterns in XQuery, LINQ and XML Schema, and more. PLAN-X 2007 will feature eight talks, three system demonstrations, extensive opportunity for discussion, and a keynote address (speaker to be announced). PLAN-X 2007 will be held in the Plaza Hotel (Nice, France) all-day on Saturday, January 20, 2007, just after and collocated with POPL 2007, the ACM SIGPLAN - SIGACT Symposium on Principles of Programming Languages (January 17-19, 2007). -- PROGRAM (Saturday, January 20, 2007) 09:00--10:00 Welcome Invited Talk by Christoph Koch (U Saarland, Germany) (title to be announced) 10:00--10:30 Coffee break 10:30--12:00 Session 1: Research Papers Streaming XML Transformations Using Term Rewriting (Alain Frisch, Keisuke Nakano) How to Recognise Different Kinds of Tree Patterns From Quite a Long Way Away (Jan Hidders, Philippe Michiels, Jerome Simeon, Roel Vercammen) Lux: A Lightweight, Statically Typed XML Update Language (James Cheney) 12:00--01:30 Workshop lunch (provided) 01:30--03:10 Session 2: Research Papers and Demo Presentations A Theory of Contracts for Web Services (Giuseppe Castagna, Nils Gesbert, Luca Padovani) XML Transformation Language Based on Monadic Second Order Logic (Kazuhiro Inaba, Haruo Hosoya) Demo: MTran: An XML Transformation Language Bases on Monadic Second Order Logic (Kazuhiro Inaba, Haruo Hosoya) Demo: XCentric: A Logic-Programming Language for XML Processing (Jorge Coelho, Mário Florido) Demo: LINQ to XSD (Ralf Lämmel) Demo: GeLaBa: A Framework to Define Classes of XML Documents and to Automatically Derive Specialized Infrastructures (Benoit Pin, Georges André Silber) 03:10--04:00 Interactive Demos and Coffee break 04:00--05:30 Session 3: Research Papers XPath Typing Using a Modal Logic with Converse for Finite Trees (Pierre Geneves, Nabil Layaida, Alan Schmitt) Deciding Equivalence of Top-Down XML Transformations in Polynomial Time (Sebastian Maneth, Helmut Seidl) A Logic Your Typechecker Can Count On: Unordered Tree Types in Practice (Nate Foster, Benjamin C. Pierce, Alan Schmitt) -- REGISTRATION PLAN-X 2007 is held in cooperation with POPL 2007. You can register for the workshop via the POPL 2007 registration process (online or offline). Please visit http://www.regmaster.com/conf/popl2007.html Registration rates are shown below. The rates are unaffected by the POPL 2007 early bird registration deadline. Note that you can upgrade an existing POPL 2007 registration to include PLAN-X 2007. Workshop-only registration is possible as well. ACM or SIGPLAN Member $89 Non-Member $99 Student $89 Your registration includes a copy of the PLAN-X 2007 informal proceedings, coffee breaks, and lunch. -- PLAN-X 2007 Workshop Chairs - General Chair - Program Chair Torsten Grust Giorgio Ghelli TU MünchenU Pisa Munich, Germany Pisa, Italy [EMAIL PROTECTED] [EMAIL PROTECTED] -- PLAN-X 2007 Program Committee - Michael Benedikt (Lucent,
[Haskell] haskell.org memory upgrade
Dear Haskellers -- Haskell.org will go down today at 1500 EST for about 10 minutes for a memory upgrade. Sorry for the inconvenience, -Paul Hudak ___ Haskell mailing list Haskell@haskell.org http://www.haskell.org/mailman/listinfo/haskell
Re: [Haskell] ANNOUNCE: Phooey -- a Functional UI library for Haske ll
On Wed, 13 Dec 2006 09:53:20 -0800, you wrote: As for doing push in a functional approach, do you mean under the hood, or somehow a visible push model? Phooey does push under the hood, but hides it from the user. I don't know what a functional, visible push model would look like. I meant visible. In the absence of hardware interrupts or the like, you still have to have some kind of prime mover to get the ball rolling; that could be a simple polling loop or whatever. In effect, it would invoke a function on each input widget in turn, and the consequences of those function invocations would ripple through the system (and eventually to the output widgets). Of course, it would likely be functional in name only, as I suspect that there would rarely be occasion to use functions whose return type is anything other than IO (). Steve Schafer Fenestra Technologies Corp. http://www.fenestra.com/ ___ Haskell mailing list Haskell@haskell.org http://www.haskell.org/mailman/listinfo/haskell
[Haskell] ANNOUNCE: Basic serialization library using only existing SYB infrastructure
Announcing GenericSerialize, a library for serialization using the existing generic-programming framework. It is often advocated that support for serialization should be added to the compiler (e.g. in the form of a deriving(Binary)). With this I intend to show that the existing infrastructure is sufficient, and has some advantages over a dedicated serialization interface. The main advantage that generic serialization posseses is that it is possible to simultaneously have several serialization modes. While interfaces such as AltBinary allow writing to any type of stream, the data format is fixed. By contrast, GenericSerialize supports multiple serialization modes; while the only currently existing module is for a subset of R5RS s-expressions, that module is less than 100 lines of code and is almost pure grammar. See the included README for (minimal...) usage examples. darcs get http://members.cox.net/stefanor/genericserialize wget http://members.cox.net/stefanor/genericserialize-0.0.tar.gz ___ Haskell mailing list Haskell@haskell.org http://www.haskell.org/mailman/listinfo/haskell
strictly matching monadic let and overloaded Bool (was: Are pattern guards obsolete?)
consider the following examples:
-- do-notation: explicit return; explicit guard; monadic result
d _ = do { Just b - return (Just True); guard b; return 42 }
-- list comprehension: explicit return; implicit guard; monadic (list) result
lc _ = [ 42 | Just b - return (Just True), b ]
-- pattern guard: implicit return; implicit guard; non-monadic result
pg _ | Just b - Just True, b = 42
This ongoing discussion has made me curious about whether we could actually
get rid of these irregularities in the language, without losing any of the
features
we like so much.
=== attempt 1
(a) boolean statements vs guards
this looks straightforward. Bool is a type, so can never be an instance of
constructor class Monad, so a boolean statement in a monadic context is
always invalid at the moment. that means we could simply extend our
syntactic sugar to take account of types, and read every
((e :: Bool) :: Monad m = m _)
in a statement of a do block as a shorthand for
(guard (e :: Bool) :: Monad m = m ())
(b) missing return in pattern guards
this could be made to fit the general pattern, if we had (return == id).
that would put us into the Identity monad, which seems fine at first,
since we only need return, bind, guard, and fail. unfortunately, those
are only the requirements for a single pattern guard - to handle not
just failure, but also fall-through, we also need mplus. which means
that the Identity monad does not have enough structure, we need at
least Maybe..
this first attempt leaves us with two problems. not only is (return==id)
not sufficient for (b), but the suggested approach to (a) is also not very
haskellish: instead of having syntactic sugar depend on type information,
the typical haskell approach is to have type-independent sugar that
introduces overloaded operations, such as
fromInteger :: Num a = Integer - a
to be resolved by the usual type class machinery. addressing these two
issues leads us to
=== attempt 2
(a) overloading Bool
following the approach of Num and overloaded numeric literals, we could
introduce a type class Boolean
class Boolean b where
fromBool :: Bool - b
instance Boolean Bool where
fromBool = id
and implicitly translate every literal expression of type Bool
True ~~ fromBool True
False ~~ fromBool False
now we can embed Boolean statements as monadic statements simply by
defining an additional instance
instance MonadPlus m = Boolean (m ()) where
fromBool = guard
(b) adding a strictly matching monadic let
we can't just have (return==id), and we do not want the hassle of having to
write
pattern - return expr
in pattern guards. the alternative of using let doesn't work either
let pattern = expr
because we do want pattern match failure to abort the pattern guard and
lead to overall match failure and fall-through. so what we really seem to want
is a shorthand notation for a strict variant of monadic let bindings. apfelmus
suggested to use '=' for this purpose, so that, wherever monadic generators
are permitted
pattern = expr ~~ pattern - return expr
===
returning to the examples, the approach of attempt 2 would allow us to write
-- do-notation: implicit return; implicit guard; monadic result
d _ = do { Just b = Just True; b; return 42 }
-- list comprehension: implicit return; implicit guard; monadic (list) result
lc _ = [ 42 | Just b = Just True, b ]
-- pattern guard: implicit return; implicit guard; non-monadic result
pg _ | Just b = Just True, b = 42
almost resolving the irregularities, and permitting uniform handling of related
syntactic constructs. hooray!-)
I say almost, because Bool permeates large parts of language and libraries,
so one would need to check every occurence of the type and possibly
replace Bool by (Boolean b = b). the Boolean Bool instance should mean
that this process could be incremental (ie, even without replacements, things
should still work, with more replacements generalizing more functionality,
similar to the Int vs Integer issue), but that hope ought to be tested in
practice.
one issue arising in practice is that we would like to have
fromBool :: MonadPlus m = Bool - m a
but the current definition of guard would fix the type to
fromBool :: MonadPlus m = Bool - m ()
which would require type annotations for Booleans used as guards. see the
attached example for an easy workaround.
on the positive side, this approach would not just make pattern guards more
regular, but '=' and 'MonadPlus m = Boolean (m ()) would be useful for
monadic code in general. even better than that, those of use doing embedded
DSLs in Haskell have been looking for a way to overload Bools for a long
time, and the implicit 'Boolean b = fromBool :: Bool - b' ought to get us
started in the right direction. most likely, we would need more Bool-based
constructs to be overloaded for
Re: strictly matching monadic let and overloaded Bool (was: Are patternguards obsolete?)
one issue arising in practice is that we would like to have fromBool :: MonadPlus m = Bool - m a but the current definition of guard would fix the type to fromBool :: MonadPlus m = Bool - m () which would require type annotations for Booleans used as guards. see the attached example for an easy workaround. what attachment, you ask? sorry, lack of sleep - now attached to this message. claus Boolean.hs Description: Binary data ___ Haskell-prime mailing list Haskell-prime@haskell.org http://www.haskell.org/mailman/listinfo/haskell-prime
Higher order syntactic sugar
apfelmus suggested to use '=' for this purpose, so that, wherever monadic generators are permitted pattern = expr ~~ pattern - return expr It was to late when i realized that = is already used as smaller than or equal to :) Obviously, the difference between the pattern guard - and the monadic - let easily slips by. I think this has to do with the fact that do-notation is not the natural style for MonadPlus Maybe, the natural style is more like the current syntax of pattern guards. I mean that one rarely hides a Just constructor like in do r - lookup x map because returning Maybe is a very special case, there are many other constructors to match on where one wants fall-back semantics. Of course, every sum type can be projected to Maybe X =~= X + 1 but this involves boilerplate. In a sense, do-notation is just not appropriate for MonadPlus Maybe. It is somewhat unfortunate that while arrows, monads and pattern guards (= MonadPlus Maybe) could share the same syntax, it is not advisable to do so because this introduces quite annoying boilerplate. The most general syntax is too much for the special case. But there is something more canonical than completely disjoint syntax: in a sense, Claus' suggestions are about making the syntax for the special case a *subset* of the syntax for the more general one. The partial order of syntax inclusion should look something like Arrows \ \ MonadPlus \ / Monad Even though arrows are more general than monads (less theorems hold), they require more syntax. On the other hand, MonadPlus provides more than a monad, so it needs a new syntax, too. Remember that these are not the only computation abstractions. Syntactic sugar for pseudo-let-declarations (akin to MonadFix but order independent, can be embedded using observable sharing) is advisable, too. Only applicative functors behave very nicely and fit into current Haskell syntax (maybe that's the reason why they have been discovered only lately? :). In a sense, even ordinary Haskell (= pure functions) is only syntactic sugar. Some higher order syntactic sugar melting machine bringing all these candies together would be very cool. Regards, apfelmus ___ Haskell-prime mailing list Haskell-prime@haskell.org http://www.haskell.org/mailman/listinfo/haskell-prime
Re: Higher order syntactic sugar
ooohh.. when I saw the subject, I fully expected a worked out proposal for
extensible syntax in Haskell, just in time for Christmas. well, maybe next
year!-)
It was to late when i realized that = is already used as smaller than
or equal to :)
oops. okay, lets change that. what about this:
pattern = expr ~~ pattern - return expr
a cleaner variant would be a let!, perhaps, but that would probably be too
noisy for pattern guards? (also, we don't want to steal nice infix ops like ==)
do-notation is not the natural style for MonadPlus Maybe, the natural
style is more like the current syntax of pattern guards. I mean that one
rarely hides a Just constructor like in
oh? getting rid of nested (case x of {Just this -..; Nothing - that}) is a
very good argument in favour of do-notation for Maybe, and I find that
very natural (for some definition of nature;-). granted, once one has taken
that step, one is close to writing in monadic style anyway, so it is no longer
specific which constructors are hidden. but I don't see a specific problem
with Maybe there, and I haven't seen convincing sugar for MonadPlus yet.
general syntax is too much for the special case. But there is something
more canonical than completely disjoint syntax: in a sense, Claus'
suggestions are about making the syntax for the special case a *subset*
of the syntax for the more general one.
indeed. thanks for pointing that out. I first went the other direction, but
as you say, generalizing pattern guards introduces too much syntax in an
awkward place. so my current suggestion follows the subset idea.
Some higher order syntactic sugar melting machine bringing all these
candies together would be very cool.
hooray for extensional syntax!-) syntax pre-transformation that would
allow me to extend a Haskell parser in library code is something I'd
really like to see for Haskell, possibly combined with error message
post-transformation. together, they'd smooth over the main objections
against embedded DSLs, or allow testing small extensions of Haskell.
I have been wondering in the past why I do not use Template Haskell
more, given that I'm a great fan of meta-programming and reflection,
and I think the answer is that it sits in an unfortunate way between two
chairs: it cannot quite be used for syntax extensions because it insists
on Haskell syntax/scopes/types, and it cannot quite be used as a
frontend because there's some typing coming after it. persistent users
have found wonderful things to do with it nevertheless, even analysis/
frontend stuff, but its main use seems to be program-dependent
program generation, within the limits of Haskell syntax.
in fact, I have a pragmatic need for even more, namely type system
extensions as well: somewhere on my disk, I have a type-directed
monadification prototype, based on a type system that infers not
just a type, but a type coercion; works well, at least for simple
monomorphic code, but what do I do with it? being type-directed,
it uses a completely different foundation than the rest of HaRe
refactorings, and to fully realize it for Haskell, I'd have to implement
and -here comes the killer- maintain a complete Haskell type system,
just because I need a few modifications/extensions. it is just not
practical to do so, let alone once for every type-directed algorithm.
Claus
___
Haskell-prime mailing list
Haskell-prime@haskell.org
http://www.haskell.org/mailman/listinfo/haskell-prime
Re: [Haskell-cafe] Aim Of Haskell
I have been keeping up with this thread. As a user of Haskell for comercial purposes, I can say that it does what I want. The only thing currently on my wish-list is some sort of run time debuging. (sometimes you want to know how you got to the empty list that you took the head of :) Anyhow, I find haskell more than adequete for my programming. I say this to set up my next statement. I really don't want there to be huge accretions to the language proper. I understand lisp has had a rough go because there wasn't enough standardisation of libraries, but on the other hand, I think languages like Java went overboard. My point, I guess, is that I find haskell to be easy and efficient to develop applications with. It is quite practical. Also, the academic research that goes in to Haskell continues to make it more practical. I, for one, do not want the spirit of Haskell to change just to make it how people think it would be useful in the comercial world. It's current spirit makes it very useful and rewarding. Now, haskell isn't the right tool for every job. I still use languages such as Perl, C, and Java. All I can say is any tool that tries to do everything will excel at none of them. If your particular problem is a good match for Haskell, please do use it. If it is not, then find a language that fits your problem better. I apologise for the rambling, but it is 3am here and I should be in bed ;) I suppose I've rambled enough -mdg On 12/13/06, Kaveh Shahbazian [EMAIL PROTECTED] wrote: I think this is going out of the way. Excuse me, but the main discussion was not about pascal! And thanks again to all. Now I think there is a bigger whole between current situation of Haskell and using It as a real tool, than what I thought before. But any way; I still have a hope for rising a new folk of thinkers in software world that will put ideas to work more practically. Haskell got academic-centric-being syndrome, as JAVA got perfectionism syndrome (see elegant and useless design patterns and architectures there!). I can not imagine a pure and clear vision about this new folk that IT world lakes now. If anyone helps me with clarification of this thing, It will be great to me! Best regards ___ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe -- Our problems are mostly behind us, now all we have to do is fight the solutions. ___ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe
Re: [Haskell-cafe] Aim Of Haskell
On Thu, Dec 14, 2006 at 03:03:51AM -0500, Mark Goldman wrote: I have been keeping up with this thread. As a user of Haskell for comercial purposes, I can say that it does what I want. The only thing currently on my wish-list is some sort of run time debuging. (sometimes you want to know how you got to the empty list that you took the head of :) Anyhow, I find haskell more than adequete for my programming. I say this to set up my next statement. I really don't want there to be huge accretions to the language proper. I understand lisp has had a rough go because there wasn't enough standardisation of libraries, but on the other hand, I think languages like Java went overboard. My point, I guess, is that I find haskell to be easy and efficient to develop applications with. It is quite practical. Also, the academic research that goes in to Haskell continues to make it more practical. I, for one, do not want the spirit of Haskell to change just to make it how people think it would be useful in the comercial world. It's current spirit makes it very useful and rewarding. Seconded! I especially agree on the following points: - Haskell is useful for practical, commercial purposes NOW - Commercial development gets substantial benefits from academic research and the academic flavour of Haskell. If you want a less academic language, there are so many to choose from. Personally, I am sometimes a bit distressed by all those big demands articulated by newcomers to Haskell world, perhaps because most of the time these are things completely unneccesary for me (a non-academic programmer). Please have the humility to take some time to learn Haskell more, and then *maybe* you will appreciate the way some things are done. Best regards Tomasz ___ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe
Re: [Haskell-cafe] Mozart versus Beethoven (was: Writing Haskell For Dummies ...)
If I remember my EWD's[1] right, whether or not composing music is similar to writing programs was not Dijkstra's point. I paraphrase (possibly from another EWD, can't be bothered to look it up): Computers, in their capacity as a tool, are highly overrated. Dijkstra was referring to the fact (as also pointed out earlier in this thread) that, due to the volatility of things written on a computer (be it text, code or whatever), someone who writes things on a computer is inclined, even encouraged, to write in a very iterative fashion. Aka you just blabber on until you read the whole thing, press shift-pageup delete, and more or less start over (times 20). Dijkstra argued that this leads to bad thinking habits, and maintained a (in those and these days) very special writing style, typically by hand or with a typewriter. It forces you to actually think about a sentence before you put it down. It is a habit I have been trying to cultivate myself, and I must say no one here will be able to convince me that he or she can more quickly outweigh different sentences or paragraph options on screen than I can in my head. Whenever I want to write something down, and I just can't seem to get it right, I just take an empty piece of paper and write it. By hand. With a pen. I'm just old enough that I can remember writing papers in the earlier years of high school, by hand. I used to write them exactly twice: one time to get the text right, one time on the special school paper that I didn't like to waste. I've been re-training myself to be able to do that again. I've actually looked into some fairly old research, concerning the use of word processor and various so called tools in offices (not available online afaik, you'll have to search the library). If I remember correctly, some experiment was set up where professionial writers (journalists,...) were asked to write a number of words, some by hand, some with computers (as they preferred, ie as there habits dictated). It turns out that the writers who write by hand wrote much faster. Other studies typically show a decrease in offcice productivity after the installation of computer supported tools. Even on a recent ICSE (2005 I think), I saw a presentation of a sociologist or psychologist who measered the number of correct diagnosis of breast cancer using mammography, both with and without computer support. The outcome was not spectacularly in favour of the computer-supported case. It makes people lazy, and feel less responsible. Typically the harder to spot cases are better found by doctors without any computer support. I highly recommend reading some EWD's. They have changed my view on computing, programming, writing, basically about everything I do in my daily life. Kurt [1] Over a thousand manuscripts written by Edsger W. Dijkstra over his carreer, all available online. http://www.cs.utexas.edu/users/EWD/ ___ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe
RE: [Haskell-cafe] type variable question
| The commented out signature is the signature that GHC infers for the | function. When I uncomment that signature, it will no longer type | check. Why does this happen? Even with the forall and the explicit | signatures in the where clause, it chokes. This very question is one that came up only yesterday http://hackage.haskell.org/trac/ghc/ticket/1050 Could you boil out a small example? A good way to shrink code is to replace a function that is not playing a significant role with an error call: replace f :: type f = big rhs with f :: type f = error urk Usually that lets you get a small example. But if you can't, just send the whole thing Simon ___ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe
Re: [Haskell-cafe] Building the community
Hi * Give tips on how to answer questions + Ok. we can put up an article here. Some suggestions: - No questions are bad questions - Code should come with examples of how to run it - Solutions with unsafePerformIO should be discouraged (moreso ;) - Be polite! (we're good at this) I'd say our worst feature is tending to give solutions which are not simple Haskell, but make use of advanced features. When a beginner asks a question, sometimes the answer requires GADT's, Template Haskell, rank-2 types etc. However this is usually because they asked the wrong question - thinking in an imperative frame of mind. Often it would be better to peel back to the original problem, where the answer is more likely to be pure neat Haskell. I guess unsafePerformIO is just one instance of this. Thanks Neil ___ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe
Re: [Haskell-cafe] Re: Writing Haskell For Dummies Or At Least For People Who Feel Like Dummies When They See The Word 'Monad'
On Wed, 13 Dec 2006 17:18:31 +0100, Justin Bailey [EMAIL PROTECTED] wrote: On 12/12/06, Joachim Durchholz [EMAIL PROTECTED] wrote: Agreed. Something along the lines of The Art of Functional Programming. +1 . I would love to read something that is the equivalent of 'design patterns', but for functional languages. I thought Osasaki's book Purely Functional Data Structures would have that, but it was little too focused on proving properties of algorithms. As someone in industry, that wasn't so important to me. I want to learn how to think functionally. Seconded! The thing I appreciate about e.g. OO is that it is very clearly articulated what the principles are to make good design choices. Having e.g. some experience with grading fairly large OO projects from masters students, such a number of general rules of thumb are invaluable. It allows you to transform good design much more directly than through the typically Haskell way (it seems) of code examples. OO also has a clear goal: to improve reuse and simplify evolution. More or less all design problems can be illustrated by saying: but what happens if I want to add functionality y? You'll have to modify code in 200 places! It seems that most (all?) Haskell introduction focus on features (functions, pattern matching, type classes, monads,...), who seem somewhat interchangeable for any given problem (at least to my newbie eyes). Also, most idioms on the wiki and answers on questions here are based on very specific examples, from which I find it hard to generalise. Usually the argument goes along this way: Oh, I see you're using feature x (e.g. type classes). I prefer to use feature y (e.g. higher order functions) here, _because it's much more elegant_, and I rewrote your code as follows: Instead of that emphasised part, I'd like to see a more particular explanation, that starts from properties of the _problem_ (not of the solution). Along the lines of: Oh, I see you're having a typical representation problem where you need to decouple a data types structure from its content. Generally, this can be handled by using features x and y as follows. This will make it easy for you to change the type's content later with minimum changes, but will affect performance negatively if you' re not careful when using feature z. (ok, that didn't actually make sense, but you get the picture) Design patterns are a good way to make such knowledge explicit. At the moment, while learning haskell, my most important difficulty is how to translate a given problem to an elegant solution. What is elegant? What are my benchmarks to weigh different solutions against each other? Kurt ___ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe
[Haskell-cafe] Re: [Haskell] interpreter ouput in color
Hi Walter, Hi all. I was wondering if some people miss the colored output of some applications, such like the IPython enhanced shell. I've been googling for similar options for Haskell but I found nothing. WinHugs already colours (to some degree) and hyperlinks error messages. http://www-users.cs.york.ac.uk/~ndm/projects/winhugs.php (screenshot on that page) GuiHaskell does it a lot more, with full syntax colouring of error messages and hyperlinks. Unfortunately it can't be used reliably at the moment due to threading issues with Gtk+Gtk2Hs+GHC+Windows. http://www-users.cs.york.ac.uk/~ndm/projects/guihaskell.php GuiHaskell merely wraps GHCi (and Hugs and other stuff), so allows syntax colouring to be implemented without diving into the GHC source code. Thanks Neil PS. The Haskell-cafe mailing list is better for this sort of question, haskell tends to be more used for announcements, so i've sent the follow up there. ___ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe
Re: [Haskell-cafe] Mozart versus Beethoven (was: Writing Haskell For Dummies ...)
Another difference with music that strikes me is the level of abstraction : a note is a note. A line of code (especially in a imperative setting) is much more than a line of code. But this is exactly what semantics is about, or not? It is the question, when you have a set of symbols or abstractions, what sort of things do they represent. Interesting to think that the old greeks and chinese basically used only 4-5 sort of abstractions to explain the different forms of matter in the universe (http://en.wikipedia.org/wiki/Classical_element), whereas now we use at least 100 sort of atoms, and millions of sort of molecules. And without the simple abstractions by Euclid (point and lines), we could not evolve mathematics and most of modern sciences. And my point is, that abstractions (concepts) change over time depending on the tools or instruments we use. Without piano's, there would be no Bach, Mozart or Beethoven. And in general, music would have been far less differentiated without the introduction of new tools (compare the differences in compositions between Palestrina, Telemann, Corelli, Bach, Haydn, Mozart, Beethoven, Wagner, Schoenberg). Also, in painting you see the emergence of many new idea's by having better ways to make paint and colors, and by the uses of lenses. Similarly, Von Neumann machines allows us to think about programming in a certain way, i.e. step-by-step-by-step-by-step but it seems that we start to learn that the amount of steps we can execute per second is not really relevant for many sort of problems. Ok, there are still many area's where we can profit from better algorithms and machines that would improve the calculation of some FFT, but what counts more is often the WAY we think about our abstractions. I think this is why functional programming is interesting. This discussion on programming approaches reminds me as well on the fight between empiricism and rationalism. The former philosophers tried to learn and generalize by experience (maybe the hacker idea), while the latter tried to improve ways of deductive reasoning (the mathematical approach). I think only later philosophers such as Kant could merge concepts from both worlds (from the senses and ideas), but to my knowledge, this had more impact on politics and ethics, rather than science or mathematics. (The source codes by Kant are quite difficult to read. It seems he wanted to write this way to increase the level of thinking.) ___ Telefonate ohne weitere Kosten vom PC zum PC: http://messenger.yahoo.de ___ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe
[Haskell-cafe] Re: Request for a Simple Pretty Printing library
I am sorry, I might have confused you. It appears that we have just a
function for doing what you want; in UU.Pretty.Basic there is a
function invisible. From the manual page I quote:
invisible ppd
Makes the formatted element invisible (all its attributes are
forgotten in order to always succeed, even if there is no space left!)
In exceptional cases we want to escape to the page width limit, for
example when you want to generate additional tags for markup
languages such as LaTeX or HTML:
res_word rw = invisible (pp {\\bf ) | rw | invisible (pp })
and try render (res_word let) 3.
Doaitse
On Dec 14, 2006, at 9:57 AM, Christian Maeder wrote:
Doaitse Swierstra schrieb:
The Prettyprint library you can download from:
http://www.cs.uu.nl/wiki/HUT/Download
I've looked into your module UU.Pretty.Basic starting with:
-- $Header: /data/cvs-rep/uust/lib/pretty/UU/Pretty/Basic.hs,v 1.2
2003/02/26 11:18:27 uust Exp $
And I did not find the type Doc that you describe below.
Christian
and is described on:
http://www.cs.uu.nl/wiki/HUT/PrettyPrintingCombinators
contains amongst others the following code:
data Doc= Empty
| Char Char -- invariant: char is not
'\n'
| Text !Int String -- invariant: text doesn't
contain '\n'
| Line !Bool-- True = when undone by
group, do not insert a space
| Cat Doc Doc
| Nest !Int Doc
| Union Doc Doc -- invariant: first lines of
first doc longer than the first lines of the second doc
| Column (Int - Doc)
| Nesting (Int - Doc)
text = Empty
text s = Text (length s) s
so if you define now:
wrap l t r = Text 0 l | text t | Text 0 r
you should be set and done,
Doaitse Swierstra
___
Haskell-Cafe mailing list
Haskell-Cafe@haskell.org
http://www.haskell.org/mailman/listinfo/haskell-cafe
Re: [Haskell-cafe] Re: Writing Haskell For Dummies Or At Least For People Who Feel Like Dummies When They See The Word 'Monad'
On 12/13/06, Justin Bailey [EMAIL PROTECTED] wrote: On 12/12/06, Joachim Durchholz [EMAIL PROTECTED] wrote: Agreed. Something along the lines of The Art of Functional Programming. +1 . I would love to read something that is the equivalent of 'design patterns', but for functional languages. I thought Osasaki's book Purely Functional Data Structures would have that, but it was little too focused on proving properties of algorithms. As someone in industry, that wasn't so important to me. I want to learn how to think functionally. Check out this paper by Jeremy Gibbons, Design Patterns as Higher-Order Datatype-Generic Programs: http://web.comlab.ox.ac.uk/oucl/work/jeremy.gibbons/publications/index.html#hodgp If you want to learn how to think functionally, forget you ever heard the words design pattern. There shouldn't be patterns in your programs. If there are, that means that either your language isn't providing you with enough abstractions or that you aren't using the abstractions that are available (or possibly both). Cheers, Kirsten -- Kirsten Chevalier* [EMAIL PROTECTED] *Often in error, never in doubt Anyone who spends their life on a computer is pretty unusual. -- Bill Gates ___ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe
Re: [Haskell-cafe] Re: Writing Haskell For Dummies Or At Least ForPeople Who Feel Like Dummies When They See The Word 'Monad'
+1 . I would love to read something that is the equivalent of 'design patterns', but for functional languages.. I want to learn how to think functionally. If you want to learn how to think functionally, forget you ever heard the words design pattern. There shouldn't be patterns in your programs. If there are, that means that either your language isn't providing you with enough abstractions or that you aren't using the abstractions that are available (or possibly both). while that is perhaps the ideal, we often hit intermediate stages, where it is useful to express the pattern of what we are trying to program, before attempting to extend the language so that we can capture that pattern more easily. and even if the pattern then becomes as trivial as use MonadPlus for multiple solutions or use combinators and language recursion to capture grammars for parsers, it may still be useful to list them, because that makes it easier to communicate them to others (and would give newcomers a way in to making better use of the abstractions that are available). what is perhaps different in Haskell is that instead of managing growing databases of complex patterns with arbitrary names, the language evolves and generalizes existing features to make the common patterns easy to capture. once that happens, the pattern description becomes short enough and the language features become general enough to make invented names superfluous, and listings of design patterns less necessary. for many instances of that, and generally for nice-to-read Haskell, I recommend browsing through Mark Jones' papers: http://web.cecs.pdx.edu/~mpj/pubs.html for starters, try the Springschool paper or the one on monad transformers. Claus ___ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe
Re: [Haskell-cafe] Building the community
On 12/14/06, Neil Mitchell [EMAIL PROTECTED] wrote: Hi * Give tips on how to answer questions + Ok. we can put up an article here. Some suggestions: - No questions are bad questions - Code should come with examples of how to run it - Solutions with unsafePerformIO should be discouraged (moreso ;) - Be polite! (we're good at this) I'd say our worst feature is tending to give solutions which are not simple Haskell, but make use of advanced features. When a beginner asks a question, sometimes the answer requires GADT's, Template Haskell, rank-2 types etc. However this is usually because they asked the wrong question - thinking in an imperative frame of mind. Often it would be better to peel back to the original problem, where the answer is more likely to be pure neat Haskell. As a newbie, and a lurker on this list, I'd second this. Often, the subtle and sophisticated answers are very rewarding to study, but they do give the impression that what the person who asked the original question was trying to do, is hard. Generally, it's a turn-off to feel that something which seems simple in another (probably procedural) language is hard in Haskell. At its worst, it comes across as people trying to look clever, rather than trying to help. If the user thinks it's a simple task, show a simple answer where at all possible. But overall I'd agree, this is a very helpful community - it's just that you all seem so much cleverer than I, so I'm not sure I'll ever be smart enough to write Haskell programs :-) (50% joke...) Paul. ___ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe
Re: [Haskell-cafe] Re: Designing an object model in Haskell (RESOLVED)
Hello John, Thursday, December 14, 2006, 6:13:56 AM, you wrote: I'm now using existential types. I avoided learning about them because the name sounded so highly technical and obscure it did not occur to me they could be related to OO. look at http://haskell.org/haskellwiki/OOP_vs_type_classes -- Best regards, Bulatmailto:[EMAIL PROTECTED] ___ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe
Re: [Haskell-cafe] Building the community
Hallo, On 12/14/06, Paul Moore [EMAIL PROTECTED] wrote: But overall I'd agree, this is a very helpful community - it's just that you all seem so much cleverer than I, so I'm not sure I'll ever be smart enough to write Haskell programs :-) (50% joke...) I know the feeling. :-) -- -alex http://www.ventonegro.org/ ___ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe
[Haskell-cafe] Optimization again.
From GHC documentation: Once profiling has thrown the spotlight on the guilty time-consumer(s), it may be better to re-think your program than to try all the tweaks listed below. So, how should I rethink my program? Which way to take? ___ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe
Re: [Haskell-cafe] Optimization again.
szefirov: From GHC documentation: Once profiling has thrown the spotlight on the guilty time-consumer(s), it may be better to re-think your program than to try all the tweaks listed below. So, how should I rethink my program? Which way to take? Do you have some particular code that is underperforming? Performance tips are documented here: http://haskell.org/haskellwiki/Performance Happy coding! :) -- Don ___ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe
Re: [Haskell-cafe] Building the community
On Thu, Dec 14, 2006 at 10:16:10AM +, Neil Mitchell wrote: I'd say our worst feature is tending to give solutions which are not simple Haskell, but make use of advanced features. When a beginner asks a question, sometimes the answer requires GADT's, Template Haskell, rank-2 types etc. However this is usually because they asked the wrong question - thinking in an imperative frame of mind. Often it would be better to peel back to the original problem, where the answer is more likely to be pure neat Haskell. I guess unsafePerformIO is just one instance of this. Absolutely. Some more questions of this type: How do I update a variable? How can I efficiently update an array? How do I get debugging output? How can I put different types of things in a list? Sometimes the person asking is ready for the advanced features, but all too often beginners are pointed at IORefs, the ST monad, trace and existential types, when, as you say, they probably asked the wrong question because they don't have the frame of reference to know what they need. ___ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe
Re: [Haskell-cafe] Optimization again.
Donald Bruce Stewart wrote: szefirov: From GHC documentation: Once profiling has thrown the spotlight on the guilty time-consumer(s), it may be better to re-think your program than to try all the tweaks listed below. So, how should I rethink my program? Which way to take? Do you have some particular code that is underperforming? I have a plenty of it. ;) I'm yet to decide what to blame. Performance tips are documented here: http://haskell.org/haskellwiki/Performance Thank you. I loaded it the next second I received your answer. ;) I profiled my program and found that residency looks pretty fixed but program memory usage grows and eventually I get heap overflow (on Windows) or heavy pagefile trashing (on Linux). When I turn on +RTS -c to use heap compaction I immediately get the following: - .exe: internal error: scavenge_mark_stack: unimplemented/strange closure type 30 @ 03678268 Please report this as a bug to glasgow-haskell-bugs@haskell.org, or http://www.sourceforge.net/projects/ghc/ - This already reported as a bug, but isn't fixed yet. The bug is right here: http://cvs.haskell.org/trac/ghc/ticket/954 It does appear with 6.4.1 too. So I try as hard as I can to reduce the size of garbage produced. No much luck so far. ___ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe
Re: [Haskell-cafe] Optimization again.
szefirov: I profiled my program and found that residency looks pretty fixed but program memory usage grows and eventually I get heap overflow (on Windows) or heavy pagefile trashing (on Linux). When I turn on +RTS -c to use heap compaction I immediately get the following: - .exe: internal error: scavenge_mark_stack: unimplemented/strange closure type 30 @ 03678268 Please report this as a bug to glasgow-haskell-bugs@haskell.org, or http://www.sourceforge.net/projects/ghc/ - This already reported as a bug, but isn't fixed yet. The bug is right here: http://cvs.haskell.org/trac/ghc/ticket/954 It does appear with 6.4.1 too. Can you produce this bug using ghc 6.6? If so, please submit a test case so this can be reproduced and fixed. Either annotate the existing bug (if you think its the same one), or create a new bug report: http://hackage.haskell.org/trac/ghc/newticket?type=bug So I try as hard as I can to reduce the size of garbage produced. No much luck so far. Ok. I doubt anyone can help here though, unless you make the code available :) Is it possible to put the code online? Is it available via darcs? What does your profiling output look like? (The .prof file). What code is doing the most allocation? -- Don ___ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe
Re: [Haskell-cafe] Re: Writing Haskell For Dummies Or At Least For People Who Feel Like Dummies When They See The Word 'Monad'
ke, 2006-12-13 kello 08:18 -0800, Justin Bailey kirjoitti: On 12/12/06, Joachim Durchholz [EMAIL PROTECTED] wrote: Agreed. Something along the lines of The Art of Functional Programming. +1 . I would love to read something that is the equivalent of 'design patterns', but for functional languages. I thought Osasaki's book Hi, Would the following fit the need? http://www.cs.vu.nl/Strafunski/ http://www.cs.vu.nl/Strafunski/dp-sf/ br, Isto ___ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe
Re[2]: [Haskell-cafe] Optimization again.
Hello szefirov, Thursday, December 14, 2006, 5:24:11 PM, you wrote: When I turn on +RTS -c to use heap compaction I immediately get the following: - .exe: internal error: scavenge_mark_stack: unimplemented/strange this bug was fixed at Nov 15 so you should just donwload up-to-date GHC snapshot: Wed Nov 15 05:50:20 PST 2006 Ian Lynagh [EMAIL PROTECTED] * MERGE: Fix (yet another) odd interaction between selector thunks and compacting GC Tue Nov 14 12:31:57 GMT 2006 Simon Marlow [EMAIL PROTECTED] * Fix (yet another) odd interaction between selector thunks and compacting GC This should fix errors of the form internal error: scavenge_mark_stack: unimplemented/strange closure type 28 @ 0x2b92e5f79960 But since it's quite difficult to reproduce the error, I can't be 100% certain it's gone. I certainly can't reproduce it again after the fix, anyway. M ./rts/GC.c +8 -- Best regards, Bulatmailto:[EMAIL PROTECTED] ___ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe
Re: [Haskell-cafe] Optimization again.
Hello szefirov, Thursday, December 14, 2006, 4:18:37 PM, you wrote: From GHC documentation: Once profiling has thrown the spotlight on the guilty time-consumer(s), it may be better to re-think your program than to try all the tweaks listed below. So, how should I rethink my program? Which way to take? i think they mean usual change-your-algorithm stuff -- Best regards, Bulatmailto:[EMAIL PROTECTED] ___ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe
Re: [Haskell-cafe] Re: Writing Haskell For Dummies Or At Least For People Who Feel Like Dummies When They See The Word 'Monad'
Those are some great resources, thanks everyone! Justin ___ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe
[Haskell-cafe] Re: Interpreter output in color
[EMAIL PROTECTED] (Donald Bruce Stewart) wrote: Currently, there is an existing tool, HsColour: http://www.cs.york.ac.uk/fp/darcs/hscolour/ Here's a mockup (the result of dumping ghci's output through HsColour): Have you tried just piping ghci through HsColour interactively? ghci 21 | HsColour -tty It works surprisingly well. I just pushed a patch that ensures stdout is unbuffered in interactive mode, so you can see the prompt before you type something, rather than after completing a line. Colouring is still a little bit jumpy, because HsColour has to consume one whole lexeme before colouring it, but the result is not bad. It does tend to mess with readline a bit though... Regards, Malcolm ___ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe
[Haskell-cafe] haskell.org memory upgrade
Dear Haskellers -- Haskell.org will go down today at 1500 EST for about 10 minutes for a memory upgrade. Sorry for the inconvenience, -Paul Hudak ___ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe
[Haskell-cafe] Re: Interoperating with Java
Here is the announce I've made today to the haskell-jvm-bridge mailing list: http://sourceforge.net/mailarchive/forum.php?thread_id=31235407forum_id=8497 ghc-6.4.2 is currently the default version on both Linux and FreeBSD, so i think it's recent enough. I'm only starting to experiment with jvm-bridge (compiling it was the only way to start learning it 8-). As long as i'm using it, i'm going to try to support it as well. Mark T.B. Carroll wrote: I was wondering, what's the status of the various means of two-way interoperation with Java? Are things actively maintained? According to the WWW, HaskellDirect's (I have Lambada in mind) current version was released Jan 2004 and compiles with 'recent' versions of GHC, such as ghc-6.2, and the latest released JVM Bridge isn't much newer. We were looking at using the Standard Widget Toolkit (SWT) but don't want to rely on driving it from Haskell if the connectors are going to rot away. (We could still use FP, after all - e.g. Scheme's Kawa and Bigloo have good Java interoperation.) -- Mark ___ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe
Re: Re: [Haskell-cafe] Building the community
On 12/14/06, Ross Paterson [EMAIL PROTECTED] wrote: Absolutely. Some more questions of this type: How do I update a variable? How can I efficiently update an array? How do I get debugging output? How can I put different types of things in a list? Sometimes the person asking is ready for the advanced features, but all too often beginners are pointed at IORefs, the ST monad, trace and existential types, when, as you say, they probably asked the wrong question because they don't have the frame of reference to know what they need. I've definitely made that mistake about the heterogenous list. I blurted out existential code when they just didn't know about data types. Sure I see the mistake I made there, but variant types are often assumed to have been ruled out--it's kind of step one with Haskell. That's not to say it was the poster's fault: any question is a good question. Sometimes it's appropriate to assume some knowledge on the poster's behalf, and it would be tedious if every first response was a list of 10 questions gauging the poster's familiarity with various intro topics. Brainstorming: 1) The first response to a FAQ should be a link to a thorough treatment of the FAQ on the wiki. Of course first responders ignorant of the wiki FAQ's existence wouldn't be able to do this, but if the community is consistent, then people will most likely catch on (I suddenly realize that I'm talking about myself...) 2) The welcome to the mailing list message could say if you're new to Haskell, please check this FAQ first. I'm talking big letters here; I'd even be OK with marquee. Are these rules too draconian? Should we just adopt the tedium of quizing every new poster? What are some other steps that could help prevent overly sophistocated first responses? Nick ___ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe
Re: [Haskell-cafe] Re: Aim Of Haskell
Brian Hulley wrote:
Yet I'm sure most people who did a computer science degree some decades ago
remember the old joke about passing things by name or value for what it's
Wirth... :-)
Wikipedia says:
“Whereas Europeans generally pronounce my name the right way ('Ni-klows Wirt'),
Americans invariably mangle it into 'Nick-les Worth'. This is to say that
Europeans call me by name, but Americans call me by value.”
:)
___
Haskell-Cafe mailing list
Haskell-Cafe@haskell.org
http://www.haskell.org/mailman/listinfo/haskell-cafe
Re: [Haskell-cafe] Re: Aim Of Haskell
On Wed, Dec 13, 2006 at 12:17:08AM +0100, Joachim Durchholz wrote: Haskell needs... bullet-proof compilers, all of this working right out of the box. (I see that this all is being worked on.) Come on, C++ got popular in spite of having NO bullet-proof, let alone complete compilers. Two years ago the only full compiler for C++ was Comeau, probably unknown to most C++ programmers. I am not sure about today, but I wouldn't bet that things improved. Best regards Tomasz ___ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe
[Haskell-cafe] Re: Aim Of Haskell
Tomasz Zielonka schrieb: On Wed, Dec 13, 2006 at 12:17:08AM +0100, Joachim Durchholz wrote: Haskell needs... bullet-proof compilers, all of this working right out of the box. (I see that this all is being worked on.) Come on, C++ got popular in spite of having NO bullet-proof, let alone complete compilers. OK, there's the option of replacing working tools with hype. It worked for C++, and it worked for Java. Pity I don't have the slightest idea how to work up a hype for Haskell. Regards, Jo ___ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe
Re: [Haskell-cafe] Re: Aim Of Haskell
On Thu, Dec 14, 2006 at 09:56:57PM +0100, Joachim Durchholz wrote: OK, there's the option of replacing working tools with hype. It worked for C++, and it worked for Java. Pity I don't have the slightest idea how to work up a hype for Haskell. Who would want such a hype? Why not simply start picking up fruits before the mainstream notices? ;-) Best regards Tomasz ___ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe
Re: [Haskell-cafe] Re: Aim Of Haskell
Hi, Am Donnerstag, den 14.12.2006, 21:56 +0100 schrieb Joachim Durchholz: OK, there's the option of replacing working tools with hype. It worked for C++, and it worked for Java. Pity I don't have the slightest idea how to work up a hype for Haskell. IMHO, three is already a haskell hype, considering the increase of activity in the last two years or so. It’s just not a mainstream hype, but so far the hype target group has been very pleasant :-) Greetings, Joachim -- Joachim Breitner e-Mail: [EMAIL PROTECTED] Homepage: http://www.joachim-breitner.de ICQ#: 74513189 ___ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe
Re: [Haskell-cafe] Re: Writing Haskell For Dummies Or At Least For People Who Feel Like Dummies When They See The Word 'Monad'
On Thu, 14 Dec 2006, Kirsten Chevalier wrote: ... If you want to learn how to think functionally, forget you ever heard the words design pattern. There shouldn't be patterns in your programs. If there are, that means that either your language isn't providing you with enough abstractions or that you aren't using the abstractions that are available (or possibly both). Well, maybe not Patterns, but wouldn't there be important skills relating to patterns in a more general sense? Like fold, for example, seems to be a pattern, with several standard implementations and no doubt countless others to suit particular applications. Donn Cave, [EMAIL PROTECTED] ___ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe
Re: Re: [Haskell-cafe] Building the community
On 15/12/06, Nicolas Frisby [EMAIL PROTECTED] wrote: ... That's not to say it was the poster's fault: any question is a good question. I agree ... 2) The welcome to the mailing list message could say if you're new to Haskell, please check this FAQ first. I'm talking big letters here; I'd even be OK with marquee. ... hence I'd caution against such a rule. Part of the reason this community is welcoming is because there is no such barrier for people new to Haskell to ask questions. Everyone has a different mathematics ability and programming experience, and an ambiguously posed question is often just scratching the surface of what someone really wants to know. It's great that this community recognises that and responds accordingly. By contrast, many technical communities follow the advice of a document called How to ask questions the smart way by Eric Raymond and Rick Moen [0]. Although it contains some useful advice for individuals who want to find the answers to simply definable technical questions, imposing that advice on people who ask questions often ends up being elitist. For an example from that document: What [hackers] are, unapologetically, is hostile to people who seem to be unwilling to think or to do their own homework before asking questions. People like that are time sinks — they take without giving back, and they waste time we could have spent on another question more interesting and another person more worthy of an answer. We call people like this losers (and for historical reasons we sometimes spell it lusers). I hope the Haskell community never adopts such an arrogant tone. By all means, responders should politely refer to existing FAQ entries, and use the opportunity of answering questions to also improve the FAQ. At best, answering questions (the smart way ;-) should be thought of as taking part in a mathematical dialogue, not as a game of wits where the original poster is only given one chance to precisely formulate their question. cheers, Conrad [0] (which you can find by searching the Web for its title) ___ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe
[Haskell-cafe] Stack, Heap and GHC
Hello everyone, I have been trying to run a Haskell program of mine that does an extensive computation with very large amounts of data. I compiled the program with ghc --make. When I run it it terminates after some time with the message: Stack space overflow: current size 8388608 bytes. Use `+RTS -Ksize' to increase it. The program isn't that well written so the overflow did not surprise me, I expected that it might run out of memory. What did surprise me was the *stack* overflow. I do not use recursion in my program except for a couple of fold operations over very large lists. So I have a number of questions: 1) Which Haskell operations cost space on the stack, which cost space on the heap? I guess this is implementation dependent, so I looked into the GHC manual but did not find an answer. Where can I look these things up? 2) What could be possible sources of a stack overflow? (Apart from a recursive but not tail-recursive function.) 3) I tried using +RTS -Ksize as suggested, but these options do not seem to be passed through if I use --make. How can I use both, these compilation flags and --make? Thanks, Felix ___ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe
Re: [Haskell-cafe] Stack, Heap and GHC
On Dec 14, 2006, at 10:00 , Felix Breuer wrote: 3) I tried using +RTS -Ksize as suggested, but these options do not seem to be passed through if I use --make. How can I use both, these compilation flags and --make? They aren't compile options; they're runtime options. The GHC runtime intercepts +RTS options and processes them before passing the remaining arguments (if any) to your program. -- brandon s. allbery[linux,solaris,freebsd,perl] [EMAIL PROTECTED] system administrator [openafs,heimdal,too many hats] [EMAIL PROTECTED] electrical and computer engineering, carnegie mellon universityKF8NH ___ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe
Re: [Haskell-cafe] Stack, Heap and GHC
On Thu, Dec 14, 2006 at 04:00:53PM +0100, Felix Breuer wrote: Hello everyone, I have been trying to run a Haskell program of mine that does an extensive computation with very large amounts of data. I compiled the program with ghc --make. When I run it it terminates after some time with the message: Stack space overflow: current size 8388608 bytes. Use `+RTS -Ksize' to increase it. The program isn't that well written so the overflow did not surprise me, I expected that it might run out of memory. What did surprise me was the *stack* overflow. I do not use recursion in my program except for a couple of fold operations over very large lists. So I have a number of questions: 1) Which Haskell operations cost space on the stack, which cost space on the heap? I guess this is implementation dependent, so I looked into the GHC manual but did not find an answer. Where can I look these things up? Lazily evaluated functions seem to get stuck on the stack., so space on the stack tends to get used up by over-lazy programs, which take a long time before they actually evaluate anything. But I'm not quite clear myself when exactly things go on the heap or the stack. 2) What could be possible sources of a stack overflow? (Apart from a recursive but not tail-recursive function.) It's probably your folds. I can never keep them straight, but quite likely switching to a stricter variant will help you, which are named with a ' at the end, e.g. foldl'. If you post your program here, I'd guess someone will take a look at it and give you a better suggestion where the trouble is. It can be hard to track down, I'm afraid. 3) I tried using +RTS -Ksize as suggested, but these options do not seem to be passed through if I use --make. How can I use both, these compilation flags and --make? You pass +RTS -Ksize to your executable, not when compiling (which would affect the stack of ghc). :) -- David Roundy Department of Physics Oregon State University ___ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe
Re: [Haskell-cafe] Stack, Heap and GHC
On Thu, Dec 14, 2006 at 04:00:53PM +0100, Felix Breuer wrote: Hello everyone, I have been trying to run a Haskell program of mine that does an extensive computation with very large amounts of data. I compiled the program with ghc --make. When I run it it terminates after some time with the message: Stack space overflow: current size 8388608 bytes. Use `+RTS -Ksize' to increase it. The program isn't that well written so the overflow did not surprise me, I expected that it might run out of memory. What did surprise me was the *stack* overflow. I do not use recursion in my program except for a couple of fold operations over very large lists. So I have a number of questions: Here's a little program that can illustrate this issue: import Data.List largenum = 100 main = do putStrLn strict foldl1 print $ foldl1' (\a b - a + 1) $ [1..largenum] putStrLn lazy foldl1 print $ foldl1 (\a b - a + 1) $ [1..largenum] It gets through the first one, but not the second call, which differs only in the strictness of the foldl. You can make it use up more memory by making largenum a hundred times bigger, in which case for some reason it doesn't seem to have a stack error (although it hasn't completed on my computer, and uses something like 2G of memory). Perhaps the thunks are placed on the heap, and only when they are actually evaluated does anything go onto the stack? -- David Roundy Department of Physics Oregon State University ___ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe
[Haskell-cafe] Re: On improving libraries: wanted list
[EMAIL PROTECTED] (Donald Bruce Stewart) writes: Can't we do something like this, on top of System.Process? Do we need unix* stuff anymore? Hi, on my computer your code (with return ()-s inserted) works with at most 135168=132*1024 bytes of input: import System.Exit import System.IO import System.Process import Control.Concurrent (forkIO, newEmptyMVar, putMVar, takeMVar) import qualified Control.Exception popen :: FilePath - [String] - Maybe String - IO (String,String,ExitCode) popen file args minput = Control.Exception.handle (\e - return ([],show e,error (show e))) $ do (inp,out,err,pid) - runInteractiveProcess file args Nothing Nothing case minput of Just input - hPutStr inp input hClose inp -- importante! Nothing- return () output - hGetContents out errput - hGetContents err forkIO (Control.Exception.evaluate (length output) return ()) forkIO (Control.Exception.evaluate (length errput) return ()) e - Control.Exception.catch (waitForProcess pid) (\_ - return ExitSuccess) return (output,errput,e) main = do (out,err,code) - popen /bin/cat [] (Just $ take 135168 input) putStrLn $ exit status: ++ show code putStrLn $ out: ++ show (length out) ++ characters putStrLn $ err= ++ err where input = concat [show n ++ , | n-[1..]] One more byte, and cat blocks on writing to its pipe. No wonder, nobody reads the other end, as our hPutStr to cat also blocks, as a direct consequence. Moving the case beyond the forkIO-s resolves this. Btw, why don't you close the other handles? Btw2 runCommand in http://happs.org/HAppS/src/HAppS/Util/Common.hs takes a similar approach with MVar-s; I wonder if they are really needed. -- Feri. ___ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe
[Haskell-cafe] what are the points in pointsfree?
i'm not naive enough to think they are the composition function, and i've gathered it has something to do with free terms, but beyond that i'm not sure. unless it also has something to do with fix points? ___ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe
Re: [Haskell-cafe] what are the points in pointsfree?
On 12/14/06, Steve Downey [EMAIL PROTECTED] wrote: i'm not naive enough to think they are the composition function, and i've gathered it has something to do with free terms, but beyond that i'm not sure. unless it also has something to do with fix points? The points are the arguments. The term comes from mathematics but I'm not sure where. ___ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe
Re: [Haskell-cafe] what are the points in pointsfree?
sdowney: i'm not naive enough to think they are the composition function, and i've gathered it has something to do with free terms, but beyond that i'm not sure. unless it also has something to do with fix points? The wiki knows all! :) http://haskell.org/haskellwiki/Pointfree 1 But pointfree has more points! A common misconception is that the 'points' of pointfree style are the (.) operator (function composition, as an ASCII symbol), which uses the same identifier as the decimal point. This is wrong. The term originated in topology, a branch of mathematics which works with spaces composed of points, and functions between those spaces. So a 'points-free' definition of a function is one which does not explicitly mention the points (values) of the space on which the function acts. In Haskell, our 'space' is some type, and 'points' are values. -- Don ___ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe
Re: Re: [Haskell-cafe] Building the community
On 14/12/06, Conrad Parker [EMAIL PROTECTED] wrote: What [hackers] are, unapologetically, is hostile to people who seem to be unwilling to think or to do their own homework before asking questions. People like that are time sinks — they take without giving back, and they waste time we could have spent on another question more interesting and another person more worthy of an answer. We call people like this losers (and for historical reasons we sometimes spell it lusers). I hope the Haskell community never adopts such an arrogant tone. I really agree with this. I think that one of the reasons that the Haskell community has grown to be so polite and helpful compared to many communities of comparable size is that kindness begets kindness. There's been a lot of chatter lately about how the Haskell community can grow faster than it has been. Personally, I would rather not have it grow any faster than we can manage. If there was a sudden influx of 1 brand-new Haskell users overnight (unattached to some pre-existing educational program), I think this community would quickly have a major problem answering all the mailing list and IRC traffic. If the community grows gradually, we'll easily be able to support it, because there will be a correspondingly larger number of experts and intermediate level users to help us out. Remember, if some significant factor of Haskell programmers advocate the language just to two of their friends, that's still exponential growth. There are also lots of other reasons why growing too quickly and gaining commercial users too quickly are double edged swords. Personally, I'd like to see the Prelude undergo a few more iterations, and it gets harder to change as more and more projects rely on it. When it does change, the maintenance cost of old code goes up, and not every project has an active maintainer. Popularity also results in large numbers of people who are invested in a particular way of doing things and are resistant to change. Haskell is a research language, and I'd personally like to see it remain a research language as its user-base grows. Granted, it would be better than the 30-year-old-at-heart programming languages people are using today, but I don't think I'd be truly satisfied if the Haskell which everyone used was not the Haskell which the researchers were working on with all the cool new ideas in it. I'm not saying don't advocate Haskell, I love it too, and I like seeing new users, but I think we need to take some care in maintaining our excellent community while we're at it. Advocating the language on a grassroots basis means that each new user gets a mentor, or if not one, then an equivalent-mentor spread across the community, and people who have been mentored in such a way tend to repay it many times over in helping other beginners. Having a tightly-knit community who have adopted the mindset of following language development closely will also help offset the costs of change to the language. There are lots of benefits to growing the community, I just think that these are things to consider before we take out a full-page ad in the New York Times. :) - Cale ___ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe
Re: [Haskell-cafe] what are the points in pointsfree?
Here, I think an examples worth a thousand poierr, words. This one comes from YAHT. Consider the two implementations of the following function: lcaseLetters :: String - String lcaseLetters s = map toLower (filter isAlpha s) lcaseLetters :: Strint - String lcaseLetters = map toLower . filter isAlpha Both functions will do the exact same thing. The second, however is written completely in terms of function composition and application. The s in the first implementation is what's being referred to as a 'point'. On 12/14/06, Steve Downey [EMAIL PROTECTED] wrote: i'm not naive enough to think they are the composition function, and i've gathered it has something to do with free terms, but beyond that i'm not sure. unless it also has something to do with fix points? ___ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe ___ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe
[Haskell-cafe] Re: what are the points in pointsfree?
the wiki wasn't half as clear. other tham covering the first half, that it doesn't mean the '.' function. so pointsfree is a step beyond leaving the domain unspecified. my reading knowledge of haskell at this point far exceeds my ability to write haskell. but so far, it has seemed to me that functions written in the pf style are the most reuseable. from what you just told me, it's not an artifact of the pf style, but that maximally reusable functions will be expressible in a pointsfree style. that those functions embody a pattern of computation, without concern for the details. On 12/14/06, Donald Bruce Stewart [EMAIL PROTECTED] wrote: sdowney: i'm not naive enough to think they are the composition function, and i've gathered it has something to do with free terms, but beyond that i'm not sure. unless it also has something to do with fix points? The wiki knows all! :) http://haskell.org/haskellwiki/Pointfree 1 But pointfree has more points! A common misconception is that the 'points' of pointfree style are the (.) operator (function composition, as an ASCII symbol), which uses the same identifier as the decimal point. This is wrong. The term originated in topology, a branch of mathematics which works with spaces composed of points, and functions between those spaces. So a 'points-free' definition of a function is one which does not explicitly mention the points (values) of the space on which the function acts. In Haskell, our 'space' is some type, and 'points' are values. -- Don ___ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe
Re: [Haskell-cafe] Stack, Heap and GHC
felix: Hello everyone, I have been trying to run a Haskell program of mine that does an extensive computation with very large amounts of data. I compiled the program with ghc --make. When I run it it terminates after some time Did you compile with -O (optimisations). Sometimes this fixes things, and its just good practice. -- Don ___ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe
Re: [Haskell-cafe] Stack, Heap and GHC
Hi Did you compile with -O (optimisations). Sometimes this fixes things, and its just good practice. It's slower to compile, and might fix things in GHC Haskell, but other compilers don't all have -O flags, so its generally best to make your program at least have the right sort of time/space behaviour using Haskell. If your code doesn't work without -O, then it probably won't work in Hugs or Yhc. Thanks Neil ___ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe
[Haskell-cafe] Cabal licence files
The cabal setup recognises a small set of licences which I don't think are well explained. I'm trying to put together a canonical list for setting up new projects. GPL: http://www.gnu.org/licenses/gpl.txt LGPL: http://www.gnu.org/licenses/lgpl.txt Thankfully the FSF are particularly anal^W well-organised about this kind of thing and they make it very easy to determine what each licence is and how to apply it BSD3/BSD4: There appears to be one explicitly-named BSD licence on the OSI site. There is also a closely related MIT licence. I don't know which would be which, if these are the two referred to in the licence data type. http://www.opensource.org/licenses/bsd-license.php http://www.opensource.org/licenses/mit-license.html PublicDomain: The Creative Commons people have a public domain licence, though I am uncertain whether it is intended for code. Maybe this doesn't matter when what you're saying is I give up all rights? http://creativecommons.org/licenses/publicdomain/ AllRightsReserved: This is the very opposite of a PD licence and, I believe, the default licence when there is no other explicitly stated. However it would be nice to say as much rather than relying on people's legal knowledge. ;) OtherLicense: This one's easy enough... If anyone can fill in gaps and correct the errors in the above I think it would be useful. Obviously if this has been discussed elsewhere just point me off in the right direction! :) Cheers, D. ___ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe
[Haskell-cafe] Well-typed functions with nonexisting signatures [Was: type variable question]
Nicolas Frisby wrote The commented out signature is the signature that GHC infers for the function. When I uncomment that signature, it will no longer type check. Why does this happen? Even with the forall and the explicit signatures in the where clause, it chokes. Alas, this is the property of Haskell, even of Haskell98. Half a year ago I even wanted to write a message on the Haskell' list, pointing out the embarrassment. One one hand, writing signatures is highly recommended. On the other hand, there exist, even in Haskell98, well-typed functions for which signatures simply do not exist. The number of such exceptions multiply when we move to higher-rank types (where such anomalies are to be expected). The reason for the anomalies is the difference between the 'internal' language that expresses inferred types and the external type language. Is there a canonical example example that exhibits this behavior? Yes, it was discussed back in 2003. Here's the canonical form: g::(Show a,Show b) = a-b g = undefined --h :: Show a = b - a h x = g(h x) Both Hugs and GHC (in the pure Haskell98 mode!) are happy with h. Both compilers infer the type for h, shown in the comment. If you give h the type signature -- the one that is inferred by the compilers themselves -- both compilers complain. This example has been distilled from practical problems (the earliest one was by Levent Erkok reported back on 2000) http://www.mail-archive.com/haskell@haskell.org/msg06754.html The following thread gives more detail and discussion: http://www.haskell.org/pipermail/haskell/2003-May/011730.html The final solution to the problem is in http://www.haskell.org/pipermail/haskell/2003-May/011762.html I have actually managed to give h the type signature. The following message indicates that the problem is actually quite common: http://www.haskell.org/pipermail/haskell-cafe/2003-May/004302.html Here's an example of an anomaly with higher-rank types: http://www.haskell.org/pipermail/haskell-cafe/2004-October/007207.html http://www.haskell.org/pipermail/haskell-cafe/2004-October/007212.html we can define functions Foo and Bar (data constructors are functions) such that we can write myFoo :: Int - Foo myFoo i = Foo (Bar run op) where run :: Monad m = StateT Int m a - m a run prog = do (a, s) - runStateT prog i return a op :: Monad m = StateT Int m Int op= get but we cannot write the composition of Foo and Bar more directly: foo run op = Foo (Bar run op) The latter is not accepted: it must have a signature but no signature can ever be given to this function. ___ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe
Re: [Haskell-cafe] Re: what are the points in pointsfree?
G'day all. Quoting Steve Downey [EMAIL PROTECTED]: from what you just told me, it's not an artifact of the pf style, but that maximally reusable functions will be expressible in a pointsfree style. Not necessarily. (There's a fairly obvious reductio ad absurdum argument as to why: at least the primitives like map and foldr need to be expressed in a pointed way!) Pointsfree functions are not necessarily maximally reusable, but they're usually maximally refactorable. As an example, the associative law for monads looks like this in pointed style: (m = k1) = k2 = m = (\x - k1 x = k2) Applying this law from left to right requires introducing a fresh variable, which involves checking for name clashes, even if only briefly, and introduces a new name that doesn't necessarily have a good meaning. Applying the law from right to left might require a lot of fiddling with k1 to get it in the right form, and checking that the variable, x, is not free in m or k2. In point-free style, the associative law for monads looks like this: join . join = join . fmap join In either direction, this is almost trivial. Cheers, Andrew Bromage ___ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe
Re: [Haskell-cafe] Re: Writing Haskell For Dummies Or At Least For People Who Feel Like Dummies When They See The Word 'Monad'
G'day all. Quoting Donn Cave [EMAIL PROTECTED]: Well, maybe not Patterns, but wouldn't there be important skills relating to patterns in a more general sense? Like fold, for example, seems to be a pattern, with several standard implementations and no doubt countless others to suit particular applications. This is actually an excellent illustration of what patterns actually are. Patterns are a form of engineering experience. When we see the same form of code or data turning up multiple times, we abstract it and give it a name so we can reason about it independently of any application that we find it in. This is exactly the same as category theory. The point of category theory is to spot patterns in mathematical structures, and then abstract them away from those structures, and give them names so we can reason about them independently. The only real problem with patterns (apart from the hype) is that some people have the mistaken impression that Design Patterns == Gang of Four Book. The patterns that GoF documented were not meant to be an exhaustive list, nor were they meant to apply to non-OO languages. (The plethora of modern C++-style headers which encapsulate a lot of the GoF patterns are good examples.) Some patterns have different names in other languages. What GoF calls factory method, for example, a Haskell programmer would call smart constructor. What they call flyweight we call memoing or hash consing. And some patterns are trivial in some languages but hard in others. In Haskell, forward iteration is trivial (we call it a lazy list), but it has to be manually added in Java. In C, global mutable state is trivial, but has to be manually simulated in Haskell. Cheers, Andrew Bromage ___ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe
