[Haskell-cafe] (no subject)
Hi all, Haskell, is arguably the best example of a design-by-committee language. The syntax is clean and most importantly, consistent. The essence of a purely functional programming is maintained, without disturbing its real world capacity. To all the people who revise the Haskell standard, and implement the language, 1. Promise to me, and the rest of the community, that you will keep up the good effort :) 2. Promise to me, and the rest of the community, that Haskell will always spiritually remain the same clean, consistent programming language as it is now! Regards, Zed Becker ___ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe
Re: [Haskell-cafe] (no subject)
On Mon, Jun 10, 2013 at 05:41:05PM +0530, Zed Becker wrote: Haskell, is arguably the best example of a design-by-committee language. You do realize that design-by-committee is generally understood to refer to the antipattern where a committee discusses a design to death and delivers an inconsistent, mediocre spec, as opposed to a situation where a leader figure takes the loose ends, runs with them, and turns them into a coherent, inspiring whole? ___ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe
Re: [Haskell-cafe] (no subject)
On Mon, Jun 10, 2013 at 05:41:05PM +0530, Zed Becker wrote: Haskell, is arguably the best example of a design-by-committee language. The syntax is clean and most importantly, consistent. The essence of a purely functional programming is maintained, without disturbing its real world capacity. To all the people who revise the Haskell standard, and implement the language, 1. Promise to me, and the rest of the community, that you will keep up the good effort :) 2. Promise to me, and the rest of the community, that Haskell will always spiritually remain the same clean, consistent programming language as it is now! Hear hear! Hopefully we, the Haskell community, will be able to support this endevour with our time and efforts. Tom ___ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe
Re: [Haskell-cafe] (no subject)
Zed, while I don't disagree regarding the clean and consistent syntax of Haskell, do you realize that some people would argue that camels are horses designed by committee too? :) While designing by committee guarantees agreement across a large number of people, it does not always ensure efficiency, as committees may lead to poor compromises, sometimes. However, Haskell may be an example of a good case of design-by-committee computer language. Flavio Flavio Villanustre On Mon, Jun 10, 2013 at 8:11 AM, Zed Becker zed.bec...@gmail.com wrote: Hi all, Haskell, is arguably the best example of a design-by-committee language. The syntax is clean and most importantly, consistent. The essence of a purely functional programming is maintained, without disturbing its real world capacity. To all the people who revise the Haskell standard, and implement the language, 1. Promise to me, and the rest of the community, that you will keep up the good effort :) 2. Promise to me, and the rest of the community, that Haskell will always spiritually remain the same clean, consistent programming language as it is now! Regards, Zed Becker ___ 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] (no subject)
Hm... Haskell was /developed/ by teams, but we had BEFORE: hope, miranda, ML ... The heritage is quite important. And individuals (say, Mark Jones) contributed to Haskell constructs. So, the /design/ is not entirely committe based 1. Promise to me, and the rest of the community, that Haskell will always spiritually remain the same clean, consistent programming language as it is now! Yes. Dear Mom, dear Dad! Promise me that you will never die... I wish that for all of you. Jerzy Karczmarczuk ___ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe
Re: [Haskell-cafe] Non-deterministic behaviour of aeson's parser
It's definitely hashable. Here's a minimal failing test case: https://gist.github.com/gregorycollins/5748445 On Sat, May 18, 2013 at 11:38 PM, Roman Cheplyaka r...@ro-che.info wrote: Indeed it looks like a bug in hashable — it goes away with hashable-1.1.2.5. Building with -f-sse2 results in a linker error Loading package hashable-1.2.0.7 ... linking ... ghc: /home/feuerbach/tmp/aeson/.cabal-sandbox/lib/i386-linux-ghc-7.6.3/hashable-1.2.0.7/libHShashable-1.2.0.7.a: unknown symbol `hashable_siphash24_sse2' ghc: unable to load package `hashable-1.2.0.7' Roman * Gregory Collins g...@gregorycollins.net [2013-05-18 22:19:38+0200] First off, everyone reporting results to this thread: your bug report would be much more helpful if you included your OS/architecture/GHC version combo, as well as the results of re-running the tests if you build hashable with cabal install -f-sse2. I have a funny feeling that this is a bug in hashable or unordered-containers. I'm guessing hashable, especially because of this: https://github.com/tibbe/hashable/issues/66 and because hashable has had subtle bugs in its C code before (see https://github.com/tibbe/hashable/issues/60). G On Sat, May 18, 2013 at 6:25 PM, Roman Cheplyaka r...@ro-che.info wrote: I am observing a non-deterministic behaviour of aeson's parser. I'm writing here in addition to filing a bug report [1] to draw attention to this (pretty scary) problem. To try to reproduce this problem, do this: git clone https://gist.github.com/5604887.git aeson cd aeson ghc aeson.hs ./aeson | sort | uniq -c This is my result: 32 Left key \module\ not present 55 Left When parsing the record SymValue of type Main.SymValueInfo the key fixity was not present. 1913 Right () Can others reproduce this in their environments? Does anyone have ideas about where the bug may lie? Many aeson's dependencies do unsafe IO stuff that could lead to such consequences. Roman [1]: https://github.com/bos/aeson/issues/125 ___ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe -- Gregory Collins g...@gregorycollins.net -- Gregory Collins g...@gregorycollins.net ___ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe
[Haskell-cafe] Only vaporware needs promises
Tom Ellis tom-lists-haskell-cafe-2...@jaguarpaw.co.uk wrote: Hear hear! Hopefully we, the Haskell community, will be able to support this endevour with our time and efforts. Every Haskell user does this in their own way by use, feedback, uploads to Hackage, authoring wiki articles or blog articles or simply by helping people. The Haskell community has a huge momentum right now and the language is developed by smart people. What does /not/ help is a thread like this. If you want to support the development of Haskell, don't unsafeCoerce people into making useless promises. Instead grab your web browser, text editor or whiteboard and do your part! Greets, Ertugrul -- Not to be or to be and (not to be or to be and (not to be or to be and (not to be or to be and ... that is the list monad. signature.asc Description: PGP signature ___ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe
Re: [Haskell-cafe] Only vaporware needs promises
On Mon, Jun 10, 2013 at 03:21:28PM +0200, Ertugrul Söylemez wrote: Tom Ellis tom-lists-haskell-cafe-2...@jaguarpaw.co.uk wrote: Hear hear! Hopefully we, the Haskell community, will be able to support this endevour with our time and efforts. Every Haskell user does this in their own way by use, feedback, uploads to Hackage, authoring wiki articles or blog articles or simply by helping people. The Haskell community has a huge momentum right now and the language is developed by smart people. What does /not/ help is a thread like this. If you want to support the development of Haskell, don't unsafeCoerce people into making useless promises. Instead grab your web browser, text editor or whiteboard and do your part! Indeed Ertugul, that's exactly what I mean. Tom ___ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe
Re: [Haskell-cafe] (no subject)
It really sounds rude, to demand promises from somebody who just gave you a big present. Отправлено с iPhone 10.06.2013, в 16:11, Zed Becker zed.bec...@gmail.com написал(а): Hi all, Haskell, is arguably the best example of a design-by-committee language. The syntax is clean and most importantly, consistent. The essence of a purely functional programming is maintained, without disturbing its real world capacity. To all the people who revise the Haskell standard, and implement the language, Promise to me, and the rest of the community, that you will keep up the good effort :) Promise to me, and the rest of the community, that Haskell will always spiritually remain the same clean, consistent programming language as it is now! Regards, Zed Becker ___ 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] (no subject)
On Mon, Jun 10, 2013 at 05:44:26PM +0400, MigMit wrote: It really sounds rude, to demand promises from somebody who just gave you a big present. Without wishing to preempt Zed Becker, I interpreted his email as an expression of delight at how well Haskell has been designed and of hope that it may endure, rather than literally as a demand for the Haskell committee to grant him promises. I hope I haven't misunderstood. Tom ___ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe
Re: [Haskell-cafe] (no subject)
I have ever wondered how a committee could have made Haskell. My conclusion is the following: For one side there were many mathematicians involved, the authors of the most terse language(s) existent: the math notation. For the other, the lemma avoid success at all costs which kept the committee away of pressures for doing it quick and dirty and also freed it from deleterious individualities 2013/6/10 Tobias Dammers tdamm...@gmail.com On Mon, Jun 10, 2013 at 05:41:05PM +0530, Zed Becker wrote: Haskell, is arguably the best example of a design-by-committee language. You do realize that design-by-committee is generally understood to refer to the antipattern where a committee discusses a design to death and delivers an inconsistent, mediocre spec, as opposed to a situation where a leader figure takes the loose ends, runs with them, and turns them into a coherent, inspiring whole? ___ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe -- Alberto. ___ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe
[Haskell-cafe] Workshop on Generic Programming, Second CFP
== CALL FOR PAPERS WGP 2013 9th ACM SIGPLAN Workshop on Generic Programming Boston, Massachusetts, USA Saturday, September 29th, 2013 http://www.wgp-sigplan.org/2013 Co-located with the International Conference on Functional Programming (ICFP 2013) == Goals of the workshop - Generic programming is about making programs more adaptable by making them more general. Generic programs often embody non-traditional kinds of polymorphism; ordinary programs are obtained from them by suitably instantiating their parameters. In contrast with normal programs, the parameters of a generic program are often quite rich in structure; for example they may be other programs, types or type constructors, class hierarchies, or even programming paradigms. Generic programming techniques have always been of interest, both to practitioners and to theoreticians, and, for at least 20 years, generic programming techniques have been a specific focus of research in the functional and object-oriented programming communities. Generic programming has gradually spread to more and more mainstream languages, and today is widely used in industry. This workshop brings together leading researchers and practitioners in generic programming from around the world, and features papers capturing the state of the art in this important area. We welcome contributions on all aspects, theoretical as well as practical, of * generic programming, * programming with (C++) concepts, * meta-programming, * programming with type classes, * programming with modules, * programming with dependent types, * type systems for generic programming, * polytypic programming, * adaptive object-oriented programming, * component-based programming, * strategic programming, * aspect-oriented programming, * family polymorphism, * object-oriented generic programming, * implementation of generic programming languages, * static and dynamic analyses of generic programs, * and so on. Program Committee - Jeremiah Willcock (co-chair), Indiana University Jacques Carette (co-chair), McMaster University Florian Rabe, Jacobs University Bremen Emilie Balland, INRIA Bordeaux Jeremy Siek, University of Colorado, Boulder Gabriel Dos Reis, Texas AM University Christophe Raffalli, Savoie University Anya Helene Bagge, Universitetet i Bergen Tiark Rompf, Ecole Polytechnique Federale de Lausanne Andreas Abel, Ludwig-Maximilians-Universitat Munchen Edward Kmett, SP Capital IQ William Cook, University of Texas, Austin Proceedings and Copyright - We plan to have formal proceedings, published by the ACM. Authors must transfer copyright to ACM upon acceptance (for government work, to the extent transferable), but retain various rights (http://www.acm.org/publications/policies/copyright_policy). Authors are encouraged to publish auxiliary material with their paper (source code, test data, etc.); they retain copyright of auxiliary material. Submission details -- Deadline for submission: Friday2013-06-14 Notification of acceptance: Wednesday 2013-07-11 Final submission due:Tuesday 2013-07-25 Workshop:Sunday2013-09-28 Papers should be submitted via EasyChair at https://www.easychair.org/conferences/?conf=wgp2013 Submitted papers should be in portable document format (PDF), formatted using the ACM SIGPLAN style guidelines (two-column, 9pt). The length is restricted to 12 pages. Travel Support -- Student attendees with accepted papers can apply for a SIGPLAN PAC grant to help cover travel expenses. PAC also offers other support, such as for child-care expenses during the meeting or for travel costs for companions of SIGPLAN members with physical disabilities, as well as for travel from locations outside of North America and Europe. For details on the PAC program, see its web page (http://www.sigplan.org/PAC.htm). History of the Workshop on Generic Programming -- Earlier Workshops on Generic Programming have been held in * Copenhagen, Denmark 2012 (affiliated with ICFP12), * Tokyo, Japan 2011 (affiliated with ICFP11), * Baltimore, Maryland, US 2010 (affiliated with ICFP10), * Edinburgh, UK 2009 (affiliated with ICFP09), * Victoria, BC, Canada 2008 (affiliated with ICFP), * Portland 2006 (affiliated with ICFP), * Ponte de Lima 2000 (affiliated with MPC), * Marstrand 1998 (affiliated with MPC). Furthermore, there were a few informal workshops * Utrecht 2005 (informal workshop), * Dagstuhl 2002 (IFIP WG2.1 Working Conference), *
Re: [Haskell-cafe] [Hackathon] ANN: ZuriHac 2013 FP Afternoon with keynote by Simon Marlow
On 10 June 2013 19:38, Roman Cheplyaka r...@ro-che.info wrote: Hi Bas, When: Thursday 30 August - Friday 1 September Where: Erudify offices, Zurich, Switzerland Is this a mistake? 30 August is Friday, 1 September is Sunday. Oops! You're right, that's embarrassing :-) Thanks, Bas ___ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe
Re: [Haskell-cafe] [Hackathon] ANN: ZuriHac 2013 FP Afternoon with keynote by Simon Marlow
Yes I'm really hoping Zurihac is on the weekend so I can actually come :) :) G On Mon, Jun 10, 2013 at 9:36 PM, Bas van Dijk v.dijk@gmail.com wrote: On 10 June 2013 19:38, Roman Cheplyaka r...@ro-che.info wrote: Hi Bas, When: Thursday 30 August - Friday 1 September Where: Erudify offices, Zurich, Switzerland Is this a mistake? 30 August is Friday, 1 September is Sunday. Oops! You're right, that's embarrassing :-) Thanks, Bas ___ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe -- Gregory Collins g...@gregorycollins.net ___ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe
Re: [Haskell-cafe] writing a function to make a correspondance between type-level integers and value-level integers
Richard Eisenberg wrote: without ScopedTypeVariables, the n that you would put on your annotation is totally unrelated to the n in the instance header, but this is benign becau se GHC can infer the type anyway. With ScopedTypeVariables, the `n`s are the same, which luckily agrees with GHC's reasoning, so it's all OK. Thanks Richard, it is perfectly clear. There are two good reasons: 1) You are suggesting that GHC do the following analysis: - There is an instance for MkSNat Zero. - Given an instance for MkSNat n, we know there is an instance for MkSNat (Succ n). - Thus, there is an instance for every (n :: Nat). This is precisely the definition of mathematical induction. GHC does not do induction. This could, theoretically, be fixed, though, which brings us to reason #2: Ok, I imagine there is no general need for induction in GHC, otherwise it would already be implemented. 2) Class constraints are *runtime* things. This piece was a complete [...] In effect, when you put the MkSNat o constraint on your instance, you are saying that we must know the value of o at *runtime*. This makes great sense now, because we really do need to know that data at runtime, in order to print the value correctly. Thinking of dictionaries, the dictionary for Show for Tensors will contain a pointer to the correct dictionary for MkSNat, which, in turn, encodes the value of o. In a very real way, MkSNat and SNat are *the same data structure*. MkSNats are implicit and SNats are explicit, but otherwise, they contain exactly the same data and have exactly the same structure. Type erasure is a very interesting thing I did not know. But I am not sure to understand correctly the fact that class constraints are runtime things and why (I know C so I know what is a pointer, but I would need to go into the details). Anyway, if it is clear that GHC does not induction, then I can accept without problem that I am compelled to indicate the class constraint `MkSNat o =` to GHC, such that the call of mkSNat on a value `P` of type `Proxy o` is correct from a type point of view - I imagine this is the way most people in Haskell community think about class constraints (?). Though I promised myself I wouldn't post about it again on this list, it's too germane to the discussion not to: You may be interested in the paper I co-wrote last year on singletons and their implementation in GHC. You can find the paper here: http://www.cis.upenn.edu/~eir/papers/2012/singletons/paper.pdf A lot of the issues that you're asking about are discussed there. And, in MkSNat, you've already reinvented some of what's in there (I called MkSNat SingI, because it Introducces a singleton). I have read the beginning of the paper: very interesting. In particular the inequality at type level may be interesting for what I have to code. I will try to go on in the next days. In fact I already read about this possibility last month, but I stopped rapidly because I found this: http://hackage.haskell.org/trac/ghc/ticket/4385 http://hackage.haskell.org/trac/ghc/attachment/ticket/4385/Ticket.hs The answer of diatchki is not so hopeful, this suggests that there is a limit to computations at type-level. In my home project, I could code everything with a simple constructor of type `Tensor` (not `Tensor order`) and runtime checks, but encoding information in types makes certainly the code shorter (even if more difficult to read for many people) and safer, perhaps quicker if the runtime checks take time (I have heard from a colleague that the runtime checks of size when indexing a vector, case with which you deal at the beginning of your paper, took a lot of time in one of his C++ program - it is interesting to see how you dealt with this problem). It is a lot of efforts for me to learn all these advanced Haskell techniques that are not in textbooks, but I feel it is important: I try to summarize all what I learn in a LyX file. My hope is at the end to be able to code clean and efficient code in real programs, instead of script-like Python code with so many errors at runtime (this is what I do at work these days in a scientific computing company). I think also that for serious programs (say, order of magnitude 10^4 lines), it is necessary to have types (I would not use Haskell for a small script, of course). I feel also, from my coding experience, that states are a real problem in traditional C/C++/Python/... code, and I want to give a try with Haskell, monads, perhaps arrows, reactive programming, etc. Very interesting, but time-consuming. Still a long path to go for me. Thanks, TP ___ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe
Re: [Haskell-cafe] (no subject)
On 11/06/2013, at 1:58 AM, Alberto G. Corona wrote: I have ever wondered how a committee could have made Haskell. A committee made Algol 60, described as an improvement on most of its successors. A committee maintains Scheme. On the other hand, an individual gave us Perl. And an individual gave us JavaScript. And let's face it, an individual gave C++ its big start. ___ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe
