[Haskell-cafe] haskell platform broken in ubuntu
I just upgraded my ubuntu laptop to 13.04 and haskell platform is gone!! http://askubuntu.com/questions/286764/how-to-install-haskell-platform-for-ubuntu-13-04 What is the current status on this? Is 13.10 going to correct this? ___ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe
Re: [Haskell-cafe] haskell platform broken in ubuntu
On Sat, Oct 5, 2013 at 9:05 AM, Vagif Verdi vagif.ve...@gmail.com wrote: 13.04 has packages for ghc 7.6.2 It is easy to install latest haskell platform though. Just run this script: https://github.com/chrisprobst/ubuntu-raring-haskell I was hoping that something a little less painful than a full from-source install is available/known. At http://askubuntu.com/questions/286764/how-to-install-haskell-platform-for-ubuntu-13-04 I find this -- basically the platform dependencies seem to have been made explicit. sudo apt-get install ghc alex cabal-install happy libghc-cgi-dev libghc-fgl-dev libghc-glut-dev libghc-haskell-src-dev libghc-html-dev libghc-http-dev libghc-hunit-dev libghc-mtl-dev libghc-network-dev libghc-opengl-dev libghc-parallel-dev libghc-parsec3-dev libghc-quickcheck2-dev libghc-regex-base-dev libghc-regex-compat-dev libghc-regex-posix-dev libghc-stm-dev libghc-syb-dev libghc-text-dev libghc-transformers-dev libghc-xhtml-dev libghc-zlib-dev I was wondering if others know it as an ok approach or are there problems? Rusi ___ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe
Re: [Haskell-cafe] haskell platform broken in ubuntu
On Sat, Oct 5, 2013 at 9:18 AM, Vagif Verdi vagif.ve...@gmail.com wrote: That will give you only ghc 7.6.2. If you want latest haskell-platform, source compile is the only option. And btw it is not THAT painful :) You run the script, wait 2-3 minutes and tada! Ok so someone is very confused -- maybe me :-) http://askubuntu.com/questions/286764/how-to-install-haskell-platform-for-ubuntu-13-04 seems to say that compiling from source takes like two full nights!! Am I missing something? ___ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe
Re: [Haskell-cafe] Poll plea: State of GUI graphics libraries in Haskell
On Fri, Sep 27, 2013 at 9:02 AM, Conal Elliott co...@conal.net wrote:
I'm polling to see whether there are will and expertise to reboot graphics
and GUIs work in Haskell. I miss working on functional graphics and GUIs in
Haskell, as I've been blocked for several years (eight?) due to the absence
of low-level foundation libraries having the following properties:
[Disclaimer: In accordance with the principle that the amount that one
speaks should be in proportion to the amount one knows, about GUI toolkits
I should say nothing . Just offering my thoughts, more on the side of
things I know -- programming languages and their history -- than not!]
When I first heard of perl (early 90s) the claim was that the same
language ran on Unix and DOS. I was incredulous. Implicitly I believed that
the only program that could run unchanged on 'never-the-twain-shall-meet'
territory was something that tended to the limiting the null program:
main() {}
What perl showed and the benchmark set for all the following scripting --
Ruby, Python etc -- revolution was that the old idea of C's portability had
given way to a new one. In the C world portability meant simply passively
avoiding non-portable features, in the new scripting world it meant
actively writing bridge code to reunite gratuitous differences: eg the
'universal newline' in some languages like python.
In short: The C world had given up on portability.
The scripting language world chose to bite the bullet
That choice may be a bigger factor in their success than people realize.
So my point for the GUI question is this: In addition to Conal's list
* cross-platform,
* easily buildable,
* GHCi-friendly, and
* OpenGL-compatible.
there are two other current holy-grails to chase:
a. Browser-Desktop portability: eg pyjamas
http://en.wikipedia.org/wiki/Pyjamas_%28software%29
b. Touch devices allowing for 'Natural user interface'[1]: Generalizing the
40 year old mouse-model to modern touch devices eg
http://kivy.org/#home
How difficult/doable is this? As I said, I am too much of an ignoramus to
know.
Hopefully the perl/scripting-language example will prompt more
knowledgeable/capable persons to at least consider the possibility of
chewing on a bullet…
[1] http://en.wikipedia.org/wiki/Natural_User_Interface
Rusi
--
http://blog.languager.org
___
Haskell-Cafe mailing list
Haskell-Cafe@haskell.org
http://www.haskell.org/mailman/listinfo/haskell-cafe
[Haskell-cafe] Fwd: Can I use String without in ghci?
On Mon, Sep 2, 2013 at 10:43 AM, Richard A. O'Keefe o...@cs.otago.ac.nzwrote: On 2/09/2013, at 3:55 PM, Rustom Mody wrote: On Mon, Sep 2, 2013 at 5:43 AM, Richard A. O'Keefe wrote: A slogan I have programmed by since I first met C and recognised how vastly superior to PL/I it was for text manipulation _because_ it didn't have a proper string type is Strings are Wrong!. C rode to fame on the back of Unix. And Unix's innovation – one of many – is that at the OS level the string type was made common fare – a universal type. So everything from file names to file contents to IPC is a string. The idea of file names being strings was no innovation. Yes, in crippled monstrosities like TOPS-10 file names were weird records -- I can still remember too much of the details -- and every ruddy TOPS-10 program had to do its own file name parsing and it seemed as if they all did it differently. But the B6700 MCP interfaces treated file names as strings before UNIX was dreamed of. File contents in UNIX are *not* strings and never have been -- NUL termination is no part of files and binary files have been commonplace since the beginning (an a.out file is not a string!). They are *byte arrays*. As for IPC, since when have System V shared memory, semaphores, or message queues had anything to do with strings? (Hint: the 'name' of a System V shared memory segment is a key_t, and that's an integral type, not a string. Hint: the 'name' of a System V semaphore is also a key_t integer, not a string. Hint: the 'name' of a System V message queue is also a key_t integer, not a string. Hint: messages sent using msgsnd are not strings, they are byte arrays with a separate count parameter. ) Whoops! my bad -- I was *thinking* 'pipes' but ended up *writing* 'IPC' :-) So let me restate more explicitly what I intended -- pipes, FIFOs, sockets, etc. IOW read/write/send/recv calls and the mathematical model represented by the (non-firstclass) pair of C data structures in those functions: buf, len (or count). As an aside: modern usage types the buf as void * . The version 7 unix manuals on which I grew up (and first edition of KR), there was no void; buf would be just 'char *buf; ' Classic UNIX uses strings for file names, and really, that's it. (The command line argv[] is not really an exception, because it was used for file names as well as options, and in fact mixing the two up caused endless problems.) Everything else in V7, S3, or SysV was identified by a *number*. Plan 9 has exit(string) but Unix has exit(byte). From the perspective of someone who used UNIX v6 in 1979, *POSIX* IPC -- with its IPC objects *might* be in the file system but then again might *not* be so their names are sorta-kinda-like file names but not really) -- and /proc are recent innovations. The idea that 'string' was even remotely like a universal type in UNIX is bizarre. Heck, UNIX never even used 'string' for *lines* in text files! Of course when instructing a beginning programmer your basic premise 'Strings are Wrong!' is most likely right. No, I'm talking about experienced programmers writing high performance programs. However if programs are seen as entities interacting with an 'external' world, the currency at the portals is invariably string. - The currency at the portals is *not* invariably string. Learn PowerShell. - Text is one thing and string is another. This was the B6700 lesson (well, really the B5500 lesson): for many purposes you want a text *stream* not a text *string* at the interface. It's also the what-Smalltalk-got-right-and-Java-got-wrong lesson: the right way to convert objects to text is via a *stream* interface, not a *string* interface. I realize this is a terminology issue: My usage of terminology like string/file are evidently more aligned to http://en.wikipedia.org/wiki/Vienna_Development_Method#Collections:_Sets.2C_Mappings_and_Sequences file(chap 4): http://red.cs.nott.ac.uk/~rxq/files/SpecificationCaseStudies.pdf Contrariwise 'file' can mean http://en.wikipedia.org/wiki/Data_set_%28IBM_mainframe%29 So coming back from terminology to principles... And more than just noob programmers have got this wrong – think of the precious one-byte opcodes that Intel wastes on ascii and decimal arithmetic. Hang on, they are there in order to *support* the numbers are text model. You can't have it both ways. So let me restate (actually I didn't state it earlier!) my point in this example: When Intel introduced these instructions in 8008 (or whatever) decades ago, it seemed like a good idea to help programmers and reduce their burden by allowing them to do some minimal arithmetic on data without burdensome conversion-to-binary functions. 4 decades on and (Intel's very own Gordon) Moore's law ensuring our machines and networks some 7 orders of magnitude larger, the cost-equations look different. printf and scanf
Re: [Haskell-cafe] Can I use String without in ghci?
On Mon, Sep 2, 2013 at 5:43 AM, Richard A. O'Keefe wrote: A slogan I have programmed by since I first met C and recognised how vastly superior to PL/I it was for text manipulation _because_ it didn't have a proper string type is Strings are Wrong!. I wonder if you notice the irony in your use of 'C' as exemplar in this context? C rode to fame on the back of Unix. And Unix's innovation - one of many - is that at the OS level the string type was made common fare - a universal type. So everything from file names to file contents to IPC is a string. Of course when instructing a beginning programmer your basic premise 'Strings are Wrong!' is most likely right. However if programs are seen as entities interacting with an 'external' world, the currency at the portals is invariably string. And more than just noob programmers have got this wrong - think of the precious one-byte opcodes that Intel wastes on ascii and decimal arithmetic. So while this is true: If bar is predefined, it *isn't* the string 'b':'a':'r':[]. If bar is a number, it *isn't* a string. So other strings is quite misleading. in the innards of haskell, bar is a string On Sun, Sep 1, 2013 at 9:51 PM, Albert Y. C. Lai wrote: When 3 and 1/2 are typed next to each other, i.e., 3 1/2 it is addition. Well mathematicians are always eliding! In 3 1/2 the elision amounts to + In xy it amounts to * And within 23 ie between the 2 and the 3, it amounts to λ x y - 10*x + y And Haskell elides function application When teaching gofer (in the early 90s) I found that undoing the elision of function application and making it explicit, made FP more withing reach of the kids. Idea inspired by Dijkstra http://www.the-magus.in/Publications/ewd.pdf And more recently summarized http://blog.languager.org/2013/08/applying-si-on-sicp.html Rusi -- http://www.the-magus.in http://blog.languager.org ___ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe
Re: [Haskell-cafe] abs minBound (0 :: Int) negate minBound == (minBound :: Int)
On Wed, Aug 21, 2013 at 11:47 AM, Ketil Malde ke...@malde.org wrote: On a more serious note, I accept that Int (and other limited precision numbers) is a fact of life, and sometimes useful for performance reasons. I would have liked, however, to have a compiler option or some other way to make my programs throw an exception on overflow - even if this turned out to be slower, I could at least use it when testing my programs, which would have caught a few bugs. Yes for software detection, some will want it and some will not; see the same discussion a few months ago http://www.haskell.org/pipermail/haskell-cafe/2013-June/107153.html The 'some other way' is hardware detection. And there is glimmer of hope that Intel may begin to do due diligence http://www.emulators.com/docs/LazyOverflowDetect_Final.pdf ___ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe
Re: [Haskell-cafe] haskore - lilypond - typesetting?
On Wed, Aug 21, 2013 at 6:35 PM, Johannes Waldmann waldm...@imn.htwk-leipzig.de wrote: I tried using lilypond ( http://www.lilypond.org/ ) for typesetting of sheet music. While the output looks nice, the input language IMHO is quite horrible, I use musescore. Its got 3 modes on entry a. clickety-click -- ie mouse b. keyboard shortcuts c. midi keyboard For bulk entry direct entry from a midi keyboard is best http://musescore.org/en/handbook/note-entry [Since I am not much of a musician, I usually hover between a and b] If after that you want the lilypond toolchain, it will export to lilypond and then use your favorite text editor. [Not sure of the quality of export] ___ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe
Re: [Haskell-cafe] abs minBound (0 :: Int) negate minBound == (minBound :: Int)
On Tue, Aug 20, 2013 at 6:37 AM, Richard A. O'Keefe o...@cs.otago.ac.nz wrote: On 20/08/2013, at 3:43 AM, Kyle Miller wrote: On Sun, Aug 18, 2013 at 8:04 PM, Richard A. O'Keefe o...@cs.otago.ac.nz wrote: The argument for twos-complement, which always puzzled me, is that the other systems have two ways to represent zero. I never found this to be a problem, not even for bitwise operations, on the B6700. I *did* find abs x 0 succeeding to be a pain in the posterior. (The B6700 had two different tests: 'are these two numbers equal' and 'are these two bit patterns equal'.) I think a better argument for twos complement is that you're just doing all of your computations modulo 2^n (where n is 32 or 64 or whatever), and addition and multiplication work as expected modulo anything. To me, that's not a better argument. These kinds of argument usually come down to a question of framing -- whether pragmatic, philosophical or pedagogical. Let me start with the philosophical It isn't even a _good_ argument. It amounts to saying if you do things wrong, you can justify it by saying you're really doing something else right, and it's the programmer's fault for wanting the wrong thing. This argument works if 'doing something right' is an available option. What if its not? One great thing about the B6700 was that you were guaranteed EITHER the mathematically correct answer in the numbers you were thinking in terms of OR an exception telling you the machine couldn't do what you wanted. When it comes to *applications* programming, the number of times I have *wanted* arithmetic modulo 2^n (in the last 40 years) can be counted on the fingers of one ear. You may call it multiplication work[ing] as expected when the product of two positive numbers comes out negative; I call it a wrong answer. Prelude let tens = 1 : map (*10) tens :: [Int] Prelude take 19 tens [1,10,100,1000,1,10, 100,1000,1, 10,100, 1000,1,10,100, 1000,1,10,100] Prelude [x * x | x - take 19 tens] [1,100,1,100,1,100, 1,100,1,100, 7766279631452241920,1864712049423024128,2003764205206896640, -2537764290115403776,4477988020393345024,5076944270305263616, -8814407033341083648,4003012203950112768,-5527149226598858752] Yes, I know that Haskell has Integer. If I want to do more arithmetic than a bit of simple counting, I like to use it. The gibberish that Int multiplication spewed out above is why. Roughly speaking, there are three ways to handle integer arithmetic: the Lisp way, the Ada way, and the Java way. Lisp just gets it right (think Haskell's Integer type). Java *defines* wrong answers to be right. Ada recognises that sometimes you want modular arithmetic (so it offers you modular types) and sometimes you don't (so it offers you bounded but non-modular types, where overflow is trapped). This issue is really a specific instance of the question: Are computers finite or infinite? If one says finite then the infinite-taped Turing machine has nothing to do with computers If one says infinite then the abstraction we are talking of is unrelated to the boxes on our desks/palmtops. If one recognises that in juggling between these two views -- dare I say a central project for a programmer?? -- we need to stuff an infinite conceptual object into a finite actual one. And in doing so some corners will be cut willy-nilly. So to say Lisp is 'right' because arithmetic does not overflow at machine word size limits misses the fact that it overflows more unpredictably when the machine memory fills out. Lets look at good ol factorial fact 0 = 1 fact n = n * fact (n-1) Now I ran it as fact 100 with signature Int - Int and with Integer - Integer In the first case I got 0 in about 3 seconds In the second... I thought I'd see what happens but after about 2 minutes of the CPU fans maxing out, firefox started giving me alarms about an 'unresponsive script'; I felt my machine had had enough punishment and gave in with C-c! And if that sounds like a unreal argument, consider representing and storing Graham's number. Of course I am arguing philosophically not pragmatically. Philosophically: Graham's number is 'just' a finite number, though a rather obese one Pragmatically: 32-bits is unwise for a bank-balance, 64 should be a bit more safe So coming to the pragmatic and to lisp... I remember a story (maybe apocryphal) about a robot in the MIT(?) lab that did a lot of clever things and then tumbled down the stairs. When asked, the concerned researcher/academic shrugged it off: It was garbage collecting If the robot had been programmed in C its real-time behavior would have been sturdier though its integer overflow properties would have been flimsier. More pragmatically, its good to remember
Re: [Haskell-cafe] Int is broken [Was: Different answers on different machines]
On Tue, Jun 4, 2013 at 7:35 AM, Richard A. O'Keefe o...@cs.otago.ac.nzwrote: On 3/06/2013, at 6:58 PM, Carter Schonwald wrote: If the Int type had either of these semantics by default, many many performance sensitive libraries would suddenly have substantially less compelling performance. Every single operation that was branchless before would have a branch *every* operation. this would be BAD. Actually, the x86 can be configured to trap integer overflows, so on that not entirely unpopular platform, there need be NO extra branches. Well yes and no. See http://software.intel.com/en-us/forums/topic/306156 Using instructions like cmovo Conditional MOve on Overflow we can test without a branch -- so in that sense yes. No, because the use of the word 'trap' is a bit misleading. If we understand 'trap' as synchronous interrupt, then intel provides the infrastructure to literally trap floating point errors but for integers such a 'trap' only works if the instruction stream contains instructions like INTO or CMOVO etc. Alternatively, and more portably, there could be separate Int and UnsafeInt types, and the performance sensitive libraries could be rewritten to use UnsafeInt. For just one week, I had the joy of using a C compiler where signed integer overflow was trapped. It was *wonderful*. In Discipline of Programming (in 1976!) Dijkstra exactly described this problem, and squarely put the blame on poorly engineered machines. He introduced 3 concepts/terms: UM : unbounded machine SLM : sufficiently large machine HSLM : hopefully sufficiently large machine The UM -- like a Turing machine -- has no messy restrictions of finiteness like wordsize and is therefore pleasant to reason with and impossible to physically build. The SLM is like most of our actual machines -- actual finite state machines approximating our conceptually nice unbounded machines. The problem is when the approximation fails, the SLM behaves unpredictably. So we have the HSLM, which (I quote): The HSLM is two things merged into one. Besides acting as the largest SLM we can afford, it checks, when called to execute a program, as the computation proceeds, whether this SLM is large enough for the current computation. If so, it proceeds with the simulation of the UM's behaviour, otherwise it refuses to continue. There exist, regretfully enough,in which the continuous check that the simulation of the behaviour of the UM is not beyond their capacity is so time-consuming, that the check is suppressed for the sake of efficiency. It is very difficult to use such machines… and we ignore them in the sequel!! In short the problem is our machines: if catching errors involves checking and checking involves a cost, some program(ers) will sometimes seek to avoid that. Moving the check to the hardware -- ie synchronous trap on errors -- removes the cost and the temptation to avoid. Until we get such machines, these arguments will continue to be there! ___ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe
[Haskell-cafe] ghc release schedule
I give ghc release schedule to google and get at/near the top: http://hackage.haskell.org/trac/ghc/wiki/Status/Releases whose title is Release plans for ghc 6.12 ___ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe
[Haskell-cafe] Teaching FP with Haskell
We are offering a MOOC on haskell : https://moocfellowship.org/submissions/the-dance-of-functional-programming-languaging-with-haskell-and-python Full Announcement on beginners list : http://www.haskell.org/pipermail/beginners/2013-May/012013.html One question that I have been grappling with in this regard: How to run ghc in lightweight/beginner mode? 2 examples of what I mean: 1. gofer used to come with an alternative standard prelude -- 'simple.pre' Using this, gofer would show many of the type-class based errors as simple (non-type-class based) errors. This was very useful for us teachers to help noobs start off without intimidating them. 2. Racket comes with a couple of levels. The easier numbers were not completely consistent with scheme semantics, but was gentle to beginners Any thoughts/inputs on this will be welcomed Rusi ___ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe
[Haskell-cafe] whats with cabal and libgmp.so.3
Today cabal suddenly started giving me errors that libgmp.so.3 is not found Moving away my old .cabal makes it work again Any explanations? [I am on debian testing. I think the causing factor was that debian switched major versions recently. There were a lot of updates... Nothing that looked like it was related to ghc] ___ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe
Re: [Haskell-cafe] A Thought: Backus, FP, and Brute Force Learning
On Mon, Mar 25, 2013 at 4:13 AM, Richard A. O'Keefe o...@cs.otago.ac.nzwrote: It's Backus, people. He was never the god of wine. I cannot detect any trace of Backus's FP in Haskell at all. FP is strict. Haskell is not. FP is typeless. Haskell is highly typeful. FP does not name formal parameters. Haskell often does. FP has roots in APL. Haskell doesn't. I don't see any trace of Backus's FP in ML, Clean, or F# either. The idea of writing programs by composing lots of small functions is common to them both, but the idea of combinators preceded them both. I really wonder about this whole discussion -- not the details… the perspective. Its like saying the Ford T http://1.bp.blogspot.com/-KGhxacA_p1k/TV0g_qeHOFI/CF8/5t8NRxpzUCo/s1600/1912-ford-model-t.jpg is an unsafe car http://1.bp.blogspot.com/-7gEOpb7-9IU/TV0g-88-dZI/CF0/u3dh8CXAAGI/s1600/f1244_it0061.jpg and should be equipped with airbags. To the OP: I believe that FP has much to contribute to programming, whether you identify yourself as an FPer or not. - Not the fancy type hackery of modern haskell - Not the math hackery of Backus Just basic stuff like http://blog.languager.org/2012/10/functional-programming-lost-booty.html [Sorry its only an outline and is skimpy] For the most part I agree with the foll -- except the type-classes. As for Def Innerproduct = (Insert +) o (ApplyToAll x) o Transpose the idea is that this ought to be *easier* to understand than an imperative loop because all of the parts are separated out instead of being graunched up together. inner_product :: Num a = ([a],[a]) - a inner_product = foldr1 (+) . map (uncurry (*)) . uncurry zip _is_ expressible in Haskell, although inner_product :: Num a = [a] - [a] - a inner_product = sum . zipWith (*) would be more idiomatic. Personal note: I recently taught a course in Erlang and I did what Ive done for 25 years -- start with FP. In the past its always more or less worked well - in 1988 it was scheme - in 1992 it was gofer, the predecessor of haskell - in 2001 it was scheme. This time I used haskell and the results were not so good, primarily because of typeclasses ___ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe
Re: [Haskell-cafe] A Thought: Backus, FP, and Brute Force Learning
On Mon, Mar 25, 2013 at 9:40 AM, Rustom Mody rustompm...@gmail.com wrote: - in 1992 it was gofer, the predecessor of haskell - in 2001 it was scheme. Sorry typo: 2001 it was python ___ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe
[Haskell-cafe] python under attack. ??Haskell??
Please see http://pyfound.blogspot.in/2013/02/python-trademark-at-risk-in-europe-we.html I cannot say that I understand whats really going on The one thing that I get is that there was some minor neglect a decade or more ago. http://blog.languager.orgMaybe there are things that Haskell needs to beware of? ___ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe
Re: [Haskell-cafe] Why isn't Program Derivation a first class citizen?
On Wed, Feb 13, 2013 at 4:17 AM, Nehal Patel nehal.a...@gmail.com wrote: A few months ago I took the Haskell plunge, and all goes well... -- but I really want to understand the paradigms as fully as possible, and as it stands, I find myself with three or four questions for which I've yet to find suitable answers. I've picked one to ask the cafe -- like my other questions, it's somewhat amorphous and ill posed -- so much thanks in advance for any thoughts and comments! Why isn't Program Derivation a first class citizen? --- (Hopefully the term program derivation is commonly understood? I mean it in the sense usually used to describe the main motif of Bird's The Algebra of Programming. Others seem to use it as well...) For me, it has come to mean solving problems in roughly the following way 1) Defining the important functions and data types in a pedantic way so that the semantics are clear as possible to a human, but possibly inefficient (I use quotes because one of my other questions is about whether it is really possible to reason effectively about program performance in ghc/Haskell…) 2) Work out some proofs of various properties of your functions and data types 3) Use the results from step 2 to provide an alternate implementation with provably same semantics but possibly much better performance. To me it seems that so much of Haskell's design is dedicated to making steps 1-3 possible, and those steps represent for me (and I imagine many others) the thing that makes Haskell (and it cousins) so beautiful. And so my question is, that in 2013, why isn't this process a full fledged part of the language? I imagine I just don't know what I'm talking about, so correct me if I'm wrong, but this is how I understand the workflow used in practice with program derivation: 1) state the problem pedantically in code, 2) work out a bunch of proofs with pen and paper, 3) and then translate that back into code, perhaps leaving you with function_v1, function_v2, function_v3, etc -- that seems fine for 1998, but why is it still being done this way? What I'm asking about might sound related to theorem provers, -- but if so ,I feel like what I'm thinking about is not so much the very difficult problem of automated proofs or even proof assistants, but the somewhat simpler task of proof verification. Concretely, here's a possibility of how I imagine the workflow could be: ++ in code, pedantically setup the problem. ++ in code, state a theorem, and prove it -- this would require a revision to the language (Haskell 201x) and perhaps look like Isabella's ISAR -- a -structured- proof syntax that is easy for humans to construct and understand -- in particular it would possible to easily reuse previous theorems and leave out various steps. At compile time, the compiler would check that the proof was correct, or perhaps complain that it can't see how I went from step 3 to step 4, in which case I might have to add in another step (3b) to help the compiler verify the proof. ++ afterwards, I would use my new theorems to create semantically identical variants of my original functions (again this process would be integrated into the language) While I feel like theorem provers offer some aspects of this workflow (in particular with the ability to export scala or haskell code when you are done), I feel that in practice it is only useful for modeling fairly technically things like protocols and crypto stuff -- whereas if this existed within haskell proper it would find much broader use and have greater impact. I haven't fully fleshed out all the various steps of what exactly it would mean to have program derivation be a first class citizen, but I'll pause here and followup if a conversation ensues. To me, it seems that something like this should be possible -- am i being naive? does it already exist? have people tried and given up? is it just around the corner? can you help me make sense of all of this? thanks! nehal ___ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe I am stating these things from somewhat foggy memory (dont have any lambda-calculus texts handy) and so will welcome corrections from those who know better… In lambda-calculus, if reduction means beta-reduction, then equality is decidable Adding eta into the mix makes it undecidable Haskell is basically a sugared beta-reducer A prover must -- to be able to go anywhere -- be a beta-eta reducer. Which is why a theorem-prover must be fundamentally more powerful and correspondingly less decidable than an implemented programming language. If a theorem-prover were as 'hands-free' as a programming language Or if an implemented programming language could do the proving that a theorem-prover could do, it would contradict the halting-problem/Rice theorem. -- http://www.the-magus.in
Re: [Haskell-cafe] Most used functions in hackage
On Sat, Feb 2, 2013 at 12:43 PM, Casey Basichis caseybasic...@gmail.comwrote: I'm not sure what you mean. I would imagine popular success for either would be circumstantial and have little to do with their actual ability and more to do with the opportunities they pursue and the cultural atmosphere at the time. For this student: http://www.youtube.com/watch?v=_bjKDJD-CLc I would have a very clear idea of the many things He He... Yes you are making a similar point to what I am making -- calibrating the learning curve. I would excise from the typical piano education to help her form her musical intuitions as simply and effectively as possible, with the knowledge that in time, she will find her own way to a personal style and repertoire. You are being a little cryptic. I don't see how the nuances that differentiate two experts relates. Sorry… Yes… a. There are some concerns which a teacher thinks about which experts -- whether in FP or in music -- may not think about b. And then there is a side that is going too far afield for a haskell list… so yes I was cryptic I guess. For now let me say this much: I spent much precious time and energy and vitality in my younger days trying (more correctly wishing) to play piano like Cziffra and just making a thorough mess. If my teacher had calibrated my learning curve according to my needs rather than my whims it may have been better. Then again who knows? How many talented students have lost interest due to over-strict teachers? This line of inquiry is perhaps best taken off the haskell list. For now let me just make a couple of observations that are (hopefully :-) ) on-topic for the question of learning haskell, though (1,2) are true for learning anything, not just FP/Haskell. 1. In any field, teachers need to work out the path aka learning curve through the field. This usually manifests as 'pre-requisites' in a curricular structure. eg To study quantum physics, differential equations are needed, they need algebra, which needs basic arithmetic 2. What the student thinks he most needs, he usually needs to go easy on. eg diabetics like sweets (usually), BP-patients like salty savouries and obese/heart-patients like rich food 3. In CS/programming the problems are compounded; nobody agrees on how the basics and the advanced stuff bifurcate. How many CS depts have a significant amount of haskell? How many start with haskell? Yes, you may say, but that is a local, specific problem. I would like to suggest that it is general and systemic: So if I may quote myself: http://blog.languager.org/2011/02/cs-education-is-fat-and-weak-2.html : CS-academics are mostly teaching the wrong things, and when right in the wrong order. Rusi ___ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe
Re: [Haskell-cafe] Most used functions in hackage
On Tue, Jan 29, 2013 at 1:53 PM, Casey Basichis caseybasic...@gmail.comwrote: Hi Dmitry, Thanks for the links. I've been through the 24 Days of Hackage, but I think its time to run through them again now that I'm a little more familiar with everything. Why do you think browsing function by function is a bad idea? It seems that knowing exactly what the most used functions are would be an extremely effective way of finding both which parts of the Prelude and Hackage are most broadly useful (instead of browsing them like a phonebook) and also finding support from the community as the most commonly used functions would likely be the easiest to find support for. Find out the most used functions seems to be eminently desirable. To do that we need to count function-uses. And to do that we need to know what to count. Do we? If you remember, the cost-centre mode of counting functions in haskell programs was precisely because the usual (first-order language) mode of counting would lead to the strange conclusion that map and foldr were the most used and therefore most inefficient functions in Haskell! So a new way of counting had to be devised. There is a book: Mathsemantics by Edward Macneal which deals with things like: How does an airline count the number of passengers. I quote from the book: I 1980 I was one passenger, ten passengers, eighteen passengers, thirty-six passengers, forty-two passengers, fifty-five passengers, seventy-two passengers and ninety-four passengers. Each of these statements is true. He then goes on to explain. I was one passenger in the sense that I was a person who traveled by air in that year. I was eighteen passengers in the sense that I made eighteen round trips. I was forty-two passengers in the sense that on forty-two different occasions I entered and exited the system of a different carrier. I was seventy-two passengers in the sense that on seventy-two occasions I was on board an aircraft when it took off from one place and landed at another. I was ninety-four passengers in the sense that I made ninety-four separate entrances and exits from airport terminal buildings. [He missed the explanation for 10!] He goes on to say that these differences are not mere technicalities and its important to get the sense of 'passenger' So… like 'passenger', how many meanings does 'function-use' have? Rusi -- http://www.the-magus.in http://blog.languager.org ___ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe
Re: [Haskell-cafe] linking errors while compile hugs98 in macos
On Fri, Feb 1, 2013 at 8:45 AM, Junior White efi...@gmail.com wrote: Sadly! I like hugs because it can embed in my game client as lua. For game logic language, I think the following properties are important: 1. Portable, works on pc,macosx,ios,android even flash or web. 2. Intepret, for quick develop, quick test. 3. Hot code load, for online bugfix. 4. Small, game client need to be as small as possiable So that lua best fits the rule very well, but i like haskell much more. After doing some research, I find in the haskell world, there is a hugs fits my demands. I'm sad to know that no one is maintaining hugs any more. I asking someone to keep develop on it, if no one, can I do it myself? I used gofer (predecessor of hugs) to teach programming in the early 90s. Some changes which I made to it are here https://github.com/rusimody/gofer It did compile a few months ago with gcc 4.7 Rusi -- http://www.the-magus.in http://blog.languager.org ___ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe
Re: [Haskell-cafe] Most used functions in hackage
On Fri, Feb 1, 2013 at 9:41 PM, Casey Basichis caseybasic...@gmail.comwrote: That book Mathsemantics sounds like something I should read, would you recommend it? Well its quite a favourite of mine, if that counts as a recommendation… Your point occurred to me the other day when measuring number of downloads of whole packages was mentioned as being the ideal measure. I have more confidence in measuring the contents of the packages themselves as creating a Hackage package suggests a competency with the language and baseline of sophistication. My thought was the best measure might be the count of functions across all packages, where an included function in any individual package would only be counted once per package. In this sense, map and fold would still likely be towards the top, but that is as it should be. But it seems there are many measures that would be useful, like the percentage of functions from a package that tend to get used in the same project - do people nit pick particular functions from a specific package or does the package use tend to require the use of all of its functions in every project the package is used in. I'd love to hear some thoughts on this as I generally don't know where to begin in solving these sorts of problems and would like to know more about those methods in general. Well… it seems to be a good idea to back off from here a bit and ask how we came here. You want to learn haskell for which you want to pinpoint the 'most' used functions. Lets leave aside the question that 'most' may be harder to specify than we may first imagine. Instead lets make a map (functor?) from learning the programming language Haskell to learning the natural language English. So I dont know English (and yeah there are Godelian anomalies in that statement) and I gather that vocabulary is a key to mastering the language. Now Webster is a bit too fat to cram up as a whole so I decide to isolate the 5000 most used English words. Do you think my English mastery will be improved that way? Surely Webster had a bigger vocabulary than Shakespeare. Do you think Webster knew English better than Shakespeare? [You can of course replace Shakespeare to whoever happens to take your fancy] IOW mastering the paradigm is more important than the details. Now its important to get that the paradigm cannot be caught in any single-point sloganeering such as: Functional programming is programming without side-effects Haskell is syntactically sugared lambda calculus The key feature of Haskell is its sexy type magic Nevertheless its also true that 'paradigm' consists of far fewer elements than 'the 500 most used functions.' I have a couple of pages on my blog: http://blog.languager.org/2012/10/functional-programming-lost-booty.html gives a few of the basics that FPers should know (IMHO) before going to advanced stuff. I should mention that it was written it because Haskell is becoming increasingly hard for beginners with the focus on 'type-magic' is overshadowing the basics. [In any case after 25 years of teaching, I am finding it harder and harder to teach] If you have crossed over the basic stage it may not be much use to you :-) There is also http://blog.languager.org/2011/02/cs-education-is-fat-and-weak-1.html and sequel which is more of a grumble about CS education than about FP/Haskell per se. Still, an undercurrent of that grumble is that much of the nonsense of CS education is because FP has not become mainstream soon enough. ___ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe
Re: [Haskell-cafe] Most used functions in hackage
On Sat, Feb 2, 2013 at 3:38 AM, Casey Basichis caseybasic...@gmail.comwrote: I just ordered Mathsemantics for a hefty $2.10. Your article's were an enjoyable read and very informative. I'll dig more into you blog tonight. I've read the Great Good book, Haskell school of music, and I'm working my way through Real World Haskell. I've also read countless blog articles on Haskell. With a great deal read and understood about Haskell I have no confidence that I can make anything in it at all. Kurt Vonnegut retyped James Joyce's work to feel a great novel under his fingers before writing his own. Webster knew English better than Shakespeare. Shakespeare was a master of creation. To be able to create from a small core and then extend those intuitions with knowledge over time is to me far more effective than mastering language and then attempting creation. While not rigorous, getting hands on with high level practical libraries and working by example would have built my intuitions far faster than all of the countless reading and toy examples I've done. The problem is, for that approach, there isn't any material for a book or insightful blog post to be written. Mimetics are mundane and unnecessary to those in the know. The teachers seem to be unaware of how their own intuitions were formed. While learning the fundamentals my mind struggles to imagine how these basic concepts play into the larger picture - how would they use foldr to build persistent? I don't have real answers to those questions but it's a constant distraction. I am certain that sitting down with a few simple examples of how to use a library like Persistent, without any concern as to how it works, will surely take me from a useless Haskeller to being able to make useful tools that I can use in my career as a composer. In learning Do notation the books took me through three ways of expressing the same thing before arriving at the sugary syntax that I will likely use for the next ten projects. I don't see that as building a core towards creation, but rather the elevation of a fetishy obsession with language. Children learn the most critical words before grammar - only in language studies does grammar come before vocabulary. The question is what is the core knowledge that facilitates creation? That core is a mutating form. It works from the high level downward as it needs to, not from the low level upward because it is thought that it should. There are thousands of articles on how to use raw C++ pointers. One in the know knows to use smart pointers because they facilitate creation. I constantly read authors of blog posts say things like I wish I had learned monad transformers sooner. What is a rigorous way to prioritize learning the full scope of Haskell so that creative intuition is maximized? How can I know that Arrows will be generally more effective than Category-Extras for creating things? If data mining Hackage to find the practical reality of how Haskell is actually being used by people who are creating complete and useful things is not an effective way to learn, what approach is better? Best, Casey Lets say you teach the piano and two prospective students come to you. A with much passion wants to play like this http://www.youtube.com/watch?v=3L0Rncqx1yQ B with more focus than passion, has this ideal http://www.youtube.com/watch?v=Yu06WnXlPCY Who do you think/feel would be more likely to succeed? Who would you prefer to teach? ___ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe
Re: [Haskell-cafe] FFI - Approaches to C/C++
On Thu, Jan 31, 2013 at 11:11 AM, Casey Basichis caseybasic...@gmail.comwrote: Hi, I'm working on a project in Haskell and C++ where the former is the brains and the latter is for UI, interaction etc. I've read this http://www.altdevblogaday.com/2012/04/26/functional-programming-in-c/ and a number of other haskell posts suggesting the OOP is not the way to go. Without trying to emulate functional programming through templates or boost::phoenix, what approaches do you all favor when designing parts of an application in C++? Patterns to embrace or avoid? Should I just use functions and handle things with name spaces? I was thinking about handling the callbacks with boosts signals and slots 2 I know this is not entirely haskell centric, but it is a question for haskell users. Thanks, Casey And then I'm on iOS so I imagine those difficulties are compounded. If you can tolerate the view that Haskell is more of an ideology than a technology, and are willing to explore areas that are technologically disparate but conceptually similar to Haskell maybe you should look at ocaml: http://web.yl.is.s.u-tokyo.ac.jp/~tosh/ocaml-on-iphone/index.html http://psellos.com/ocaml/compile-to-iphone.html Rusi -- http://www.the-magus.in http://blog.languager.org ___ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe
Re: [Haskell-cafe] list comprehansion performance has hug different
On Wed, Jan 30, 2013 at 5:32 PM, Junior White efi...@gmail.com wrote: Thanks for your reply! I must learn more to fully understand what's going on inside the list comprehension. But when I frist learn Haskell, it says sequence doesn't matter, but now it is a big matter, can compiler do some thing for us? I think this behavior is not friendly to newbies like me, I will take a very long time to work through it. Good point. Being a programmer means having to juggle many hats -- two important ones being the mathematician-hat and the machine-hat, also called declaration and 'imperation' Get only the first and your programs will run very inefficiently. Get only the second and your program will have bugs. Specifically in the case of list comprehensions the newbie needs - to practice thinking of the comprehension like a set comprehension and ignoring computation sequences - to practice thinking of comprehension in terms of map/filter etc ie operationally Both views are needed. Rusi -- http://www.the-magus.in http://blog.languager.org ___ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe
Re: [Haskell-cafe] Chordify, a new web startup using Haskell
On Fri, Jan 18, 2013 at 2:09 PM, Thiago Negri evoh...@gmail.com wrote: Is it possible to play the generated chords as a melody by itself, without the original music over it? Super work! I was meaning to ask something similar -- can we get out something of the music that chordify has reverse engineered -- maybe midi maybe musicxml? ___ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe
Re: [Haskell-cafe] resources for learning Hindley-Milner type inference for undergraduate students
On Fri, Jan 18, 2013 at 5:49 PM, Jan Stolarek jan.stola...@p.lodz.plwrote: Dnia piątek, 18 stycznia 2013, Petr P napisał: for learning Hindley-Milner type inference algorithm I could recommend to undergraduate students? The original paper is harder to understand, I'm looking for something more didactic. The students are familiar with the lambda calculus, natural deduction and System F. What is the current opinion of Mark Jones Typing haskell in haskell? http://web.cecs.pdx.edu/~mpj/thih/TypingHaskellInHaskell.html [Note This is to add to the question more than the answer] ___ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe
Re: [Haskell-cafe] Object Oriented programming for Functional Programmers
On Mon, Dec 31, 2012 at 1:28 AM, Daniel Díaz Casanueva dhelta.d...@gmail.com wrote: Hello, Haskell Cafe folks. My programming life (which has started about 3-4 years ago) has always been in the functional paradigm. Eventually, I had to program in Pascal and Prolog for my University (where I learned Haskell). I also did some PHP, SQL and HTML while building some web sites, languages that I taught to myself. I have never had any contact with JavaScript though. But all these languages were in my life as secondary languages, being Haskell my predominant preference. Haskell was the first programming language I learned, and subsequent languages never seemed so natural and worthwhile to me. In fact, every time I had to use another language, I created a combinator library in Haskell to write it (this was the reason that brought me to start with the HaTeX library). Of course, this practice wasn't always the best approach. But, why I am writing this to you, haskellers? Well, my curiosity is bringing me to learn a new general purpose programming language. Haskellers are frequently comparing Object-Oriented languages with Haskell itself, but I have never programmed in any OO-language! (perhaps this is an uncommon case) I thought it could be good to me (as a programmer) to learn C/C++. Many interesting courses (most of them) use these languages and I feel like limited for being a Haskell programmer. It looks like I have to learn imperative programming (with side effects all over around) in some point of my programming life. So my questions for you all are: * Is it really worthwhile for me to learn OO-programming? Ive been collecting material regarding (confusions around) OO. Its far from complete but the references may be useful, eg - the Rees list on the different things that OO means to different people - the fundamental philosophical differences between commitment to declarativeness and imperativeness -- in philosophical language rationalism and empiricism As I said, its still in the early stage of bits and pieces being collected... http://blog.languager.org/2012/07/we-dont-need-no-o-orientation-2.html * If so, where should I start? There are plenty of functional programming for OO programmers but I have never seen OO programming for functional programmers. In the C++ world Stepanov is almost on par with Stroupstrup. His STL has transformed C++ practices more than anything else Good to read his views on OOP http://en.wikipedia.org/wiki/Alexander_Stepanov#Criticism_of_OOP -- http://www.the-magus.in http://blog.languager.org ___ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe
Re: [Haskell-cafe] Object Oriented programming for Functional Programmers
On Mon, Dec 31, 2012 at 7:30 AM, Rustom Mody rustompm...@gmail.com wrote: Ive been collecting material regarding (confusions around) OO. Its far from complete but the references may be useful, eg - the Rees list on the different things that OO means to different people - the fundamental philosophical differences between commitment to declarativeness and imperativeness -- in philosophical language rationalism and empiricism As I said, its still in the early stage of bits and pieces being collected... http://blog.languager.org/2012/07/we-dont-need-no-o-orientation-2.html * If so, where should I start? There are plenty of functional programming for OO programmers but I have never seen OO programming for functional programmers. In the C++ world Stepanov is almost on par with Stroupstrup. His STL has transformed C++ practices more than anything else Good to read his views on OOP http://en.wikipedia.org/wiki/Alexander_Stepanov#Criticism_of_OOP Just realized that the resultant anti-OOP direction of my earlier mail is stronger than is good for a young computer scientist. In a field like ours its as important to be able to wear a technical/mathematical hat as a social or political one. And when the latter, its good to be able to participate in a discussion in which inheritance, UML etc etc figures. ___ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe
Re: [Haskell-cafe] Non polymorphic numerals option -- avoiding type classes
On Thu, Dec 27, 2012 at 8:26 PM, Kim-Ee Yeoh k...@atamo.com wrote: Hi David, it looks like Rustom's aware that haskell's not lisp. What he really wants methinks is a way to suppress type classes altogether! That or a NoOverloadedNumerals extension. -- Kim-Ee I'm not really sure about that... Look! ghci with default startup $ ghci GHCi, version 7.4.1: http://www.haskell.org/ghc/ :? for help Loading package ghc-prim ... linking ... done. Loading package integer-gmp ... linking ... done. Loading package base ... linking ... done. Prelude :t [[1,2],3] [[1,2],3] :: (Num [t], Num t) = [[t]] So it would appear that ghci is giving a well-typing for [[1,2], 3]. But is it? Prelude [[1,2],3] interactive:3:8: No instance for (Num [t0]) arising from the literal `3' Possible fix: add an instance declaration for (Num [t0]) In the expression: 3 In the expression: [[1, 2], 3] In an equation for `it': it = [[1, 2], 3] --- So is it well-typed in ghci or not?? And now we add Roman's suggestions... $ cat .ghci :set -XRebindableSyntax let fromInteger = id And run ghci again $ ghci GHCi, version 7.4.1: http://www.haskell.org/ghc/ :? for help Loading package ghc-prim ... linking ... done. Loading package integer-gmp ... linking ... done. Loading package base ... linking ... done. Prelude :t [[1,2],3] interactive:1:8: Couldn't match expected type `[Integer]' with actual type `Integer' Expected type: Integer - [Integer] Actual type: Integer - Integer In the expression: 3 In the expression: [[1, 2], 3] Prelude [[1,2],3] interactive:3:8: Couldn't match expected type `[Integer]' with actual type `Integer' Expected type: Integer - [Integer] Actual type: Integer - Integer In the expression: 3 In the expression: [[1, 2], 3] Prelude So far so good -- when an expression is type-wrong, its 'wrongness' is the same irrespective of whether I ask for its type or evaluate it. But now we are in for new surprises: Try out f x y = x / y Prelude :l f [1 of 1] Compiling Main ( f.hs, interpreted ) f.hs:1:11: Not in scope: `/' Failed, modules loaded: none. Prelude (/) Oh is it that now integer literals are just plain Integers and cant be divided using '/' ?? So lets replace '/' with '+' f.hs:1:11: Not in scope: `+' And now I am at my wits end! ___ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe
[Haskell-cafe] Non polymorphic numerals option -- avoiding type classes
In haskell, we have Prelude :t 4 4 :: Num a = a Prelude This may be nice in its generality but it makes it hard (for me at least) when teaching a beginners course to teach polymorphic vs monomorphic types. The above leads to even more 'advanced' results like this: Prelude :t [[1],2] [[1],2] :: (Num [t], Num t) = [[t]] Prelude [[1],2] interactive:5:6: No instance for (Num [t0]) arising from the literal `2' Possible fix: add an instance declaration for (Num [t0]) In the expression: 2 In the expression: [[1], 2] In an equation for `it': it = [[1], 2] By contrast in gofer, numeric literals are monomorphic and no such peculiarities arise ? :t [[1],2] ERROR: Type error in list *** expression : [[1],2] *** term : 2 *** type : Int *** does not match : [Int] [[1],2] ERROR: Type error in list *** expression : [[1],2] *** term : 2 *** type : Int *** does not match : [Int] So is there any set of flags to make haskell literals less polymorphic? ie I want 3 to have type Int and 3.0 to have type Float. This is of course for beginning students to not see type classes too early ___ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe
Re: [Haskell-cafe] Non polymorphic numerals option -- avoiding type classes
On Thu, Dec 27, 2012 at 1:48 AM, Roman Cheplyaka r...@ro-che.info wrote: * Rustom Mody rustompm...@gmail.com [2012-12-26 20:12:17+0530] So is there any set of flags to make haskell literals less polymorphic? Yes, there is! % ghci -XRebindableSyntax GHCi, version 7.6.1: http://www.haskell.org/ghc/ :? for help Loading package ghc-prim ... linking ... done. Loading package integer-gmp ... linking ... done. Loading package base ... linking ... done. import Prelude hiding (fromInteger) Prelude let fromInteger = id Prelude :t 3 3 :: Integer Roman Thanks Roman -- that helps. And yet the ghci error is much more obscure than the gofer error: --- contents of .ghci --- :set -XRebindableSyntax let fromInteger = id -- ghci session - $ ghci GHCi, version 7.4.1: http://www.haskell.org/ghc/ :? for help Loading package ghc-prim ... linking ... done. Loading package integer-gmp ... linking ... done. Loading package base ... linking ... done. Prelude :t 5 5 :: Integer Prelude :t [[1,2],3] interactive:1:8: Couldn't match expected type `[Integer]' with actual type `Integer' Expected type: Integer - [Integer] Actual type: Integer - Integer In the expression: 3 In the expression: [[1, 2], 3] - The same in gofer - Gofer session for: pustd.pre ? :t [[1,2],3] ERROR: Type error in list *** expression : [[1,2],3] *** term : 3 *** type : Int *** does not match : [Int] -- So the error is occurring at the point of the fromInteger (= id) but the message does not indicate that -- http://www.the-magus.in http://blog.languager.org ___ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe
Re: [Haskell-cafe] Can cabal be turned into a package manager?
On Thu, Dec 13, 2012 at 11:46 PM, Badi' Abdul-Wahid abdulwah...@gmail.comwrote: Just my two cents: Nix is great, Modules is not perfect, but it is good. I think that Nix solves a lot of the problems, but will likely take a while to be adopted. I'm still exploring Nix and NixOS, but I have to say: I really like it. I've found that a practical solution for my own development work has been the modules project [1]. Thanks. modules looks quite low level. Better low level and working!! Do you know about emacs/ghci integration? ___ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe
Re: [Haskell-cafe] Can cabal be turned into a package manager?
On Wed, Dec 12, 2012 at 11:25 PM, Ertugrul Söylemez e...@ertes.de wrote: Janek S. fremenz...@poczta.onet.pl wrote: In the recent months there was a lot of dicussion about cabal, dependency hell and alike. After reading some of these discussions there is a question I just have to ask: Why not create a package manager (like rpm or apt) for Haskell software? There is no need to reinvent that. See below. I've been using Linux for years. Software for Linux is mostly written in C and C++. There are thousands of libraries with lots of dependencies and yet: a) Linux distributions manage to have package repositories that are kept in a consistent state b) Linux package managers can avoid dependency hell, automatically update to new packages, etc. Linux people did it! Is there any technical issue that prevents Haskell people from doing exactly the same thing? Or are we just having non-technical problems like lack of money or developers? Actually Linux distributions do all the hard work for you. Package maintainers know what I'm talking about. It's a difficult task to specify correct dependencies, tedious to negotiate with all the other developers and all in all provide a consistent system. But that's only half of the story. The problem starts with the File Hierarchy Standard (FHS), which essentially doesn't allow you to employ a more useful concept. That's why an experimental (yet quite usable) Linux distribution called NixOS [1] has established. It recognizes the problems of the FHS. The solution is simple and radical: the FHS sucks, so ignore it. NixOS uses the Nix package manager, which you can also use for your Haskell packages to escape from the dependency hell. With Nix you can even allow all users to install arbitrary packages without interfering with other users, even the same packages with different versions. Two programs can depend on different versions of the same library, etc. It's the package manager of the future. Unfortunately the concept is new and different enough that it will be difficult to convince a large portion of the Linux community to employ it. It's the same issue Haskell has in the programming language world. There is no need to switch to NixOS to use Nix. You can even install it in your home directory. [1]: http://nixos.org/ Thanks Ertugrul for mentioning nix. My initial study of nix looked very promising as a solution to cabal-hell[2] but it seemed to suggest that one needs to change the whole OS! I must say that I am still dilly-dallying between cabal-dev virthualenv and nix and would appreciate a push! [2] I believe that saying cabal-hell is part of the problem with cabal-hell. A more correct phrase may be Haskell-has-no-standardized-package-manager-hell (which is a bit long!) ___ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe
Re: [Haskell-cafe] education or experience?
Thanks Doug for reminding me of points that I had forgotten (and which are new) I will insert them into the blog My comments inline On Sun, Dec 9, 2012 at 10:01 PM, Doug McIlroy d...@cs.dartmouth.edu wrote: Yes... CS academics delivers less than it could/should; and whatever this delivery is, its asymptotically sub-linear. Some of it is to do with the not-quick-enough takeup of FP in academia, though there are obviously many other factors as well. http://blog.languager.org/2011/02/cs-education-is-fat-and-weak-1.html and sequel is about this: how we are not getting over the quirks of the past history of CS in present day teaching. Here too suggestions for modifications/ change of emphasis are appreciated. Rusi's cogent blog post includes a list of techniques/concepts that the unconverted could profitably pick up from the FP community. In fact the FP community came late to some of these, just as programming languages at large came late to garbage collection. Lazy evaluation--at the heart of spreadsheets since the beginning. Never thought of that -- nice! Pattern matching--native to string processing (e.g. COMIT, SNOBOL). Snobol -- yes, comit Ive heard of but dont know Appeared nearly in its present form in COGENT (1965). Hmm google gives me different cogents/ I guess you are referring to the Reynolds one? Booleans as first class*--surely this is a joke. Algol 60 had them. Not sure what you are saying (unless its about the footnote that Boole treated bools as ints! This is new to me) I was referring to the fact that C programmers have great difficulty thinking of bools as first class for similar reasons to why lists as first class is hard. [And python programmers also for that matter, whose language does not have a proper first class bool type] Matlab exploits them heavily (though represented as doubles). Not sure what you are referring to Data orientation--COBOL fostered this outlook; see Michael Jackson. Interesting! I wonder though whether you and I use 'data-orientation' in the same way? See below. As long as Lisp ruled, FP lagged on data types. A tendentious point: A lisper would say that since Lisp from the beginning had a universal data-type, it need never bother to restrict types. [Note I recollect first hearing the term data orientation from SICP] FP also deserves credit for infinite data structures (though the special case of stream processing dates way back). Doug McIlroy * It's amusing to note that real Booleans--the ones that Boole used--were integers. For Boole, or(a,b) = a + b - a*b. ___ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe -- http://www.the-magus.in http://blog.languager.org ___ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe
Re: [Haskell-cafe] education or experience?
On Sun, Dec 9, 2012 at 11:04 PM, Malcolm Wallace malcolm.wall...@me.comwrote: On 9 Dec 2012, at 16:31, Doug McIlroy wrote: In fact the FP community came late to some of these, just as programming languages at large came late to garbage collection. Lazy evaluation--at the heart of spreadsheets since the beginning. Lazy evaluation for the lambda calculus - 1971 (Wadsworth) Lazy evaluation in a programming language - 1976 (HendersonMorris, FriedmanWise) I wouldn't call those dates late, especially since VisiCalc, the first widely-used electronic spreadsheet entered the market in 1978. Regards, Malcolm You are reading an associativity/parse to Doug's post that he probably did not intend. FP came late was meant to apply to the data orientation (I think) thanks to the long domination of Lisp ___ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe
Re: [Haskell-cafe] education or experience?
On Mon, Dec 10, 2012 at 5:33 AM, Doug McIlroy d...@cs.dartmouth.edu wrote: Matlab exploits them heavily (though represented as doubles). Not sure what you are referring to I had in mind Matlab's frequent use of a Boolean array as a characteristic function describing some property of the elements of another array. Such arrays are used to control other array operations. In this usage, the characteristic array may be optimized out of existense, but it fosters higher-level thinking and concise code. In which case it goes back to APL's compress operator ie 1960. http://www.aplusdev.org/APlusRefV2_8.html#HEADING179 Heres a session that demonstrates A+ Copyright (c) 1990-2008 Morgan Stanley. All rights reserved. This version is Release 4.22 a ← 1 2 3 4 5 b ← 1 0 1 1 0 b/a 1 3 4 b ← 1 0 2 1 0 b/a 1 3 3 4 -- http://www.the-magus.in http://blog.languager.org ___ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe
Re: [Haskell-cafe] education or experience?
On Sun, Dec 9, 2012 at 7:04 AM, Jerzy Karczmarczuk jerzy.karczmarc...@unicaen.fr wrote: For me, opposing experience and education is simply silly. Probably more than 70% of all people would learn much faster on their own than at school. But, learn WHAT? : 1. Probably less than 1% would guess correctly what they SHOULD learn, and 2. in general they will not be able to assess their own knowledge... Very good points Haskell kneads the avant garde type-hackery stuff with classical (Hindley-Milner) functional programming very seamlessly. For the programing-pro this is a joy and a thrill. The beginner however can get completely unnerved that misplacing a bracket or forgetting an argument gives error messages involving type classes, suggestions turning on/off arcane compiler options etc etc. FWIW I have a list of points/items trying to address this issue: http://blog.languager.org/2012/10/functional-programming-lost-booty.html Please note this is work-in-progress: additions/modifications are appreciated. On Sun, Dec 9, 2012 at 4:21 AM, Roman Cheplyaka r...@ro-che.info wrote: Compared to an academic career, you'll have a more real goal of making good software (instead of publishing papers). Also, this experience will be much more relevant for your future job. Yes... CS academics delivers less than it could/should; and whatever this delivery is, its asymptotically sub-linear. Some of it is to do with the not-quick-enough takeup of FP in academia, though there are obviously many other factors as well. http://blog.languager.org/2011/02/cs-education-is-fat-and-weak-1.html and sequel is about this: how we are not getting over the quirks of the past history of CS in present day teaching. Here too suggestions for modifications/ change of emphasis are appreciated. Rusi -- http://www.the-magus.in http://blog.languager.org ___ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe
Re: [Haskell-cafe] Design of a DSL in Haskell
On Sun, Dec 2, 2012 at 7:31 PM, Joerg Fritsch frit...@joerg.cc wrote: This is probably a very basic question. I am working on a DSL that eventuyally would allow me to say: import language.cwmwl main = runCWMWL $ do eval (isFib::, 1000, ?BOOL) I have just started to work on the interpreter-function runCWMWL and I wonder whether it is possible to escape to real Haskell somehow (and how?) either inside ot outside the do-block. I thought of providing a defautl-wrapper for some required prelude functions (such as print) inside my interpreter but I wonder if there are more elegant ways to co-loacate a DSL and Haskell without falling back to being a normal library only. --Joerg +1 I am also interested in the DSL-in-Haskell possibilities [I am assuming Joerg that you're familiar with the basic ideas and terminology like http://martinfowler.com/bliki/DomainSpecificLanguage.html and the links therein] Rusi -- http://www.the-magus.in http://blog.languager.org ___ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe
[Haskell-cafe] Optimal line length for haskell
There was a recent discussion on the python list regarding maximum line length. It occured to me that beautiful haskell programs tend to be plump (ie have long lines) compared to other languages whose programs are 'skinnier'. My thoughts on this are at http://blog.languager.org/2012/10/layout-imperative-in-functional.html. Are there more striking examples than the lexer from the standard prelude? [Or any other thoughts/opinions :-) ] Thanks, Rusi ___ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe
Re: [Haskell-cafe] Optimal line length for haskell
On Mon, Oct 29, 2012 at 5:29 PM, Iustin Pop ius...@google.com wrote: On Mon, Oct 29, 2012 at 05:20:20PM +0530, Rustom Mody wrote: There was a recent discussion on the python list regarding maximum line length. It occured to me that beautiful haskell programs tend to be plump (ie have long lines) compared to other languages whose programs are 'skinnier'. My thoughts on this are at http://blog.languager.org/2012/10/layout-imperative-in-functional.html. Are there more striking examples than the lexer from the standard prelude? [Or any other thoughts/opinions :-) ] For what is worth, in our project (Ganeti) which has a mixed Python/Haskell codebase, we're using the same maximum length (80-but-really-79) in both languages, without any (real) issues. regards, iustin Sure! There can hardly be a case that 80 causes any issues. Just that a bit more than 80 can sometimes lead to distinctly more elegant programs. Too much more than 80 can cause issues with readability and/or other tools. ___ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe
Re: [Haskell-cafe] Optimal line length for haskell
On Mon, Oct 29, 2012 at 5:40 PM, Malcolm Wallace malcolm.wall...@me.comwrote: It is kind of ironic that the wide code examples in the blog post are wrapped at 65 chars by the blog formatting. Regards, Malcolm Well that goes to underscore a couple of points: 1. The fixed 80 char width that was inviolable decades ago breaks today on both sides: it may be too low or too high! 2. I guess I dont know how to use blogger very well :-) 3. Are you viewing on a narrow device? ___ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe
Re: [Haskell-cafe] Optimal line length for haskell
On Mon, Oct 29, 2012 at 5:55 PM, Colin Adams colinpaulad...@gmail.comwrote: I'm not viewing on a narrow device, and I see the wrapped (and the whole post confined to the centre of the screen). I certainly don't use an 80-column limit any more. I use the rule: A function must be completely visible in my editor on my screen. (but this is only a good rule if most people who will be reading the code will also have a similar sized viewport. After all, code is far more often read than written.) And I balance line length with function length. Very good point: getting the line to fit in one screen-line is of comparable importance to getting a function into one screen. And especially when one is teaching, (as Roman easily figured out!) having to scroll up and down in the midst of explanations is a certain show-spoiler. On Mon, Oct 29, 2012 at 6:40 PM, Mike Meyer m...@mired.org wrote: On the other hand, readable cross-platform text formatting always seems to be a lost cause, as this mail and the referenced blog posting demonstrate. -- Sent from my Android tablet with K-9 Mail. Please excuse my swyping. As for the wraparound problems, hopefully they are now solved (for normal computers!) I'd appreciate hearing if they are not. And Thanks Colin for the debugging support! Clearly prettifying code and prettifying a blog are different issues and putting them together makes a harder constraint-solving problem (especially for a blogger noob!) Rusi ___ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe
Re: [Haskell-cafe] Optimal line length for haskell
On Mon, Oct 29, 2012 at 7:58 PM, Alexander Solla alex.so...@gmail.comwrote: On Mon, Oct 29, 2012 at 6:52 AM, Michael Orlitzky mich...@orlitzky.comwrote: On 10/29/2012 07:50 AM, Rustom Mody wrote: There was a recent discussion on the python list regarding maximum line length. It occured to me that beautiful haskell programs tend to be plump (ie have long lines) compared to other languages whose programs are 'skinnier'. My thoughts on this are at http://blog.languager.org/2012/10/layout-imperative-in-functional.html. Are there more striking examples than the lexer from the standard prelude? [Or any other thoughts/opinions :-) ] In any language, a line longer than 80 characters usually (but not always) suggests that you might want to stop and rethink your design. In many cases a refactoring or two will greatly simplify the code and reduce your line length as a result. I disagree. That might be true for imperative languages, where width is indicative of deep nesting and its associated problems. But it is not true for a functional language, where it is merely indicative of a wide normal form. Yes, the normal form can sometimes be refactored, but to what end? You might easily end up refactoring out of the level of abstraction you actually want. Or the wide form might have useful properties, like the ability to sort the lines of source code alphanumerically (which would be lost if you switched to a stanza-based format) Interesting points. In fact my wish for using (when appropriate) a wide form is related to some hunch about this 'wide normal form' Can you throw some light on how one may understand that phraset? Also BTW Ive cleaned up the post again. Since my ineptitude with blogger was looking like an ineptitude with haskell (which may well be there and more :-) ) Ive moved the wide code to gist. I believe the code examples speak differently in this new format Rusi -- http://blog.languager.org ___ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe
Re: [Haskell-cafe] [Off-topic] How unimportant it is whether submarines can swim (EWD1056)
On Sat, Oct 27, 2012 at 2:21 AM, Henk-Jan van Tuyl hjgt...@chello.nlwrote: L.S., I thought you might be interested to know, that I have translated one of prof. Edsger W. Dijkstra's writings to English[0]. I will submit this translation to the E. W. Dijkstra Archive of the University of Texas[1]. Some of the highlights: - can submarines swim? - redefining mathematics - something unimaginably unimaginable - a baby faster than fighter jets Regards, Henk-Jan van Tuyl Thank you Henk-Jan for doing this -- It's always a treat reading Dijkstra! I had some small corrections to make but it seems others have already spotted them. Only one general comment: Your use of courier font quite threw me off -- I thought I was reading 'an original EWD nnn' … until I saw the last line -- Translated by Henk-Jan van Tuyl 2012-10-13! Dijkstra's connection with functional programming is enigmatic and very interesting. On the one hand he seems to say that the only proper languages are imperative, yet at the meta level, his semantics has a strong kind of functional flavour -- he would argue that his semantics are more functional than even denotational semantics! In particular, there is one small notational point that he insisted on towards the end of his career (and life) viz. where traditional mathematicians write *f(x) *and functional programmers write *f x*, he would write *f.x* , ie he showed apply with a '.' In trying to understand his intentions, I wrote the following 'thought-dialogue' [as in thought-experiment :-) ] http://www.the-magus.in/Publications/ewd.pdf Regards Rusi ___ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe
Re: [Haskell-cafe] Tutorial: Haskell for the Evil Genius
On Sun, Sep 16, 2012 at 8:18 PM, Tillmann Rendel ren...@informatik.uni-marburg.de wrote: Hi, Kristopher Micinski wrote: Everyone in the Haskell cafe probably has a secret dream to give the best five minute monad talk. (1) Most programming languages support side effects. There are different kinds of side effects such as accessing mutable variables, reading files, running in parallel, raising exceptions, nondeterministically returning more than one answer, and many more. Most languages have some of these effects built into their semantics, and do not support the others at all. (2) Haskell is pure, so it doesn't support any side effects. Instead, when Haskell programmers want to perform a side effect, they explicitly construct a description of the side effecting computation as a value. For every group of related side effects, there is a Haskell type that describes computations that can have that group of side effects. (3) Some of these types are built in, such as IO for accessing the world outside the processor and ST for accessing local mutable variables. Other such types are defined in Haskell libraries, such as for computations that can fail and for computations that can return multiple answers. Application programmers often define their own types for the side effects they need to describe, tailoring the language to their needs. (4) All computation types have a common interface for operations that are independent of the exact side effects performed. Some functions work with arbitrary computations, just using this interface. For example, we can compose a computation with itself in order to run it twice. Such generic operations are highly reusable. (5) The common interface for constructing computations is called Monad. It is inspired by the mathematical theory that some computer scientists use when they describe what exactly the semantics of a programming language with side effects is. So most other languages support some monad natively without the programmer ever noticing, whereas Haskell programmers can choose (and even implement) exactly the monads they want. This makes Haskell a very good language for side effecting computation. Tillmann http://blog.languager.org Very nice! Except that perhaps I'd rewrite the last line as: ...makes Haskell a good language for playing with alternative paradigms of side-effecting computation though mine is not as pithy as yours! Rusi http://blog.languager.org ___ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe
Re: Kindness of strangers (or strangeness of Kinds)
On Thu, Jun 7, 2012 at 7:16 AM, AntC anthony_clay...@clear.net.nz wrote: I'm confused about something with promoted Kinds (using an example with Kind- promoted Nats). This is in GHC 7.4.1. (Apologies if this is a known bug/limitation/already explained somewhere Is there a way of seeing kinds in ghci? [In gofer I could do :s +k -- yeah this was 20 years ago :-) ] ___ Glasgow-haskell-users mailing list Glasgow-haskell-users@haskell.org http://www.haskell.org/mailman/listinfo/glasgow-haskell-users
Re: [Haskell-cafe] Need inputs for a Haskell awareness presentation
On Thu, May 31, 2012 at 11:53 PM, C K Kashyap ckkash...@gmail.com wrote: Hi folks, I have the opportunity to make a presentation to folks (developers and managers) in my organization about Haskell - and why it's important - and why it's the only way forward. You (and we) may believe that but saying so usually does not work. What is more likely to work is talking to people about what interests them (rather than you :-) ). For example teachers of CS are usually struck by and bowled over by quicksort in 2 lines because for them teaching quicksort is considered an important activity. Professional object-oriented programmers are unlikely to take to such an 'academic' example kindly. Likewise those interested in algorithms and data-structures would be caught by a (tree) dfs in 1 line, or that a graph dfs and bfs are the same except that a [x] ++ pending becomes pending ++ [x] But if they were not so interested in algos and data-structures (Java programmers more than C++ are particularly prone to being using-happy, understanding-chary) this example would not work. So in short find what matters to your audience and then survey, focus and drill into that -- using Haskell I request you to share your experiences/suggestions for the following - 1. Any thoughts around the outline of the presentation - target audience being seasoned imperative programmers who love and live at the pinnacle of object oriented bliss. 2. Handling questions/comments like these in witty/interesting ways - a) It looks good and mathematical but practically, what can we do with it, all our stuff is in C++ b) Wow, what do you mean you cannot reason about its space complexity? c) Where's my inheritance? Yes you need to find a hot OO guru saying that inheritance is best avoided where templates/STL etc work d) Debugging looks like a nightmare - we cannot even put a print in the function? Maybe a (concocted) example of how the typechecker does most of the debugging for you? Better of course if the example is genuinely hacked out in front of the class (ideally from some thing they want to see solved) that can be convincing re things like debugging. This also brings up what is (for me) a very important point regarding haskell -- using an interpreter, ie ghci. -- the tight feedback loop -- not being bound to having to write a main -- the general sense of a workbench in which various objects (some joke here for the OO guys?) are are in different states of under construction to shrink-wrapped Personally I do not see how I could teach (or do) haskell without emacs. Admittedly this attracts some strongly and repels others equally strongly e) Static types - in this day and age - come on - productivity in X is so much more - and that's because they got rid of type mess. f) Is there anything serious/large written in it? [GHC will not qualify as a good answer I feel] g) Oh FP, as in Lisp, oh, that's AI stuff right ... we don't really do AI. h) Any other questions/comments that you may have heard. 3. Ideas about interesting problems that can be used so that it appeals to people. I mean, while fibonacci etc look good but showing those examples tend to send the signal that it's good for those kind of problems. 4. Is talking about or referring to Lambda calculus a good idea - I mean, showing that using its ultra simple constructs one could build up things like if/then etc I'm gonna do my bit to wear the limestone!!! Regards, Kashyap ___ 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] Correspondence between libraries and modules
On Wed, May 23, 2012 at 9:44 PM, Gregg Lebovitz glebov...@gmail.com wrote: Rustom, I am drafting a document that captures some of the social norms from the comments on this list, mostly from Brandon and Wren. I have captured the discussion about module namespace and am sorting out the comments on the relationship between libraries and packages. My initial question to the list was to try an identify where Haskell is different from other open source distributions. From what I can tell, the issues are very similar. The module name space seems to have characteristics very similar to the include file hierarchy of linux distributions. If you have some spare cycles and would like to contribute, I think everyone would appreciate your help and effort Gregg Hi Gregg. One of the common complaints one gets from a first year programming student (and its now about 3 decades I dealing with these!) is: The compiler/interpreter etc HAS a BUG!!! So... While I am an old geezer with programming and functional programming -- doing, teaching, playing, implementing, or just plain thinking but -- I am too much of a noob to ghc to risk falling into the 1st year student trap above. Yes perhaps not a typical noob... Somethings are easier for me than the typical noob -- all the 'classical' good-stuff like pattern-matching, lambda-calculus, type-inferencing, polymorphism etc. And this is helpful to understand the 'modern good stuff' starting monads and onwards But then I get hit -- finding my way round hackage, installing with cabal etc -- even tho I'm an ol-time unix hacker and sysadmin-er. So I guess its best to assume (as of now) that I dont know the ropes rather than something is wrong/broken with them. O well... If the noob trap is one error playing it safe is probably another so here goes with me saying things that I (probably) know nothing about: 1. cabal was a beautiful system 10 years ago. Now its being forcibly scaled up 2 (3?) orders of magnitude and is creaking at the seams 2. There's too much conflicting suggestions out there on the web for a noob - use system install (eg apt-get) or use cabal - cabal in user area or system area etc - the problem is exponentiated by the absence of cabal uninstall ___ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe
Re: [Haskell-cafe] Correspondence between libraries and modules
On Tue, Apr 24, 2012 at 7:29 PM, Gregg Lebovitz glebov...@gmail.com wrote: On 4/23/2012 10:17 PM, Brandon Allbery wrote: On Mon, Apr 23, 2012 at 17:16, Gregg Lebovitz glebov...@gmail.comwrote: On 4/23/2012 3:39 PM, Brandon Allbery wrote: The other dirty little secret that is carefully being avoided here is the battle between the folks for whom Haskell is a language research platform and those who use it to get work done. It's not entirely inaccurate to say the former group would regard a fragmented module namespace as a good thing, specifically because it discourages people from considering it to be stable Brandon, I find that a little hard to believe. If the issues are similar to other systems and languages, then I think it is more likely that no one has volunteered to work on it. You volunteering to help? Does haskell/hackage have something like debian's lintian? Debian has a detailed policy document that keeps evolving: http://www.debian.org/doc/debian-policy/ Lintian tries hard to automate (as much as possible) policy-compliance http://lintian.debian.org/manual/index.html Eg how packages should use the file system http://tldp.org/LDP/Linux-Filesystem-Hierarchy/html/ Even 'boring' legal stuff like license-checking is somewhat automated http://dep.debian.net/deps/dep5/ And most important is the dos and donts for package dependency making possible nice pics http://collab-maint.alioth.debian.org/debtree/ Of course as Wren pointed out, the Linux communities have enough manpower to police their distributions which haskell perhaps cannot. My question is really: Would not something like a haskell-lintian make such sanity checking easier and more useful for everyone? ___ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe
Re: [Haskell-cafe] Embed Haskell
On Sun, Apr 22, 2012 at 9:29 PM, Rosario Borda
rosario.bo...@sinervis.comwrote:
Hi All,
Is there a simple method for embed haskell in other languages, like latex?
An example in quasiquotation notation:
\documentclass{article}
\title{Hello World}
\begin{document}
\maketitle
Hello world! and reversed: [haskell: putStrLn reverse Hello, World!]
\end{document}
Many thanks, :)
Rosario
You may want to look at babel: http://orgmode.org/worg/org-contrib/babel/
Haskell is one of the babel languages
http://orgmode.org/worg/org-contrib/babel/languages.html
___
Haskell-Cafe mailing list
Haskell-Cafe@haskell.org
http://www.haskell.org/mailman/listinfo/haskell-cafe
Re: [Haskell-cafe] If you'd design a Haskell-like language, what would you do different?
On Sat, Dec 24, 2011 at 8:20 PM, Alexander Solla alex.so...@gmail.comwrote: On Wed, Dec 21, 2011 at 8:39 PM, MigMit miguelim...@yandex.ru wrote: On 22 Dec 2011, at 06:25, Alexander Solla wrote: Denotational semantics is unrealistic. And so are imaginary numbers. But they are damn useful for electrical circuits calculations, so who cares? Not a fair comparison. Quaternions are not particularly useful for electrical circuits, because it is unrealistic to apply a four-dimensional construct to two-dimensional phase spaces. In the same way, denotational semantics adds features which do not apply to a theory of finite computation. The /defining/ feature of a bottom is that it doesn't have an interpretation. What do you mean by interpretation? You know, the basic notion of a function which maps syntax to concrete values. http://en.wikipedia.org/wiki/Model_theory They should all be treated alike, and be treated differently from every other Haskell value. But they ARE very similar to other values. They can be members of otherwise meaningful structures, and you can do calculations with these structures. fst (1, _|_) is a good and meaningful calculation. Mere syntax. What is fst doing? It computes forall (x,y) |- x. Using the language of model theory, we can say that Haskell computes an interpretation forall (x,y) |= x. It is _|_ that lacks an intepretation, not fst. We can see that by trying fst (_|_,1), which reduces to _|_ by the proof rule for fst. _|_ lacks an interpretation, so the run-time either loops forever or throws an error (notice that error throwing is only done with compiler magic -- if you define your own undefined = undefined, using it will loop. GHC is specially trained to look for Prelude.undefined to throw the undefined error.) Every other Haskell value /does/ have an interpretation. So, (_|_) is bad, but (1, _|_) is good? I did not introduce good and bad into this discussion. I have merely said (in more words) that I want my hypothetical perfect language to prefer OPERATIONAL (model) SEMANTICS for a typed PARACONSISTENT LOGIC over the DENOTATIONAL SEMANTICS which the official documentation sometimes dips into. Using examples from denotational semantics is not going to change my mind about the applicability of one or the other. It is clear that denotational semantics is a Platonic model of constructive computation. You make it sound as though platonism is somehow bad. Before we get into that lets look at a capsule of our history: Kronecker and Cantor disagree on whether sets exist. K: God created the natural numbers; all the rest is the work of man. C: All manner of infinite sets exist (presumably in the mind of God?) A generation later and continuing, Hilbert and Brouwer disagree on what constitutes a proof. A little later Goedel sets out to demolish Hilbert's formalist agenda. The (interpretations of) Hilbert's philosophical position is particularly curious: For Brouwer, Hilbert is wrong because he is a platonist -- believes in completed infinities For Goedel, Hilbert is wrong because he is not a platonist -- he is looking for mechanizable proofs. Talk of two stools!! Turing tries to demolish Goedel. His real intention is AI not the Turing machine. He does not succeed -- simple questions turn out to be undecidable/non-computable. However a 'side-effect' (ahem) of his attempts via the TM is ... the computer. That Goedel was a (mostly closet) platonist: http://guidetoreality.blogspot.com/2006/12/gdels-platonism.html Am I arguing that platonism is good? Dunno... I am only pointing out that the tension between platonism and its opponents (formalist, empiricist, constructivist etc) is evidently a strong driver for progress BTW a more detailed look at the historical arguments would show that the disagreements were more violent than anything on this list :-) Hopefully on this list we will be cordial and wish each other a merry Christmas! ___ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe
Re: [Haskell-cafe] If you'd design a Haskell-like language, what would you do different?
2011/12/22 Gábor Lehel illiss...@gmail.com On Mon, Dec 19, 2011 at 8:20 PM, Robert Clausecker fuz...@gmail.com wrote: Image you would create your own language with a paradigm similar to Haskell or have to chance to change Haskell without the need to keep any compatibility. What stuff would you add to your language, what stuff would you remove and what problems would you solve completely different? Thanks in advance for all answers, yours Robert Clausecker I would have compose (probably not called '.') read the same way we read this sentence (and unix pipes) ie left to right. I would not overload . to mean compose and module-access. Probably gadt could be the norm and classic 'data' could be removed. ___ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe
Re: [Haskell-cafe] indentation blues
Is the haskell-mode that comes out of the box with emacs (v 23.3) the one you folk use or do you use something more specific/uptodate? How to find out? [There should be a haskell-mode-version...] To the folks from the (hesitating) vi-camp: Whatever you use, please take time to familiarize yourself with ghci. Its my finding that the majority of vi aficionados imagine that programming is invariably tied to - having a main - built with make - run from a shell - back to vi This is way less performant than the tight feedback that an interpreter gives. And for that ghci in an 'inferior' emacs buffer is better than anything else (for me). However vi-users can (probably?) use two shells -- one for vi, one for ghci ___ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe
Re: [Haskell-cafe] Program used for debugging
On Thu, Dec 1, 2011 at 7:40 PM, Yves Parès limestr...@gmail.com wrote: Hey, What do you mostly use for debugging? Simple calls to Debug.Trace.trace? Hpc? Hood? I also wonder about 'type-debugging' Using ghci: For a top level expression: - if it is not compiling I can put in (or remove) a type decl and see how things change. - if it is compiling I can of course :t it But for internal expressions it can be quite hairy to figure out why what haskell thinks is the type of something and what I think dont match. So is there something like type-intellisense for haskell where if one hovers the mouse (maybe over a selection) haskell tells what type it finds there? ___ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe
source/build separation
I am building ghc from source. The building page http://hackage.haskell.org/trac/ghc/wiki/Building/Using#Sourcetreesandbuildtrees mentions lndir for separating source trees from build trees. Given how much detail is generally given for individual commands eg http://hackage.haskell.org/trac/ghc/wiki/Building/GettingTheSources maybe it would be nice to have a (typical?) lndir command also given? Also there is a mention about using a local git clone here http://hackage.haskell.org/trac/ghc/wiki/Building/GettingTheSources Arent these two alternative ways with similar intent - viz. keeping source pristine and separating build 'messiness'? Or do people use both git (local) clone + lndir? If so why? Rusi [ghc noob here: Please tell me if this is the wrong list to ask this kind of question :-) ] ___ Glasgow-haskell-users mailing list Glasgow-haskell-users@haskell.org http://www.haskell.org/mailman/listinfo/glasgow-haskell-users
[Haskell-cafe] capri cabal-dev virtualenv cab
Does anyone give me a little comparison of these? What would all my requirements be? Not sure... these seem important for me 1. Need to sandbox not just haskell-projects but ghc (different compilations/versions) itself 2. Stability of the (sandboxing) tool 3. Correcting the deficiencies of cabal (eg inability to uninstall, quarrels between cabal and apt etc) OS: Debian/testing System haskell: 7.0.4 My question on beginners for a little more context: http://www.haskell.org/pipermail/beginners/2011-November/008943.html capri: http://www.haskell.org/haskellwiki/Capri virtualenv: https://github.com/Paczesiowa/virthualenv cabal-dev: http://corp.galois.com/blog/2010/12/20/cabal-dev-sandboxed-development-builds-for-haskell.html cab: http://www.mew.org/~kazu/proj/cab/en/ ___ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe
Re: [Haskell-cafe] Libraries to compare trees?
On Fri, Oct 28, 2011 at 8:54 PM, Ozgur Akgun ozgurak...@gmail.com wrote: Hi. On 27 October 2011 13:49, dokondr doko...@gmail.com wrote: Please advise on Haskell libraries to compare trees in textual representation. I need to compare both structure and node contents of two trees, find similar sub-trees, and need some metric to measure distance between two trees. This might help: http://hackage.haskell.org/package/gdiff-1.0 Best, Ozgur This is interesting. Just putting some thoughts here. Please comment. I am a user of emacs org-mode http://orgmode.org/. Basically org imposes a tree structure onto plain text and when that is appropriate its quite a nifty tool. Recently there was some discussion on the org list that diffs of org files were less than useful because while org understands hierarchical structure, diff doesn't. I wonder what would be involved in setting up a bi-directional pipe between emacs and haskell so that orgmode could use gdiff's findings? ___ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe
Re: [Haskell-cafe] ANN: diagrams 0.4
On Tue, Oct 25, 2011 at 10:40 AM, Ivan Lazar Miljenovic ivan.miljeno...@gmail.com wrote: On 25 October 2011 16:02, Rustom Mody rustompm...@gmail.com wrote: On Mon, Oct 24, 2011 at 10:16 AM, Ivan Lazar Miljenovic ivan.miljeno...@gmail.com wrote: On 24 October 2011 13:51, Rustom Mody rustompm...@gmail.com wrote: How does diagrams compare with graphviz? If this is an inappropriate (type-wrong?) question thats ok :-) Its just that when I last looked at graphviz I found the documentation somewhat impenetrable -- like much else in Hackage -- lots of types, no examples. How is it now, better? If not, what kind of more documentation would you like? Without claiming to have looked very hard, I looked up grahhviz in hayoo, gathered I should be looking at Data.GraphViz and tried clicking everything that looked reasonable here but still cant find an example of a graph :-) ie a graphviz graph in haskell. Well, there are indeed examples in there, but not in Data.GraphViz: that module is aimed more at how can I convert my existing data into a Dot representation, not constructing one by hand. As of the latest version (2999.12.*), there are indeed examples for anyone that wants them: * Sample graph in Dot representation used as a base case: http://hackage.haskell.org/packages/archive/graphviz/2999.12.0.3/doc/html/Data-GraphViz-Types.html * Using the canonical representation: http://hackage.haskell.org/packages/archive/graphviz/2999.12.0.3/doc/html/Data-GraphViz-Types-Canonical.html * Using the graph representation: http://hackage.haskell.org/packages/archive/graphviz/2999.12.0.3/doc/html/Data-GraphViz-Types-Generalised.html * Using the Monadic representation (based upon the dotgen package): http://hackage.haskell.org/packages/archive/graphviz/2999.12.0.3/doc/html/Data-GraphViz-Types-Graph.html Thanks. In the Data.GraphViz.Types.Generalised page you have the starting line: It is sometimes useful to be able to manipulate a Dot graph *as* an actual graph. This representation lets you do so... Evidently some other context is needed to understand this line? [Sorry if I am dense] ___ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe
Re: [Haskell-cafe] ANN: diagrams 0.4
On Mon, Oct 24, 2011 at 10:17 PM, Stephen Tetley stephen.tet...@gmail.comwrote: Rustom Mody rustompm...@gmail.com writes: I remember (vaguely) a 'live page' ie where one could enter (into the browser) changes to the diagrams code and see the results immediately. Is that page there? (Or am I mixing up with something else?) Maybe it was Péter Diviánszky's 'dia' (entirely different to 'diagrams') ? http://pnyf.inf.elte.hu/fp/Diagrams_en.xml Yes that was it (It is called diagrams :-) ___ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe
Re: [Haskell-cafe] ANN: diagrams 0.4
On Mon, Oct 24, 2011 at 10:16 AM, Ivan Lazar Miljenovic ivan.miljeno...@gmail.com wrote: On 24 October 2011 13:51, Rustom Mody rustompm...@gmail.com wrote: How does diagrams compare with graphviz? If this is an inappropriate (type-wrong?) question thats ok :-) Its just that when I last looked at graphviz I found the documentation somewhat impenetrable -- like much else in Hackage -- lots of types, no examples. How is it now, better? If not, what kind of more documentation would you like? Without claiming to have looked very hard, I looked up grahhviz in hayoo, gathered I should be looking at Data.GraphViz and tried clicking everything that looked reasonable here but still cant find an example of a graph :-) ie a graphviz graph in haskell. Is this a complaint against graphviz or against hackage/cabal etc?? Dunno. [Maybe I am just tired] ___ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe
Re: [Haskell-cafe] ANN: diagrams 0.4
Thanks. This is attractive. I remember (vaguely) a 'live page' ie where one could enter (into the browser) changes to the diagrams code and see the results immediately. Is that page there? (Or am I mixing up with something else?) How does diagrams compare with graphviz? If this is an inappropriate (type-wrong?) question thats ok :-) Its just that when I last looked at graphviz I found the documentation somewhat impenetrable -- like much else in Hackage -- lots of types, no examples. On Mon, Oct 24, 2011 at 12:17 AM, Brent Yorgey byor...@seas.upenn.eduwrote: I am pleased to announce the release of version 0.4 of diagrams, a full-featured framework and embedded domain-specific language for declarative drawing. The last announcement was of the 0.1 release; there have been quite a few changes and improvements since then, including: - A new website including a gallery of examples: http://projects.haskell.org/diagrams/gallery.html - A new comprehensive user manual with lots of illustrative examples: http://projects.haskell.org/manual/diagrams-manual.html - New primitive shapes: rounded rectangles, wedges, and a new flexible API for generating polygons - Cubic splines - Basic text support - Support for external image primitives - Lots more convenient combinators, bug fixes, and improvements Cool, how can I try it out? --- For the truly impatient: cabal install gtk2hs-buildtools cabal install diagrams For the slightly less impatient, read the quick tutorial, which has detailed information about how to install the necessary packages and will introduce you to the fundamentals of the framework: http://projects.haskell.org/diagrams/tutorial/DiagramsTutorial.html For those who are even less impatient but want to really dig in and use the power features, read the user manual: http://projects.haskell.org/manual/diagrams-manual.html Cool, how can I contribute? --- There are lots of ways you can contribute! First, you may want to subscribe to the project mailing list (http://groups.google.com/group/diagrams-discuss), and/or come hang out in the #diagrams IRC channel on freenode.org. - There are lots of easy bug fixes, improvements, and feature requests just waiting for people wanting to get involved: see the bug tracker for a list of open tickets: http://code.google.com/p/diagrams/issues/list - The source repositories are mirrored using both darcs (on patch-tag.com) and git (on github.com), and patches are accepted in either place, thanks to Owen Stephen's great work on darcs-bridge [1]. - Create a higher-level module built on top of the diagrams framework (e.g. tree or graph layout, generating Turing machine configuration diagrams, Penrose tilings ... your imagination is the only limit!) and submit it for inclusion in a special diagrams-contrib package which will be created for such higher-level user-contributed modules. - Use diagrams to create some cool graphics and submit them for inclusion in the gallery. - Start your own project built on top of diagrams and let us know how it goes! - Last but certainly not least, just try it out for your pet graphics generation needs and contribute your bug reports and feature requests. Happy diagramming! Brought to you by the diagrams team: - Brent Yorgey - Ryan Yates with contributions from: - Sam Griffin - Claude Heiland-Allen - John Lato - Vilhelm Sjöberg - Luite Stegeman - Kanchalai Suveepattananont - Scott Walck [1] http://wiki.darcs.net/DarcsBridgeUsage ___ 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] lost in generics
I need some help finding my way around the various generics libraries. My usage scenario is -- at least to start with -- the ASTs of programming languages. It appears to me that there are two generations of generics -- earlier there was generic haskell and strafunski Now there is uniplate and kure (and syb? -- not sure of its generation...) I get this impression because I saw a comment somewhat along these lines. And also the very first reference link on the strafunski webpage: http://www.haskell.org/haskellwiki/Applications_and_libraries/Generic_programming/Strafunski viz http://www.cs.vu.nl/Strafunski/ seems to be dead. So I am wondering whether strafunski is still under development or is it defunct? The following paras from http://www.cs.uu.nl/research/techreps/repo/CS-2008/2008-010.pdf The current status of generic programming in Haskell is comparable to the lazy Tower of Babel preceding the birth of Haskell in the eighties [Hudak et al., 2007]. We have many single-site languages or libraries, each individually lacking critical mass in terms of language/library-design effort, implementations, and users. Although generic programming has been used in several applications, it has few users for real-life projects. This is understandable. Developing a large application takes a couple of years, and choosing a particular approach to generic programming for such a project involves a risk. Few approaches that have been developed over the last decade are still supported, and there is a high risk that the chosen approach will not be supported anymore, or that it will change in a backwards-incompatible way in a couple of years time. sound omninous :-) In general my question is: What is alive/active and what is alive/active and what is -- um -- moved-on-from. And of course which are easier and which more difficult to dig into. Thanks Rusi ___ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe
[Haskell-cafe] what's the best environment for haskell work?
Do most people who work with haskell use emacs/vi/eclipse or something else?? Personal Note: I used gofer some 15 years ago. At that time I hacked up a emacs mode (I did not know of any then) along with some changes to gofer to have gofer inside emacs rather than vi inside gofer. Things have got more exciting now -- just trying to catch up!! [Note: My preferrred/default OS is debian-squeeze] ___ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe
