Re: [Haskell-cafe] Threadscope 0.2.2 goes in segmentation fault on Mac Os X 10.8.3
Hi Alfredo, No dark magic as far as I recall (except in the actual bundling as a Mac app, unfortunately that required some magic, the GTK libraries don't relocate so easily :-( ). I didn't have any problems building. I compiled it with ghc 7.6.1, with the GTK libraries installed manually (there are some suggestions on how to do that at the very end of my Comprehensive Haskell Sandboxes post, http://www.edsko.net/2013/02/10/comprehensive-haskell-sandboxes/). It used to be a lot more painful (requiring the latest versions of Haskell libraries, with patches etc.) but these days the situation is a lot better. (That's not so say that problems like the one you reported don't still crop up from time to time, and can cause many a sleepless night..). Edsko On Wed, Apr 3, 2013 at 9:33 PM, Alfredo Di Napoli alfredo.dinap...@gmail.com wrote: Thanks Edsko, the app is awesome and it's starting just fine. Even though this fixes my problem, it doesn't solve the root, namely why it was failing. Can you tell me a bit more about the dark magic you used to make it work? Which GHC version did you use? Thanks a lot, A. On 3 April 2013 12:40, Edsko de Vries edskodevr...@gmail.com wrote: I provide a ThreadScope binary on my site ( http://www.edsko.net/2013/01/24/threadscope-0-2-2/) which runs fine for me on 10.8.3. -E On Mon, Apr 1, 2013 at 8:01 AM, Dominic Steinitz domi...@steinitz.orgwrote: Alfredo Di Napoli alfredo.dinapoli at gmail.com writes: Said that,has someone had any luck in running Threadscope on Mac OS X 10.8 at all? Thanks, A. I think I have encountered the same problem: https://groups.google.com/d/msg/parallel-haskell/-lhrgNN8elw/KzqLM9BzoJwJ In my experience, anything that uses gtk is a problem on a MAC. I still intend to do some analysis *not* using threadscope but using event-logs directly but that is at least a few weeks away. Dominic. ___ 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 mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe
Re: [Haskell-cafe] Threadscope 0.2.2 goes in segmentation fault on Mac Os X 10.8.3
Hi Edsko, thanks for the reply. The only things that might affect the outcome are: a) Ghc version: I'm running ghc 7.6.2 instead of 7.6.1 b) Don't know if you are using cabal-dev as sandboxing (like any good Haskell programmer I'm too lazy to open your blog post :D ), whilst I'm using hsenv c) I've brewed GTK instead of manually installing it, but gtk-demo runs just fine d) Are you using XQuartz? If yes, which version? Thanks again! A. On 4 April 2013 08:52, Edsko de Vries edskodevr...@gmail.com wrote: Hi Alfredo, No dark magic as far as I recall (except in the actual bundling as a Mac app, unfortunately that required some magic, the GTK libraries don't relocate so easily :-( ). I didn't have any problems building. I compiled it with ghc 7.6.1, with the GTK libraries installed manually (there are some suggestions on how to do that at the very end of my Comprehensive Haskell Sandboxes post, http://www.edsko.net/2013/02/10/comprehensive-haskell-sandboxes/). It used to be a lot more painful (requiring the latest versions of Haskell libraries, with patches etc.) but these days the situation is a lot better. (That's not so say that problems like the one you reported don't still crop up from time to time, and can cause many a sleepless night..). Edsko On Wed, Apr 3, 2013 at 9:33 PM, Alfredo Di Napoli alfredo.dinap...@gmail.com wrote: Thanks Edsko, the app is awesome and it's starting just fine. Even though this fixes my problem, it doesn't solve the root, namely why it was failing. Can you tell me a bit more about the dark magic you used to make it work? Which GHC version did you use? Thanks a lot, A. On 3 April 2013 12:40, Edsko de Vries edskodevr...@gmail.com wrote: I provide a ThreadScope binary on my site ( http://www.edsko.net/2013/01/24/threadscope-0-2-2/) which runs fine for me on 10.8.3. -E On Mon, Apr 1, 2013 at 8:01 AM, Dominic Steinitz domi...@steinitz.orgwrote: Alfredo Di Napoli alfredo.dinapoli at gmail.com writes: Said that,has someone had any luck in running Threadscope on Mac OS X 10.8 at all? Thanks, A. I think I have encountered the same problem: https://groups.google.com/d/msg/parallel-haskell/-lhrgNN8elw/KzqLM9BzoJwJ In my experience, anything that uses gtk is a problem on a MAC. I still intend to do some analysis *not* using threadscope but using event-logs directly but that is at least a few weeks away. Dominic. ___ 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 mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe
Re: [Haskell-cafe] Threadscope 0.2.2 goes in segmentation fault on Mac Os X 10.8.3
a) 7.6.2 vs 7.6.1 seems unlike to be the issue, although theoretically possible I guess. b) Actually, the blog post is how to set things up by hand for better control than either of those tools give you; but again, I don't think it's relevant. c) This might be a bigger difference. I don't know what version brew installs, where it installs it, etc. etc. d) And this might be related too; yes, I'm using XQuartz and have the GTK compiled for it; currently using 2.7.4 but I don't know if I upgraded since building. -E On Thu, Apr 4, 2013 at 9:07 AM, Alfredo Di Napoli alfredo.dinap...@gmail.com wrote: Hi Edsko, thanks for the reply. The only things that might affect the outcome are: a) Ghc version: I'm running ghc 7.6.2 instead of 7.6.1 b) Don't know if you are using cabal-dev as sandboxing (like any good Haskell programmer I'm too lazy to open your blog post :D ), whilst I'm using hsenv c) I've brewed GTK instead of manually installing it, but gtk-demo runs just fine d) Are you using XQuartz? If yes, which version? Thanks again! A. On 4 April 2013 08:52, Edsko de Vries edskodevr...@gmail.com wrote: Hi Alfredo, No dark magic as far as I recall (except in the actual bundling as a Mac app, unfortunately that required some magic, the GTK libraries don't relocate so easily :-( ). I didn't have any problems building. I compiled it with ghc 7.6.1, with the GTK libraries installed manually (there are some suggestions on how to do that at the very end of my Comprehensive Haskell Sandboxes post, http://www.edsko.net/2013/02/10/comprehensive-haskell-sandboxes/). It used to be a lot more painful (requiring the latest versions of Haskell libraries, with patches etc.) but these days the situation is a lot better. (That's not so say that problems like the one you reported don't still crop up from time to time, and can cause many a sleepless night..). Edsko On Wed, Apr 3, 2013 at 9:33 PM, Alfredo Di Napoli alfredo.dinap...@gmail.com wrote: Thanks Edsko, the app is awesome and it's starting just fine. Even though this fixes my problem, it doesn't solve the root, namely why it was failing. Can you tell me a bit more about the dark magic you used to make it work? Which GHC version did you use? Thanks a lot, A. On 3 April 2013 12:40, Edsko de Vries edskodevr...@gmail.com wrote: I provide a ThreadScope binary on my site ( http://www.edsko.net/2013/01/24/threadscope-0-2-2/) which runs fine for me on 10.8.3. -E On Mon, Apr 1, 2013 at 8:01 AM, Dominic Steinitz domi...@steinitz.orgwrote: Alfredo Di Napoli alfredo.dinapoli at gmail.com writes: Said that,has someone had any luck in running Threadscope on Mac OS X 10.8 at all? Thanks, A. I think I have encountered the same problem: https://groups.google.com/d/msg/parallel-haskell/-lhrgNN8elw/KzqLM9BzoJwJ In my experience, anything that uses gtk is a problem on a MAC. I still intend to do some analysis *not* using threadscope but using event-logs directly but that is at least a few weeks away. Dominic. ___ 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 mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe
Re: [Haskell-cafe] Threadscope 0.2.2 goes in segmentation fault on Mac Os X 10.8.3
Perfect, I will try to probe the ground for points c) and d), and I will get back to all of you if I manage to shed some light to this mystery :D A. On 4 April 2013 09:12, Edsko de Vries edskodevr...@gmail.com wrote: a) 7.6.2 vs 7.6.1 seems unlike to be the issue, although theoretically possible I guess. b) Actually, the blog post is how to set things up by hand for better control than either of those tools give you; but again, I don't think it's relevant. c) This might be a bigger difference. I don't know what version brew installs, where it installs it, etc. etc. d) And this might be related too; yes, I'm using XQuartz and have the GTK compiled for it; currently using 2.7.4 but I don't know if I upgraded since building. -E On Thu, Apr 4, 2013 at 9:07 AM, Alfredo Di Napoli alfredo.dinap...@gmail.com wrote: Hi Edsko, thanks for the reply. The only things that might affect the outcome are: a) Ghc version: I'm running ghc 7.6.2 instead of 7.6.1 b) Don't know if you are using cabal-dev as sandboxing (like any good Haskell programmer I'm too lazy to open your blog post :D ), whilst I'm using hsenv c) I've brewed GTK instead of manually installing it, but gtk-demo runs just fine d) Are you using XQuartz? If yes, which version? Thanks again! A. On 4 April 2013 08:52, Edsko de Vries edskodevr...@gmail.com wrote: Hi Alfredo, No dark magic as far as I recall (except in the actual bundling as a Mac app, unfortunately that required some magic, the GTK libraries don't relocate so easily :-( ). I didn't have any problems building. I compiled it with ghc 7.6.1, with the GTK libraries installed manually (there are some suggestions on how to do that at the very end of my Comprehensive Haskell Sandboxes post, http://www.edsko.net/2013/02/10/comprehensive-haskell-sandboxes/). It used to be a lot more painful (requiring the latest versions of Haskell libraries, with patches etc.) but these days the situation is a lot better. (That's not so say that problems like the one you reported don't still crop up from time to time, and can cause many a sleepless night..). Edsko On Wed, Apr 3, 2013 at 9:33 PM, Alfredo Di Napoli alfredo.dinap...@gmail.com wrote: Thanks Edsko, the app is awesome and it's starting just fine. Even though this fixes my problem, it doesn't solve the root, namely why it was failing. Can you tell me a bit more about the dark magic you used to make it work? Which GHC version did you use? Thanks a lot, A. On 3 April 2013 12:40, Edsko de Vries edskodevr...@gmail.com wrote: I provide a ThreadScope binary on my site ( http://www.edsko.net/2013/01/24/threadscope-0-2-2/) which runs fine for me on 10.8.3. -E On Mon, Apr 1, 2013 at 8:01 AM, Dominic Steinitz domi...@steinitz.org wrote: Alfredo Di Napoli alfredo.dinapoli at gmail.com writes: Said that,has someone had any luck in running Threadscope on Mac OS X 10.8 at all? Thanks, A. I think I have encountered the same problem: https://groups.google.com/d/msg/parallel-haskell/-lhrgNN8elw/KzqLM9BzoJwJ In my experience, anything that uses gtk is a problem on a MAC. I still intend to do some analysis *not* using threadscope but using event-logs directly but that is at least a few weeks away. Dominic. ___ 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 mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe
Re: [Haskell-cafe] Haskell is a declarative language? Let's see how easy it is to declare types of things.
Albert Y. C. Lai trebla at vex.net writes: Quantifiers are complicated, but I don't see how explicit is more so than implicit. [...] I have just seen recently [...] Great example. I completely agree. My feeling is that mathematicians use this principle of leaving out some of the quantifiers and putting some others in the wrong place as a cultural entry barrier to protect their field from newbies. Well, not use, but willingly tolerate, perhaps. (I do have a diploma in mathematics, from a German university.) ___ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe
[Haskell-cafe] Possible GSoC project
Hi, I proposed a bioinformatics GSoC project involving Haskell using OSC as the mentoring organization. Typically, haskell.org projects concern infrastructure rather than applications, and I don't know if I'm allowed to submit both places :-) Anyway, as this is a likely place to find prospective students and (co-)mentors, I thought I'd mention it here. But if anybody is interested, I think it makes for a quite focused, solvable problem, which I belive would be quite useful. It could also likely result in a scientific publication of some sort. A quick writeup (that I'll probably update) is here: http://biohaskell.org/Google_Summer_of_Code#optimizing-transalign -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] Haskell is a declarative language? Let's see how easy it is to declare types of things.
On Thu, Apr 04, 2013 at 11:02:34AM +, Johannes Waldmann wrote: My feeling is that mathematicians use this principle of leaving out some of the quantifiers and putting some others in the wrong place as a cultural entry barrier to protect their field from newbies. Albert showed an example of leaving out quantifiers, but I didn't see an example of quantifiers in the wrong place. Did I miss one? Tom ___ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe
Re: [Haskell-cafe] Haskell is a declarative language? Let's see how easy it is to declare types of things.
Hi,
Richard A. O'Keefe wrote:
As I understand it, in ML, it seemed to be a clever idea to not have type
signatures at all.
Wrong. In ML, it seemed to be a clever idea not to *NEED* type signatures,
and for local definitions they are very commonly omitted.
In the ML I used, I remember that it was syntactically impossible to use
type signatures directly adjacent to a local definition. Instead, I was
thaught to put something like a type signature in a comment,
approximately like this:
(* getOpt : 'a option * 'a - 'a *)
fun getOpt (SOME x, y) = x
| getOpt (NONE, y) = y
An example of this style can be found in Danvy and Nielsen,
Defunctionalization at Work, Proc. of PPDP 2001 (extended version
available at
ftp://ftp.daimi.au.dk/pub/BRICS/Reports/RS/01/23/BRICS-RS-01-23.pdf).
But you can certainly HAVE type signatures, and for modules
('structures') it is normal to have them in the interfaces ('signatures').
In my opinion, a signature for a structure would not count as directly
adjacent. Also, while I don't know much about the history of ML, I
suspect that structures and signatures were a later addition to the core
language.
I just checked Milner, Tofte and Harper, The Definition of Standard ML,
MIT Press 1990 (available at
http://www.itu.dk/people/tofte/publ/1990sml/1990sml.html), and learned
that we can have explicit type annotations for both patterns and
expressions, so the following variants of the above are possible in
Standard ML:
1. We can embed parts of the signature into the definition:
fun getOpt (SOME (x : 'a), y : 'a) : 'a = x
| getOpt (NONE, y : 'a) : 'a = y
With decomposing the type signature into its parts, and then duplicating
these parts, this is not very attractive.
2. We can do better by avoiding the derived form for function bindings:
val getOpt : 'a option * 'a - 'a
= fn (SOME x, y) = x
| (NONE, y) = y
This looks ok to me, and I wonder why I was not thaught this style, at
least as an alternative. The benefit over type signatures in comments is
clear: The type checker will check that the signatures are accurate, and
there is a chance that error messages contain type variables chosen by
the programmer instead of automatically generated names.
Tillmann
___
Haskell-Cafe mailing list
Haskell-Cafe@haskell.org
http://www.haskell.org/mailman/listinfo/haskell-cafe
Re: [Haskell-cafe] Haskell is a declarative language? Let's see how easy it is to declare types of things.
Tom Ellis tom-lists-haskell-cafe-2013 at jaguarpaw.co.uk writes: I didn't see an example of quantifiers in the wrong place. The example was: every x satisfies P(x,y) for some y ___ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe
Re: [Haskell-cafe] Type level natural numbers
Mateusz Kowalczyk fuuze...@fuuzetsu.co.uk writes: About two weeks ago we got an email (at ghc-users) mentioning that comparing to 7.6, 7.7.x snapshot would contain (amongst other things), type level natural numbers. I believe the package used is at [1]. Can someone explain what use is such package in Haskell? I understand uses in a language such as Agda where we can provide proofs about a type and then use that to perform computations using the type system (such as guaranteeing that concatenating two vectors together will give a new one with the length of the two initial vectors combine) however as far as I can tell, this is not the case in Haskell (although I don't want to say ?impossible? and have Oleg jump me). It most certainly will be possible to do type level arithmetic. For one use-case, see Linear.V from the linear library [1]. The DataKinds work is already available in 7.6, allowing one to use type level naturals, but the type checker is unable to unify arithmetic operations. Cheers, - Ben [1] http://hackage.haskell.org/packages/archive/linear/1.1.1/doc/html/Linear-V.html ___ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe
Re: [Haskell-cafe] Haskell is a declarative language? Let's see how easy it is to declare types of things.
On Thu, Apr 04, 2013 at 01:15:27PM +, Johannes Waldmann wrote: Tom Ellis tom-lists-haskell-cafe-2013 at jaguarpaw.co.uk writes: I didn't see an example of quantifiers in the wrong place. The example was: every x satisfies P(x,y) for some y Oh I see. I interpreted that as lack of disambiguating parentheses, but it's not unreasonable to assert that quantifiers should always come before formulas. Syntax certainly is hard. I remember being completely puzzled the first time I saw / | dx (long expression in x) / when I expected / | (long expression in x) dx / (Those are integral signs, by the way!) Tom ___ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe
Re: [Haskell-cafe] Possible GSoC project
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 On 04/04/13 12:35, Ketil Malde wrote: Hi, I proposed a bioinformatics GSoC project involving Haskell using OSC as the mentoring organization. Typically, haskell.org projects concern infrastructure rather than applications, and I don't know if I'm allowed to submit both places :-) Anyway, as this is a likely place to find prospective students and (co-)mentors, I thought I'd mention it here. But if anybody is interested, I think it makes for a quite focused, solvable problem, which I belive would be quite useful. It could also likely result in a scientific publication of some sort. A quick writeup (that I'll probably update) is here: http://biohaskell.org/Google_Summer_of_Code#optimizing-transalign -k What would you say is the level of bioinformatics understanding that one would have to have to even consider applying? - -- Mateusz K. -BEGIN PGP SIGNATURE- Version: GnuPG v2.0.19 (GNU/Linux) iQIcBAEBAgAGBQJRXYwYAAoJEM1mucMq2pqXSzcP/3RfYhPwAQU1LsI3tKa/sRni fBxGOSyPnySqUHzvDIGTw+1Ym3p9Kdy7Mv6l4zh65fcjqBPzRfK6gWWTJ6vYbGT9 poko8LzSmUsXPUnI+jca9W/iWJaR3pTI4iQkhqfpGz9qU2I9OKg0D3oNbFg4rkaS REXRXz0UEioMPh17OkX+O2KXP7SrX2cu879n6AIKptLDCkiUr4dY758PtfbgVE7N z4TNAquZ4ytsajgOD1dBpys8U1aaxNna9MBxhFpglDQXs9CBCZOkK+2DWo99dGD5 opP133bJnhja/fOcUAPW4BhUy28q7Tf78lXet9vWgurWOV1hlv8sRUinosT2UET1 +9nTDD0Y9p93KAysV0YPO+LKrQnwhp/6Qcug48FbqwkfMcJmGgdaq+Yx+LLmEKK2 31Qh8oSnr3Ye782XFXDKtBRtBlima1lPg8tykk3jiFrKqRhjBCPtpWIb6jYTyOTJ 792fyXeMzwUgvZyV3jU7axS5+F44v72i0yKmCrD8gmdNNVMbP4wIVFR7MU/THVo+ FF1qoHc7jiAlLn5/z75CuL7aCi5VTq2x1cxv0EeyRyqOfAxXoNDq0d96J24mVvsF Dar6nfqiH9VOcEnTf/N0WWN3AqSQJ+144NlgFtV5d2pFN4n/5s+DcGIooy68jZbg wdk3DX0s7/IkAT3T/rwz =W2wV -END PGP SIGNATURE- ___ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe
Re: [Haskell-cafe] Possible GSoC project
Mateusz Kowalczyk fuuze...@fuuzetsu.co.uk wrote: What would you say is the level of bioinformatics understanding that one would have to have to even consider applying? Not very much, some knowledge of string edit distance and dynamic programming would be good, but if not, it's something I can straighten out with a student in an afternoon, I think. -k -- De profundis ad te clamo. ___ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe
[Haskell-cafe] GSoC Project Proposal: Markdown support for Haddock
Hi all,
Haddock's current markup language leaves something to be desired once
you want to write more serious documentation (e.g. several paragraphs
of introductory text at the top of the module doc). Several features
are lacking (bold text, links that render as text instead of URLs,
inline HTML).
I suggest that we implement an alternative haddock syntax that's a
superset of Markdown. It's a superset in the sense that we still want
to support linkifying Haskell identifiers, etc. Modules that want to
use the new syntax (which will probably be incompatible with the
current syntax) can set:
{-# HADDOCK Markdown #-}
on top of the source file.
Ticket: http://trac.haskell.org/haddock/ticket/244
-- Johan
___
Haskell-Cafe mailing list
Haskell-Cafe@haskell.org
http://www.haskell.org/mailman/listinfo/haskell-cafe
Re: [Haskell-cafe] ANNOUNCE: antiquoter-0.1.0.0
Hi, L Corbijn wrote: I'm happy to announce the release of my first package antiquoter, a combinator library for writing quasiquoters and antiquoters. The main aim is to simplify their definitions and reduce copy-and-paste programming. Very interesting. I'm using something similar to your EP class, but yours looks more refined. See class PatOrExp in https://github.com/Toxaris/pts/blob/master/src-lib/PTS/QuasiQuote.hs I'm a bit overwhelmed by the rest of your library, though. Is the overall design explained somewhere? And: Your package description says that it is especially aimed at making user extensible antiquoters. That sounds very cool. Can you provide an example for how the antiquoter package supports extensions, and what kinds of extensions are supported? Tillmann ___ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe
Re: [Haskell-cafe] GSoC Project Proposal: Markdown support for Haddock
Yes please!
-E
On Thu, Apr 4, 2013 at 5:49 PM, Johan Tibell johan.tib...@gmail.com wrote:
Hi all,
Haddock's current markup language leaves something to be desired once
you want to write more serious documentation (e.g. several paragraphs
of introductory text at the top of the module doc). Several features
are lacking (bold text, links that render as text instead of URLs,
inline HTML).
I suggest that we implement an alternative haddock syntax that's a
superset of Markdown. It's a superset in the sense that we still want
to support linkifying Haskell identifiers, etc. Modules that want to
use the new syntax (which will probably be incompatible with the
current syntax) can set:
{-# HADDOCK Markdown #-}
on top of the source file.
Ticket: http://trac.haskell.org/haddock/ticket/244
-- Johan
___
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] GSoC Project Proposal: Markdown support for Haddock
On Thu, Apr 04, 2013 at 06:41:19PM +0100, Edsko de Vries wrote:
Yes please!
+1 as well. I find the current syntax too restrictive…
iustin
On Thu, Apr 4, 2013 at 5:49 PM, Johan Tibell johan.tib...@gmail.com wrote:
Hi all,
Haddock's current markup language leaves something to be desired once
you want to write more serious documentation (e.g. several paragraphs
of introductory text at the top of the module doc). Several features
are lacking (bold text, links that render as text instead of URLs,
inline HTML).
I suggest that we implement an alternative haddock syntax that's a
superset of Markdown. It's a superset in the sense that we still want
to support linkifying Haskell identifiers, etc. Modules that want to
use the new syntax (which will probably be incompatible with the
current syntax) can set:
{-# HADDOCK Markdown #-}
on top of the source file.
Ticket: http://trac.haskell.org/haddock/ticket/244
-- Johan
___
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 mailing list
Haskell-Cafe@haskell.org
http://www.haskell.org/mailman/listinfo/haskell-cafe
Re: [Haskell-cafe] GSoC Project Proposal: Markdown support for Haddock
On Thu, Apr 4, 2013 at 7:49 PM, Johan Tibell johan.tib...@gmail.com wrote:
Hi all,
Haddock's current markup language leaves something to be desired once
you want to write more serious documentation (e.g. several paragraphs
of introductory text at the top of the module doc). Several features
are lacking (bold text, links that render as text instead of URLs,
inline HTML).
I suggest that we implement an alternative haddock syntax that's a
superset of Markdown. It's a superset in the sense that we still want
to support linkifying Haskell identifiers, etc. Modules that want to
use the new syntax (which will probably be incompatible with the
current syntax) can set:
{-# HADDOCK Markdown #-}
on top of the source file.
Ticket: http://trac.haskell.org/haddock/ticket/244
-- Johan
___
Haskell-Cafe mailing list
Haskell-Cafe@haskell.org
http://www.haskell.org/mailman/listinfo/haskell-cafe
+1
In case it can be useful in any way for this project, my markdown
package[1] is certainly available for scavenging, though we'd likely want
to refactor it to not use conduit (I can't imagine conduit being a good
dependency for Haddock).
[1] http://hackage.haskell.org/package/markdown
___
Haskell-Cafe mailing list
Haskell-Cafe@haskell.org
http://www.haskell.org/mailman/listinfo/haskell-cafe
Re: [Haskell-cafe] GSoC Project Proposal: Markdown support for Haddock
A sane markup for haddock would be greatly appreciated. I've grown
tired of noticing highlighted words arising from unescaped quotes all
over hackage.
On Thu, 4 Apr 2013 09:49:04 -0700 Johan Tibell johan.tib...@gmail.com
wrote:
Hi all,
Haddock's current markup language leaves something to be desired once
you want to write more serious documentation (e.g. several paragraphs
of introductory text at the top of the module doc). Several features
are lacking (bold text, links that render as text instead of URLs,
inline HTML).
I suggest that we implement an alternative haddock syntax that's a
superset of Markdown. It's a superset in the sense that we still want
to support linkifying Haskell identifiers, etc. Modules that want to
use the new syntax (which will probably be incompatible with the
current syntax) can set:
{-# HADDOCK Markdown #-}
on top of the source file.
Ticket: http://trac.haskell.org/haddock/ticket/244
-- Johan
___
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] Resource Limits for Haskell
On Mon, Apr 1, 2013 at 5:56 PM, Edward Z. Yang ezy...@mit.edu wrote: http://ezyang.com/papers/ezyang13-rlimits.pdf Correct me if I'm wrong, but reading that I don't seem to see any tests against actual adversarial code - just checking that the limits kick in on a bunch of ordinary code. -- gwern http://www.gwern.net ___ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe
Re: [Haskell-cafe] [Haskell] ANN: adobe-swatch-exchange-0.1.0.0
(Redirecting follow-up to haskell-cafe) Very cool! I have been hoping someone will find a way to integrate kuler.adobe.com with diagrams, and this will help a lot. =) https://github.com/diagrams/diagrams-lib/issues/77 -Brent On Wed, Apr 03, 2013 at 06:49:34PM -0500, Jeremy Shaw wrote: I am pleased to annouce the release of adobe-swatch-exchange 0.1.0.0. My primary motivation in writing this is to make it easier to download color swatches from http://kuler.adobe.com/ and test them on my site. Though, perhaps there is already a great way of doing this and I didn't look hard enough. But, the end result is we can now read and write .ASE files in Haskell and convert them to .css. So that probably opens up some new possibilities. I have provided both a library and an executable. I have also used this as a way to test the waters with github, https://github.com/stepcut/ase2css I heard putting things on github will get me all sorts of contributors. I suggest someone start with haddock comments. ;) Cheers! - jeremy ___ Haskell mailing list hask...@haskell.org http://www.haskell.org/mailman/listinfo/haskell ___ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe
Re: [Haskell-cafe] [Haskell] ANN: adobe-swatch-exchange-0.1.0.0
On Thu, Apr 4, 2013 at 1:46 PM, Brent Yorgey byor...@seas.upenn.edu wrote: (Redirecting follow-up to haskell-cafe) Very cool! I have been hoping someone will find a way to integrate kuler.adobe.com with diagrams, and this will help a lot. =) https://github.com/diagrams/diagrams-lib/issues/77 Nice! One thing I would love to see added is a way to directly fetch the .ase files from kuler. Unfortunately, I think you have to be logged in in order to get the download option. But, we should be able to do that using one of the HTTP client libraries -- it will just require a bit of extra code to do the authentication steps. - jeremy ___ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe
Re: [Haskell-cafe] Possible GSoC project
On Thu, Apr 4, 2013 at 10:03 PM, Ketil Malde ke...@malde.org wrote: Not very much, some knowledge of string edit distance and dynamic programming would be good, but if not, it's something I can straighten out with a student in an afternoon, I think. Just a suggestion: People love quizzes and brain teasers. (Remember those google billboards?) If you could blog briefly (expository-style) about this with links to further reading, and more importantly, include challenges in the bottom-half, I bet you could get some buzz circulating. Especially if you manage those all-important bragging rights! -- Kim-Ee ___ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe
Re: [Haskell-cafe] GSoC Project Proposal: Markdown support for Haddock
I humbly suggest reStructuredText rather than Markdown, which is what
is used by the Python community for documentation. Since it's specifically
made for documentation it may be nicer. But, I don't want to spark
a format argument.
There is also the Pandoc program, which is a universal-ish markup-
language-converter, conveniently written in Haskell. Might be a place
to start for this, regardless of the language chosen:
http://www.johnmacfarlane.net/pandoc/
Simon
Excerpts from Johan Tibell's message of 2013-04-04 09:49:04 -0700:
Hi all,
Haddock's current markup language leaves something to be desired once
you want to write more serious documentation (e.g. several paragraphs
of introductory text at the top of the module doc). Several features
are lacking (bold text, links that render as text instead of URLs,
inline HTML).
I suggest that we implement an alternative haddock syntax that's a
superset of Markdown. It's a superset in the sense that we still want
to support linkifying Haskell identifiers, etc. Modules that want to
use the new syntax (which will probably be incompatible with the
current syntax) can set:
{-# HADDOCK Markdown #-}
on top of the source file.
Ticket: http://trac.haskell.org/haddock/ticket/244
-- Johan
___
Haskell-Cafe mailing list
Haskell-Cafe@haskell.org
http://www.haskell.org/mailman/listinfo/haskell-cafe
Re: [Haskell-cafe] GSoC Project Proposal: Markdown support for Haddock
On Fri, Apr 5, 2013 at 3:04 AM, Simon Heath icefo...@gmail.com wrote: I humbly suggest reStructuredText rather than Markdown, which is what is used by the Python community for documentation. Since it's specifically made for documentation it may be nicer. But, I don't want to spark a format argument. Could you say something about /why/ you make the suggestion? I, for one, would be happy to google and read links, but what's missing from that experience would be input from a fellow haskeller. In context. In real-time. On topic. -- Kim-Ee ___ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe
Re: [Haskell-cafe] GSoC Project Proposal: Markdown support for Haddock
On Thu, Apr 4, 2013 at 11:22 PM, Kim-Ee Yeoh k...@atamo.com wrote: On Fri, Apr 5, 2013 at 3:04 AM, Simon Heath icefo...@gmail.com wrote: I humbly suggest reStructuredText rather than Markdown, which is what is used by the Python community for documentation. Since it's specifically made for documentation it may be nicer. But, I don't want to spark a format argument. Could you say something about /why/ you make the suggestion? I, for one, would be happy to google and read links, but what's missing from that experience would be input from a fellow haskeller. In context. In real-time. On topic. -- Kim-Ee ___ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe I'd actually like to say that Python has great documentation traditions not just thanks to adoption of reStructuredText format, but a bit more. The greatest thing is an adoption of Sphinx [1] documentation engine. In Sphinx you write in extended (by special extensions) reStructuredText format, which is able to easily link to function definitions (with :func:`foo.bar.baz` or :class:`foo.bar.Baz`), other documents (with :doc:`other/doc`) and (most importantly) has extension called autodoc which goes and generates documentation for classes and functions automatically (by gathering it from docstrings and other things, similar to haddoc, if I'm not mistaken). My main point is that thanks to adoption of mixed documentation techinique people usually tend to keep documentation with has these properties: - it's up to date - there's (most of the time) no need to keep separate API and non-API documentation - API documentation can be easily be extended with long introduction without having to write it in source code (you can write it in document and then include autodoc) I think Haskell's documentation would greatly benefit from (possible?) adoption of something like Sphinx, but I don't think it supports Haskell currently. [1]: http://sphinx.pocoo.org ___ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe
Re: [Haskell-cafe] GSoC Project Proposal: Markdown support for Haddock
On 4 April 2013 20:49, Johan Tibell johan.tib...@gmail.com wrote: Hi all, Haddock's current markup language leaves something to be desired once you want to write more serious documentation (e.g. several paragraphs of introductory text at the top of the module doc). Several features are lacking (bold text, links that render as text instead of URLs, inline HTML). I suggest that we implement an alternative haddock syntax that's a superset of Markdown. It's a superset in the sense that we still want to support linkifying Haskell identifiers, etc. Modules that want to use the new syntax (which will probably be incompatible with the current syntax) can set: If we are going to change haddock syntax we should add ability to add math formulae to documentation. It's not currently possible and it makes documenting numeric code properly difficult. ___ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe
Re: [Haskell-cafe] Haskell is a declarative language? Let's see how easy it is to declare types of things.
On 13-04-04 01:07 AM, wren ng thornton wrote: When the quantifiers are implicit, we can rely on the unique human ability to DWIM. This is a tremendous advantage when first teaching people about mathematical concerns from a logical perspective. However, once people move beyond the basics of quantification (i.e., schemata, rank-1 polymorphism, etc), things get really hairy and this has lead to no end of quibbles in philosophy and semantics, where people seem perversely attached to ill-specified and outdated logics. On the other hand, with explicit quantification you can't rely on DWIM and must teach people all the gritty details up front--- since the application of those details is being made explicit. This is an extremely difficult task for people who are new to symbolic reasoning/manipulation in the first place. In my experience, it's better to get people fluently comfortable with symbolic manipulations before even mentioning quantifiers. I agree with most of it. I disagree with the first two sentences. With only one variable, therefore only one implicit quantifier, and even being told that this quantifier is placed outermost, it is already hairy enough. The unique human ability to DWIM (do what *I* mean) as opposed to DWYM (do what *you* mean) can be relied upon for confusion, frustration, students and teachers being at each others' throats, and needing to quibble in semantics which is WDYM (what do you mean) afterall. WDIM? (What do I mean?) In IRC channel #haskell, beginners write like the following and ask why it is a type error: f :: Bool - t f True = 'x' f False = 'y' You may think you know what's wrong, but you don't actually know until you know how to clarify to the beginners. Note: harping on the word any does not clarify, for the beginners exactly say this: Yeah, t can be *any* type, therefore *I* am making it Char. Isn't that what *any* means? The same reasoning happens in highschool and college math classes: Teacher: prove (t+2)^2 = t^2 + 4t + 4 Student: plug t=0. 2 = 2. works. Teacher: that's wrong, blah blah *any* blah blah Student: Yeah, t can be *any* number, therefore *I* am making it 0. Isn't that what *any* means? The folks in #haskell, after seeing it enough times, realize the real issue (not with the word any) and converge on this very efficient clarification: t can be chosen, but *I*, the vendor of f, the student, do not choose. *You*, the user of f, the teacher, choose. All beginners immediately understand. Later, they go on to understand higher-rank types with ease. (Identify positive and negative positions. Then, simply, user chooses what goes into the positive ones, and vendor chooses what goes into the negative ones.) The unique human ability of doing what *I*, the stduent, mean is the obstacle, not the pivot. At the basic level of single variable and rank 1, we already have to explain quantifier semantics, even if we don't display quantifier syntax. If we go implicit and do not spell it out upfront (symbolically or verbally), we force students to struggle at guessing, and then we are forced to spell it out anyway. That complexity does not decrease. And increased is the complexity of the aftermath flame war of why didn't you say it earlier? because it's obvious! no it's not! yes it is! is not! but all mathematicians find it obvious! well then I am not a mathematician and will never be! The two-person game semantics is in practice very efficient to convey; it is probably because most students have had extensive experience playing two-person games, coping with choices made by self and choices made by opponents, long before learning haskell or algebra. See also my http://www.vex.net/~trebla/weblog/any-all-some.html ___ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe
Re: [Haskell-cafe] Haskell is a declarative language? Let's see how easy it is to declare types of things.
On 5/04/2013, at 1:22 AM, Tillmann Rendel wrote:
Hi,
Richard A. O'Keefe wrote:
As I understand it, in ML, it seemed to be a clever idea to not have type
signatures at all.
Wrong. In ML, it seemed to be a clever idea not to *NEED* type signatures,
and for local definitions they are very commonly omitted.
In the ML I used, I remember that it was syntactically impossible to use type
signatures directly adjacent to a local definition.
Notice that the goal-posts just got moved far far away.
The original complaint was that ML did not allow type signatures.
Now the complaint is that it does not allow them to be
directly adjacent.
Instead, I was thaught to put something like a type signature in a comment,
approximately like this:
(* getOpt : 'a option * 'a - 'a *)
fun getOpt (SOME x, y) = x
| getOpt (NONE, y) = y
Well, that's a bit silly, isn't it?
Put getOpt in a structure where it belongs,
and the type in the signature, where the
compiler can enforce it.
A type signature that is not enforced is a type signature
you cannot trust.
But you can certainly HAVE type signatures, and for modules
('structures') it is normal to have them in the interfaces ('signatures').
In my opinion, a signature for a structure would not count as directly
adjacent. Also, while I don't know much about the history of ML, I suspect
that structures and signatures were a later addition to the core language.
The history of ML is not so hard to find out.
Structures and signatures have been part of Standard ML since the
1980s. The ML in Edinburgh LCF and Luca Cardelli's VAX ML were
significantly different languages from SML, but VAX ML at least did
have modules. The distinction between Core and Modules in old
SML documentation has to do with convenience of specification more
than anything else.
I just checked Milner, Tofte and Harper, The Definition of Standard ML, MIT
Press 1990 (available at
http://www.itu.dk/people/tofte/publ/1990sml/1990sml.html),
That's the old out-of-date edition. The current version of the language is
SML'97. However, this much is the same:
- there are declarations that provide *interfaces* (grammatical category
spec -- see page 13), which may occur in signatures
- and declarations that provide *values* (grammatical category dec --
see page 8), which may occur in structures, at top level, and elsewhere
So it is definitely true that, by design, SML type signatures (strictly
speaking, valdescs) are segregated from SML function definitions
(valbinds or fvalbinds).
This is pretty much a consequence of SML having a very expressive module
system in which modules _have_ signatures.
and learned that we can have explicit type annotations for both patterns and
expressions, so the following variants of the above are possible in Standard
ML:
1. We can embed parts of the signature into the definition:
fun getOpt (SOME (x : 'a), y : 'a) : 'a = x
| getOpt (NONE, y : 'a) : 'a = y
Perhaps better:
fun get_opt (SOME x, _) = x
| get_opt (NONE, y) = y
val getOpt : 'a option * 'a - 'a = get_opt
which can be written
local
fun getOpt(SOME x, _) = x
| getOpt(NONE, y) = y
in
val getOpt: 'a option * 'a - 'a = getOpt
end
With decomposing the type signature into its parts, and then duplicating
these parts, this is not very attractive.
This is a sure sign that you are NOT using the language the way it was intended
to be used, and maybe it isn't the language that's wrong.
2. We can do better by avoiding the derived form for function bindings:
val getOpt : 'a option * 'a - 'a
= fn (SOME x, y) = x
| (NONE, y) = y
This looks ok to me, and I wonder why I was not thaught this style,
Because it is atrociously ugly.
(Aside.) val here should be val rec in general. (End Aside).
ML is designed to have type specifications for functions *inside signatures*.
Since functions are supposed to be declared inside structures,
and structures are supposed to *have* signatures,
it would be rather silly to write function type specifications twice.
So ML is *not* designed to encourage you to do that.
___
Haskell-Cafe mailing list
Haskell-Cafe@haskell.org
http://www.haskell.org/mailman/listinfo/haskell-cafe
Re: [Haskell-cafe] GSoC Project Proposal: Markdown support for Haddock
On Thu, Apr 4, 2013 at 9:49 AM, Johan Tibell johan.tib...@gmail.com wrote:
I suggest that we implement an alternative haddock syntax that's a
superset of Markdown. It's a superset in the sense that we still want
to support linkifying Haskell identifiers, etc. Modules that want to
use the new syntax (which will probably be incompatible with the
current syntax) can set:
{-# HADDOCK Markdown #-}
Let me briefly argue for why I suggested Markdown instead of the many
other markup languages out there.
Markdown has won. Look at all the big programming sites out there,
from GitHub to StackOverflow, they all use a superset of Markdown. It
did so mostly (in my opinion) because it codified the formatting style
people were already using in emails and because it was pragmatic
enough to include HTML as an escape hatch.
-- Johan
___
Haskell-Cafe mailing list
Haskell-Cafe@haskell.org
http://www.haskell.org/mailman/listinfo/haskell-cafe
[Haskell-cafe] Functional Programming Internship @ Intel
[I'm posting on behalf of my colleague Jesse Bingham. While Jesse and I work for different groups at Intel, we collaborate quite often, and I do expect to work with the intern to an extent as well. To that end, I'm happy to answer any questions you might have. Otherwise, direct all correspondence to Jesse as indicated below. -Levent.] = Hi, we are looking to hire an intern to fill the below position. If interested, please send your resume to jesse.d.bing...@intel.com. Thanks Intern SW Engr. Formal Verification - 708053 Description Design and Technology Solutions (DTS) creates the software that caters to Intel's insatiable appetite for innovating silicon technology. Through our CAD solutions and engineering services, we enable Intel's process engineers to achieve the technical breakthroughs required to deliver tomorrows technology, and we help Intel's architects and chip designers develop products that change the world. To us, Moore's law is the imperative that drives our work to continuously improve the ways we explore technology options, so we can deliver better products, faster. As a software engineer in DTS, you will work as part of a multi-disciplinary team to create software tools that meet Intel's specific, rapidly evolving requirements for designing, manufacturing, testing, and packaging silicon products. We work very closely with process engineers and chip designers (our internal customers) around the world, to understand their technical challenges, and to create proprietary CAD solutions. We help them apply our software to answer critical questions, and to address their design and manufacturing objectives. The daily work in DTS spans the complete software life cycle, from early research to mature production code with industrial robustness and quality. To deliver critical new features in our established solutions, or to create new CAD capabilities beyond the state of art in the industry, our teams frequently go through all steps in software development - problem analysis, requirements definition, design, coding, test, and deployment. As a member of our team, you are expected to participate actively in all these steps. Success in this fast-paced, results-oriented environment requires strong analytical skills and the ability to perform productive teamwork, which depends on very good communication skills. In this particular job opening, you will join DTS's Formal Verification Center of Expertise (FVCoE) for a three month placement in Hillsboro, Oregon, in the timeframe of fall 2013. A primary responsibility of FVCoE is the maintenance of a large code base used for formal verification of Intel's core datapath designs; you will help rework several key aspects of this code to make it more robust and user-friendly. This will involve strict software engineering discipline to deliver robust, quality code that must perform reliably and predictably, The code is written in an in-house functional language called reflect. Reflect is similar to the popular functional languages Ocaml and Haskell; hence you should have considerable experience with one of these. Experience with formal verification is preferred but not necessarily required. Applicants will ideally be working towards a graduate degree in Computer Science or a related discipline. Qualifications Minimum Requirements Skills: Functional programming coding skills; experience with one or more scripting languages; analytical skills for problem abstraction; broad theoretical knowledge in computer science, including algorithms and data structures; familiarity with standard software engineering practices. Experience: acquired through coursework, internships, or personal projects. Experience in applied computer programming in a functional language. Education: working toward an MS or Ph.D. degree in Computer Science, Applied Mathematics, or in an Engineering field related to silicon technology. Strong senior undergraduates will also be considered. Preferred Requirements Skills: Familiarity with: hardware formal verification techniques (especially symbolic simulation, binary decision diagrams, parametric substitutions, case splitting), arithmetic/floating point computer hardware designs, IEEE 754 floating point standard, Intel x86 instruction set. ___ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe
Re: [Haskell-cafe] GSoC Project Proposal: Markdown support for Haddock
Johan Tibell johan.tib...@gmail.com writes:
On Thu, Apr 4, 2013 at 9:49 AM, Johan Tibell johan.tib...@gmail.com wrote:
I suggest that we implement an alternative haddock syntax that's a
superset of Markdown. It's a superset in the sense that we still want
to support linkifying Haskell identifiers, etc. Modules that want to
use the new syntax (which will probably be incompatible with the
current syntax) can set:
{-# HADDOCK Markdown #-}
Let me briefly argue for why I suggested Markdown instead of the many
other markup languages out there.
Markdown has won. Look at all the big programming sites out there,
from GitHub to StackOverflow, they all use a superset of Markdown. It
did so mostly (in my opinion) because it codified the formatting style
people were already using in emails and because it was pragmatic
enough to include HTML as an escape hatch.
For what it's worth, I think Markdown is a fine choice for very much the
same reason. RST has some nice properties (especially for documenting
Python), but Markdown is much more common. Moreover, I've always found
RST's linkification syntax a bit awkward.
Cheers,
- Ben
___
Haskell-Cafe mailing list
Haskell-Cafe@haskell.org
http://www.haskell.org/mailman/listinfo/haskell-cafe
[Haskell-cafe] Haskell and WinRT
There was a short thread on this in the beginners section a while back. I think it is an exciting subject and would like to hear what others thoughts are on it. The Windows 8 metro style apps are built using a new API that is designed to be exposed to other languages using language projections which are a thin wrapper around the windows runtime. Microsoft has provided these for C#, C++, Javascript HTML and is encouraging language developers to create them for other languages. This seems like it might be the easiest rout to getting Haskell apps on tablets etc. with a modern UI. Simon Marlow discusses it briefly on this https://plus.google.com/107890464054636586545/posts/PuFPongpyR4 page and there is a video on the topic here http://channel9.msdn.com/Events/Lang-NEXT/Lang-NEXT-2012/The-Windows-Runtime . Might even be a good summer of code project for someone. -- View this message in context: http://haskell.1045720.n5.nabble.com/Haskell-and-WinRT-tp5728106.html Sent from the Haskell - Haskell-Cafe mailing list archive at Nabble.com. ___ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe
Re: [Haskell-cafe] GSoC Project Proposal: Markdown support for Haddock
On 5/04/2013, at 12:34 PM, Johan Tibell wrote: Markdown has won. Look at all the big programming sites out there, from GitHub to StackOverflow, they all use a superset of Markdown. Yes, but they tend to use _different_ supersets of Markdown. Would it be too much to ask that a notation be used which has a formal syntax and a formal semantics? I mean, this *is* Haskell we're talking about, not some slapped-together who-cares-if-a-primary-buffer-panel-falls-off FireflyXXX dynamic programming language. ___ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe
Re: [Haskell-cafe] GSoC Project Proposal: Markdown support for Haddock
Would it be too much to ask that a notation be used which has a formal syntax and a formal semantics? We will document our superset, sure. That's what others did as well. The point is using Markdown as the shared base. ___ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe
Re: [Haskell-cafe] Haskell is a declarative language? Let's see how easy it is to declare types of things.
On Thu, Apr 4, 2013 at 3:29 PM, Albert Y. C. Lai tre...@vex.net wrote: On 13-04-04 01:07 AM, wren ng thornton wrote: When the quantifiers are implicit, we can rely on the unique human ability to DWIM. This is a tremendous advantage when first teaching people about mathematical concerns from a logical perspective. However, once people move beyond the basics of quantification (i.e., schemata, rank-1 polymorphism, etc), things get really hairy and this has lead to no end of quibbles in philosophy and semantics, where people seem perversely attached to ill-specified and outdated logics. On the other hand, with explicit quantification you can't rely on DWIM and must teach people all the gritty details up front--- since the application of those details is being made explicit. This is an extremely difficult task for people who are new to symbolic reasoning/manipulation in the first place. In my experience, it's better to get people fluently comfortable with symbolic manipulations before even mentioning quantifiers. I agree with most of it. I disagree with the first two sentences. With only one variable, therefore only one implicit quantifier, and even being told that this quantifier is placed outermost, it is already hairy enough. The unique human ability to DWIM (do what *I* mean) as opposed to DWYM (do what *you* mean) can be relied upon for confusion, frustration, students and teachers being at each others' throats, and needing to quibble in semantics which is WDYM (what do you mean) afterall. Students need to learn to do what the professor means. That is what they are paying for. Let me tell you a short story about the first college math class I ever took. It was a course in introductory analysis, where we started by constructing the natural numbers, and slowly introducing the field axioms, and finally constructing R and C. Well, sometime during the first week, we encountered 0, a symbol I had obviously seen before. And I used some properties I knew about zero in a proof. My professor called me into his office, and told me to treat the circular thing he was talking about in class as, essentially, a symbol whose semantics we are /determining/ in terms of the axioms introduced. This is the very paradigm of semantic quibbling -- what does 0 MEAN? It depends! And not just on the axioms in play, but also on the community of language speakers/math doers, and the contexts in which they are discussing a problem. (Indeed, a week later, I had proved enough about the symbol 0 that it /BECAME/ the zero I knew and loved in high school. In IRC channel #haskell, beginners write like the following and ask why it is a type error: f :: Bool - t f True = 'x' f False = 'y' You may think you know what's wrong, but you don't actually know until you know how to clarify to the beginners. Note: harping on the word any does not clarify, for the beginners exactly say this: Yeah, t can be *any* type, therefore *I* am making it Char. Isn't that what *any* means? Indeed. And this confusion would continue to exist if the quantifier was made explicit. Notice that the confusion is about what any means, and not what upside-down A means, or what a missing upside-down A means. ___ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe
Re: [Haskell-cafe] GSoC Project Proposal: Markdown support for Haddock
+++ Simon Heath [Apr 04 13 13:04 ]: I humbly suggest reStructuredText rather than Markdown, which is what is used by the Python community for documentation. Since it's specifically made for documentation it may be nicer. But, I don't want to spark a format argument. There is also the Pandoc program, which is a universal-ish markup- language-converter, conveniently written in Haskell. Might be a place to start for this, regardless of the language chosen: http://www.johnmacfarlane.net/pandoc/ Simon (Pandoc author here.) It probably wouldn't make sense for a key infrastructure component like Haddock to depend on a behemoth like pandoc. But I could help out with a markdown-superset parser if needed. I have an experimental thing here that could be used as a basis (it's 7x faster than pandoc and uses 1/5 the memory, BSD licensed): https://github.com/jgm/Markdown Another idea: If someone contributed a Haddock markup writer to pandoc, then documentation could be written in markdown (or RST or whatever) and converted automatically to standard Haddock markup. David Lazar has recently contributed a Haddock markup reader, but there is no writer. Note: Creating a writer would be a bit tricky, because Haddock markup isn't expressive enough for many of the constructions pandoc allows -- for example, if I'm not mistaken, you can't have multiple paragraphs inside list items. Decisions would have to be made about how to deal with such cases. There are also a few Haddock constructions that don't correspond to anything in pandoc. John ___ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe
Re: [Haskell-cafe] GSoC Project Proposal: Markdown support for Haddock
On 5/04/2013, at 2:00 PM, Johan Tibell wrote: Would it be too much to ask that a notation be used which has a formal syntax and a formal semantics? We will document our superset, sure. That's what others did as well. The point is using Markdown as the shared base. Nononono. Sure, the others documented their supersets. But they did *NOT* provide what I am asking for: - a FORMAL SYNTAX and - a FORMAL SEMANTICS. I tried to use one of these systems, and found myself unable to determine which combinations of features were legal and what legal combinations of features *meant*. I corresponded with some people who had built markdown parsers, and the answer was the same each time: they had reversed engineered some other parser (typically a Perl one) and bashed on it until they were bug-compatible. If I want to get a particular effect in LaTeX or even in HTML+CSS, I can usually figure it out *without* having to run any program. If I want to get a particular effect in Markdown, I flounder around and end up doing without. I am sick of documentation that vaguely hints at things, and I am especially sick of Markdown so-called documentation. To say it one more time: I was unable to use the official Markdown documentation, http://daringfireball.net/projects/markdown/syntax, to guide the construction of a parser. For example, br is a valid URL enclosed in . . ., so is it a link, as the Automatic Links section would suggest, or is it embedded HTML, as the Inline HTML section would suggest? Can you tell *from the documentation*? For another example, is *foo**bar**ugh* supposed to map to emfoostrongbar/strongugh/em or to emfoo/emembar/ememugh/em? Again, I'm not asking what does this or that *program* do, I'm asking can you tell from the documentation what they *ought* to do? If there is an unambiguous specification of Markdown somewhere (specification; not program), I would be glad to see it. ___ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe
Re: [Haskell-cafe] GSoC Project Proposal: Markdown support for Haddock
On 5 April 2013 13:24, Richard A. O'Keefe o...@cs.otago.ac.nz wrote: On 5/04/2013, at 2:00 PM, Johan Tibell wrote: Would it be too much to ask that a notation be used which has a formal syntax and a formal semantics? We will document our superset, sure. That's what others did as well. The point is using Markdown as the shared base. Nononono. Sure, the others documented their supersets. But they did *NOT* provide what I am asking for: - a FORMAL SYNTAX and - a FORMAL SEMANTICS. I tried to use one of these systems, and found myself unable to determine which combinations of features were legal and what legal combinations of features *meant*. I corresponded with some people who had built markdown parsers, and the answer was the same each time: they had reversed engineered some other parser (typically a Perl one) and bashed on it until they were bug-compatible. If I want to get a particular effect in LaTeX or even in HTML+CSS, I can usually figure it out *without* having to run any program. If I want to get a particular effect in Markdown, I flounder around and end up doing without. I am sick of documentation that vaguely hints at things, and I am especially sick of Markdown so-called documentation. To say it one more time: I was unable to use the official Markdown documentation, http://daringfireball.net/projects/markdown/syntax, to guide the construction of a parser. For example, br is a valid URL enclosed in . . ., so is it a link, as the Automatic Links section would suggest, or is it embedded HTML, as the Inline HTML section would suggest? Can you tell *from the documentation*? For another example, is *foo**bar**ugh* supposed to map to emfoostrongbar/strongugh/em or to emfoo/emembar/ememugh/em? Again, I'm not asking what does this or that *program* do, I'm asking can you tell from the documentation what they *ought* to do? If there is an unambiguous specification of Markdown somewhere (specification; not program), I would be glad to see it. I don't think so; this was one of the big issues recently when people were trying to get Gruber to actually _do_ something with Markdown as there were all these corner cases. ___ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe -- Ivan Lazar Miljenovic ivan.miljeno...@gmail.com http://IvanMiljenovic.wordpress.com ___ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe
Re: [Haskell-cafe] GSoC Project Proposal: Markdown support for Haddock
On Fri, Apr 5, 2013 at 10:44 AM, Ivan Lazar Miljenovic ivan.miljeno...@gmail.com wrote: I don't think so; this was one of the big issues recently when people were trying to get Gruber to actually _do_ something with Markdown as there were all these corner cases. In that case, surely this is an opportunity to convene a committee (a la H98) to craft a formal spec? -- Kim-Ee ___ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe
Re: [Haskell-cafe] GSoC Project Proposal: Markdown support for Haddock
On 5 April 2013 15:49, Kim-Ee Yeoh k...@atamo.com wrote: On Fri, Apr 5, 2013 at 10:44 AM, Ivan Lazar Miljenovic ivan.miljeno...@gmail.com wrote: I don't think so; this was one of the big issues recently when people were trying to get Gruber to actually _do_ something with Markdown as there were all these corner cases. In that case, surely this is an opportunity to convene a committee (a la H98) to craft a formal spec? There have been calls for such a committee: http://www.codinghorror.com/blog/2012/10/the-future-of-markdown.html -- Kim-Ee -- Ivan Lazar Miljenovic ivan.miljeno...@gmail.com http://IvanMiljenovic.wordpress.com ___ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe
Re: [Haskell-cafe] Haskell is a declarative language? Let's see how easy it is to declare types of things.
(Folks, let's rescue this increasingly tendentious thread.) Some points to ponder: (1) Any can be often be clarified to mean all, depending on how polymorphic functions are exegeted. In a homotopy-flavored explanation of natural transformation, its components (read parametric instances) exist /all at once/ like the collinear rays of a rainbow. So given this: f :: Bool - t f True = 'x' f False = 'y' nope, no rainbow. :( ... the aftermath flame war of why didn't you say it earlier? because it's obvious! no it's not! yes it is! is not! but all mathematicians find it obvious! well then I am not a mathematician and will never be! And more to the point, an excellent learning environment requires empathy from all participants, juniors and seniors alike. Where diversity is celebrated as a source of new ideas and new ways to explain old ones. And where the coupling between the two is as gut-obvious as day and night. (2) prove or disprove: for all e0, there exists d0, if 0bad, then (a-b)/sqrt(b) e I grant you that clearly the implicit quantifiers for a and b are for all. The unclear part is where to put them. There are essentially 4 choices That's a stretch. It's all in the context, and here it's clearly a continuity verification exercise from freshman calculus. Unless being deliberately obtuse, one has no excuse not inferring where the quantifiers go if one knows about a theorem prover, what more wielding one to nuke this gnat of a proof. Moreover, if we grant the imaginary student the rudiments of logic, 3 of the 4 choices render the statement vacuously true. Almost. Set d to deny the antecedent, QED. I partly agree with Albert's main point, notwithstanding his choice of examples, that the absence of explicit quantifiers can lead to confusion. It all depends. On the other hand Alexander Solla is also on the money with his remark. A mathematician writes [1], In particular, any given assertion in hard analysis usually comes with a number of unsightly quantifiers (For every there exists an N…) which can require some thought for a reader to parse. (3) Newspaper headline: Someone gets hit by a car every 6 seconds. A few months ago, a good chunk of Devlin's Intro to Math Thinking massive online course devoted itself to explicit and precise placement of quantifiers. So not only is the above headline judged improperly worded and hence badly ambiguous, but also commonplaces like In case of fire do not use elevator. I'm a fervent believer against ambiguity: Let zealotry take its place. [1] http://terrytao.wordpress.com/2007/06/25/ultrafilters-nonstandard-analysis-and-epsilon-management/ -- Kim-Ee ___ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe
