Re: [GHC] #4241: Optimization causes HUnit to behave incorrectly
#4241: Optimization causes HUnit to behave incorrectly --+- Reporter: beej175560 | Owner: Type: bug | Status: closed Priority: high | Milestone: 7.0.1 Component: Compiler |Version: 6.12.1 Resolution: fixed| Keywords: Testcase: | Blockedby: 3983 Difficulty: | Os: MacOS X Blocking: | Architecture: x86 Failure: Incorrect result at runtime | --+- Changes (by beej175560): * status: infoneeded = closed * resolution: = fixed Comment: I confirm this is fixed in 6.12.3. -- Ticket URL: http://hackage.haskell.org/trac/ghc/ticket/4241#comment:5 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: [GHC] #4241: Optimization causes HUnit to behave incorrectly
#4241: Optimization causes HUnit to behave incorrectly --+- Reporter: beej175560 | Owner: Type: bug | Status: closed Priority: high | Milestone: 7.0.1 Component: Compiler |Version: 6.12.1 Resolution: fixed| Keywords: Testcase: | Blockedby: 3983 Difficulty: | Os: MacOS X Blocking: | Architecture: x86 Failure: Incorrect result at runtime | --+- Comment(by simonpj): Thanks for the original report, and for testing the fix. Simon -- Ticket URL: http://hackage.haskell.org/trac/ghc/ticket/4241#comment:6 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: [GHC] #4373: Lexer does not handle unicode numeric subscripts
#4373: Lexer does not handle unicode numeric subscripts -+-- Reporter: liamoc|Owner: Type: bug | Status: new Priority: normal|Milestone: Component: Compiler (Parser) | Version: Keywords: lexer, unicode, tiny | Testcase: Blockedby:| Difficulty: Os: Unknown/Multiple | Blocking: Architecture: Unknown/Multiple | Failure: GHC rejects valid program -+-- Comment(by simonmar): The change you suggest sounds reasonable. You want to make these legal characters in an identifier, but not legal in a numeric constant, which is exactly what happens if you categorise them as digit. Numeric constants are already restricted to only contain decimal digits. Could you make a patch and attach it to this ticket? -- Ticket URL: http://hackage.haskell.org/trac/ghc/ticket/4373#comment:1 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: [GHC] #4373: Lexer does not handle unicode numeric subscripts
#4373: Lexer does not handle unicode numeric subscripts -+-- Reporter: liamoc|Owner: Type: feature request | Status: new Priority: normal|Milestone: Component: Compiler (Parser) | Version: Keywords: lexer, unicode, tiny | Testcase: Blockedby:| Difficulty: Os: Unknown/Multiple | Blocking: Architecture: Unknown/Multiple | Failure: None/Unknown -+-- Changes (by simonmar): * failure: GHC rejects valid program = None/Unknown * type: bug = feature request -- Ticket URL: http://hackage.haskell.org/trac/ghc/ticket/4373#comment:2 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
[GHC] #4376: Unexpected failures in testsuite due to .ghci
#4376: Unexpected failures in testsuite due to .ghci
--+-
Reporter: daniel.is.fischer | Owner:
Type: bug| Status: new
Priority: normal | Component: Test Suite
Version: 7.1|Keywords:
Testcase: | Blockedby:
Os: Unknown/Multiple |Blocking:
Architecture: Unknown/Multiple | Failure: None/Unknown
--+-
Running the testsuite, I get e.g.
{{{
= 3171(normal) 375 of 2596 [0, 1, 0]
cd ./ghci/should_run $MAKE -s --no-print-directory 3171/dev/null
3171.run.stdout 23171.run.stderr
= bug1465(normal) 376 of 2596 [0, 1, 0]
cd ./typecheck/bug1465 $MAKE -s --no-print-directory bug1465
/dev/null bug1465.run.stdout 2bug1465.run.stderr
Actual stdout output differs from expected:
--- ./ghci/should_run/3171.stdout.normalised2010-10-07
13:20:16.0 +0200
+++ ./ghci/should_run/3171.run.stdout.normalised2010-10-07
13:20:16.0 +0200
@@ -1 +1,3 @@
+ghci: warnings (except type defaulting and unused do-binds) on; MR off.
+(0.05 secs, 2799172 bytes)
Interrupted.
*** unexpected failure for 3171(normal)
}}}
since it reads ~/.ghci.
I think -ignore-dot-ghci should be passed in the testsuite to avoid such
gratuitous unexpected failures.
--
Ticket URL: http://hackage.haskell.org/trac/ghc/ticket/4376
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: [GHC] #4376: Unexpected failures in testsuite due to .ghci
#4376: Unexpected failures in testsuite due to .ghci
--+-
Reporter: daniel.is.fischer | Owner:
Type: bug| Status: new
Priority: normal | Component: Test Suite
Version: 7.1|Keywords:
Testcase: | Blockedby:
Os: Unknown/Multiple |Blocking:
Architecture: Unknown/Multiple | Failure: None/Unknown
--+-
Comment(by daniel.is.fischer):
Hmm, actually, in testsuite/driver/testlib.py, it seems to be passed in
{{{
def ghci_script( name, way, script ):
...
cmd = HC=' + config.compiler + ' + \
HC_OPTS=' + join(flags,' ') + ' + \
' + config.compiler + ' + \
' --interactive -v0 -ignore-dot-ghci ' + \
join(flags,' ')
}}}
Nevertheless, apparently .ghci is not ignored.
--
Ticket URL: http://hackage.haskell.org/trac/ghc/ticket/4376#comment:1
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: [GHC] #3756: Missing -lz option in testsuite
#3756: Missing -lz option in testsuite
+---
Reporter: daniel.is.fischer | Type: bug
Status: new| Priority: low
Milestone: 7.0.1 | Component: Build System
Version: 6.12.1 | Keywords:
Testcase: | Blockedby:
Difficulty: | Os: Linux
Blocking: | Architecture: x86
Failure: Other |
+---
Comment(by daniel.is.fischer):
Still four unexpected failures while running validate in a HEAD repo
today.[[BR]]
Failing tests:
{{{
3231(threaded1)
ffi014(threaded1)
numsparks001(threaded1)
testwsdeque(threaded1)
}}}
--
Ticket URL: http://hackage.haskell.org/trac/ghc/ticket/3756#comment:19
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: [GHC] #4345: Compiler crash building regex-posix version 0.94.1 using ghc 7.0.1-rc1
#4345: Compiler crash building regex-posix version 0.94.1 using ghc 7.0.1-rc1 -+-- Reporter: dsf |Owner: simonpj Type: bug | Status: new Priority: highest |Milestone: 7.0.1 Component: Compiler | Version: 7.1 Keywords:| Testcase: Blockedby:| Difficulty: Os: Linux | Blocking: Architecture: x86 | Failure: Compile-time crash -+-- Changes (by HoseinAttarzadeh): * cc: HoseinAttarzadeh (added) -- Ticket URL: http://hackage.haskell.org/trac/ghc/ticket/4345#comment:10 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: [GHC] #4372: Extending quasiquotation support
#4372: Extending quasiquotation support
-+--
Reporter: simonpj |Owner:
Type: bug | Status: new
Priority: normal|Milestone:
Component: Template Haskell | Version: 6.12.3
Keywords:| Testcase:
Blockedby:| Difficulty:
Os: Unknown/Multiple | Blocking:
Architecture: Unknown/Multiple | Failure: None/Unknown
-+--
Comment(by simonpj):
It's also worth reminding ourselves that quasi-quote syntax is only
shorthand for a TH splice. Thus
{{{
[pads| blah |]
}}}
means
{{{
$(quoteExp pads blah)
}}}
So in the case proposed by Gershom you could say
{{{
$(quoteExp (jmt [jsModuleSig]) blah)
}}}
and away you go. Is that so bad?
At the moment you can't do TH splices in patterns or local declarations,
whereas you can use quasi-quotes. I have separate plans to change that
(need time to write up), but let's assume for the sake of argument that
patterns can be done the same way as expressions.
--
Ticket URL: http://hackage.haskell.org/trac/ghc/ticket/4372#comment:8
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: [GHC] #4372: Extending quasiquotation support
#4372: Extending quasiquotation support -+-- Reporter: simonpj |Owner: Type: bug | Status: new Priority: normal|Milestone: Component: Template Haskell | Version: 6.12.3 Keywords:| Testcase: Blockedby:| Difficulty: Os: Unknown/Multiple | Blocking: Architecture: Unknown/Multiple | Failure: None/Unknown -+-- Comment(by gershomb): This is all shorthand, you're right. But the syntactic sugar makes a huge difference here. In quasiquote syntax, the only quotation issue that an end user has to worry about is the bar followed by close bracket. In standard splice syntax, the quoted expression is forced to respect all the rules of haskell. Multiline strings either use the \ syntax are have to be written with explicit appends. Double quotes need additional escaping, etc. Furthermore, error messages can't give nearly as nice locality. With quasiquotes, its possible to write very fluently in an embedded dsl with almost arbitrary concrete syntax. Template Haskell splices on their own make doing so very painful. Most of the libraries using quasiquotation that I now know of would be extremely painful to use without the shorthand syntax provided by quasiquotation. In general, Kathleen's preference is fine -- super lightweight syntax for the simple case, and extended syntax for the extended case. This causes a bit more work at the lexing level, and in the parser (but only a few lines), but subsequent to that there's a single code path which is as simple as or simpler than what exists now. In fact, '[$' for introducing an extended quoter and '|' alone for introducing the quotee, which is what I've now implemented, seems fine to me as well, unless there is strong sentiment otherwise. -- Ticket URL: http://hackage.haskell.org/trac/ghc/ticket/4372#comment:9 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: [GHC] #4372: Extending quasiquotation support
#4372: Extending quasiquotation support -+-- Reporter: simonpj |Owner: Type: bug | Status: new Priority: normal|Milestone: Component: Template Haskell | Version: 6.12.3 Keywords:| Testcase: Blockedby:| Difficulty: Os: Unknown/Multiple | Blocking: Architecture: Unknown/Multiple | Failure: None/Unknown -+-- Changes (by snoyberg): * cc: mich...@… (added) Comment: Just to add another use case: Hamlet uses quasi-quotation for HTML templates. There are currently two parameters to the hamletWithSettings function: whether to close tags like HTML or XHTML (eg, br vs br/) and the doctype. Hamlet itself defines two quasi-quoters built on hamletWithSettings: hamlet and xhamlet. But it's easily imaginable that someone will want to create some other combination (such as HTML 3.2) that is not currently provided. Currently, they would need to define their new quasi-quoter in a separate module; this proposal would appear to make that process a little bit nicer. In fact, if I understand the proposal properly, I had originally assumed this ''is'' how quasi-quoters worked and was surprised when the compiler disagreed with me ;). -- Ticket URL: http://hackage.haskell.org/trac/ghc/ticket/4372#comment:10 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
[GHC] #4377: sizedText function for Text.PrettyPrint
#4377: sizedText function for Text.PrettyPrint
-+--
Reporter: lerkok| Owner:
Type: feature request | Status: new
Priority: normal| Component: libraries/pretty
Version:|Keywords: text, sizedText, pretty
printing, Text.PrettyPrint
Testcase:| Blockedby:
Os: Unknown/Multiple |Blocking:
Architecture: Unknown/Multiple | Failure: None/Unknown
-+--
The `Text.PrettyPrint` library has a `text` function for converting
ordinary strings to documents. This function takes the length of the
string to be its final size. However, there are use cases where the actual
length of this string and the virtual length of the document it
represents are not necessarily the same. This use case comes up in cases
where the resulting Doc is rendered to String and a further processor
works on that particular string with its own built-in assumptions about
how things should be laid out. (In our case, we produce Isabelle/HOL code
from Cryptol, which gets rendered by the Isabelle theorem prover. These
strings are the tags that correspond to Isabelle's own escape sequences
for certain theory specific logical symbols.)
To remedy this, adding a function sizedText to the library would
suffice:
{{{
sizedText :: Int - String - Doc
sizedText l s = TextBeside (Str s') l Empty
where s' = s ++ take (l - length s) (repeat ' ')
}}}
Unfortunately this function can '''not''' be defined outside the
`PrettyPrint` library itself, This is because the `TextBeside` constructor
is not exported, and there seems to be no other way of accessing the
length field otherwise.
Note that in the above code the user given length `l` can be larger or
smaller than the actual length of the string `s`; so the first argument to
`take` can be positive or negative. In either case the function does the
right thing for our use case: If smaller, you get the original string;
which messes up the ASCII output a bit but is the right thing to the for
the target processor; if larger, then it gets padded with space at the end
appropriately to get the ASCII looking right as well.
Our current workaround for this issue is to replicate the library code
ourselves and add this function on top, which is a kludge at best that
we'd like to avoid.
The function `sizedText` satisfies the law:
{{{
sizedText (length s) s = text s
}}}
and hence agrees with the existing `text` function for ordinary usage.
--
Ticket URL: http://hackage.haskell.org/trac/ghc/ticket/4377
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: [GHC] #4370: Bring back monad comprehensions
#4370: Bring back monad comprehensions -+-- Reporter: simonpj |Owner: Type: bug | Status: new Priority: normal|Milestone: Component: Compiler | Version: 6.12.3 Keywords:| Testcase: Blockedby:| Difficulty: Os: Unknown/Multiple | Blocking: Architecture: Unknown/Multiple | Failure: None/Unknown -+-- Changes (by nsch): * cc: m...@… (added) -- Ticket URL: http://hackage.haskell.org/trac/ghc/ticket/4370#comment:7 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: [GHC] #2041: Allow splicing in concrete syntax
#2041: Allow splicing in concrete syntax
-+--
Reporter: igloo |Owner:
Type: feature request | Status: new
Priority: normal|Milestone: _|_
Component: Template Haskell | Version: 6.8.2
Keywords:| Testcase:
Blockedby:| Difficulty: Unknown
Os: Unknown/Multiple | Blocking:
Architecture: Unknown/Multiple | Failure: None/Unknown
-+--
Changes (by reinerp):
* cc: reiner.p...@… (added)
* failure: = None/Unknown
Comment:
Another use for this would be for creating custom quasiquoters with
antiquoting. Say, to create a custom list quasiquoter:
{{{
[list| x^2+y, 3*z |]
}}}
the quasiquoter needs to parse antiquoted expressions such as {{{x^2+y}}}
and {{{3*z}}} into TH abstract syntax. Current quasiquoters mostly do this
using haskell-src-exts (via the haskell-src-meta library), but it would be
neater just to return a {{{RawE antiquoted_stuff}}} expression.
--
Ticket URL: http://hackage.haskell.org/trac/ghc/ticket/2041#comment:6
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: [GHC] #4316: Interactive do notation in GHCi
#4316: Interactive do notation in GHCi -+-- Reporter: mitar |Owner: vivian Type: feature request | Status: new Priority: normal|Milestone: 7.2.1 Component: GHCi | Version: 6.12.3 Keywords:| Testcase: Blockedby:| Difficulty: Os: Unknown/Multiple | Blocking: Architecture: Unknown/Multiple | Failure: None/Unknown -+-- Changes (by vivian): * owner: = vivian -- Ticket URL: http://hackage.haskell.org/trac/ghc/ticket/4316#comment:10 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: Bringing back Monad Comprehensions (in style)
On 7 October 2010 12:04, Sebastiaan Visser hask...@fvisser.nl wrote:
What exactly are the benefits of Monad comprehensions over, for example, the
do-notation or idioms?
List comprehensions are just a specialisation of the do-notation for lists.
Monad comprehensions are a generalisation for arbitrary monads of this
specialisation :-)
I don't think there are major benefits to this. The major change is
that they look like lists (which might be important if you are
writing a SQL library) and the final return is hoisted into the head
of the comprehension [HERE | with, the, usual, do, notation, sequence,
here].
I'm not fully aware of what Monad comprehensions would offer in general, but
aren't most comprehensions directly translatable to applicative style?
Monadic style, not applicative style.
For example:
[(x, y) | x - xs | y - ys] -- Comprehension.
This computes a zip of xs and ys.
(,) $ xs * ys -- Applicative style.
This actually computes a cartesian product instead.
You are right in spirit because:
[e | qs] == do { qs; return e }
For example:
[(x, y) | x - xs, y - ys] == do { x - xs; y - ys; return (x, y) }
Cheers,
Max
___
Glasgow-haskell-users mailing list
Glasgow-haskell-users@haskell.org
http://www.haskell.org/mailman/listinfo/glasgow-haskell-users
Re: Bringing back Monad Comprehensions (in style)
Hi Sebastian, For example: [(x, y) | x - xs | y - ys] -- Comprehension. versus (,) $ xs * ys -- Applicative style. or (| (,) xs ys |) -- Idiom brackets in She. Or am I missing some subtle points here? Perhaps, you meant [(x, y) | x - xs , y - ys] which translates to the following code in the do notation: do x - xs y - ys return (x,y) The comprehension notation also features filters. [(x, y) | x - xs , y - ys, x == y] which for instances of MonadPlus (i.e., not for all monads) translates to: do x - xs y - ys guard (x == y) return (x,y) See Michael Adams' (link is in Max's reply) suggestion on how to translate 'order by' and 'group by' to monadic combinators. There, monadic code gets really unwieldy. The point of the comprehension notation is that (just like of any other notation, including do) it makes certain kinds of programs easier to write and read. As I have already mentioned, the comprehension notation is extremely well suited for writing programs that process collections of values. Maybe this is because the set comprehension notation was hardwired in our brains during high school math. Haskell is widely used for EDSL development. Some EDSLs are about processing collections of values. Monad comprehensions would allow EDSLs to utilise the expressive list comprehension notation that is currently only allowed for lists. Having said that, since the comprehension notation (to some extent) is used in high school math curricula, even a bit mathematically inclined non-computer scientist users of list-based EDSLs may feel at home when offered to program using the comprehension notation. To summarise, IMO programming list-processing applications is more natural in the comprehension notation than in do notation and programming with 'group by' and 'order by' is infeasible in monadic combinators. Of course one could extend do notation further, but I think it is better for the reasons outlined above to generalise the list comprehension notation instead. Of course, I still welcome alternative suggestions. Cheers, George ___ Glasgow-haskell-users mailing list Glasgow-haskell-users@haskell.org http://www.haskell.org/mailman/listinfo/glasgow-haskell-users
GHC static binaries with glibc-2.12?
Hi all, I recently upgraded my Arch Linux system to glibc 2.12 and static binaries compiled with GHC 6.12.3 all fail with the message mkTextEncoding: invalid argument (Invalid argument). This did not happen with glibc 2.11. Has anyone else had this problem? Does anyone have any advice for debugging it? Thanks, Alex ___ Glasgow-haskell-users mailing list Glasgow-haskell-users@haskell.org http://www.haskell.org/mailman/listinfo/glasgow-haskell-users
[Haskell] CFP MSCS Issue: Dependently Typed Programming
(s:S)-(p:P s)*(s:S)-(p:P s)*(s:S)-(p:P s)*(s:S)-(p:P s)*(s:S)- (p:P s)* OPEN CALL FOR PAPERS for a Special Issue of MATHEMATICAL STRUCTURES in COMPUTER SCIENCE in association with the workshop DEPENDENTLY TYPED PROGRAMMING 2010 editors: Thorsten Altenkirch (Nottingham), Conor McBride (Strathclyde) 2011 timeline: submission Jan 31; notification May 31; final version June 30 (s:S)-(p:P s)*(s:S)-(p:P s)*(s:S)-(p:P s)*(s:S)-(p:P s)*(s:S)- (p:P s)* Thorsten Altenkirch and Conor McBride are delighted to invite contributions to a Special Issue of the journal Mathematical Structures in Computer Science (Cambridge University Press), in association with the Workshop on Dependently Typed Programming, which we organised on 9 and 10 July 2010 in Edinburgh, as part of FLoC, associated with LiCS. The workshop had a packed programme of exciting developments, reflecting the strength of work on this topic at this time. More recent workshops and conferences have exhibited a significant contribution from researchers in this area. We are grateful to Editor-in-Chief Giuseppe Longo and to Editor Eugenio Moggi for the opportunity to reflect these welcome developments in the pages of MSCS, and we encourage researchers to consider submitting a paper. submission deadline: January 31 2011 notification: May 31 2011 final versions due: June 30 2011 We invite full journal articles concerning Dependently Typed Programming or related topics, from authors at work in this area. Submissions are particularly welcome from but not limited to contributors to the workshop, and the same journal-standard peer review process will apply in any case. Please feel free to address any enquiries about scope and suitability to the guest editors, Thorsten Altenkirch (University of Nottingham) and Conor McBride (University of Strathclyde). Submissions should usually not exceed 35 pages. Authors should adhere to the guidelines issued by Cambridge University Press for MSCS contributors: http://assets.cambridge.org/MSC/MSC_ifc.pdf. These include directions to the relevant LaTeX resources. We very much look forward to hearing from you. Thorsten and Conor ___ Haskell mailing list Haskell@haskell.org http://www.haskell.org/mailman/listinfo/haskell
Re: [Haskell-cafe] Haskellers.com profiles: advice requested
On Wed, Oct 6, 2010 at 8:14 PM, Brent Yorgey byor...@seas.upenn.edu wrote: One (slightly off-topic) question: at the top of the site it says the meeting place for professional Haskell programmers. Is this supposed to be geared towards Haskell programmers who get paid (or want to get paid) to write Haskell? If so, fine; if not, in my opinion the word professional ought to be dropped. The fact is that the site has two functions: on the one hand, it's simply a social network for anyone connected to the Haskell world. In that sense, the word professional is inaccurate. However, the second function is to encourage Haskell usage in industry, by showing a large number of highly qualified Haskell programmers. In this sense, the word professional is very apt. I hope the word professional isn't scaring off the hobbyists; I would definitely want them to be signing up on the site as well. But as far as the marketing of the site goes, I think our main goal should be impressing industry. Michael ___ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe
Re: [Haskell-cafe] Haskellers.com profiles: advice requested
2010/10/7 Michael Snoyman mich...@snoyman.com: On Wed, Oct 6, 2010 at 8:14 PM, Brent Yorgey byor...@seas.upenn.edu wrote: One (slightly off-topic) question: at the top of the site it says the meeting place for professional Haskell programmers. Is this supposed to be geared towards Haskell programmers who get paid (or want to get paid) to write Haskell? If so, fine; if not, in my opinion the word professional ought to be dropped. The fact is that the site has two functions: on the one hand, it's simply a social network for anyone connected to the Haskell world. In that sense, the word professional is inaccurate. However, the second function is to encourage Haskell usage in industry, by showing a large number of highly qualified Haskell programmers. In this sense, the word professional is very apt. I hope the word professional isn't scaring off the hobbyists; I would definitely want them to be signing up on the site as well. But as far as the marketing of the site goes, I think our main goal should be impressing industry. Hi, Does this mean it is possible to accurately distinct a hobbyist and a highly qualified professional within the site? Cheers, Thu ___ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe
Re: [Haskell-cafe] Haskellers.com profiles: advice requested
On Thu, Oct 7, 2010 at 12:42 AM, Bas van Dijk v.dijk@gmail.com wrote: Feature suggestion: Allow users to provide their location and show it (and the aggregate of all Haskellers) in a (Google) map. (I Just uploaded my initial profile) Bas I like it, I'll get on it soon. Maybe I can use some of them fancy HTML 5 geolocation APIs ;). Also, just to let everyone know: since no one is really getting back a list of skills they'd like to see, I'm just going to give everyone permission on the site to add new skills. If it gets out of hand, I can start requiring moderation of the entries, but I think we're all pretty mature here. Michael ___ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe
Re: [Haskell-cafe] Haskellers.com profiles: advice requested
On Wed, Oct 6, 2010 at 2:11 AM, Michael Snoyman mich...@snoyman.com wrote: Hi all, After finally getting OpenID 2 support worked out, I've now put up the Haskellers.com website[1]. Not all features are implemented yet, but the basics are in. One of the most important features is going to be the user profiles, and I wanted some community input on the kind of stuff they'd like to see. For now, I collect email address (spam-protected, don't worry), website, number of years of Haskell experience, and a free-form description. I've also added a skills section, but have purposely not added many. I wanted community input on the kinds of skills. Some ideas: Is it possible to change the years of experience to allow us to enter when we started learning Haskell and let the website calculate years of experience? It's unlikely that people will remember to update the years of experience I think. Of course, that doesn't work so well for people who have gaps in their experience. So allowing date ranges would probably be even better. Jason ___ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe
[Haskell-cafe] Ordering vs. Order
Hi all, I'm not a native English speaker and recently I was wondering about the two words order and ordering (the main reason why I write this to the Haskell mailing list, is that the type class Ordering does exist). My dictionaries tell me that order (besides other meanings) denotes an ordered structure on elements and ordering (as only meaning) denotes some request that I made at some entity. So, to me it seems that calling the type class Ordering is wrong ;) However, I do know that there are many publications about ordered structures which use the word ordering (most of which I'm aware of, not by native speakers). What do native speakers have to say about that? best regards chris ___ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe
Re: [Haskell-cafe] Ordering vs. Order
On Oct 7, 2010, at 1:02 AM, Christian Sternagel wrote: Hi all, I'm not a native English speaker and recently I was wondering about the two words order and ordering (the main reason why I write this to the Haskell mailing list, is that the type class Ordering does exist). My dictionaries tell me that order (besides other meanings) denotes an ordered structure on elements and ordering (as only meaning) denotes some request that I made at some entity. So, to me it seems that calling the type class Ordering is wrong ;) However, I do know that there are many publications about ordered structures which use the word ordering (most of which I'm aware of, not by native speakers). What do native speakers have to say about that? They're pretty much synonymous. Given a specific context, an order is the relation that orders a set, whereas an ordering is a relation that orders a set. For example, a set with three elements can be ordered in three different ways. Each of them is an ordering. But none is THE order. (If the elements are integers, then they can inherit THE integer order, if you wanted the set to inherit that notion of an order) ___ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe
Re: [Haskell-cafe] HTML library with DOM?
Excerpts from Gregory Collins's message of Wed Oct 06 19:44:44 -0400 2010: I've got the month of October off, and one of the things I've been planning on working on is a compliant HTML5 parser for Haskell -- something which is sorely needed! I will ping the list back if/when I get it finished. I've heard that some of the existing HTML parsers in Haskell were already HTML5 compliant (this topic came up when I was complaining that there were some algorithms that you absolutely had to have state for, because that was how they were specified.) I never verified this assertion though. Edward ___ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe
Re: [Haskell-cafe] HTML library with DOM?
Edward Z. Yang ezy...@mit.edu writes: Excerpts from Gregory Collins's message of Wed Oct 06 19:44:44 -0400 2010: I've got the month of October off, and one of the things I've been planning on working on is a compliant HTML5 parser for Haskell -- something which is sorely needed! I will ping the list back if/when I get it finished. I've heard that some of the existing HTML parsers in Haskell were already HTML5 compliant (this topic came up when I was complaining that there were some algorithms that you absolutely had to have state for, because that was how they were specified.) I never verified this assertion though. If there's already a library which *correctly* parses html5 documents into DOM trees, could someone please let me know so I can use it instead of wasting a bunch of time writing one? Thanks, G -- Gregory Collins g...@gregorycollins.net ___ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe
Re: [Haskell-cafe] Ordering vs. Order
Chris, I'm not a native English speaker and recently I was wondering about the two words order and ordering (the main reason why I write this to the Haskell mailing list, is that the type class Ordering does exist). Irrelevant to your struggle, but note that the *type class* is dubbed Ord, while the Prelude provides a *type* Ordering: class ... = Ord a where ... data Ordering = LT | EQ | GT deriving ... Cheers, Stefan ___ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe
[Haskell-cafe] Packaging a Gtk2hs based program for Windows
Hello, haskellers. Recently I stumbled upon a problem. It may sound quite off-topic for this list, but, I'm sure, almost every haskell programmer runs into it sooner or later. It sounds: How to make a neat Windows installer for a nice Gtk2hs program I wrote last week? How to solve the problem of dependency on GTK? Should I ask my users to install a GTK package or it would be better to package all the dynamic libraries needed along with my program? Are there any troubles with different character encodings used in Windows? How to change the application icon? And so on.. I understand, there is no ultimate answer, but I hope there is some wisdom to share. I've been a Linux user for more then five years and now I've found myself completely illiterate on how to make my code easily accessible for a nontechnical Windows user. I would appreciate any thoughts and advises Best wishes, Dmitry ___ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe
[Haskell-cafe] Re: Notes from Haskell takes over the world BoF at ICFP
On 07/10/2010 02:45, Jason Dagit wrote: + well documented workflow for lightweight changes + heavy weight process for major work. + bugs, tickets. + Simon Marlow contributions are going up, and process is working well That's reassuring. Is their workflow documented for the benefit of other Haskell projects and the greater FOSS community in general? We have pretty extensive instructions on how to contribute to GHC here: http://hackage.haskell.org/trac/ghc/wiki/WorkingConventions If you find anything missing, or something that could be improved, please let us know! Cheers, Simon ___ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe
Re: [Haskell-cafe] Packaging a Gtk2hs based program for Windows
2010/10/7 Dmitry V'yal akam...@gmail.com: It sounds: How to make a neat Windows installer for a nice Gtk2hs program I wrote last week? How to solve the problem of dependency on GTK? Should I ask my users to install a GTK package or it would be better to package all the dynamic libraries needed along with my program? Are there any troubles with different character encodings used in Windows? How to change the application icon? And so on.. It is better to copy GTK libraries with your application. If you ask user to install GTK libraries they can install incompatible version (and certainly will). ;) We didn't encountered difficulties with different character encodings. You have to look on gcc documentation (ld part of it) where you can specify resource file with application icon. Don't forget -mwindows key for ld. ___ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe
Re: [Haskell-cafe] Re: Lazy evaluation from Why Functional programming matters
Have you seen Potential (http://intoverflow.wordpress.com/2010/05/21/announcing-potential-x86-64-assembler-as-a-haskell-edsl/)? Quote: The language’s goal is to provide a solid foundation for the development of a useful (multi-tasked, multi-processor, etc) microkernel Which sounds like it's exactly what you want. Also, see Harpy (http://uebb.cs.tu-berlin.de/harpy/). Thank you very very much Neil for pointing me to Potential. I'll take a look at it. -- Regards, Kashyap ___ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe
Re: [Haskell-cafe] Haskellers.com profiles: advice requested
On Thu, Oct 7, 2010 at 8:41 AM, Vo Minh Thu not...@gmail.com wrote: 2010/10/7 Michael Snoyman mich...@snoyman.com: On Wed, Oct 6, 2010 at 8:14 PM, Brent Yorgey byor...@seas.upenn.edu wrote: One (slightly off-topic) question: at the top of the site it says the meeting place for professional Haskell programmers. Is this supposed to be geared towards Haskell programmers who get paid (or want to get paid) to write Haskell? If so, fine; if not, in my opinion the word professional ought to be dropped. The fact is that the site has two functions: on the one hand, it's simply a social network for anyone connected to the Haskell world. In that sense, the word professional is inaccurate. However, the second function is to encourage Haskell usage in industry, by showing a large number of highly qualified Haskell programmers. In this sense, the word professional is very apt. I hope the word professional isn't scaring off the hobbyists; I would definitely want them to be signing up on the site as well. But as far as the marketing of the site goes, I think our main goal should be impressing industry. Hi, Does this mean it is possible to accurately distinct a hobbyist and a highly qualified professional within the site? No. Firstly, there can be a very fine line between hobbyist and professional. At my previous job, I did 95% of my coding and SAS and VBA (the lovely insurance industry). However, they had one project where we needed fast parsing of large binary files and I used Haskell for it. I would have considered myself at the time a Haskell hobbyist, but it's not really clear. Secondly, the only information which is verified on the Haskellers site right now is email address. I have plans to add badges so that people can be verified, but I'm hesitant to do so right now. You can get an idea of how professional a Haskeller someone is right now based on their years of experience and their description field. Michael ___ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe
Re: [Haskell-cafe] Re: EDSL for Makefile
which looks somewhat nicer. This example also defines runTest and a test function (which calls the shell command echo to print some lines) you can try in ghci by typing runTest test... [1] http://gist.github.com/614246 Thank you very much Steffen for taking the time out for the example ... I'll study the code. -- Regards, Kashyap ___ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe
Re: [Haskell-cafe] ANNOUNCE: tls, native TLS/SSL protocol implementation
On Thu, Oct 07, 2010 at 12:29:51AM +0200, Christopher Done wrote: On 6 October 2010 23:26, Vincent Hanquez t...@snarc.org wrote: I'ld like to announce the tls package [1][2], which is a native implementation of the TLS protocol, client and server. It's currently mostly supporting SSL3, TLS1.0 and TLS1.1. It's got *lots* of rough edges, and a bunch of unsupported features, but it's humming along, and at each iteration it's becoming more tighly secure and featureful. Wow, great! So might we be able to combine this with Network.HTTP some day? I am interested in moving away from C libraries (curl) to pure Haskell libraries, for a safer, richer Haskell ecosystem and for solving the interesting problems. That's one of the goal of this library. Ultimately I want something more flexible than usual APIs in traditional libraries; TLS can do lots of things, that are not typically exposed by others libraries. Otherwise more pratically, there's michael's http-enumerator. I hope i'll see more package depending on tls in the future instead of gnutls/openssl bindings. Will you eventually add benchmarks? This is on my TODO list but the priority is quite low; I'm trying to focus on correctness and security for now. However I suspect what does make the biggest difference is the crypto implementation that is used, and the current dependencies should be all reasonable (cryptohash is close to C performance level with hashes, the AES package has a pretty fast implementation, ghc seems quite good with big number benefiting RSA, ..). -- Vincent Hnquez ___ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe
[Haskell-cafe] Eta-expansion destroys memoization?
Hi all, See below for this message from one of my students which has me stumped. Just when you think you understand Haskell... ;) I've cc'ed him on this message; please include him on any replies as I don't think he is subscribed to -cafe. -Brent - Forwarded message from Yue Wang yulew...@gmail.com - From: Yue Wang yulew...@gmail.com Date: Tue, 5 Oct 2010 21:23:57 -0400 To: Brent Yorgey byor...@seas.upenn.edu Subject: store evaluated values Hi, Anthony (or Brent): Last time (in Anthony's TA office hour) we talked about how to store evaluated values in the program for later used. I googled for a while and wrote some code. But I still encountered two problems. Can you take a look? Thanks. First, let's write the naive fib function: naive_fib 0 = 0 naive_fib 1 = 1 naive_fib n = trace(show(n)) naive_fib (n - 1) + naive_fib (n - 2) this works good except it tries to calculate the same expression many times. So when we evaluate it ghci will show the following: *Main naive_fib 5 5 4 3 2 2 3 2 5 Then there is a clever way to do that on haskell wiki: fib = ((map fib' [0 ..]) !!) where fib' 0 = 0 fib' 1 = 1 fib' n =trace(show(n)) fib (n - 1) + fib (n - 2) When we evaluate the same expression we can see it does not evaluate the redundant expression over and over: *Main fib 5 5 4 3 2 5 The source code seems to be easy to read, but I don't think I understand that. For me I think if I change the first line from fib = ((map fib' [0 ..]) !!) to fib x = ((map fib' [0 ..]) !!) x It should do the same thing since I think the previous version is just an abbreviation for the second one. But After I change that, *Main fib 5 5 4 3 2 2 3 2 5 So why does the x here matters? ___ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe
[Haskell-cafe] ANNOUNCE: Haskell XML Toolbox Version 9.0.0
Haskell XML Toolbox 9.0.0 I would like to announce a new version of the Haskell XML Toolbox. HXT has grown over the years. Components for XPath, XSLT, validation with RelaxNG, picklers for conversion from/to native Haskell data, lazy parsing with tagsoup, input via curl and native Haskell HTTP and others have been added. This has led to a rather large package with a lot of dependencies. To make the toolbox more modular and to reduce the dependencies on other packages, hxt has been split into various smaller packages since this version. Information about this release, about the new packages, changes and incompatibilities to older versions can be found at HXT home: http://www.fh-wedel.de/~si/HXmlToolbox/index.html; and on the Haskell wiki page about HXT http://www.haskell.org/haskellwiki/HXT; The source repo has been moved to GitHub: http://github.com/UweSchmidt/hxt; Downloads and installation is available from hackage. Please email comments, bugs, etc. to hxmltool...@fh-wedel.de or s...@fh-wedel.de Uwe -- University of Applied Sciences, Wedel, Germany http://www.fh-wedel.de/~si/index.html ___ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe
Re: [Haskell-cafe] Ordering vs. Order
Christian Sternagel c.sterna...@gmail.com writes: recently I was wondering about the two words order and ordering I would use ordering to mean the relation or function that orders (ranks) elements, and I'd use order to refer the actual progression. So by applying an ordering, you get elements in a particular order. My dictionary lists them as synonyms for this, but order has the unfortunate potential to be confused with the verb, and generally seems to have more possible meanings than ordering. I'm not a native English speaker Me neither. :-) -k -- If I haven't seen further, it is by standing in the footprints of giants ___ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe
Re: [Haskell-cafe] HTML library with DOM?
Michael Snoyman mich...@snoyman.com writes: As far as I know, Neil Mitchel's tagsoup[1] parses according to the HTML 5 parsing rules, but it just generates a list of Tags[2], so you'd have to build the DOM tree up from there. I personally have had great experience with tagsoup. It's even the core of HTML-scraping technology powering searchonce[3]. Yep, someone else wrote me privately to say this (that tagsoup respects the html5 lexing rules). So I'll be using this as the basis of an html5 DOM parser. Stay tuned! G -- Gregory Collins g...@gregorycollins.net ___ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe
Re: [Haskell-cafe] HTML library with DOM?
2010/10/7 Gregory Collins g...@gregorycollins.net: Edward Z. Yang ezy...@mit.edu writes: Excerpts from Gregory Collins's message of Wed Oct 06 19:44:44 -0400 2010: I've got the month of October off, and one of the things I've been planning on working on is a compliant HTML5 parser for Haskell -- something which is sorely needed! I will ping the list back if/when I get it finished. I've heard that some of the existing HTML parsers in Haskell were already HTML5 compliant (this topic came up when I was complaining that there were some algorithms that you absolutely had to have state for, because that was how they were specified.) I never verified this assertion though. If there's already a library which *correctly* parses html5 documents into DOM trees, could someone please let me know so I can use it instead of wasting a bunch of time writing one? As far as I know, Neil Mitchel's tagsoup[1] parses according to the HTML 5 parsing rules, but it just generates a list of Tags[2], so you'd have to build the DOM tree up from there. I personally have had great experience with tagsoup. It's even the core of HTML-scraping technology powering searchonce[3]. Michael [1] http://hackage.haskell.org/package/tagsoup [2] http://hackage.haskell.org/packages/archive/tagsoup/0.11.1/doc/html/Text-HTML-TagSoup.html#t:Tag [3] http://www.search-once.com/ ___ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe
Re: [Haskell-cafe] Eta-expansion destroys memoization?
On Thu, Oct 7, 2010 at 6:17 AM, Brent Yorgey byor...@seas.upenn.edu wrote: The source code seems to be easy to read, but I don't think I understand that. For me I think if I change the first line from fib = ((map fib' [0 ..]) !!) to fib x = ((map fib' [0 ..]) !!) x It should do the same thing since I think the previous version is just an abbreviation for the second one. Semantically, yes. And it's possible that ghc -O is clever enough to notice that. But at least under ghci's naive evaluation strategy, lambdas determine the lifetime of expressions. Any expression within a lambda will be re-evaluated each time the lambda is expanded. Thus: fib = (map fib' [0..] !!)-- fast fib = \x - map fib' [0..] !! x-- slow fib = let memo = map fib' [0..] in \x - memo !! x -- fast The section works because (a %^) (for some operator %^) is short for (%^) a and (%^ a) is short for flip (%^) a. Sections don't expand into lambdas. In other words, in the middle expression, there is a new map fib' [0..] for each x, whereas in the others, it is shared between invocations. Does that make sense? Luke ___ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe
Re: [Haskell-cafe] Eta-expansion destroys memoization?
On Thu, Oct 7, 2010 at 8:44 AM, Luke Palmer lrpal...@gmail.com wrote: On Thu, Oct 7, 2010 at 6:17 AM, Brent Yorgey byor...@seas.upenn.edu wrote: The source code seems to be easy to read, but I don't think I understand that. For me I think if I change the first line from fib = ((map fib' [0 ..]) !!) to fib x = ((map fib' [0 ..]) !!) x It should do the same thing since I think the previous version is just an abbreviation for the second one. Semantically, yes. And it's possible that ghc -O is clever enough to notice that. But at least under ghci's naive evaluation strategy, lambdas determine the lifetime of expressions. Any expression within a lambda will be re-evaluated each time the lambda is expanded. Thus: fib = (map fib' [0..] !!) -- fast fib = \x - map fib' [0..] !! x -- slow fib = let memo = map fib' [0..] in \x - memo !! x -- fast The section works because (a %^) (for some operator %^) is short for (%^) a and (%^ a) is short for flip (%^) a. Sections don't expand into lambdas. In other words, in the middle expression, there is a new map fib' [0..] for each x, whereas in the others, it is shared between invocations. Does that make sense? In general, f is not semantically equivalent to \x - f x in Haskell. However, that is not what Brent said. The Report -defines- (m !!) as \x - m !! x. GHC simply does not follow the Report here. You can witness this via: (() `undefined`) `seq` 0. By the Report this should evaluate to 0, in GHC it evaluates to undefined. As for the rest... The operational behavior of the above is implementation dependent, but GHC, and I imagine most implementations, more or less do the natural thing. The Report gives no way to control sharing behavior, but being able to control it is rather important, so predictable behavior here is desirable. ___ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe
Re: [Haskell-cafe] Eta-expansion destroys memoization?
On Thu, Oct 7, 2010 at 1:44 PM, Luke Palmer lrpal...@gmail.com wrote: The section works because (a %^) (for some operator %^) is short for (%^) a and (%^ a) is short for flip (%^) a. Sections don't expand into lambdas. According to the report they do: http://haskell.org/onlinereport/exps.html#sections http://haskell.org/onlinereport/haskell2010/haskellch3.html#x8-33.5 but GHC is different, I think: http://www.haskell.org/ghc/docs/6.12.2/html/users_guide/syntax-extns.html#postfix-operators I'm not sure if the significance of this difference is explored anywhere, but notice that: ghci (() `undefined`) `seq` () *** Exception: Prelude.undefined ghci (`undefined` ()) `seq` () () ___ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe
Re: [Haskell-cafe] Eta-expansion destroys memoization?
On Thursday 07 October 2010 14:17:18, Brent Yorgey wrote: Hi all, See below for this message from one of my students which has me stumped. Just when you think you understand Haskell... ;) I've cc'ed him on this message; please include him on any replies as I don't think he is subscribed to -cafe. -Brent cf. http://www.haskell.org/pipermail/haskell-cafe/2009-October/067811.html If fib is defined without a type signature, the monomorphism restriction also kicks in, when fib is bound via a function binding, fib x = ... fib has polymorphic type (Num a) = Int - a and that prevents sharing the list (since there are lists for all Num types). If bound via a simple pattern binding, fib = (map fib' [0 .. ] !!) where ... and the MR is not disabled, fib gets the monomorphic type Int - Integer and that allows the list to be shared. If you give fib an explicit monomorphic type fib :: Int - Integer the list will still not be shared if it's bound via a function binding because fib' and the list are bound inside the lambda: fib = \k - let fib' ... in (map fib' [0 .. ] !!) k fib' is not a constant, so it's not floated out of the lambda, so it's not shared (and a fortiori map fib' [0 .. ] isn't shared). if fib is bound via a simple pattern binding (and no explicit lambda is given), fib' and the list are bound outside the lambda and hence shared: fib = let fib' = ...; lst = map fib' [0 .. ] in \k - lst !! k Note however that using the list as map fib' [0 .. ] is more brittle than giving it a name and binding it explicitly in the where clause: fib :: Int - Integer fib = (fibList !!) where fibList = map fib' [0 .. ] fib' 0 = 0 ... For the time being, GHC treats both the same, but the latter is less likely to break. - Forwarded message from Yue Wang yulew...@gmail.com - From: Yue Wang yulew...@gmail.com Date: Tue, 5 Oct 2010 21:23:57 -0400 To: Brent Yorgey byor...@seas.upenn.edu Subject: store evaluated values Hi, Anthony (or Brent): Last time (in Anthony's TA office hour) we talked about how to store evaluated values in the program for later used. I googled for a while and wrote some code. But I still encountered two problems. Can you take a look? Thanks. First, let's write the naive fib function: naive_fib 0 = 0 naive_fib 1 = 1 naive_fib n = trace(show(n)) naive_fib (n - 1) + naive_fib (n - 2) this works good except it tries to calculate the same expression many times. So when we evaluate it ghci will show the following: *Main naive_fib 5 5 4 3 2 2 3 2 5 Then there is a clever way to do that on haskell wiki: fib = ((map fib' [0 ..]) !!) where fib' 0 = 0 fib' 1 = 1 fib' n =trace(show(n)) fib (n - 1) + fib (n - 2) When we evaluate the same expression we can see it does not evaluate the redundant expression over and over: *Main fib 5 5 4 3 2 5 The source code seems to be easy to read, but I don't think I understand that. For me I think if I change the first line from fib = ((map fib' [0 ..]) !!) to fib x = ((map fib' [0 ..]) !!) x It should do the same thing since I think the previous version is just an abbreviation for the second one. But After I change that, *Main fib 5 5 4 3 2 2 3 2 5 So why does the x here matters? ___ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe
Re: [Haskell-cafe] Ordering vs. Order
On Thu, 07 Oct 2010 10:02:20 +0200, you wrote: I'm not a native English speaker and recently I was wondering about the two words order and ordering (the main reason why I write this to the Haskell mailing list, is that the type class Ordering does exist). My dictionaries tell me that order (besides other meanings) denotes an ordered structure on elements and ordering (as only meaning) denotes some request that I made at some entity. So, to me it seems that calling the type class Ordering is wrong ;) Considering them both used as nouns, I would say that in normal usage, there is a difference in their active/passive connotation. If you have a collection of things, they have an order, whether or not that order was imposed on them (it could be that they just fell out of the box in a certain order). On the other hand, if they possess an ordering, it implies that someone or something put them in that order; i.e., that it was a purposeful act. I think the reason for this conceptual distinction can be traced to the derivation of ordering as the gerund form of the verb order, in that it implies that an action has occurred (or is still occurring). -Steve Schafer ___ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe
Re: [Haskell-cafe] Eta-expansion destroys memoization?
What people seem to be missing here is that the location of the where-binding with respect to the lambda changes in each case. As a result, I think the forgoing explanations were rather confusing; there's no magic going on here. On Thu, Oct 7, 2010 at 8:17 AM, Brent Yorgey byor...@seas.upenn.edu wrote: - Forwarded message from Yue Wang yulew...@gmail.com - From: Yue Wang yulew...@gmail.com Then there is a clever way to do that on haskell wiki: fib = ((map fib' [0 ..]) !!) where fib' 0 = 0 fib' 1 = 1 fib' n =trace(show(n)) fib (n - 1) + fib (n - 2) This is indeed equivalent to: fib = let fib' 0 = 0 fib' 1 = 1 fib' n = fib (n-1) + fib (n-2) in (map fib' [0..] !!) But adding the argument embeds the let inside the function call: fib x = let fib' 0 = 0 fib' 1 = 1 fib' n = fib (n-1) + fib (n-2) in (map fib' [0..] !!) Now we create a new fib' for each invocation of fib. Not efficient at all! (Much *less* efficient the the recursive fib). There's no evaluation magic here---all that's happening is GHC is executing the program exactly as written. It can't float the list out of the function, as that can lead to unexpected space leaks (if you didn't intend to keep the list of fibs around forever). -Jan-Willem Maessen ___ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe
Re: [Haskell-cafe] Eta-expansion destroys memoization?
On Thu, Oct 7, 2010 at 9:33 AM, Jan-Willem Maessen jmaes...@alum.mit.edu wrote: There's no evaluation magic here---all that's happening is GHC is executing the program exactly as written. It can't float the list out of the function, as that can lead to unexpected space leaks (if you didn't intend to keep the list of fibs around forever). To echo Jan-Willem a bit, the impact of let floating can be seen by compiling the eta expanded version (i.e. fib x = map fib' [0..] !! x) with different options. $ ghc --make -O -fforce-recomp FibMemo.hs [1 of 1] Compiling Main ( FibMemo.hs, FibMemo.o ) Linking FibMemo ... $ ./FibMemo 5 3 2 4 5 $ ghc --make -O -fforce-recomp FibMemo.hs -fno-full-laziness [1 of 1] Compiling Main ( FibMemo.hs, FibMemo.o ) Linking FibMemo ... $ ./FibMemo 5 3 2 4 2 3 2 5 My understanding is that this is just a case where GHCi is able to float a binding in the partial application formulation because the dependency analysis is trivial due to there being no name for the binding. Looking at the core for the optimized version of the eta expanded code, there is a a top-level function for building a list of fibonacci numbers, a top-level value of type [Type.Integer] set to an application of the builder function to zero, and finally the fib function that indexes into that list. The version with -fno-full-laziness leaves the let binding under the lambda as expected. So the optimizer is clever and can see through the lambda, but we make the interpreter's job easier by not putting a lambda over its eyes to begin with. Anthony On Thu, Oct 7, 2010 at 9:33 AM, Jan-Willem Maessen jmaes...@alum.mit.edu wrote: What people seem to be missing here is that the location of the where-binding with respect to the lambda changes in each case. As a result, I think the forgoing explanations were rather confusing; there's no magic going on here. On Thu, Oct 7, 2010 at 8:17 AM, Brent Yorgey byor...@seas.upenn.edu wrote: - Forwarded message from Yue Wang yulew...@gmail.com - From: Yue Wang yulew...@gmail.com Then there is a clever way to do that on haskell wiki: fib = ((map fib' [0 ..]) !!) where fib' 0 = 0 fib' 1 = 1 fib' n =trace(show(n)) fib (n - 1) + fib (n - 2) This is indeed equivalent to: fib = let fib' 0 = 0 fib' 1 = 1 fib' n = fib (n-1) + fib (n-2) in (map fib' [0..] !!) But adding the argument embeds the let inside the function call: fib x = let fib' 0 = 0 fib' 1 = 1 fib' n = fib (n-1) + fib (n-2) in (map fib' [0..] !!) Now we create a new fib' for each invocation of fib. Not efficient at all! (Much *less* efficient the the recursive fib). There's no evaluation magic here---all that's happening is GHC is executing the program exactly as written. It can't float the list out of the function, as that can lead to unexpected space leaks (if you didn't intend to keep the list of fibs around forever). -Jan-Willem Maessen ___ 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
Re: [Haskell-cafe] Re: Lambda-case / lambda-if
Hi,
On 06.10.2010, at 22:43, Sterling Clover wrote:
On Oct 6, 2010, at 5:39 AM, Simon Marlow wrote:
A slightly different suggestion from Simon PJ and myself (we agreed on
something syntax-related :-) is the following:
\case 1 - f
2 - g
where the two-token sequence '\ case' introduces a new optional layout
context, the body of which is exactly the same as in a case expression. So
you could also write
\case { 1 - f; 2 - g }
if you want. Guards are allowed of course.
* a bit more noisy than just \: I'm not sure what the
ramifications of having \ introduce a layout context
on its own would be, but I suspect there would be difficulties.
Certainly some existing code would fail to parse, e.g.
(case e of [] - \x - x+1; (x:xs) - \x - x+2)
\ introducing a layout context is a no-go because, as in the example given,
it breaks too much code. However, \case as described is somewhat less
powerful. In particular, \ with a layout context lets us have multi-argument
pattern matching, while both \case and case of give only single argument
pattern matching. I don't know if the extra functionality is that important,
but I don't see why we can't provide for it anyway, as in:
\case (x:xs) n - go xs; _ n - n;
Then, there is an inconsistency between lambda-case and traditional case and
people will start complaining about that.
Haskell98 is a very well thought out language with very few syntactiv warts.
I'd avoid introducing new language extensions which do introduce new warts.
Backwards compatibility is not so important, because GHC will hopefully make it
optional. Even when an extended \{ p1 - e1; p2 - e2 } is part of Haskell 2012
GHC will probably support Haskell 2011 as well. Therefore, I'd worry less about
backwards compatibility, but concentrate more on consistency and elegance. I.e
I'll favor
\p1 p2 - e1
p3 p4 - e2
Just my 2 cents.
-- Jean___
Haskell-Cafe mailing list
Haskell-Cafe@haskell.org
http://www.haskell.org/mailman/listinfo/haskell-cafe
[Haskell-cafe] CFP MSCS Issue: Dependently Typed Programming
(s:S)-(p:P s)*(s:S)-(p:P s)*(s:S)-(p:P s)*(s:S)-(p:P s)*(s:S)- (p:P s)* OPEN CALL FOR PAPERS for a Special Issue of MATHEMATICAL STRUCTURES in COMPUTER SCIENCE in association with the workshop DEPENDENTLY TYPED PROGRAMMING 2010 editors: Thorsten Altenkirch (Nottingham), Conor McBride (Strathclyde) 2011 timeline: submission Jan 31; notification May 31; final version June 30 (s:S)-(p:P s)*(s:S)-(p:P s)*(s:S)-(p:P s)*(s:S)-(p:P s)*(s:S)- (p:P s)* Thorsten Altenkirch and Conor McBride are delighted to invite contributions to a Special Issue of the journal Mathematical Structures in Computer Science (Cambridge University Press), in association with the Workshop on Dependently Typed Programming, which we organised on 9 and 10 July 2010 in Edinburgh, as part of FLoC, associated with LiCS. The workshop had a packed programme of exciting developments, reflecting the strength of work on this topic at this time. More recent workshops and conferences have exhibited a significant contribution from researchers in this area. We are grateful to Editor-in-Chief Giuseppe Longo and to Editor Eugenio Moggi for the opportunity to reflect these welcome developments in the pages of MSCS, and we encourage researchers to consider submitting a paper. submission deadline: January 31 2011 notification: May 31 2011 final versions due: June 30 2011 We invite full journal articles concerning Dependently Typed Programming or related topics, from authors at work in this area. Submissions are particularly welcome from but not limited to contributors to the workshop, and the same journal-standard peer review process will apply in any case. Please feel free to address any enquiries about scope and suitability to the guest editors, Thorsten Altenkirch (University of Nottingham) and Conor McBride (University of Strathclyde). Submissions should usually not exceed 35 pages. Authors should adhere to the guidelines issued by Cambridge University Press for MSCS contributors: http://assets.cambridge.org/MSC/MSC_ifc.pdf. These include directions to the relevant LaTeX resources. We very much look forward to hearing from you. Thorsten and Conor ___ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe
[Haskell-cafe] Re: Lambda-case / lambda-if
On Tue, 2010-10-05 at 17:10 -0700, Evan Laforge wrote: +1 for something to solve the dummy - m; case dummy of problem. Here are the possibilities I can think of: Might be off-topic here, but I have wondered for a while why Haskell doesn't support something like follows: do case (- m) of ... With the more general rule being: do ... e (- m) g = ... m = \tmp - e tmp g Reasons: * - is already sugary, and the transformation is similar. Just removes the need for the user to define a throw-away name. * Better than liftMX and the Applicative operators. As shown, this is more flexible while requiring less magic operators as a bonus. Also makes more clear where the sides effects actually are. * Goes well with the spirit of getting the good parts of imperative coding where it potentially makes the code more concise. Can be abused, obviously, but I have also seen a lot of code that I feel could be written better using this. Anything I am overlooking here? I tried to find a discussion about something like this, but didn't really know what to look for... Greetings, Peter Wortmann ___ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe
Re: [Haskell-cafe] ANNOUNCE: Haskell XML Toolbox Version 9.0.0
Could you explain to me why HXT uses arrows? I have never been able to figure out what advantage this gives your library over monads. Since your arrows in practice implement ArrowApply, they are really just monads anyway, so it seems to me that using arrows instead of monads only serves to add complexity to the library without adding any benefit. Furthermore, by using arrows instead of monads people cannot use the many standard monad libraries out there, but have to instead write their own generalizations of them to arrows. Is there some benefit that your library gets out of using arrows that I missed which makes these costs worth it? Cheers, Greg On 10/7/10 5:28 AM, Uwe Schmidt wrote: Haskell XML Toolbox 9.0.0 I would like to announce a new version of the Haskell XML Toolbox. HXT has grown over the years. Components for XPath, XSLT, validation with RelaxNG, picklers for conversion from/to native Haskell data, lazy parsing with tagsoup, input via curl and native Haskell HTTP and others have been added. This has led to a rather large package with a lot of dependencies. To make the toolbox more modular and to reduce the dependencies on other packages, hxt has been split into various smaller packages since this version. Information about this release, about the new packages, changes and incompatibilities to older versions can be found at HXT home: http://www.fh-wedel.de/~si/HXmlToolbox/index.html; and on the Haskell wiki page about HXT http://www.haskell.org/haskellwiki/HXT; The source repo has been moved to GitHub: http://github.com/UweSchmidt/hxt; Downloads and installation is available from hackage. Please email comments, bugs, etc. to hxmltool...@fh-wedel.de or s...@fh-wedel.de Uwe -- University of Applied Sciences, Wedel, Germany http://www.fh-wedel.de/~si/index.html ___ 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
Re: [Haskell-cafe] Re: Lambda-case / lambda-if
Отправлено с iPhone Oct 7, 2010, в 21:03, Peter Wortmann sc...@leeds.ac.uk написал(а): On Tue, 2010-10-05 at 17:10 -0700, Evan Laforge wrote: +1 for something to solve the dummy - m; case dummy of problem. Here are the possibilities I can think of: Might be off-topic here, but I have wondered for a while why Haskell doesn't support something like follows: do case (- m) of ... I think it'd be better to write just 'case (- m) of', without 'do'. With the more general rule being: do ... e (- m) g = ... m = \tmp - e tmp g Reasons: * - is already sugary, and the transformation is similar. Just removes the need for the user to define a throw-away name. * Better than liftMX and the Applicative operators. As shown, this is more flexible while requiring less magic operators as a bonus. Also makes more clear where the sides effects actually are. * Goes well with the spirit of getting the good parts of imperative coding where it potentially makes the code more concise. Can be abused, obviously, but I have also seen a lot of code that I feel could be written better using this. Anything I am overlooking here? I tried to find a discussion about something like this, but didn't really know what to look for... Greetings, Peter Wortmann ___ 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] I'm still having challenges to get a Haskell GUI to work under Windows 7
I'm still having challenges to get a Haskell GUI to work under Windows 7; even after various instructions on the web. e.g. Haskell Platform 2010.2.0.0, wxWidgets-2.9.1, wxHaskell 0.12.1.6 Similar challenges with GTK+ and gtk2hs. ___ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe
[Haskell-cafe] Is there a more recent paper or article than Can GUI Programming Be Liberated From The IO Monad
Is there a more recent paper or article than Can GUI Programming Be Liberated From The IO Monad? :) ___ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe
Re: [Haskell-cafe] HTML library with DOM?
Yes, I don't think I've officially announced a version of TagSoup that has had HTML 5 parsing, but it now does as standard for the last few releases. The HTML 5 spec is still changing, so it's entirely possible something is incorrect in a corner case, but please let me know and I'll fix it. Thanks, Neil 2010/10/7 Gregory Collins g...@gregorycollins.net: Michael Snoyman mich...@snoyman.com writes: As far as I know, Neil Mitchel's tagsoup[1] parses according to the HTML 5 parsing rules, but it just generates a list of Tags[2], so you'd have to build the DOM tree up from there. I personally have had great experience with tagsoup. It's even the core of HTML-scraping technology powering searchonce[3]. Yep, someone else wrote me privately to say this (that tagsoup respects the html5 lexing rules). So I'll be using this as the basis of an html5 DOM parser. Stay tuned! G -- Gregory Collins g...@gregorycollins.net ___ 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
Re: [Haskell-cafe] Re: Lambda-case / lambda-if
On Thu, 07 Oct 2010 18:03:48 +0100, Peter Wortmann sc...@leeds.ac.uk wrote:
On Tue, 2010-10-05 at 17:10 -0700, Evan Laforge wrote:
+1 for something to solve the dummy - m; case dummy of problem.
Here are the possibilities I can think of:
Might be off-topic here, but I have wondered for a while why Haskell
doesn't support something like follows:
do case (- m) of ...
With the more general rule being:
do ... e (- m) g
=
... m = \tmp - e tmp g
Reasons:
* - is already sugary, and the transformation is similar. Just
removes the need for the user to define a throw-away name.
* Better than liftMX and the Applicative operators. As shown, this is
more flexible while requiring less magic operators as a bonus. Also
makes more clear where the sides effects actually are.
* Goes well with the spirit of getting the good parts of imperative
coding where it potentially makes the code more concise. Can be
abused, obviously, but I have also seen a lot of code that I feel
could be written better using this.
Anything I am overlooking here? I tried to find a discussion about
something like this, but didn't really know what to look for...
Your notation feels very tempting, however it relies a lot on finding
the do to put the bind. Recall that do is just syntax, and that
it has no more meaning than its desugaring.
Imagine these examples:
do {a; b (- c) d; e} = do {a; x - c; b x d; e}
do {a b (- c) d; e}
|
+-- do {x - c; a b x d; e}
|
+-- do {a; x - c; b x d; e}
Imagine that b can be equal to b1 b2 and so where placing the
x - c is non obvious and it should be.
On the other hand case (- m) of {...} being translated into
m = \x - case x of {...} is non-ambigous.
Best regards,
--
Nicolas Pouillard
http://nicolaspouillard.fr
___
Haskell-Cafe mailing list
Haskell-Cafe@haskell.org
http://www.haskell.org/mailman/listinfo/haskell-cafe
Re: [Haskell-cafe] Notes from Haskell takes over the world BoF at ICFP
Hi Digressing a little, can anyone interested in doing so merge hoogle and Hayoo and make them part of Hackage? I am currently working on this in my spare time. I hope to have something to show in the next month. Thanks, Neil ___ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe
Re: [Haskell-cafe] Is there a more recent paper or article than Can GUI Programming Be Liberated From The IO Monad
Of related interest, there have been more recent papers by the Clean developers on Arrow GECS and iData but they are about Clean where this is no IO monad. Maybe Haskell cannot be liberated from IO after all... ___ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe
Re: [Haskell-cafe] Re: Lambda-case / lambda-if
On Thu, Oct 07, 2010 at 02:45:58PM -0700, Nicolas Pouillard wrote:
On Thu, 07 Oct 2010 18:03:48 +0100, Peter Wortmann sc...@leeds.ac.uk wrote:
Might be off-topic here, but I have wondered for a while why Haskell
doesn't support something like follows:
do case (- m) of ...
With the more general rule being:
do ... e (- m) g
=
... m = \tmp - e tmp g
Your general rule doesn't subsume your case example, since a case
expression is not an application. I think you mean something like
do C[(- m)]
=
m = \tmp - C[tmp]
where C is an arbitrary expression context. It could further be
generalized to allow several (- ...) subterms in an expression, with
implied left-to right sequencing. Frankly, that seems like a very
attractive way to make the do-notation into a more practical
imperative sub-language.
This should probably also cover binding, i.e. do { p - C[(- m)];
... } should also work.
Imagine these examples:
do {a; b (- c) d; e} = do {a; x - c; b x d; e}
do {a b (- c) d; e}
|
+-- do {x - c; a b x d; e}
|
+-- do {a; x - c; b x d; e}
To my understanding no rule would produce this latter variant. do {a;
b} is transformed into a do {b}, not the other way around. The
proposed transformation rule seems clear to me: the context covers the
entire expression-statement, including of course expressions
containing monadic operations:
do {a b (- c) d; e} = c = \x - a b x d e
and if you want a to go before c, you have to do
do {a; b (- c) d; e)= a c = \x - b x d e
Imagine that b can be equal to b1 b2 and so where placing the
x - c is non obvious and it should be.
I don't see what this has to do with anything. All we are interested
in is the syntax of do-expressions. The do-transformation is
completely oblivious to monadic operations within the statements, it
only produces some more monadic operations.
Cheers,
Lauri
___
Haskell-Cafe mailing list
Haskell-Cafe@haskell.org
http://www.haskell.org/mailman/listinfo/haskell-cafe
Re: [Haskell-cafe] A model theory question
On Sep 30, 2010, at 1:39 AM, Patrick Browne wrote: I think my original question can be rephrased as: Can type classes preserve satisfaction under the the expansion sentences (signature/theory morphisms inducing a model morphism). According to [1] expansion requires further measures (programming?) which you demonstrated. But this raises are further question. Does Haskell’s multiple inheritance represent a model expansion where the classes in the context of an instance are combined in the new bigger model? In principle, the answer is yes (I think). But I kept running into walls when I tried. It is almost as if there is too big a gap to be filled between compile-time and run-time. At least for the approaches I tried. I have two suggestions though. First, monadism is a great way to approach this problem from a run-time level. Indeed, a monad is an interpreter, which comes with the associated notions of a free algebra/ model and the like. Injecting a new axiom amounts to creating a new monadic action. Monad transformers can do lifting and lowering in a fairly straight forward way. Another suggestion is to check out the OOHaskell paper. I know they use type level forcing to get stuff done, but I guess they used a different cluster of extensions than I tried. http://homepages.cwi.nl/~ralf/OOHaskell/ Sorry for the delay in responding. -Alex___ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe
Re: [Haskell-cafe] Eta-expansion destroys memoization?
Brent Yeu, I recently ran into the same question. You can see the thread[1] which includes lots of references to papers that describe the behavior you're seeing along with examples. Implementations of call-by-name lambda calculus all tend to have the same runtime behavior that you're describing. It's usually called sharing. You can look at how ghc reduces expressions like this directly(see [2] and [3]). However, this is really low level and doesn't help us understand the way other Haskell implementations work. John Launchbury[4] came along and said hey, these denotational definitions of call-by-name lambda calculus don't help us understand the runtime of current implementations. He developed a high level operational semantics for call-by-name that correctly, and simply, accounts for sharing across all implementations. I found the paper accessible and very helpful when analyzing the sometimes mysterious runtime behavior of Haskell. Ariola et. all[5] improved upon on Launchbury's work and made an even more high level operational semantics for call-by-name which they called, confusingly enough, call-by-need. This paper is not as accessible as Launchbury, but presents a clever way to describe how sharing works without using a heap construct. If you read carefully through the thread I mentioned in the beginning and Launchbury's paper, you should be equipped to write down reductions by hand that illustrate the different runtime behaviors of your semantically equivalent expressions. David [1] http://comments.gmane.org/gmane.comp.lang.haskell.cafe/81029 [2] http://www.haskell.org/haskellwiki/Ministg [3] http://research.microsoft.com/en-us/um/people/simonpj/Papers/eval-apply/index.htm [4] http://citeseerx.ist.psu.edu/viewdoc/summary?doi=10.1.1.35.2016 [5] http://homepages.inf.ed.ac.uk/wadler/papers/need/need.ps -- David Sankel Sankel Software www.sankelsoftware.com 585 617 4748 (Office) ___ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe
Re: [Haskell-cafe] ANNOUNCE: tls, native TLS/SSL protocol implementation
Does native mean Haskell only - without FFI? -- Regards, Kashyap ___ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe
