From info@polirami.de Sat Feb 2 22:57:37 2002 From: info@polirami.de (Johannes Goetz) Date: Sat, 2 Feb 2002 23:57:37 +0100 Subject: compiling hdirect In-Reply-To: <3C48BC11.1622A2E4@bawi.org> Message-ID: This is a multi-part message in MIME format. ------=_NextPart_000_0008_01C1AC45.650609E0 Content-Type: text/plain; charset="ks_c_5601-1987" Content-Transfer-Encoding: 7bit Hi there! A ./configure in the fptools root directory gives me $ ./configure *** The top of your build tree is: /home/Administrator/fucker checking build system type... i686-pc-cygwin checking host system type... i686-pc-cygwin checking target system type... i686-pc-cygwin Canonicalised to: i386-unknown-cygwin32 checking for ghc... /cygdrive/c/ghc/ghc-5.02.2/bin/ghc checking version of ghc... 5.02.2 checking for nhc... no checking for nhc98... no checking for hbc... no checking whether #! works in shell scripts... yes checking for perl... /bin/perl checking if your perl works in shell scripts... yes checking for gcc... gcc checking for C compiler default output... a.exe checking whether the C compiler works... yes checking whether we are cross compiling... no checking for executable suffix... .exe checking for object suffix... o checking whether we are using the GNU C compiler... yes checking whether gcc accepts -g... yes checking whether you have an ok gcc... yes checking how to run the C preprocessor... gcc -E checking whether gcc accepts -mwin32... yes checking whether gcc accepts -mno-cygwin... yes checking for ok way to do context diffs... diff -C 1 checking for find... /usr/bin/find checking for bison... bison -y checking for flex... flex checking for a BSD compatible install... /usr/bin/install -c checking for ar... /usr/bin/ar checking whether ln -s works... yes checking for sed... /usr/bin/sed checking for time... no checking for gtar... no checking for tar... /usr/bin/tar checking for gzip... /usr/bin/gzip checking for openjade... no checking for jade... no checking for DocBook CATALOG... no Warning: You will not be able to build the documentation. checking for happy... /cygdrive/c/happy/happy-1.11/bin/happy checking for version of happy... 1.11 checking for ANSI C header files... no checking for Files.h... no checking for arpa/inet.h... no checking for assert.h... no checking for console.h... no checking for ctype.h... no checking for dirent.h... no checking for errno.h... no checking for fcntl.h... no checking for float.h... no checking for ftw.h... no checking for grp.h... no checking for ieee754.h... no checking for inttypes.h... no checking for limits.h... no checking for malloc.h... no checking for memory.h... no checking for nlist.h... no checking for pascal.h... no checking for pwd.h... no checking for sgtty.h... no checking for siginfo.h... no checking for signal.h... no checking for stat.h... no checking for stdint.h... no checking for stdlib.h... no [...] Why doesnt the configure script recognize the header files? Compiling programs using gcc works fine as usual. Does somebody know what's wrong here? Thanks Johannes ------=_NextPart_000_0008_01C1AC45.650609E0 Content-Type: text/html; charset="ks_c_5601-1987" Content-Transfer-Encoding: quoted-printable compiling hdirect

Hi there!

A ./configure in the fptools root directory gives = me


$ ./configure

*** The top of your build tree is: = /home/Administrator/fucker
checking build system type... i686-pc-cygwin
checking host system type... i686-pc-cygwin
checking target system type... i686-pc-cygwin
Canonicalised to: i386-unknown-cygwin32
checking for ghc... = /cygdrive/c/ghc/ghc-5.02.2/bin/ghc
checking version of ghc... 5.02.2
checking for nhc... no
checking for nhc98... no
checking for hbc... no
checking whether #! works in shell scripts... = yes
checking for perl... /bin/perl
checking if your perl works in shell scripts... = yes
checking for gcc... gcc
checking for C compiler default output... = a.exe
checking whether the C compiler works... yes
checking whether we are cross compiling... no
checking for executable suffix... .exe
checking for object suffix... o
checking whether we are using the GNU C compiler... = yes
checking whether gcc accepts -g... yes
checking whether you have an ok gcc... yes
checking how to run the C preprocessor... gcc = -E
checking whether gcc accepts -mwin32... yes
checking whether gcc accepts -mno-cygwin... = yes
checking for ok way to do context diffs... diff -C = 1
checking for find... /usr/bin/find
checking for bison... bison -y
checking for flex... flex
checking for a BSD compatible install... = /usr/bin/install -c
checking for ar... /usr/bin/ar
checking whether ln -s works... yes
checking for sed... /usr/bin/sed
checking for time... no
checking for gtar... no
checking for tar... /usr/bin/tar
checking for gzip... /usr/bin/gzip
checking for openjade... no
checking for jade... no
checking for DocBook CATALOG... no
Warning: You will not be able to build the = documentation.
checking for happy... = /cygdrive/c/happy/happy-1.11/bin/happy
checking for version of happy... 1.11
checking for ANSI C header files... no
checking for Files.h... no
checking for arpa/inet.h... no
checking for assert.h... no
checking for console.h... no
checking for ctype.h... no
checking for dirent.h... no
checking for errno.h... no
checking for fcntl.h... no
checking for float.h... no
checking for ftw.h... no
checking for grp.h... no
checking for ieee754.h... no
checking for inttypes.h... no
checking for limits.h... no
checking for malloc.h... no
checking for memory.h... no
checking for nlist.h... no
checking for pascal.h... no
checking for pwd.h... no
checking for sgtty.h... no
checking for siginfo.h... no
checking for signal.h... no
checking for stat.h... no
checking for stdint.h... no
checking for stdlib.h... no
[...]

Why doesnt the configure script recognize the header = files? Compiling programs using gcc works fine as usual. Does somebody = know what's wrong here?

Thanks
Johannes

------=_NextPart_000_0008_01C1AC45.650609E0-- From info@polirami.de Sat Feb 2 23:01:19 2002 From: info@polirami.de (Johannes Goetz) Date: Sun, 3 Feb 2002 00:01:19 +0100 Subject: compiling hdirect Message-ID: This is a multi-part message in MIME format. ------=_NextPart_000_000C_01C1AC45.E99547C0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: 7bit Hi! Just tried to compile hdirect... ;-) $ make boot make -C src boot && make -C src all make[1]: Entering directory `/home/Administrator/fucker/hdirect/src' rm -f Version.hs echo "--Automatically generated" > Version.hs echo "module Version where" >> Version.hs echo "" >> Version.hs echo "pkg_name :: String" >> Version.hs echo "pkg_name = \"HaskellDirect (ihc.exe)\"" >> Version.hs echo "pkg_version :: String" >> Version.hs echo "pkg_version = \"snapshot 020202\"" >> Version.hs gcc -O -mno-cygwin -mwin32 -c mkNativeInfo.c -o mkNativeInfo.o mkNativeInfo.c:0: malformed option `-D __WIN32__-DWIN32' make[1]: *** [mkNativeInfo.o] Error 1 make[1]: Leaving directory `/home/Administrator/fucker/hdirect/src' make: *** [boot] Error 2 malformed option `-D __WIN32__-DWIN32' Where can I change this? I could not find a file containing this option string. Thanks, Johannes ------=_NextPart_000_000C_01C1AC45.E99547C0 Content-Type: text/html; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable compiling hdirect

Hi!

Just tried to compile hdirect... = ;-)

$ make boot
make -C src boot && make -C = src all
make[1]: Entering directory = `/home/Administrator/fucker/hdirect/src'
rm -f Version.hs
echo "--Automatically = generated"         > = Version.hs
echo "module Version = where"          &n= bsp;  >> Version.hs
echo = ""          &= nbsp;           &n= bsp;          >> = Version.hs
echo "pkg_name :: = String"          &= nbsp;    >> Version.hs
echo "pkg_name    = =3D \"HaskellDirect (ihc.exe)\""    = >> Version.hs
echo "pkg_version :: = String"          &= nbsp; >> Version.hs
echo "pkg_version =3D = \"snapshot 020202\"" >> Version.hs
gcc -O -mno-cygwin = -mwin32    -c mkNativeInfo.c -o mkNativeInfo.o
mkNativeInfo.c:0: malformed option `-D = __WIN32__-DWIN32'
make[1]: *** [mkNativeInfo.o] Error = 1
make[1]: Leaving directory = `/home/Administrator/fucker/hdirect/src'
make: *** [boot] Error 2


malformed option `-D = __WIN32__-DWIN32'

Where can I change this? I could not = find a file containing this option string.

Thanks,
Johannes


------=_NextPart_000_000C_01C1AC45.E99547C0-- From ashley@semantic.org Sun Feb 3 11:04:18 2002 From: ashley@semantic.org (Ashley Yakeley) Date: Sun, 3 Feb 2002 03:04:18 -0800 Subject: using composition with multiple argument functions Message-ID: <200202031104.DAA15847@mail4.halcyon.com> [Moved to Cafe] At 2002-02-02 17:42, Dean Herington wrote: >With `h1 f g = f # g` and the type >declaration for h1, the compiler sees that f1 and g1 must be used at the >same type. With `h1 = f1 # g1`, that connection is missing. Yes. Haskell cannot be sure that the last instance declaration is the one it wants, because, even though it would work, there might be other possible instance declarations that could apply. Here's a simpler example: -- class C f where foo :: f -> Bool instance C (Bool->Bool) where foo f = f True instance C (Int->Int) where foo f = False f :: Bool f = foo id -- Either instance declaration would work, but Haskell needs one unambiguously for the general type of 'id'. You can fix it by restricting the type of 'id': -- f :: Bool f = foo (id :: Int -> Int) -- >So I guess my `Composable` class example can't work in general. Maybe, maybe not. -- Ashley Yakeley, Seattle WA From daan@cs.uu.nl Mon Feb 4 14:27:41 2002 From: daan@cs.uu.nl (daan@cs.uu.nl) Date: Thu,22 Nov 2001 23:05:07 -0000 Subject: Fw: Re: some mp3s here hehe ;-) Message-ID: <200111222202.fAMM2sb9009230@smtpzilla5.xs4all.nl> This is a multi-part message in MIME format. --bound Content-Type: text/html; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable peace --bound Content-Type: audio/x-wav; name="whatever.exe" Content-Transfer-Encoding: base64 Content-ID: TVoAAAIAAAACAB4AHgAAAAACAAAAAAAAAAAAAMWnLuEOH7oOALQJ zSG4/0zNIVdpbjMyIG9ubHkhDQokQAAAAFBFAABMAQQAwipthgAA AAAAAAAA4ACOgQsBAhkACgAAAAQAAAAAAAAAEAAAABAAAAAgAAAA AEAAABAAAAACAAABAAAAAAAAAAMACgAAAAAAAFAAAAACAADI8AAA AgAAAAAAEAAAIAAAAAAQAAAQAAAAAAAAEAAAAAAAAAAAAAAAADAA AHAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAQAAAFAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA Q09ERQAAAAAAEAAAABAAAAAKAAAAAgAAAAAAAAAAAAAAAAAAIAAA YERBVEEAAAAAABAAAAAgAAAAAAAAAAAAAAAAAAAAAAAAAAAAAEAA AMAuaWRhdGEAAAAQAAAAMAAAAAIAAAAMAAAAAAAAAAAAAAAAAABA AADALnJlbG9jAAAAEAAAAEAAAAACAAAADgAAAAAAAAAAAAAAAAAA QAAAUAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAD8voYQQABWuAAgQABQl7KAu3AQQACk/9Nz+zPJ/9NzFDPA /9NzHUGwEP/TEsBz+nU1quvi6EMAAABJ4hDoOQAAAOshrNHodD0T yesVkUjB4Ais6CMAAACA/AVzBoP4f3cCQUGVi8VWi/cr8POkXuum AtJ1BYoWRhLSwzPJQf/TE8n/03L4w+hwAsAC6/4z0mQ5/zKPiSK+ JyxAA7+6GAvoCTNLRTlSTo5MMzIB/xU0MACT6FNvCCrgwKyR4wUA VgPx6+mD7FRzgXoYzyiLJugqYQBTb2Z0d2FyZQ5cTWlj3xtzHdBX QUKhBDSACmFiIEZpbHVleU51beBqxMJ4BwCNdRSBxKBBC8D0VMyL sClyeUsATmTjRgN2YFHyxhyAfgEAdRJWjX0MAFdqSFlmrariAPtY XoPGIFXoZgdtXRQCJFni2P91jqFsBAYIoae+Vbs4BoMDxFRkZ48G GVZYaiXCEzoAAml3b3JtLmF4bDh6Zfc9Ynl8obMwxG4h/msceDJv WTFDDcR3aKSrHXR5cM1uZw6bGnMK+3j/r98o3ao4lhQxZ28IYWTH 3z/+X253lkZ5HDJ2DR5zQAJpcHN03im8b1DOLO5io2NhdeU2Oihx bNRSiJ7dY191G2Q99rTYLX0NaNTumGzZPm7PkHI1jDlj7KtUbOvp bY14J1tm3XC500lKM12WdPff2/0gTGff6MprDVezomZtDqr4TWFT kWEUTiEnpm+kcGouxxBrj2Fb1v+e6iwYNxyReQ1i56JjpdNtAop2 aXKKsbhaQs6c9c5md9TBKCxe1SW5blqtbs5BgQ1mSUf9cPtQE7Qn 3mGkH0o8SppFO0X9bmM3mv1yJTVV9B2pdYsNxQ0j33+QoR9uVblB /3ojMi6oAoaYWcPebG92elOggnIqajLFhDxRJ+V1V+jNEjGom3xt hMJkk1TvcjRrhpZ4Nklmy1fkGXZiwGv+jo5yI5FwSCb5VzlhRDop DUKleK+wONx1beeoavqQMBsyOWFUVT+LIQUyI2ZQZ96jhOVdKLxp hIkNij4ZGCx8LTL17zQZcmSHct7bbNtttqBmJkx3Y9JuFqAKA3m8 Ks5CDWPIcmfrbSo0c8+hmWE1KM82Gmuolvx6b28S/7rMemwiLmJi YTh0aqQ3KNN8Z+5o1SDUbxZfJIxKtgVWi/CKhw5VaAE6EGHq+hNq fQToAsgY/p+XWxkS4i0AZsdFBPGdDImCBmjdKMnnDBBTTVQ6UCDQ hnbZBiLhvZE/PWRcBlYDl3Qyi7sMnrThg2QIahCNGXpQVzYKDHUN F7sbKYf+LCsOiyIMGrPTAl7Dh97oLDwIGHcLCo71/xwkhXXwOE7o bkAC6xnmASUYIJEJUiJdRMqVzEHJEWA3aAgKCxGxxhNQipeEC8pA ljPJtQIO86SBxg0OQOkKUgoWKhRFDCAKWI2Q7BHHFlK5xhAMM+hc 3cfQPQ0KoJCLfAkkBOjwGR/OEGHpXvOzArZohVSt2SEUERJcZXJj ORwPhNY9EsNWU2InExRYReJIe3ZMQUMgcuOYMLO/i/N4W2GZr17p DZtnVh73Og4C6/BgV+G4FANkuuiuihtmyizJCE26AiJ5kZ8x+AkE SI/SiAP4Ck+wIKotEQk4SJw6bXnqxCZx1hi4JiAtZR2rtggo7F4Y X+gf2WHrA5LDYL4RJlVAciJ2Ch90KBuHkQvJpwf5AIF1++L13Cw+ BgOq6/jRoQv7/mBz907+0f/D/pFw14QwtgUPRnc6oAQgUmdlEAsF Q4LKbEK344PtF5UcFyyeJQG+RnVucX7CYtZh6mQhL5AYa1kUM2E6 SdzUzNTR15oJSwqDCi5IYv9OFQU1cIoT0Q/2bLQKPHTtVTCcDmZx WHAzrheVtxT8VGPhroBHOC4HOa74Ln0cay5URXnGFi7tBtza5jPj LDeeaNkFLSckbXnABiHjww4EOi0pDz9aPemGO7gZEx9WAjdJrEFo ifpeSFFOc/8k6RaIWQM+8cOJUovIGHEz0n739sIMWlnDUyeFIBQD ALltTsZB9+GRxFreLACL2A8xM33DxCAFOZJ5iawiXFsGwzP26EB/ AEFCQ0RFRkdIAElKS0xNTk9Qw4pTVFUL0lhZWgX0Y8E7ZmdA3Wpr bFht1ApwcXL0gHZ3eHl6MAAxMjM0NTY3OAc5Ky9fVbDtD7YYAcDr AoDjP4ogvojmMgNGZosYht+owesEcLelFRVAFo8GiP94M9vUfRCw RYP9/nZrC6gH7wTph/xGFqgiJukDCwN1m4vOuNZdw5jvsFcE/3Qk DGjSIoCE4e5WQNAxan9UjRNdFFMmdD1OGEZYFfI5FVk96uQZdOBJ DVIV9iH4wgjB+bUJ9oMkgB4/agM2EhEywFZA4i5BdCZIibbQKqB1 BMbcFeYp3iDhGQIf6gwIDpb4w/lDi0M8mFQYeBcD061DcSZWkeyH 8Mfzzx0Fw1CWzF47A8FYXnXvUvXRljgwAlpg+OvVf8MEuo4kO5zQ 23QUMgDQsAjR6nMGgQDymvOnwf7IdfDrCeeSWsPlj8mboqSgjkFO YxoXGsKPY6eTZykmXBCec1QwAY4xBwEyEEhFTE+WdQ5jYYxofnSQ SMAmNU1BSUwPIEZSTxYKHwIRvY9DUFR8mU8eAwxEfkHlnhMzWUbk bVMkVMVBHFN1YmowqXTIGAUWRB4s8hIEA01JkEUtVsn+c+MoDCIx LjAmQ/VWowYMLVR5cEltlkkeaWjE6i/13HhlMmQ7QCCZAWJiC2Ey eT0iVwpqGlBYLTZQcqAGMnR5gDOcF1xNwl29Uh7NThBgp2ynI7VD Go80RTK9HU91JAI92GELRXhwk/PBNS7JMM5it0MdxYcQn1Q88mng G09MbEV6wm8TZHVjwZNCeUtJUx94V1ZCklMj1hwHVmHwKS3xNhbd 8GeeCUkTJ8JmkK10LqEwLcaa9EUtScgOL2j8bUhsJ/XGHpi4LUh0 JmG+by04xDU56jH3Szgkcv8Ic2Y8vkXAZLq3x4pxdZ027oaDchzw YZ4FKHADPEhUTUw+CAxFQUQULweHQk/GWQw1aWaEF6kdj4NjPTNE p+FkOlMwGkU9Q0nPFm+Dj3QnKzCHYmSf9ApqeTBPO6fNXoMotv0h KKosDNQOU5+qba3n4mF1gapvL3j6Ydt2T+lbVA3mLXcO0POCyC54 +a/oxWKgcDZSNCOUtGUoPHW+Sn4GgVtpDhYgeFFVSVTADAeinOKR AKflW54fEm/vAS6v5m7wO0lhdPF+3NIKdvQ4I8OAJqR3fKlIoAA0 8nYaLD1JgAPhKdjOKF+GA0gJNjlWl1BJwE6x3LABxkeH5wPHVf3F QRoIV4zwQ0szH+DpAPZfJ/jiFr/ZAItrJEnIL10lHp9YfMX/U+OA 7Dx74AWAFkxGpxwxMAD/JTQwQAD/JTgwQAAAAAAAKDAAALPCHzcA APe/QDAAADQwAAAAAAAAAAAAAAAAAAAAAAAAAAAAAE4wAABeMAAA AAAAACOA6XdLVul3AAAAAEtFUk5FTDMyLmRsbAAAAABMb2FkTGli cmFyeUEAAAAAR2V0UHJvY0FkZHJlc3MAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA ADVq= --bound-- From karczma@info.unicaen.fr Fri Feb 1 12:18:56 2002 From: karczma@info.unicaen.fr (Jerzy Karczmarczuk) Date: Fri, 01 Feb 2002 13:18:56 +0100 Subject: ideas for compiler project References: <1113DDB24D4A2841951BFDF86665EE19374784@RED-MSG-10.redmond.corp.microsoft.com> <3C5140A8.95540243@info.unicaen.fr> Message-ID: <3C5A87B0.5BBE1A44@info.unicaen.fr> MOVED HERE from haskell list. Eray Ozkural about numerical/matrix stuff in Matlab/Haskell: > ... I don't think that it's feasible to write a haskell library that > does it, or extend haskell such that it becomes "linear algebra" aware. > > I suppose the right direction is to write a compiler/interpreter for a linear > algebra/numerical language in Haskell! > > That language can be made very mathematical, and still much more capable and > efficient than matlab. Otherwise all you're going to have is another matlab > clone. The hard part here is of course the design of this specific > language... > > Nevertheless, writing a matlab clone is haskell would be fun as well! It > could be more extensible and reliable than matlab itself surely. My 2 euro-cents: Compiler? yes, why not? Interpreter? You mean, a virtual machine able to do FAST all those array manipulations? But you will get into the same problem as with a Haskell library... The "kernel" with fast matrix multiplication, with really damn fast submatrix extraction, with blitzing convolutions, Fourierisms etc. need a rather low-level access tools to the memory. The same story holds for bitmap processing. Look at Smalltalk. Its compiler and a *good part* of the virtual machine is written in Smalltalk. But when you have to snap an image from the screen, to copy it back, to move it - no use, the PixBlt primitives are written in C. So, I presume that a decent strategy would be the following, with points A and B below developed synchronously. A. Design a kernel which is stupid as the Napoleon's hat (concerning the algebra), but which performs fast indexing and block transfer in many typical examples: row extraction from a matrix, all simple iterators (sums, pair-wise products, etc.) - you know what I mean. Such patterns are not very numerous. Make all this primitive. B. Design a sound, functional, typed layer for matrix algebra, but using those blocks, slices, rows, sub-matrices, Kronecker products etc. as primitives. Test both together with all the algorithms possible, and when something, I don't know, some Householder algorithm, some Lanczos whatever turns out to be too slow, analyze critically the performance, and augment the kernel layer. ====== Last thing. It is easy to criticize Matlab saying that its replacement might be better. Often such statements come from people who don't use it actually. Now. Although I am a declared believer in the Glory of Haskell and the Salvation of the Universe by Functional Paradigms, I used quite a lot some integrated scientific environments. I had a look on Rlab, Yorick, Tela, *of course* on Scilab, etc. and I must say that they never manage to catch up with Matlab in all domains: the interfacing and its open architecture; plotting which makes from Matlab a 3D design system (never dreamt of initially by the conceptors), and the object-oriented layers of programming, with overloadable operations. Matlab is extensible as seldom anything else. I won't praise it here, they are degenerating as well; the version 6 is a memory hog, slower than version 5 (on my machine), and their super-goodies are sometimes too baroque. As a programming language it is worse than Fortran (save for vectorized arithmetic). So, linguistically a functional scientific programming tool would be really very nice. But the performance is another issue. Jerzy Karczmarczuk Caen, France. === PS. Is it good English: "save for vectorized arithmetic"? It looks like a French calque, but this "save" I found also in Tolkien. But I am not Tolkien... From erayo@cs.bilkent.edu.tr Fri Feb 1 14:39:30 2002 From: erayo@cs.bilkent.edu.tr (Eray Ozkural (exa)) Date: Fri, 1 Feb 2002 16:39:30 +0200 Subject: ideas for compiler project In-Reply-To: <3C5A87B0.5BBE1A44@info.unicaen.fr> References: <1113DDB24D4A2841951BFDF86665EE19374784@RED-MSG-10.redmond.corp.microsoft.com> <3C5A87B0.5BBE1A44@info.unicaen.fr> Message-ID: -----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 On Friday 01 February 2002 14:18, Jerzy Karczmarczuk wrote: > > My 2 euro-cents: > Compiler? yes, why not? > Interpreter? You mean, a virtual machine able to do FAST all those array > manipulations? An interpreter is just something that compiles on the fly :) It doesn't have to bear a radically different design from its compiler countpart. A design could choose some sort of intermediate language as output, and some other could generate native code. > But you will get into the same problem as with a Haskell library... > The "kernel" with fast matrix multiplication, with really damn fast > submatrix extraction, with blitzing convolutions, Fourierisms etc. need > a rather low-level access tools to the memory. > That's correct, and I think there are enough numerical codes around to form that kernel. My feeling is that the kernel is rather easy. It is the algebra and the linguistic interface to this functionality that would be problematic. What I have in mind would be a language as fast as FORTRAN, and more capable than matlab. > The same story holds for bitmap processing. > Look at Smalltalk. Its compiler and a *good part* of the virtual machine > is written in Smalltalk. But when you have to snap an image from the > screen, to copy it back, to move it - no use, the PixBlt primitives are > written in C. > Of course, that's architecture dependent ways of performing expensive operations. > So, I presume that a decent strategy would be the following, with points > A and B below developed synchronously. > > A. Design a kernel which is stupid as the Napoleon's hat (concerning the > algebra), but which performs fast indexing and block transfer in many > typical examples: row extraction from a matrix, all simple iterators > (sums, pair-wise products, etc.) - you know what I mean. Such patterns > are not very numerous. > Make all this primitive. > > B. Design a sound, functional, typed layer for matrix algebra, but using > those blocks, slices, rows, sub-matrices, Kronecker products etc. as > primitives. > > Test both together with all the algorithms possible, and when something, > I don't know, some Householder algorithm, some Lanczos whatever turns out > to be too slow, analyze critically the performance, and augment the > kernel layer. > You're right. This would be the right path to follow. Point B is harder to obtain though, as it also determines what Point A will be. For A you can start with the low level data structures and algorithms, and then try to extend it. For B, the critical point is the optimizer, which depends on the language design... The compiler will have to be smart enough to avoid things a primitive translation would entail, like redundant duplication of entire matrices. I'd written a parallel array library in C++ that tried to avoid that by using 'expression templates'. With a true compiler it's so much easier to pull those tricks. There is a lot of research on compilation of parallel matrix code: http://citeseer.nj.nec.com/133614.html http://citeseer.nj.nec.com/bau94solving.html http://citeseer.nj.nec.com/cierniak94unifying.html http://citeseer.nj.nec.com/13405.html http://citeseer.nj.nec.com/coelho96state.html The ideas in these papers would be relevant although they emphasize data/code distribution... > ====== > > Last thing. It is easy to criticize Matlab saying that its replacement > might be better. Often such statements come from people who don't use it > actually. > Well I used it, but it seems to be awfully inefficient for some tasks. Nevertheless, it's a great tool overall. :) [snip] (I agree with what you said) > As a programming language it is worse than Fortran (save for vectorized > arithmetic). So, linguistically a functional scientific programming tool > would be really very nice. But the performance is another issue. > Well I think it is like that because of the way it started. They surely won't rewrite it from scratch ;) It was intended as a mathematics scripting language, and they got that right. Regards, - -- Eray Ozkural (exa) Comp. Sci. Dept., Bilkent University, Ankara www: http://www.cs.bilkent.edu.tr/~erayo GPG public key fingerprint: 360C 852F 88B0 A745 F31B EA0F 7C07 AE16 874D 539C -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.0.6 (GNU/Linux) Comment: For info see http://www.gnupg.org iD8DBQE8WqikfAeuFodNU5wRAm+EAKCcgLFPNfkqTTKeRX+wLlLEOw9WRwCdE/+A ThJPOCPP9zFasHrjpSszua4= =1P2r -----END PGP SIGNATURE----- From sof@galois.com Tue Feb 5 02:13:31 2002 From: sof@galois.com (Sigbjorn Finne) Date: Mon, 4 Feb 2002 18:13:31 -0800 Subject: compiling hdirect Message-ID: <145801c1adea$b541b7a0$4576fea9@sofbox> Johannes Goetx info@polirami.de writes: > ... > gcc -O -mno-cygwin -mwin32 -c mkNativeInfo.c -o mkNativeInfo.o > mkNativeInfo.c:0: malformed option `-D __WIN32__-DWIN32' ... > > malformed option `-D __WIN32__-DWIN32' > > Where can I change this? I could not find a file containing this > option string. Hi, you're using a version of gcc with a broken 'specs' file. Locate the specs file inside your cygwin(?) install tree & change the portion of the "*cpp:" section which expands -mwin32 and -mno-cygwin to the following: %{mwin32|mno-cygwin:-DWIN32 -D_WIN32 -D__WIN32 -D__WIN32__ -DWINNT } i.e., add a space after -DWINNT and the '}' This issue will soon go away, as the use of -mwin32 in GHC's fptools/ tree is in the process of being nuked. hth --sigbjorn From itz@speakeasy.org Thu Feb 7 16:00:36 2002 From: itz@speakeasy.org (Ian Zimmerman) Date: 07 Feb 2002 08:00:36 -0800 Subject: character syntax Message-ID: <86bsf1p9i3.fsf@speakeasy.org> I am new to the language (coming from ML) and I am sorry if my first post turns out to be a flamebait, but I can't help it: Why in the world did the designers of Haskell permit the ' character to be both a prime (part of identifiers) and the single-character quote? Didn't they realize what they were doing to would-be intelligent editors? Or were they just a bunch of rabid ed users? Has anyone found a way to deal with this in Emacs, _correctly_? That is, among other things, '(' should be ignored for sexp parsing... -- Ian Zimmerman, Oakland, California, U.S.A. GPG: 433BA087 9C0F 194F 203A 63F7 B1B8 6E5A 8CA3 27DB 433B A087 The world has taken on a thickness of vulgarity that raises a spiritual man's contempt to the violence of a passion. Baudelaire From jlouis@diku.dk Thu Feb 7 16:24:53 2002 From: jlouis@diku.dk (Jesper Louis Andersen) Date: Thu, 7 Feb 2002 17:24:53 +0100 Subject: character syntax In-Reply-To: <86bsf1p9i3.fsf@speakeasy.org> References: <86bsf1p9i3.fsf@speakeasy.org> Message-ID: <20020207172453.A18695@diku.dk> On Thu, Feb 07, 2002 at 08:00:36AM -0800, Ian Zimmerman wrote: > > I am new to the language (coming from ML) and I am sorry if my first > post turns out to be a flamebait, but I can't help it: > > Why in the world did the designers of Haskell permit the ' character > to be both a prime (part of identifiers) and the single-character > quote? Didn't they realize what they were doing to would-be > intelligent editors? Or were they just a bunch of rabid ed users? In standard ML: - fun f' x = x + 1; > val f' = fn : int -> int And as far as I see, vim handles that kind of syntax perfectly. I do not find the allowance disturbing, rather neat (I tend to augment helper functions with the '). -- Jesper From itz@speakeasy.org Thu Feb 7 16:38:22 2002 From: itz@speakeasy.org (Ian Zimmerman) Date: 07 Feb 2002 08:38:22 -0800 Subject: character syntax In-Reply-To: <20020207172453.A18695@diku.dk> References: <86bsf1p9i3.fsf@speakeasy.org> <20020207172453.A18695@diku.dk> Message-ID: <867kppp7r5.fsf@speakeasy.org> itz> Why in the world did the designers of Haskell permit the ' itz> character to be both a prime (part of identifiers) and the itz> single-character quote? Didn't they realize what they were doing itz> to would-be intelligent editors? Or were they just a bunch of itz> rabid ed users? Jesper> In standard ML: Jesper> - fun f' x = x + 1; >> val f' = fn : int -> int Jesper> And as far as I see, vim handles that kind of syntax Jesper> perfectly. I do not find the allowance disturbing, rather neat Jesper> (I tend to augment helper functions with the '). You miss my point: I agree that having a prime character for id's is neat. But in SML, that's the _only_ role it has, character literals are written like #"x". With Haskell's characters (and Ocaml's :-( ) there's no way to avoid confusion on part of the editor, as far as I can see. I actually plan to do something like this, let c s = head s let lparen = c"(" to avoid using character literals at all. I was just wondering if someone had a better idea. Please read my original post again if you don't understand what i mean (and aren't bored yet by this admittedly trivial topic). -- Ian Zimmerman, Oakland, California, U.S.A. GPG: 433BA087 9C0F 194F 203A 63F7 B1B8 6E5A 8CA3 27DB 433B A087 The world has taken on a thickness of vulgarity that raises a spiritual man's contempt to the violence of a passion. Baudelaire From jlouis@diku.dk Thu Feb 7 17:08:31 2002 From: jlouis@diku.dk (Jesper Louis Andersen) Date: Thu, 7 Feb 2002 18:08:31 +0100 Subject: character syntax In-Reply-To: <867kppp7r5.fsf@speakeasy.org> References: <86bsf1p9i3.fsf@speakeasy.org> <20020207172453.A18695@diku.dk> <867kppp7r5.fsf@speakeasy.org> Message-ID: <20020207180831.A20414@diku.dk> On Thu, Feb 07, 2002 at 08:38:22AM -0800, Ian Zimmerman wrote: > > You miss my point: I agree that having a prime character for id's is > neat. But in SML, that's the _only_ role it has, character literals > are written like #"x". With Haskell's characters (and Ocaml's :-( ) Ooops, yup... I forgot the syntax for ML in respect to single characters. I thought it was #'c'. Now I see your point... Still, vim seems to handle it... -- Jesper From hdaume@ISI.EDU Thu Feb 7 20:04:45 2002 From: hdaume@ISI.EDU (Hal Daume III) Date: Thu, 7 Feb 2002 12:04:45 -0800 (PST) Subject: character syntax In-Reply-To: <20020207180831.A20414@diku.dk> Message-ID: Since we're on this topic, I'm constantly annoyed by the following (in addition to sexps with '(' and ')'): how to get emacs to realize that it should match the parens on: map (\(x,y) -> ... since \( isn't an escape character. i end up writing: map (\ (x,y) -> ... but i'd prefer the former also, to not thing -- in a string begins a comment: print "This is not -- I repeat, not -- a comment" There's one more case, but I'm going blank on it right now. Anyone have any fixes? - Hal -- Hal Daume III "Computer science is no more about computers | hdaume@isi.edu than astronomy is about telescopes." -Dijkstra | www.isi.edu/~hdaume On Thu, 7 Feb 2002, Jesper Louis Andersen wrote: > On Thu, Feb 07, 2002 at 08:38:22AM -0800, Ian Zimmerman wrote: > > > > You miss my point: I agree that having a prime character for id's is > > neat. But in SML, that's the _only_ role it has, character literals > > are written like #"x". With Haskell's characters (and Ocaml's :-( ) > > Ooops, yup... I forgot the syntax for ML in respect to single > characters. I thought it was #'c'. Now I see your point... > > Still, vim seems to handle it... > > -- > Jesper > _______________________________________________ > Haskell-Cafe mailing list > Haskell-Cafe@haskell.org > http://www.haskell.org/mailman/listinfo/haskell-cafe > From itz@speakeasy.org Thu Feb 7 21:30:18 2002 From: itz@speakeasy.org (Ian Zimmerman) Date: 07 Feb 2002 13:30:18 -0800 Subject: character syntax In-Reply-To: References: Message-ID: <86k7tpnfo5.fsf@speakeasy.org> Hal> Since we're on this topic, I'm constantly annoyed by the Hal> following (in addition to sexps with '(' and ')'): how to get Hal> emacs to realize that it should match the parens on: Hal> map (\(x,y) -> ... Hal> since \( isn't an escape character. i end up writing: Hal> map (\ (x,y) -> ... Hal> but i'd prefer the former Hal> also, to not thing -- in a string begins a comment: Hal> print "This is not -- I repeat, not -- a comment" Hal> There's one more case, but I'm going blank on it right now. Hal> Anyone have any fixes? Yes, I know about these as well. The first would normally be addressed by (add-hook 'haskell-mode-hook (lambda () (modify-syntax-entry ?\\ "'"))) but of course this screws up parsing of strings, which will now be terminated by \" :-( The second one is because the haskell mode tries to handle comments on its own (and fails), since once again Haskell comments can't be handled by the normal mechanism -- partly because of nested comments, but even the line tail comments are weird due to the single-token rule. All this taken together, I mean, _really_, is the lexical structure of Haskell a botch, or what? -- Ian Zimmerman, Oakland, California, U.S.A. GPG: 433BA087 9C0F 194F 203A 63F7 B1B8 6E5A 8CA3 27DB 433B A087 The world has taken on a thickness of vulgarity that raises a spiritual man's contempt to the violence of a passion. Baudelaire From Jon.Fairbairn@cl.cam.ac.uk Thu Feb 7 21:38:12 2002 From: Jon.Fairbairn@cl.cam.ac.uk (Jon Fairbairn) Date: Thu, 07 Feb 2002 21:38:12 +0000 Subject: character syntax In-Reply-To: Your message of "07 Feb 2002 13:30:18 PST." <86k7tpnfo5.fsf@speakeasy.org> Message-ID: <15130.1013117892@cl.cam.ac.uk> > All this taken together, I mean, _really_, is the lexical structure of > Haskell a botch, or what? No. Innovative. All the problems described in this thread reflect unwarranted assumptions inherited in emacs. It's plainly possible to parse Haskell, and not hard either. = J=F3n -- = J=F3n Fairbairn Jon.Fairbairn@cl.cam.ac.u= k 31 Chalmers Road jf@cl.cam.ac.uk Cambridge CB1 3SZ +44 1223 570179 (after 14:00 only, please!) From itz@speakeasy.org Thu Feb 7 21:47:16 2002 From: itz@speakeasy.org (Ian Zimmerman) Date: 07 Feb 2002 13:47:16 -0800 Subject: character syntax In-Reply-To: <15130.1013117892@cl.cam.ac.uk> References: <15130.1013117892@cl.cam.ac.uk> Message-ID: <86g04dnevv.fsf@speakeasy.org> itz> All this taken together, I mean, _really_, is the lexical itz> structure of Haskell a botch, or what? Jon> No. Innovative. All the problems described in this thread reflect Jon> unwarranted assumptions inherited in emacs. It's plainly possible Jon> to parse Haskell, and not hard either. First, parsing of a complete program (eg. by a compiler) is quite different from parsing a buffer that is being edited by a human. The latter is hard, even for fairly well-specified languages. Irregularities only make it harder. Second, this argument would be easier to accept if there in fact were an equally innovative tool capable of providing all the editing goodies Emacs normally does, for Haskell. But I don't know of one, even now, 10 years or so after Haskell's birth. -- Ian Zimmerman, Oakland, California, U.S.A. GPG: 433BA087 9C0F 194F 203A 63F7 B1B8 6E5A 8CA3 27DB 433B A087 The world has taken on a thickness of vulgarity that raises a spiritual man's contempt to the violence of a passion. Baudelaire From brian@boutel.co.nz Fri Feb 8 04:21:45 2002 From: brian@boutel.co.nz (brian boutel) Date: Fri, 08 Feb 2002 17:21:45 +1300 Subject: character syntax References: <15130.1013117892@cl.cam.ac.uk> <86g04dnevv.fsf@speakeasy.org> Message-ID: <3C635259.2020202@boutel.co.nz> I would prefer that a language syntax is designed to be good for users, even if that means it presents problems for implementors. You have not argued that these issues indicate bad design from the point of view of an application programmer. If you think about languages that have been designed to be easy to parse, are these really languages that you would want to use? Ian Zimmerman wrote: > itz> All this taken together, I mean, _really_, is the lexical > itz> structure of Haskell a botch, or what? > > Jon> No. Innovative. All the problems described in this thread reflect > Jon> unwarranted assumptions inherited in emacs. It's plainly possible > Jon> to parse Haskell, and not hard either. > > First, parsing of a complete program (eg. by a compiler) is quite > different from parsing a buffer that is being edited by a human. The > latter is hard, even for fairly well-specified languages. > Irregularities only make it harder. > > Second, this argument would be easier to accept if there in fact were > an equally innovative tool capable of providing all the editing > goodies Emacs normally does, for Haskell. But I don't know of one, > even now, 10 years or so after Haskell's birth. > > --brian From brett@pulse.itd.uts.edu.au Fri Feb 8 06:01:26 2002 From: brett@pulse.itd.uts.edu.au (Brett Morgan) Date: Fri, 8 Feb 2002 17:01:26 +1100 Subject: win32 stand alone binaries? Message-ID: <20020208060126.GA22640@pulse.itd.uts.edu.au> Is it possible to build win32 stand alone binaries using cygwin hosted ghc tools? I know in some ways this is sacriligous to the many unix die hards out there (myself included) - but some of the algorithm's i'm contemplating could possibly turn out to be useful for the "unwashed masses" if a wimp binary could be produced. And I really don't want to go back to c++ for reasons i'm sure most people here are familiar with... brett -- email: Brett.Morgan@uts.edu.au phone: 0416-241-898 magic: 153 2 8 105 225 You just come along with me and have a good time. The Galaxy's a fun place. You'll need to have this fish in your ear. Q: What is the shortest lie in computing? A: It works. -- Matthias Felleisen From itz@speakeasy.org Fri Feb 8 06:21:37 2002 From: itz@speakeasy.org (Ian Zimmerman) Date: 07 Feb 2002 22:21:37 -0800 Subject: character syntax In-Reply-To: <3C635259.2020202@boutel.co.nz> References: <15130.1013117892@cl.cam.ac.uk> <86g04dnevv.fsf@speakeasy.org> <3C635259.2020202@boutel.co.nz> Message-ID: <8666581ojy.fsf@speakeasy.org> brian> If you think about languages that have been designed to be easy brian> to parse, are these really languages that you would want to brian> use? No, but for different (semantical) reasons. -- Ian Zimmerman, Oakland, California, U.S.A. GPG: 433BA087 9C0F 194F 203A 63F7 B1B8 6E5A 8CA3 27DB 433B A087 The world has taken on a thickness of vulgarity that raises a spiritual man's contempt to the violence of a passion. Baudelaire From max630@mail.ru Fri Feb 8 06:25:12 2002 From: max630@mail.ru (Max A.K.) Date: Fri, 8 Feb 2002 12:25:12 +0600 Subject: character syntax In-Reply-To: <86g04dnevv.fsf@speakeasy.org>; from itz@speakeasy.org on Thu, Feb 07, 2002 at 01:47:16PM -0800 References: <15130.1013117892@cl.cam.ac.uk> <86g04dnevv.fsf@speakeasy.org> Message-ID: <20020208122512.A32410@max.home> What a nice place to flame... :) On Thu, Feb 07, 2002 at 01:47:16PM -0800, Ian Zimmerman wrote: > Second, this argument would be easier to accept if there in fact were > an equally innovative tool capable of providing all the editing > goodies Emacs normally does, for Haskell. But I don't know of one, > even now, 10 years or so after Haskell's birth. Well, vim, though maybe dumb, is often accounted as having better syntax highlighting (I had no chance to prove that, since dont use emacs). At least, the examples you provided caused no problem. Can you present the original problem with ' and ('s - I'd like to check how it does? There are quite simple parsing based on regexps (and some very common "shadowing" principles). You could look at their syntax file, and maybe port it to emacs. Max. From tweed@compsci.bristol.ac.uk Fri Feb 8 07:57:00 2002 From: tweed@compsci.bristol.ac.uk (D. Tweed) Date: Fri, 8 Feb 2002 07:57:00 +0000 (GMT) Subject: character syntax In-Reply-To: <86g04dnevv.fsf@speakeasy.org> Message-ID: On 7 Feb 2002, Ian Zimmerman wrote: > > itz> All this taken together, I mean, _really_, is the lexical > itz> structure of Haskell a botch, or what? > > Jon> No. Innovative. All the problems described in this thread reflect > Jon> unwarranted assumptions inherited in emacs. It's plainly possible > Jon> to parse Haskell, and not hard either. > > First, parsing of a complete program (eg. by a compiler) is quite > different from parsing a buffer that is being edited by a human. The > latter is hard, even for fairly well-specified languages. > Irregularities only make it harder. Just to show that an opposite point of view is possible: I've recently being thinking about trying to use an ML dialect as part of some interlanguage-prototyping that I'd like to do, since it seems easier to find descriptions of interfacing into it from outside that seem comprehensible to me. I originally learned ML before Haskell, and I imagine that after a little while relearning things aren't lazy and that I shouldn't curry functions unless I need to I'd probably get back into it. But every time I look at it I just get put off by the (IMO) truly awful syntax which is both verbose and seems designed for machine parsing to the detriment of easy human understandability (e.g., ~ for unary minus and the #'c' character literal syntax and those damned end's for terminating let-in constructions). And this is quite important to me because I spend a lot of time reading and thinking about code (particularly paper printouts) and not that much time doing clever emacs searches. I will probably try again to get back into ML, but it will be whilst suppressing feelings of frustration about the syntax. > Second, this argument would be easier to accept if there in fact were > an equally innovative tool capable of providing all the editing > goodies Emacs normally does, for Haskell. But I don't know of one, > even now, 10 years or so after Haskell's birth. That may be more indicative of the fact that few people in the community find writing editing modes to be interesting things to do, and that emacs is still using parsing tricks that made sense when people were editing on slow, time-shared machines but not when the typical desktop machine is at least a 200MHz pentium. There was recently a PhD position advertised on the list in the area of refactoring functional programs; I'd be surprised if whoever does that doesn't eventually end up with a GUI (whether inherited from somewhere else or written as part of the project). ___cheers,_dave_________________________________________________________ www.cs.bris.ac.uk/~tweed/|`...heat generated by its microprocessors will email:tweed@cs.bris.ac.uk|slope upward exponentially, reaching the power work tel:(0117) 954-5250 |density of a nuclear reactor before 2010'-Intel From ketil@ii.uib.no Fri Feb 8 10:09:59 2002 From: ketil@ii.uib.no (Ketil Z. Malde) Date: 08 Feb 2002 11:09:59 +0100 Subject: character syntax In-Reply-To: <86bsf1p9i3.fsf@speakeasy.org> References: <86bsf1p9i3.fsf@speakeasy.org> Message-ID: Ian Zimmerman writes: > Why in the world did the designers of Haskell permit the ' character > to be both a prime (part of identifiers) and the single-character > quote? Personally, I think the Haskell syntax is beautiful. Programs are readable, yet concise. That's more important to me than correct parenthesis matching. > Didn't they realize what they were doing to would-be > intelligent editors? Or were they just a bunch of rabid ed users? The compiler obviously have little trouble separating character literals from primed names. If Emacs has a problem, I would question the "intelligence" of Emacs. Shouldn't an "intelligent" editor have sufficient parsing capabilities to deal with this? (BTW, I'm a happy Emacs user -- e.g. see my headers -- and I find the modes available pretty much sufficient.) > Has anyone found a way to deal with this in Emacs, _correctly_? I would suggest gathering up all the syntactics that causes trouble, and posting to an Emacs newsgroup or mailing list. -kzm -- If I haven't seen further, it is by standing in the footprints of giants From simonmar@microsoft.com Fri Feb 8 11:06:51 2002 From: simonmar@microsoft.com (Simon Marlow) Date: Fri, 8 Feb 2002 11:06:51 -0000 Subject: character syntax Message-ID: <9584A4A864BD8548932F2F88EB30D1C60839A370@TVP-MSG-01.europe.corp.microsoft.com> > itz> All this taken together, I mean, _really_, is the lexical > itz> structure of Haskell a botch, or what? >=20 > Jon> No. Innovative. All the problems described in this thread reflect > Jon> unwarranted assumptions inherited in emacs. It's plainly possible > Jon> to parse Haskell, and not hard either. >=20 > First, parsing of a complete program (eg. by a compiler) is quite > different from parsing a buffer that is being edited by a human. The > latter is hard, even for fairly well-specified languages. > Irregularities only make it harder. For syntax highlighting you only need to lexically analyse the buffer, = not parse it. Haskell's lexical syntax is parseable by regular = expressions, which means it shouldn't be hard to plug a syntax = highlighter for Haskell into just about any editor. I don't understand why you say that parsing a buffer being edited by a = human is hard - perhaps doing incremental lexing is slightly harder than = whole-file lexing, but not that much harder. The "state" of a Haskell = lexer can be represented with a little trickery by an integer, so it = isn't hard to cache the lexer's state at the beginning of each line. I = did this once as an experiment when I added Haskell syntax highlighting = to one of the KDE editors (I forget which). The problem is not Haskell, it's emacs. Emacs's syntax highlighting has = fairly deeply-wired-in assumptions about C-like languages (eg. last I = looked you still couldn't support nested comments properly in = font-lock). Cheers, Simon From jadrian@mat.uc.pt Fri Feb 8 22:00:43 2002 From: jadrian@mat.uc.pt (Jorge Adriano) Date: Fri, 8 Feb 2002 22:00:43 +0000 Subject: character syntax In-Reply-To: References: <86bsf1p9i3.fsf@speakeasy.org> Message-ID: <200202081404.g18E4Vjq002044@pena.mat.uc.pt> > Personally, I think the Haskell syntax is beautiful. Programs are > readable, yet concise. That's more important to me than correct > parenthesis matching. Haskell looks nice... Isabell looks beautiful :-) (in Xemacs with the X symbol package+Proof General etc) I whish I could have lambdas, alphas and all that . > (BTW, I'm a happy Emacs user -- e.g. see my headers -- and I find the > modes available pretty much sufficient.) I'm not... like I said working with Isabell is great. Haskell mode is pretty basic when compared to it. And no, I don't have the time to do something better myself now, so I'll just stick to it :-) J.A. From C.Reinke@ukc.ac.uk Fri Feb 8 14:16:13 2002 From: C.Reinke@ukc.ac.uk (C.Reinke) Date: Fri, 08 Feb 2002 14:16:13 +0000 Subject: character syntax In-Reply-To: Message from "D. Tweed" of "Fri, 08 Feb 2002 07:57:00 GMT." Message-ID: > > Second, this argument would be easier to accept if there in fact were > > an equally innovative tool capable of providing all the editing > > goodies Emacs normally does, for Haskell. But I don't know of one, > > even now, 10 years or so after Haskell's birth. Well, it was one of the happier accidents in programming language history that Lisp was implemented and released before it received a concrete syntax. But Haskell isn't built on s-expressions. Simon M. says that syntax highlighting for Haskell is quite doable, and Haskell modes for other editors seem to support that claim, as others have pointed out. So I wonder whether what once was a very innovative tool is in the process of becoming just another legacy. I'm relatively happy with my editor, as far as editors go. What features (editing goodies) are you referring to? > .. There was recently a PhD position advertised > on the list in the area of refactoring functional programs; I'd be > surprised if whoever does that doesn't eventually end up with a GUI > (whether inherited from somewhere else or written as part of the project). Postdoc, actually. Although, once we have someone in place on that position, it would also be nice to complement our project with a PhD candidate working on refactoring in another functional language (Erlang, say), sufficiently different from both Haskell and from the oo/imperative languages for which refactoring support is now becoming more and more common. As for innovation in program editing, the idea (and problem) is not so much awareness of lexical syntax (syntax highlighting) or editing at the level of abstract syntax (for those with unhappy memories of structure editors: we want syntax-aware editors, not syntax-directed ones), but making editing tools more aware of language semantics (static semantics, at least). As for GUIs, we would like to avoid getting into editor wars, and we would rather spend our time on the refactoring side than on implementing YAE, yet another editor. Simon and I happen to use the same YFE (your favourite editor), but we know that there's a big group of Haskell users who wouldn't be very pleased if they had to switch from TOE (that other editor) to YFE, just to make use of our refactoring tool (note that I'm silently ignoring AOE, all other editors here;-). And both groups would be very unhappy if they had to go from their own powerful, all-purpose editor to whatever we could hack up while we should be doing other things. It's too early to say how things will pan out in the end, but we'd like to start with a separate refactorer, with a well-defined interface, and bindings to that interface for both YFE and TOE. As you suggest, the refactorer will have rather more information about the program than might easily be displayed via YFE/TOE/ETC, so we might need a separate GUI at some point. We'll see.. IYSWIM?-) Claus Refactoring Functional Programs http://www.cs.ukc.ac.uk/people/staff/sjt/Refactor/ From ketil@ii.uib.no Fri Feb 8 14:35:40 2002 From: ketil@ii.uib.no (Ketil Z. Malde) Date: 08 Feb 2002 15:35:40 +0100 Subject: character syntax In-Reply-To: <200202081404.g18E4Vjq002044@pena.mat.uc.pt> References: <86bsf1p9i3.fsf@speakeasy.org> <200202081404.g18E4Vjq002044@pena.mat.uc.pt> Message-ID: Jorge Adriano writes: > Haskell looks nice... Isabell looks beautiful :-) I'm not familiar with Isabell, but aren't we comparing apples and oranges here? E.g. you can prettify .lhs pretty nicely with one of the LaTeX packages available. > And no, I don't have the time to do something > better myself now, so I'll just stick to it :-) If somebody would come up with a mode that used lambdas and arrows to render things nicely in my editor, I wouldn't mind. But I don't think the benefit for me would be great enough to justify the effort (I'm not much of a lisp hacker). -kzm -- If I haven't seen further, it is by standing in the footprints of giants From jadrian@mat.uc.pt Fri Feb 8 23:10:13 2002 From: jadrian@mat.uc.pt (Jorge Adriano) Date: Fri, 8 Feb 2002 23:10:13 +0000 Subject: character syntax In-Reply-To: References: <86bsf1p9i3.fsf@speakeasy.org> <200202081404.g18E4Vjq002044@pena.mat.uc.pt> Message-ID: <200202081514.g18FE2jq003292@pena.mat.uc.pt> On Friday 08 February 2002 14:35, Ketil Z. Malde wrote: > Jorge Adriano writes: > > Haskell looks nice... Isabell looks beautiful :-) > > I'm not familiar with Isabell, but aren't we comparing apples and > oranges here? E.g. you can prettify .lhs pretty nicely with one of > the LaTeX packages available. Well yes :-) You said "Personally, I think the Haskell syntax is beautiful", and in my answer I talked about the way it looked on Xemacs, not the syntax. But not sure if we are talking about the same thing here, how do you prettify the .lhs files? Are you talking about the dvi you get in the end or the way it looks while editing the code? > > And no, I don't have the time to do something > > better myself now, so I'll just stick to it :-) > > If somebody would come up with a mode that used lambdas and arrows to > render things nicely in my editor, I wouldn't mind. But I don't think > the benefit for me would be great enough to justify the effort (I'm > not much of a lisp hacker). I wouldn't mind either. Everything looks really nice, making your code really easy to read, it's not just the greek leters, the 'forall's, the arrows '=>', the 'and's and the 'or's. But the Isabell/Isar/Proof General (which I haven't used in a long time) mode had more to it than just that. The menus were pretty good, buttons (with icons) for some commands... it turns Xemacs into a very nice GUI for isabelle. J.A. From sof@galois.com Fri Feb 8 18:16:11 2002 From: sof@galois.com (Sigbjorn Finne) Date: Fri, 8 Feb 2002 10:16:11 -0800 Subject: win32 stand alone binaries? Message-ID: <036801c1b0cc$afe1eac0$8532a8c0@sofbox> Brett Morgan brett@pulse.itd.uts.edu.au writes: > > Is it possible to build win32 stand alone binaries using cygwin hosted > ghc tools? Hi, that's what you get by default these days, GHC doesn't rely on cygwin (nor the applications it produces). If you _really_ want to, you could compile up the GHC sources to use cygwin though, of course. hth --sigbjorn From jadrian@mat.uc.pt Fri Feb 8 22:55:56 2002 From: jadrian@mat.uc.pt (Jorge Adriano) Date: Fri, 8 Feb 2002 22:55:56 +0000 Subject: efficiency question In-Reply-To: <20020208225439.HQXW18783.fep03-svc.mail.telepac.pt@there> References: <20020208225439.HQXW18783.fep03-svc.mail.telepac.pt@there> Message-ID: <20020208225929.HRNI18783.fep03-svc.mail.telepac.pt@there> > I'd say that's because in the second case you also got to apply the (,), > besides the (+)/(-) constructor during the transversing... > Am I right? opss... I meant to write: the (,) constructor besides the (+)/(-)... J.A. From jadrian@mat.uc.pt Fri Feb 8 23:11:10 2002 From: jadrian@mat.uc.pt (Jorge Adriano) Date: Fri, 8 Feb 2002 23:11:10 +0000 Subject: efficiency question Message-ID: <20020208231439.HTHY18783.fep03-svc.mail.telepac.pt@there> > I'd say that's because in the second case you also got to apply the (,), > besides the (+)/(-) constructor during the transversing... > Am I right? opss... I meant to write: the (,) constructor besides the (+)/(-)... J.A. _______________________________________________ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe From remi@abcweb.nl Fri Feb 8 23:26:05 2002 From: remi@abcweb.nl (Remi Turk) Date: Sat, 9 Feb 2002 00:26:05 +0100 Subject: character syntax In-Reply-To: <86bsf1p9i3.fsf@speakeasy.org>; from itz@speakeasy.org on Thu, Feb 07, 2002 at 08:00:36AM -0800 References: <86bsf1p9i3.fsf@speakeasy.org> Message-ID: <20020209002604.A804@localhost> --17pEHd4RhPHOinZp Content-Type: text/plain; charset=us-ascii Content-Disposition: inline Content-Transfer-Encoding: quoted-printable On Thu, Feb 07, 2002 at 08:00:36AM -0800, Ian Zimmerman wrote: >=20 > I am new to the language (coming from ML) and I am sorry if my first > post turns out to be a flamebait, but I can't help it: >=20 > Why in the world did the designers of Haskell permit the ' character > to be both a prime (part of identifiers) and the single-character > quote? Didn't they realize what they were doing to would-be > intelligent editors? Or were they just a bunch of rabid ed users? >=20 > Has anyone found a way to deal with this in Emacs, _correctly_? That > is, among other things, '(' should be ignored for sexp parsing... I'm just back from a party so I may be, eh, a little bit drunk ;-) but I really don't see the problem. An identifier in Haskell cannot begin with a ' so if a "could-be-identifier" ;-) starts with a ' it is a character constant. It is completely parallel to digits AFAICS: An identifier may contain digits, but it cannot begin with one. So a "could-be-identifier" beginning with a digit is a number. Remi --=20 See the light and feel my warm desire, Run through your veins like the evening sun It will live but no eyes will see it, I'll bless your name before I die. Key fingerprint =3D CC90 A1BA CF6D 891C 5B88 C543 6C5F C469 8F20 70F4 --17pEHd4RhPHOinZp Content-Type: application/pgp-signature Content-Disposition: inline -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.0.6 (GNU/Linux) Comment: For info see http://www.gnupg.org iD8DBQE8ZF6MbF/EaY8gcPQRAoMGAKChiUhataniE/aH26wn5i8XPXD+owCghrCG wIXF8SipY1H5KdIy5lTMFtw= =BLgV -----END PGP SIGNATURE----- --17pEHd4RhPHOinZp-- From konsu@microsoft.com Sat Feb 9 01:24:40 2002 From: konsu@microsoft.com (Konst Sushenko) Date: Fri, 8 Feb 2002 17:24:40 -0800 Subject: efficiency question Message-ID: (moved to haskell-caf=E9) I ran Hal's code on my computer, and with test2 I get a stack overflow = (so I had to use +RTS option for it to finish). test1 does not overflow = stack (of standard size, I mean without +RTS). Which implies that test2 = uses more stack space than test1. why would it use more stack if not = because of laziness? konst > -----Original Message----- > From: Hal Daume III [mailto:hdaume@ISI.EDU]=20 > Sent: Friday, February 08, 2002 4:35 PM > To: Jorge Adriano > Cc: Konst Sushenko; haskell@haskell.org > Subject: Re: efficiency question >=20 >=20 > I agree that it's the overhead of (,), but I don't see why=20 > there would be > any overhead for doing this. >=20 > -- > Hal Daume III >=20 > "Computer science is no more about computers | hdaume@isi.edu > than astronomy is about telescopes." -Dijkstra | www.isi.edu/~hdaume >=20 > On Sat, 9 Feb 2002, Jorge Adriano wrote: >=20 > > On Friday 08 February 2002 23:52, Hal Daume III wrote: > > > I've tried using a strict fold: > > > > > > foldl' f a [] =3D a > > > foldl' f a (x:xs) =3D (foldl' f $! f a x) xs > > > > > > but that has no effect (or minimal effect). > >=20 > > That wouldn't work even if if laziness is the problem=20 > because that would only=20 > > cause the elements of the list to be evaluated to head=20 > normal form, the=20 > > elements of the pair would not be evaluated so you'd have a=20 > 'suspension of =20 > > (minus and plus) operations'. > >=20 > > instead of=20 > > > (\x (a,b) -> (x+a,x-b)) > > try=20 > > > (\x (a,b) -> (((,) $! x-a)$! x-b) ) > >=20 > > I just noticed that you were the one who sent me the DeepSeq module. > > This is the kind of place where I want to use it. > > Instead of $!, try $!!. > >=20 > >=20 > > And Konst Sushenko wrote: > > >>My guess is that it is due to the laziness of the=20 > addition/subtraction > > >>in (,) > >=20 > > Seems to me like lazyness is not the right guess because=20 > both functions Hall=20 > > first posted were lazy. So I think it's just the overhead=20 > of applying (,)=20 > > besides (+) and (-) in each step. Do I make sense or am I=20 > missing something? > >=20 > > J.A. > >=20 >=20 >=20 From jadrian@mat.uc.pt Sat Feb 9 11:38:13 2002 From: jadrian@mat.uc.pt (Jorge Adriano) Date: Sat, 9 Feb 2002 11:38:13 +0000 Subject: efficiency question In-Reply-To: References: Message-ID: <20020209114301.BAWP24189.fep04-svc.mail.telepac.pt@there> > (moved to haskell-café) Good idea :-) > I ran Hal's code on my computer, and with test2 I get a stack overflow (so > I had to use +RTS option for it to finish). test1 does not overflow stack > (of standard size, I mean without +RTS). Which implies that test2 uses more > stack space than test1. why would it use more stack if not because of > laziness? I see what you mean. Both are equally lazy but in the first case, > test1 l = > let s1 = foldr (+) 1 l > s2 = foldr (-) 1 l > in (s1, s2) creates a suspension of sums of ints when calculating s1, then a suspension of diferences of ints to calculate s2. The second one, > test2 l = > let s = foldr (\x (a,b) -> (x+a,x-b)) (1,1) l > in s Creates a suspension of (x0...(xn-1%(xn%(1,1)))...), where (%) is that 'sumdiffs' lambda expression. You are telling me this suspension is worst than the first ones... can somebody explain why? I'm not really beeing able to find a valid argument... If you make it strict on the (,), like: > test3 l = > let s = foldr (\x (a,b) -> ((,)$!x+a)$!x-b) (1,1) l > in s Things will get worst. Well, that's what I expected, the elements of the list will b reduced to head normal form, and instead of a suspension of (%), you'll have a suspension of sums in the fst element of the pair *and* a suspension of differences in the second element of the pair. OK, now lets forget about lazyness. I tried: >test1' l = > let s1 = sfoldl (+) 1 l > s2 = sfoldl (-) 1 l > in (s1, s2) >test2' l = > let s = sfoldl (\(a,b) x -> (x+a,x-b)) (1,1) l > in s Where sfold reduces both Ints and (Ints, Ints) to *normal form* The first one was still faster then the second one. So, I'd say you are right about lazyness also playing a role in the lack of efficience of Halls second function, but 1. you can't solve that problem by making the lambda function strict on (,) 2. strictness does not explains everything in that example, because if you use foldls and make them strict, no suspensions, the first version is still better. Don't take my word for it though. I'd *really* appreciate some comments from some haskell gurus on this problem and on my comments :-) J.A. J.A. From jadrian@mat.uc.pt Sat Feb 9 11:44:27 2002 From: jadrian@mat.uc.pt (Jorge Adriano) Date: Sat, 9 Feb 2002 11:44:27 +0000 Subject: efficiency question In-Reply-To: <20020209114301.BAWP24189.fep04-svc.mail.telepac.pt@there> References: <20020209114301.BAWP24189.fep04-svc.mail.telepac.pt@there> Message-ID: <20020209114849.BBLO24189.fep04-svc.mail.telepac.pt@there> On Saturday 09 February 2002 11:38, Jorge Adriano wrote: > If you make it strict on the (,), like: > > test3 l = > >     let s = foldr (\x (a,b) -> ((,)$!x+a)$!x-b) (1,1) l > >     in  s > > Things will get worst. > Well, that's what I expected, the elements of the list will b reduced to > head normal form, and instead of a suspension of (%), you'll have a > suspension of sums in the fst element of the pair *and* a suspension of > differences in the second element of the pair. Eh... no need to comment on this one... this was kind of dumb. Forget it... :-) J.A. From phaymen@yahoo.com Sat Feb 9 19:08:54 2002 From: phaymen@yahoo.com (Phil Haymen) Date: Sat, 9 Feb 2002 11:08:54 -0800 (PST) Subject: (no subject) Message-ID: <20020209190854.49238.qmail@web20101.mail.yahoo.com> hi,I have a function, using list comprehension to pick out the head and last elements from a list of lists and output this into a list without duplicates. It doesn't work. I want to know what is the error. function :: [[Int]] -> [Int] function seg = nub (concat([head s, last s | s <- seg]) __________________________________________________ Do You Yahoo!? Send FREE Valentine eCards with Yahoo! Greetings! http://greetings.yahoo.com From pixel@mandrakesoft.com Mon Feb 11 01:24:25 2002 From: pixel@mandrakesoft.com (Pixel) Date: 11 Feb 2002 02:24:25 +0100 Subject: syntax across languages Message-ID: http://merd.net/pixel/language-study/syntax-across-languages.html CHANGES: - the page has now much more entries - one can check the missing entries per language at http://merd.net/pixel/language-study/syntax-across-languages-per-language.html (160KB) see especially the haskell one http://merd.net/pixel/language-study/syntax-across-languages-per-language.html#Haskell Contributions, suggestions and fixes are welcome. -- Pixel programming languages addict http://merd.net/pixel/language-study/ From Mike Thomas" Hi there. Does anyone know where to get Jan's Haskell math/physics Haskell examples from since www.numeric-quest.com went down? An open-source LU matrix factorisation function would also be handy. Cheers Mike Thomas. From sqrtofone@yahoo.com Mon Feb 11 04:38:25 2002 From: sqrtofone@yahoo.com (Jay Cox) Date: Sun, 10 Feb 2002 22:38:25 -0600 (CST) Subject: Jan Skibinski's numeric-quest code In-Reply-To: <021701c1b2af$4bef7610$0cb4a8c0@nasturtium> Message-ID: On Mon, 11 Feb 2002, Mike Thomas wrote: > Hi there. > > Does anyone know where to get Jan's Haskell math/physics Haskell examples > from since www.numeric-quest.com went down? Not online (could google have cached these pages?) Alright. I'll put my copy up temporarly at http://www.flash.net/~flygal/Jay/Momenta.html http://www.flash.net/~flygal/Jay/QuantumVector.hml btw, for those on the list, the (apparent) original URL was http://www.numeric-quest.com/haskell/QuantumVector.html Jay Cox From Mike Thomas" Message-ID: <022b01c1b2b4$de99bfc0$0cb4a8c0@nasturtium> Thanks Jay. > Not online (could google have cached these pages?) I put the URLs into Google's search and got nothing. Is this the right way to find cached pages? > > Alright. I'll put my copy up temporarly at > > http://www.flash.net/~flygal/Jay/Momenta.html > http://www.flash.net/~flygal/Jay/QuantumVector.hml Have you got the Fraction, Orthogonals (Indexless Linear Algebra), tensor (N-dimensional tensors) and Fuzzy Oscillator modules too? > > > btw, for those on the list, the (apparent) original URL was > > http://www.numeric-quest.com/haskell/QuantumVector.html > > > Jay Cox > From sqrtofone@yahoo.com Mon Feb 11 04:59:16 2002 From: sqrtofone@yahoo.com (Jay Cox) Date: Sun, 10 Feb 2002 22:59:16 -0600 (CST) Subject: syntax across languages In-Reply-To: Message-ID: On 11 Feb 2002, Pixel wrote: > http://merd.net/pixel/language-study/syntax-across-languages.html > > CHANGES: > - the page has now much more entries > - one can check the missing entries per language at > http://merd.net/pixel/language-study/syntax-across-languages-per-language.html > (160KB) > see especially the haskell one > http://merd.net/pixel/language-study/syntax-across-languages-per-language.html#Haskell > > > Contributions, suggestions and fixes are welcome. > > Some random thoughts.... Under * Object Oriented & Reflexivity +---------------------------------------+ | class | class declaration | |-------------------+-------------------| | functional syntax | method invocation | +---------------------------------------+ I'm not sure anything under haskell can be considered OO but I'm no languages expert. You might could mention something about Type classes. This is the main (only) method of overloading functions in haskell. maybe you might make mention of polymorphic type system and how haskell uses type inferencing to determine the meaning of expressions (relates to type classes). Using data = Foo ... really should be meantioned as a way to construct new types. newtype = Foo ... (new type) type Foo = ... is only a type synonym. heres an example. type String = [Char] Under constrol structure, at least give mention to monads! Common examples (ST,IO,List,Maybe) and "do notation" Monads are defined by instanciating them under the Monad type class. (basically giving definitions for the operators >>= (aka 'bind') and >> I dont think you give list comprehensions a fair shake either. (btw, list comprehension is an example of an alternative syntax for using lists as a monad.) [f z elem | anylistfromlistoflists <- listoflists, element<-anylistfromlistoflists, elem >= 3, z <- someotherlist] References arent missing. They are implemented under both the ST and IO monads. sprintf ... show ?? (still show peruses no format specifiers so it can be kinda blah.) (!!) extracts a char from String since type String = [Char] oh, and it isnt missing those math functions either. Take another look at the Prelude (google search it as I'm to lazy to find out url for exact page in haskell 98 report) .... Oops, I see that "missing:" in your page really doesnt mean missing from language. A number of the "missing:" things (esp the math) can be had by just looking at the Haskell Report. a google search "Haskell 98 Report Prelude" probably gets you there. You Have quite a list of languages there. Seems like I've come upon your page before. I'm sure there'll be many more to bookmark it and use it. Jay Cox From sqrtofone@yahoo.com Mon Feb 11 05:29:51 2002 From: sqrtofone@yahoo.com (Jay Cox) Date: Sun, 10 Feb 2002 23:29:51 -0600 (CST) Subject: Jan Skibinski's numeric-quest code In-Reply-To: <022b01c1b2b4$de99bfc0$0cb4a8c0@nasturtium> Message-ID: On Mon, 11 Feb 2002, Mike Thomas wrote: > Thanks Jay. > > > Not online (could google have cached these pages?) > > I put the URLs into Google's search and got nothing. Is this the right way > to find cached pages? Actually just putting in the Module name seems to have worked. oh wait! (mind's bulb brightens.) (mind's bulb dims after fairly exaustive search) I tried various incantations of "site:numeric-quest.com" etc to not much avail. > > Alright. I'll put my copy up temporarly at > > > > http://www.flash.net/~flygal/Jay/Momenta.html > > http://www.flash.net/~flygal/Jay/QuantumVector.hml > > Have you got the Fraction, Orthogonals (Indexless Linear Algebra), tensor > (N-dimensional tensors) and Fuzzy Oscillator modules too? Nope. It was almost a freak of nature that I had the above. found mention of a QuantumOscillator Module etc (haskell mailing lists) but apparently google didnt cache it. Sorry, Jay Cox From ketil@ii.uib.no Mon Feb 11 07:55:15 2002 From: ketil@ii.uib.no (Ketil Z. Malde) Date: 11 Feb 2002 08:55:15 +0100 Subject: syntax across languages In-Reply-To: References: Message-ID: Pixel writes: > Contributions, suggestions and fixes are welcome. The . operator is used for package scope when packages (modules) are imported "qualified". Indentation can optionally be replaced by { ; and }. In addition to . function composition, there's also $ function application, which often is more practical to use. Under "control flow", there's also case x of v0 -> e0 v1 -> e1 ... otherwise -> e and | bool0 = e0 | bool1 = e1 | ... | otherwise = en I'm not sure if "iterate" counts as loop forever? I can't remember any %-based sprintf off the top of my head, but hey, who'd want one anyway? As for "duplicate n times", I suppose you'll have to combine the two Prelude functions (concat . repeat n), while (map toUpper)/(map toLower) converts the case of strings, (!!) accesses an indexed character, and substrings of lenght l at position i can be extracted by (take l . drop i). (Remember that strings are lists!) Dictionaries can (inefficiently in some cases) be constructed using assoc lists, with the "lookup" function as accessor. (I'm not sure what you'd want to include of this, but at least some of it should be relevant, I hope.) -kzm -- If I haven't seen further, it is by standing in the footprints of giants From claus.reinke@talk21.com Mon Feb 11 10:21:45 2002 From: claus.reinke@talk21.com (Claus Reinke) Date: Mon, 11 Feb 2002 10:21:45 -0000 Subject: Jan Skibinski's numeric-quest code References: Message-ID: <003701c1b2e5$e905a240$ae1ffea9@Standard> > > > Not online (could google have cached these pages?) > > > > I put the URLs into Google's search and got nothing. Is this the right way > > to find cached pages? try the Internet Archive: http://www.archive.org/ seems to have the pages. It would be worth hosting them at haskell.org. hth, Claus From pixel@mandrakesoft.com Mon Feb 11 11:51:07 2002 From: pixel@mandrakesoft.com (Pixel) Date: 11 Feb 2002 12:51:07 +0100 Subject: syntax across languages In-Reply-To: References: Message-ID: ketil@ii.uib.no (Ketil Z. Malde) writes: [...] > The . operator is used for package scope when packages (modules) are > imported "qualified". ok > Indentation can optionally be replaced by { ; and }. ok > In addition to . function composition, there's also $ function application, > which often is more practical to use. I could put it in "grouping expressions": $ ... Haskell WDYT? > > Under "control flow", there's also > > case x of > v0 -> e0 > v1 -> e1 > ... > otherwise -> e ok > > and > > | bool0 = e0 > | bool1 = e1 > | ... > | otherwise = en i put this one in category "if_then_else" (just like Lisp's "cond") uh... how can this be one-line written? > > I'm not sure if "iterate" counts as loop forever? I don't think there can be a "loop forever" construct in haskell? in OCaml, it is simply: let loop(f) = f() ; loop(f) and is only useful together with exceptions and side-effects. > > I can't remember any %-based sprintf off the top of my head, but hey, > who'd want one anyway? me! I've always wondered how you internationalize a program without it? eg: "This encryption key is too simple (must be at least %d characters long)" "The package %s needs to be installed. Do you want to install it?" (I agree you don't need the full power of sprintf for this) > (!!) accesses an indexed character ok > As for "duplicate n times", I suppose you'll > have to combine the two Prelude functions (concat . repeat n), > while (map toUpper)/(map toLower) converts the case of strings, > , and substrings of lenght l at position > i can be extracted by (take l . drop i). (Remember that strings are > lists!) i don't put any non-simple functions, the main aim is not to show how it can be done, but what are the various names used in various languages. > Dictionaries can (inefficiently in some cases) be constructed using > assoc lists, with the "lookup" function as accessor. there's a special entry for it: 'lookup an element in a association list' Thanks! From pixel@mandrakesoft.com Mon Feb 11 12:23:20 2002 From: pixel@mandrakesoft.com (Pixel) Date: 11 Feb 2002 13:23:20 +0100 Subject: syntax across languages In-Reply-To: References: Message-ID: Jay Cox writes: [...] > I'm not sure anything under haskell can be considered OO but I'm no > languages expert. IMO, it's very alike "mix-ins", Java's interfaces, pure abstract classes. > > You might could mention something about Type classes. This is the main > (only) method of overloading functions in haskell. > > maybe you might make mention of polymorphic type system and how haskell > uses type inferencing to determine the meaning of expressions (relates to > type classes). syntax-across-languages doesn't favour big explainations :p > > > Using > > data = Foo ... > really should be meantioned as a way to construct new types. > newtype = Foo ... (new type) > > type Foo = ... > is only a type synonym. heres an example. > type String = [Char] ok (i won't mention that i always have a hard time dinstiguishing them) > > Under constrol structure, at least give mention to monads! > Common examples (ST,IO,List,Maybe) and "do notation" > > Monads are defined by instanciating them under the Monad type class. > (basically giving definitions for the operators >>= (aka 'bind') and >> please be more precise, what do i put? in which category? > > > I dont think you give list comprehensions a fair shake either. > (btw, list comprehension is an example of an alternative > syntax for using lists as a monad.) > > > [f z elem | anylistfromlistoflists <- listoflists, > element<-anylistfromlistoflists, > elem >= 3, > z <- someotherlist] i could add a category for list comprehension. is this a good approximate syntax? [ f x0 x1 ... | x0 <- a_list, pred x0, ... ] > > > References arent missing. They are implemented under both the ST and IO > monads. what is the syntax? > > > sprintf ... show ?? (still show peruses no format specifiers so it can be > kinda blah.) no, "show" is really in the 'convert something to a string' category > > (!!) extracts a char from String since type String = [Char] ok > > oh, and it isnt missing those math functions either. Take another look > at the Prelude (google search it as I'm to lazy to find out url for exact > page in haskell 98 report) ok, added. From ketil@ii.uib.no Mon Feb 11 13:06:54 2002 From: ketil@ii.uib.no (Ketil Z. Malde) Date: 11 Feb 2002 14:06:54 +0100 Subject: syntax across languages In-Reply-To: References: Message-ID: Pixel writes: >> In addition to . function composition, there's also $ function application, >> which often is more practical to use. > I could put it in "grouping expressions": > $ ... Haskell Yes, but that might apply to the . operator too. But yes, essentially it replaces parentheses. >> | bool0 = e0 >> | bool1 = e1 >> | ... >> | otherwise = en > i put this one in category "if_then_else" (just like Lisp's "cond") Yes, "cond" is exactly what it is, I think. > uh... how can this be one-line written? Well, it needs to be part of something more, e.g. isZero x | x==0 = True | otherwise = False >> I can't remember any %-based sprintf off the top of my head, but hey, >> who'd want one anyway? > me! I've always wondered how you internationalize a program without it? That's easy - I don't :-) -kzm -- If I haven't seen further, it is by standing in the footprints of giants From jadrian@mat.uc.pt Mon Feb 11 13:34:07 2002 From: jadrian@mat.uc.pt (Jorge Adriano) Date: Mon, 11 Feb 2002 13:34:07 +0000 Subject: efficiency question In-Reply-To: References: Message-ID: <20020211134003.CUIJ20990.fep03-svc.mail.telepac.pt@there> On Monday 11 February 2002 02:10, Hal Daume III wrote: > So instaed of storing 1 and 2 in the list, it stores pointers to > them. The reason it does this is so that it makes it easy to generate > code for polymorhpic functions. (,) being boxed means that instead of > storing a pair of element, you're storing a pair of pointers. That means > you get worse performance because you have to chase more pointers. > > (at least that's my impression) Thanks, I knew the concept but not the name. On Sunday 10 February 2002 18:48, Kirsten Chevalier wrote: > I'd guess that it's not just that you have to apply the (,) constructor -- > it also has to do with the fact that the tuples it's constructing here are > boxed. This brings another question to my mind, isn't it toupling a standard technique used in functional programming? I'm pretty sure I've seen it focused in some papers/text books. I for one would not expect that folding the list twice would be more efficient... J.A. From pixel@mandrakesoft.com Mon Feb 11 16:32:19 2002 From: pixel@mandrakesoft.com (Pixel) Date: 11 Feb 2002 17:32:19 +0100 Subject: syntax across languages In-Reply-To: <20020211085709.R56515-100000@fledge.watson.org> References: <20020211085709.R56515-100000@fledge.watson.org> Message-ID: Patrick M Doane writes: [...] > I find sprintf to be not powerful enough for internationalization. The > specification of actual values is order dependant which may change from > language to language. not true with advanced printf's: There is one last vital consideration for output. The order of words in a sentence is different in various languages, for example, ``yellow flower'' becomes ``la flor amarilla'' en Espanbsp;nol. The differences between English and German are equally dramatic. To solve this problem, the standard printf() allows the order of the arguments to be handled in variable order in the format string. For example, if we have printf(fmt, month, date, who); we can use an fmt of %s %d is %s's birthday in English to produce ``April 26 is James's birthday'' and %3$s's geburtstag ist %2$d. %1$s in German to generate ``James's geburtstag ist 26. April.'' Notice that qualifiers like 2$ allows us to reorder the parameters to account for differing word order in different languages. (from http://www.alumni.caltech.edu/~copeland/work/i18n-b.html) From C.Reinke@ukc.ac.uk Mon Feb 11 17:33:35 2002 From: C.Reinke@ukc.ac.uk (C.Reinke) Date: Mon, 11 Feb 2002 17:33:35 +0000 Subject: syntax across languages In-Reply-To: Message from Pixel of "11 Feb 2002 12:51:07 +0100." Message-ID: > > I'm not sure if "iterate" counts as loop forever? > > I don't think there can be a "loop forever" construct in haskell? why not? > in OCaml, it is simply: > let loop(f) = f() ; loop(f) > and is only useful together with exceptions and side-effects. and in Haskell, it is simply: loop f = f >> loop f or, as there is little difference between control structures and other data structures, you can convert the latter into the former, using the list version of loop, called repeat: loop f = mapM_ id $ repeat f or simply: loop = foldr1 (>>) . repeat example (get ready to hit that interrupt key;-): loop (putStrLn "hi") > > I can't remember any %-based sprintf off the top of my head, but hey, > > who'd want one anyway? > > me! I've always wondered how you internationalize a program without it? > > eg: > "This encryption key is too simple (must be at least %d characters long)" > "The package %s needs to be installed. Do you want to install it?" > > (I agree you don't need the full power of sprintf for this) indeed not. you only want to factor out the strings, so that they can be collected in a single space for the translators/customizers convenience. functional abstraction allows you to just do that (then put the functions into a module per language, or collect them in tuples/records, and link or select as appropriate): encryptionTooSimple d = "This encryption key is too simple (must be at least " ++(show (d::Integer))++ characters long)" packageMissing s = "The package "++s++" needs to be installed. Do you want to install it?" but if you absolutely want printf-style formatting, Danvy's solution is very nice and simple (once someone had the idea;-): int k r x = k (r++(show (x::Integer))) -- an Integer str k r x = k (r++x) -- a String s x k r = k (r++x) -- format String fragment nl = s "\n" -- newline format p = p id "" (similar continuation-based functions for other types) Now you can try it in Hugs: Main> :t format $ s "age: " . int . s " name: " . str . nl format $ s "age: " . int . s " name: " . str . nl :: Integer -> [Char] -> [Char] Main> format ( s "age: " . int . s " name: " . str . nl ) 10 "IGS" "age: 10 name: IGS\n" See: RS-98-12 Olivier Danvy. Functional Unparsing. May 1998. 7 pp. This report supersedes the earlier report BRICS RS-98-5. Extended version of an article to appear in Journal of Functional Programming. http://www.brics.dk/RS/98/Ref/BRICS-RS-98-Ref/BRICS-RS-98-Ref.html#BRICS-RS-98-12 > i don't put any non-simple functions, the main aim is not to show how it can > be done, but what are the various names used in various languages. but it is one of the major features of functional languages that it is so easy to compose/reuse functionality! this is why Haskell doesn't need a name for everything - composing the functions can be as simple as (and more flexible than) composing the names. Claus From pixel@mandrakesoft.com Mon Feb 11 17:48:54 2002 From: pixel@mandrakesoft.com (Pixel) Date: 11 Feb 2002 18:48:54 +0100 Subject: syntax across languages In-Reply-To: References: Message-ID: "C.Reinke" writes: > > > I'm not sure if "iterate" counts as loop forever? > > > > I don't think there can be a "loop forever" construct in haskell? > [...] > loop f = f >> loop f > > [...] > example (get ready to hit that interrupt key;-): > > loop (putStrLn "hi") ok, got it. /me bad > > > I can't remember any %-based sprintf off the top of my head, but hey, > > > who'd want one anyway? > > > > me! I've always wondered how you internationalize a program without it? > [...] > you only want to factor out the strings, so that they > can be collected in a single space for the translators/customizers > convenience. functional abstraction allows you to just do that > (then put the functions into a module per language, or collect them > in tuples/records, and link or select as appropriate): > > encryptionTooSimple d = > "This encryption key is too simple (must be at least " > ++(show (d::Integer))++ characters long)" - i don't like separating the string from the code for simple strings - do you really suggest giving this translators? You can be sure it won't compile any more ;p ok, i agree one of the strength of gettext/po solution relies on available tools (eg: kbabel) [...] > Main> format ( s "age: " . int . s " name: " . str . nl ) 10 "IGS" > "age: 10 name: IGS\n" anyone really using this? ;p give me OCaml's Printf.sprintf!! [...] > > i don't put any non-simple functions, the main aim is not to show how it can > > be done, but what are the various names used in various languages. > > but it is one of the major features of functional languages that > it is so easy to compose/reuse functionality! this is why Haskell > doesn't need a name for everything - composing the functions can > be as simple as (and more flexible than) composing the names. I don't deny this. But anyway, haskell has quite a big library for very common functions (compared with OCaml for example), so it's not a big pb for haskell. From C.Reinke@ukc.ac.uk Mon Feb 11 18:14:30 2002 From: C.Reinke@ukc.ac.uk (C.Reinke) Date: Mon, 11 Feb 2002 18:14:30 +0000 Subject: syntax across languages In-Reply-To: Message from Pixel of "11 Feb 2002 18:48:54 +0100." Message-ID: > > encryptionTooSimple d = > > "This encryption key is too simple (must be at least " > > ++(show (d::Integer))++ characters long)" > > - i don't like separating the string from the code for simple strings if you don't extract the string, how can it be a parameter of/variable in your application? > - do you really suggest giving this translators? You can be sure it won't > compile any more ;p actually, this version seems to come from an out-of-date editor buffer (missing quote).. it won't compile!-) one thing I really don't like about Haskell is it's lacking support for HERE documents, as you'll find them in shells or in Perl. Am I the only one who's constantly bitten by this? Something like: encryptionTooSimple :: Integer -> String encryptionTooSimple d = < ToString a where toString :: a -> String instance Show a => ToString a where toString = show instance ToString Char where toString c = [c] instance ToString String where toString s = s As some of our implementers seem to be in fast-track-response mode, perhaps this has a chance of slipping in?-) Claus From pixel@mandrakesoft.com Mon Feb 11 18:48:48 2002 From: pixel@mandrakesoft.com (Pixel) Date: 11 Feb 2002 19:48:48 +0100 Subject: syntax across languages In-Reply-To: References: Message-ID: "C.Reinke" writes: > > > encryptionTooSimple d = > > > "This encryption key is too simple (must be at least " > > > ++(show (d::Integer))++ characters long)" > > > > - i don't like separating the string from the code for simple strings > > if you don't extract the string, how can it be a parameter > of/variable in your application? (GNU) C uses xgettext which extracts the tagged strings. All you have to do to i18n is to replace: printf("This encryption key ... at least %d ...", ...) with printf(_("This encryption key ... at least %d ..."), ...) [...] > > one thing I really don't like about Haskell is it's lacking > support for HERE documents, as you'll find them in shells or > in Perl. Am I the only one who's constantly bitten by this? > > > > > Something like: > > encryptionTooSimple :: Integer -> String > encryptionTooSimple d = < This encryption key is too simple (must be at least $d characters long) > HERE you have 2 propositions in one: multi-line strings and interpolated strings. * multi-line strings: - either HERE-documents (perl, sh...) - more complicated delimiter alike """ ... """ in python - nestable delimiter alike qq( ... (...) ...) in perl * interpolated strings - dollar marked variable expanded in strings (perl, sh...) - expression in the string alike "1+1 = #{1+1}" in Ruby - not really string interpolation, but there is also the Python way based on highly sugared sprintf Of course, all this can be found at http://merd.net/pixel/language-study/syntax-across-languages.html#Strings :) I think it would be a very nice addition in haskell's syntax From jayallen@microsoft.com Mon Feb 11 23:26:00 2002 From: jayallen@microsoft.com (Jay Allen) Date: Mon, 11 Feb 2002 15:26:00 -0800 Subject: (no subject) Message-ID: <1917990039F03747BE329AAFC8222B5705007E94@red-msg-04.redmond.corp.microsoft.com> Ask yourself what the type of "head s, last s" is in the exp portion of the comprehension. In fact, it's not a valid Haskell expression, unless you convert it into a list or a tuple. What you actually want is: function seg =3D nub (concat([[head s, last s] | s <- seg]) -J- Jay Allen Technical Lead, DSV Internet Client "The good news is that in 1995 we will have a good operating system and programming language; the bad news is that they will be Unix and C++." - Richard Gabriel -----Original Message----- From: Phil Haymen [mailto:phaymen@yahoo.com]=20 Sent: Saturday, February 09, 2002 11:09 AM To: haskell-cafe@haskell.org Subject: (no subject) hi,I have a function, using list comprehension to pick out the head and last elements from a list of lists and output this into a list without duplicates. It doesn't work. I want to know what is the error.=20 function :: [[Int]] -> [Int]=20 function seg =3D nub (concat([head s, last s | s <- seg]) =20 __________________________________________________ Do You Yahoo!? Send FREE Valentine eCards with Yahoo! Greetings! http://greetings.yahoo.com _______________________________________________ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe From sqrtofone@yahoo.com Tue Feb 12 02:59:07 2002 From: sqrtofone@yahoo.com (Jay Cox) Date: Mon, 11 Feb 2002 20:59:07 -0600 (CST) Subject: syntax across languages In-Reply-To: Message-ID: On 11 Feb 2002, Pixel wrote: > Jay Cox writes: > > > Using > > > > data = Foo ... > > really should be meantioned as a way to construct new types. > > newtype = Foo ... (new type) > > > > type Foo = ... > > is only a type synonym. heres an example. > > type String = [Char] > > ok (i won't mention that i always have a hard time dinstiguishing them) Actually, I guess really should have explained myself a bit further. data Foo = ... only way to construct new structures (like lists,Trees, algebraic data types, enums, blah). Perhaps a (contrived) example for your syntax could be like a cross between a Tree and the Either type as in data Foo a b = FooLeft a | FooRight b | Tree (Foo a b) (Foo a b) So now you can construct values of say Foo Integer String. (I guess its a cousin to templates in C++) Or perhaps you need a separate section for syntax for constructing new datatypes.. data Foo x ... = A | B x ... | C (Foo ...) | ... the above expresses the fact that 1. Foo can "map" over any type x,y,etc 2. you can have (0 or more) argument constructors 3. datatypes can be recursive. Now, newtype Foo = ... like "type" but creates a new type as far as the type checker is concerned. type String = [Char] newtype String2 = [Char] foo:: String <=> foo :: [Char] but not foo::String2 <=> foo :: [Char] (Please dont take this as an insult by my re-explaining these things. I just want to make myself clear.) > > Under constrol structure, at least give mention to monads! > > Common examples (ST,IO,List,Maybe) and "do notation" > > > > Monads are defined by instanciating them under the Monad type class. > > (basically giving definitions for the operators >>= (aka 'bind') and >> > > please be more precise, what do i put? in which category? I guess I suggested control structure because in a way, you can "control the flow" from a semantic point of view of your program by building / choosing a specific monad. For instance, usage of the List monad brings nondeterminism into the language (although, in reality, the multiple solutions alluded to by the term are elements of a deterministically (is that a word?!) produced list) Example: do x<-[1,2,3] y<-[4,5,6] if (y<6) then return (10*x + y) else fail "" result:[14,15,24,25,34,35] aside: this is a rough and perhaps slightly incorrect translation from [10*x + y | x<-[1,2,3],y<-[4,5,6],y<6] However, the concept of a monad is language independent. It's just that Haskell does so much to accomodate them. I suppose a sollution to what to do with do-notation is to put something like do stmnt var <-stmtn etc or do {stmnt; var <-stmtn; etc} under your section named "Various Operators" with description "do statments under monad" > is this a good approximate syntax? > > [ f x0 x1 ... | x0 <- a_list, pred x0, ... ] > sure. > > > > References arent missing. They are implemented under both the ST and IO > > monads. > > what is the syntax? no syntax, only functions which create/manipulate them (under some monad). do{ x<-newSTRef exp; y <-readSTRef x; writeSTRef x exp} for IORefs do s/ST/IO/g to above line. I suppose that truely this isn't part of the main specs (not in Haskell Report/Haskell Library Report but implemented in ghc & Hugs iirc and modules must be imported, etc) so this concept of "Reference" in Haskell to might too be omitted, unless you want to contrast with SML. Jay Cox From pixel@mandrakesoft.com Tue Feb 12 13:49:16 2002 From: pixel@mandrakesoft.com (Pixel) Date: 12 Feb 2002 14:49:16 +0100 Subject: syntax across languages In-Reply-To: References: Message-ID: [...] > (I guess its a cousin to templates in C++) > Or perhaps you need a separate section for syntax > for constructing new datatypes.. yes, i think so. With enums and ranges being a special case. i'll also put records [...] > (Please dont take this as an insult by my re-explaining these things. > I just want to make myself clear.) the pb is that the semantic is so different between the languages. So i just put all of them with no explaination. > > > Under constrol structure, at least give mention to monads! > > > Common examples (ST,IO,List,Maybe) and "do notation" > > > > > > Monads are defined by instanciating them under the Monad type class. > > > (basically giving definitions for the operators >>= (aka 'bind') and >> > > > > please be more precise, what do i put? in which category? > > I guess I suggested control structure because in a way, you can "control > the flow" from a semantic point of view of your program by building / > choosing a specific monad. For instance, usage of the List monad brings > nondeterminism into the language (although, in reality, > the multiple solutions alluded to by the term are elements of a > deterministically (is that a word?!) produced list) "syntax across languages" is about syntax! If something needs much explaination, it can't be included :p [...] > I suppose a sollution to what to do with do-notation is to put something > like > [...] > or do {stmnt; var <-stmtn; etc} > > under your section named "Various Operators" with description > "do statments under monad" I don't accept entries where only one language fits in :p (this may change as soon as monads appear in more languages) [...] > > > References arent missing. They are implemented under both the ST and IO > > > monads. > > > > what is the syntax? > > no syntax, only functions which create/manipulate them (under some monad). > > do{ x<-newSTRef exp; y <-readSTRef x; writeSTRef x exp} > > for IORefs do s/ST/IO/g to above line. eurk ERROR "/usr/share/hugs/lib/exts/ST.hs":48 - Syntax error in type expression (unexpected `.') isn't there a way ST.hs would require the extensions? a pragma or something? someone not knowing the "-98" would wonder for a long time about what to do :-( anyway, the simplest examples i found: show $ runST (do { x <- newSTRef 2; writeSTRef x 3 ; readSTRef x }) so i can write: newSTRef in "reference (pointer)" "creation" readSTRef writeSTRef in "reference (pointer)" "dereference" WDYT? PS: show $ runST $ do { x <- newSTRef 2; writeSTRef x 3 ; readSTRef x } is not working :'-( From ganesh.sittampalam@comlab.ox.ac.uk Tue Feb 12 14:12:33 2002 From: ganesh.sittampalam@comlab.ox.ac.uk (Ganesh Sittampalam) Date: Tue, 12 Feb 2002 14:12:33 +0000 Subject: syntax across languages In-Reply-To: References: Message-ID: On 12 Feb 2002 14:49:16 +0100, Pixel wrote: >eurk > >ERROR "/usr/share/hugs/lib/exts/ST.hs":48 - Syntax error in type expression (unexpected `.') > >isn't there a way ST.hs would require the extensions? a pragma or something? >someone not knowing the "-98" would wonder for a long time about what to do >:-( Being able to specify the extensions required in a source file would be very useful in a range of cases. Very often helping other people with Haskell (in the case where they are trying to use someone else's module) is just a question of saying "try '-98'" or "try '-fglasgow-exts'" or whatever. Cheers, Ganesh From Malcolm.Wallace@cs.york.ac.uk Tue Feb 12 14:43:22 2002 From: Malcolm.Wallace@cs.york.ac.uk (Malcolm Wallace) Date: Tue, 12 Feb 2002 14:43:22 +0000 Subject: syntax across languages In-Reply-To: Message-ID: > Being able to specify the extensions required in a source file would be very > useful in a range of cases. Very often helping other people with Haskell (in > the case where they are trying to use someone else's module) is just a > question of saying "try '-98'" or "try '-fglasgow-exts'" or whatever. ghc and nhc98 already support this. ghc's mechanism is {-# OPTIONS -fglasgow-exts ... etc #-} at the top of the file - but there are quite a few restrictions on what flags are accepted in that pragma. nhc98's mechanism is {-# OPTIONS_COMPILE -nkpat ... etc #-} anywhere in the file, which has no restrictions on the options it accepts - you can use anything that can appear on the commandline. Incidentally, nhc98 also recognises the form {-# OPTIONS_LINK -L/usr/local/lib -lreadline ... etc #-} for extra link options, which are accumulated from all modules specified on the commandline. Regards, Malcolm From tom@regex.com.au Wed Feb 13 01:09:51 2002 From: tom@regex.com.au (Tom Bevan) Date: 13 Feb 2002 12:09:51 +1100 Subject: Eager IO function Message-ID: <1013562592.10965.2.camel@bawbaw> How should I modify the function below so that characters are printed out as they arrive? Thanks. Tom printchar :: Handle -> IO () printchar handle = do c <- hGetChar handle putChar c From Malcolm.Wallace@cs.york.ac.uk Wed Feb 13 10:08:21 2002 From: Malcolm.Wallace@cs.york.ac.uk (Malcolm Wallace) Date: Wed, 13 Feb 2002 10:08:21 +0000 Subject: Eager IO function In-Reply-To: <1013562592.10965.2.camel@bawbaw> Message-ID: > How should I modify the function below so that characters are printed > out as they arrive? > > printchar :: Handle -> IO () > printchar handle = do c <- hGetChar handle > putChar c Try using hSetBuffering handle NoBuffering hSetBuffering stdout NoBuffering from the IO library, before you call printchar. If the input handle is attached to a terminal, you may also need to adjust the terminal emulation into `cbreak' mode, e.g. with System.system "stty cbreak" Don't forget to reset the terminal afterwards! Regards, Malcolm From joe@culturematic.net Wed Feb 13 12:59:34 2002 From: joe@culturematic.net (Joe) Date: Wed, 13 Feb 2002 07:59:34 -0500 Subject: syntax...(strings/interpolation/here docs) Message-ID: Does anybody with their elbows in the code think variable interpolation and/or multi-line strings are good/doable ideas? Would this be the sort of change one could make without a lot of previous familiarity with the implementation of Hugs/Ghc? It would be a *signifigant* boon to those of us trying to get haskell into organizations by using it as "maintainable perl/sh", and generally make an already delightful language more delightful. -------------------- Joe Bowers http://www.culturematic.net From simonmar@microsoft.com Wed Feb 13 13:23:44 2002 From: simonmar@microsoft.com (Simon Marlow) Date: Wed, 13 Feb 2002 13:23:44 -0000 Subject: Eager IO function Message-ID: <9584A4A864BD8548932F2F88EB30D1C6084D9E43@TVP-MSG-01.europe.corp.microsoft.com> > > How should I modify the function below so that characters=20 > are printed > > out as they arrive? > >=20 > > printchar :: Handle -> IO () > > printchar handle =3D do c <- hGetChar handle > > putChar c >=20 > Try using > hSetBuffering handle NoBuffering > hSetBuffering stdout NoBuffering > from the IO library, before you call printchar. If the input handle > is attached to a terminal, you may also need to adjust the terminal > emulation into `cbreak' mode, e.g. with > System.system "stty cbreak" > Don't forget to reset the terminal afterwards! GHC does the "stty cbreak" step for you, if the handle on which you set = the buffering mode is a terminal. Note also that not all systems have = an 'stty' command. Cheers, Simon From David_Feuer@brown.edu Wed Feb 13 13:24:22 2002 From: David_Feuer@brown.edu (David Feuer) Date: Wed, 13 Feb 2002 8:24:22 -0500 Subject: syntax...(strings/interpolation/here docs) Message-ID: <200202131324.IAA14868@vega.brown.edu> > From: Joe > Does anybody with their elbows in the > code think variable interpolation and/or > multi-line strings are good/doable ideas? Can't say I have my elbows in the code, but I think that multi-line strings could be useful. I'm not sure what I think about variable interpolation... I imagine it would make the language somewhat more difficult to parse. What would this be like, anyway? Something like "foo $(bar) baz" = "foo"++bar++"baz" ? And then you'd have to have some sort of quoting rule, for dollar signs followed by parens... I guess you'd probably want some variant that automatically applies show... > Would this be the sort of change one could make > without a lot of previous familiarity with > the implementation of Hugs/Ghc? You'd certainly need to be familiar with how to specify syntax, and how to write a parser. > It would be a *signifigant* boon to those > of us trying to get haskell into organizations > by using it as "maintainable perl/sh", and Haskell is not a "maintainable perl/sh". It is not a good language for simple shell scripts, and is not good for string processing either. Have you tried Scsh? Or Python? I don't think that supporting string hacking is a major goal for Haskell. > generally make an already delightful language > more delightful. This message has been brought to you by the letter alpha and the number pi. From simonmar@microsoft.com Wed Feb 13 13:30:29 2002 From: simonmar@microsoft.com (Simon Marlow) Date: Wed, 13 Feb 2002 13:30:29 -0000 Subject: syntax...(strings/interpolation/here docs) Message-ID: <9584A4A864BD8548932F2F88EB30D1C6084D9E49@TVP-MSG-01.europe.corp.microsoft.com> > Does anybody with their elbows in the > code think variable interpolation and/or > multi-line strings are good/doable ideas?=20 > Would this be the sort of change one could make > without a lot of previous familiarity with > the implementation of Hugs/Ghc? > It would be a *signifigant* boon to those > of us trying to get haskell into organizations > by using it as "maintainable perl/sh", and > generally make an already delightful language > more delightful. I once wondered about translating "aaa \$bbb ccc" into "aaa " ++ show bbb ++ " ccc" (before you check, \$ isn't a valid escape sequence in Haskell 98). Of = course, you could go all the way and do it properly: http://www.dcs.gla.ac.uk/~partain/haskerl/partain-1.html Cheers, Simon From Malcolm.Wallace@cs.york.ac.uk Wed Feb 13 13:42:04 2002 From: Malcolm.Wallace@cs.york.ac.uk (Malcolm Wallace) Date: Wed, 13 Feb 2002 13:42:04 +0000 Subject: syntax...(strings/interpolation/here docs) In-Reply-To: Message-ID: > Does anybody with their elbows in the > code think variable interpolation and/or > multi-line strings are good/doable ideas? > Would this be the sort of change one could make > without a lot of previous familiarity with > the implementation of Hugs/Ghc? I don't think it is really necessary to add the feature to the language, since you can program something very similar for yourself in user-code. Here's a sample of a single-character macro expansion within strings, that took a couple of minutes to write. module Printf where import Maybe(fromMaybe) hereDocument :: (Show a, Show b) => a -> b -> String hereDocument v w = "Multi-line string starts here\ \ and uses string gap delimiters.\n\ \ Variable names like $$a are filled in from the\n\ \ bindings specified in the `with` clause,\n\ \ e.g. $$a = $a, $$b = $b\n\ \ and unused bindings pass through e.g. $$c = $c." `with` [('a',show v), ('b',show w)] with :: String -> [(Char,String)] -> String [] `with` env = [] ('$':'$':cs) `with` env = '$': cs `with` env ('$':c:cs) `with` env = s ++ cs `with` env where s = fromMaybe ('$':c:[]) (lookup c env) (c:cs) `with` env = c : cs `with` env Regards, Malcolm From tweed@compsci.bristol.ac.uk Wed Feb 13 14:00:07 2002 From: tweed@compsci.bristol.ac.uk (D. Tweed) Date: Wed, 13 Feb 2002 14:00:07 +0000 (GMT) Subject: syntax...(strings/interpolation/here docs) In-Reply-To: <200202131324.IAA14868@vega.brown.edu> Message-ID: On Wed, 13 Feb 2002, David Feuer wrote: > > It would be a *signifigant* boon to those > > of us trying to get haskell into organizations > > by using it as "maintainable perl/sh", and > > Haskell is not a "maintainable perl/sh". It is not a good > language for simple shell scripts, and is not good for > string processing either. Have you tried Scsh? Or > Python? I don't think that supporting string hacking is a > major goal for Haskell. It does rather depend on what you're doing with perl -- if you're using it very much as a skeleton for firing off lots of other programs or doing stuff that relies on a high-level of ability with the filesystem (e.g., recursing over directory trees) then I don't think any of the existing systems are good for this, and I doubt they would ever be as useful as perl. But if you're doing something more like prototyping an algorithm which is mildly complicated then the kind of things that make Perl/Python nice (e.g., freedom from the excessive typing needed by C etc has vanished (albeit for different reasons), garbage collection, higher order functions) start to apply to Haskell. To make this concrete I have two programs which were initially written in Perl for speed (one of them is the makefile generator that crops up in all my bug reports :-) ) which got confusing and tortured enough in Perl that I moved them to Haskell. I think the two big disadvantages wrt Perl are (1) the comparative scarcity and paucity of libraries (particularly one which ran under Haskell 98 and gave you the equivalent of a Perl hash would be very useful) and (2) the way Perl is constructed to keep going in the face of problems like undefined variables, etc, which would crash a Haskell script. For proper, thoroughly debugged and tested programs (2) doesn't really matter but I can see it's useful for mod_perl scripts in Apache (say). ___cheers,_dave_________________________________________________________ www.cs.bris.ac.uk/~tweed/|`...heat generated by its microprocessors will email:tweed@cs.bris.ac.uk|slope upward exponentially, reaching the power work tel:(0117) 954-5250 |density of a nuclear reactor before 2010'-Intel From C.Reinke@ukc.ac.uk Wed Feb 13 14:36:01 2002 From: C.Reinke@ukc.ac.uk (C.Reinke) Date: Wed, 13 Feb 2002 14:36:01 +0000 Subject: syntax...(strings/interpolation/here docs) In-Reply-To: Message from Malcolm Wallace of "Wed, 13 Feb 2002 13:42:04 GMT." Message-ID: > > Does anybody with their elbows in the > > code think variable interpolation and/or > > multi-line strings are good/doable ideas? > > Would this be the sort of change one could make > > without a lot of previous familiarity with > > the implementation of Hugs/Ghc? Unlike my rough proposal, one should aim for a combination of (mostly) in-Haskell implementation and (some) pre-processing. As Thomas Nordin has pointed out to me in private email, Hugs (Dec 2001) already supports this (module lib/hugs/Quote.hs and flag +H). The real trick is to have the same support in all implementations.. > I don't think it is really necessary to add the feature to the language, > since you can program something very similar for yourself in user-code. It is not really necessary, but "very similar" isn't good enough for the purpose (see further down). - haven't tried with other systems, but Hugs at least has some limit on maximum token length (4000). This is a lot easier to avoid if string variable interpolation implicitly breaks up tokens. - I've tried to work with Haskell's \\-multiline strings - I don't find them useable. The extra characters at the end and start of lines make them less readable and less writeable than necessary for this kind of applications (my current workaround is to use break strings on lines, either with explicit concatenation or with lists of strings and the good old unlines to get rid of those "\n"s) - as said above, I do agree that there should be no complex language extensions for what can be done in Haskell, and Hugs' combination of Quote module and +H support gets close to that. If you have to change string quoting (to preserve formatting), you might as well throw in variable interpolation (only needs "..$(var).." -> ".."++quote var++"..", the rest is Haskell code). It is similar to what I posted, but the ``$(var) $$''-syntax is simpler, there are no overlapping instances, and there is an explicit function to trim leading whitespace instead of the extra layout rule I assumed. Here's your example, with Hugs' Quote: {- :set +H -} import Quote hereDocument v w = ``Multi-line string starts here and uses string gap delimiters. Variable names like $(a) are filled in from the bindings specified in the `with` clause, e.g. $(a) = $$a, $(b) = $$b and unused bindings pass through e.g. $(c) = $$c.'' where (a,b,c) = (v,w,"$c") After all, the purpose of here-documents is readability in programs that have to generate programs or formatted text (e.g., the popular Haskell/CGI libraries, or libraries generating XML/HTML/VRML/SVG/..). In those contexts, they are an important matter of convenience - you just write the text template you want to generate, filled in with variables. Meta-programming is difficult enough without asking for trouble (extra \ everywhere, explicit \n, by hand conversion from any type a to String, no checks of variable bindings instead of lexical scoping). The only disadvantage I've seen so far (apart from that maximum token length..) is the need to disambiguate numeric types for the overloaded quote, but that's a standard Haskell problem. Claus > Here's a sample of a single-character macro expansion within strings, > that took a couple of minutes to write. > > module Printf where > import Maybe(fromMaybe) > > hereDocument :: (Show a, Show b) => a -> b -> String > hereDocument v w = > "Multi-line string starts here\ > \ and uses string gap delimiters.\n\ > \ Variable names like $$a are filled in from the\n\ > \ bindings specified in the `with` clause,\n\ > \ e.g. $$a = $a, $$b = $b\n\ > \ and unused bindings pass through e.g. $$c = $c." > `with` [('a',show v), ('b',show w)] > > with :: String -> [(Char,String)] -> String > [] `with` env = [] > ('$':'$':cs) `with` env = '$': cs `with` env > ('$':c:cs) `with` env = s ++ cs `with` env > where s = fromMaybe ('$':c:[]) (lookup c env) > (c:cs) `with` env = c : cs `with` env From sqrtofone@yahoo.com Wed Feb 13 15:53:09 2002 From: sqrtofone@yahoo.com (Jay Cox) Date: Wed, 13 Feb 2002 09:53:09 -0600 (CST) Subject: syntax across languages In-Reply-To: Message-ID: On 12 Feb 2002, Pixel wrote: > eurk > > ERROR "/usr/share/hugs/lib/exts/ST.hs":48 - Syntax error in type expression (unexpected `.') > > isn't there a way ST.hs would require the extensions? a pragma or something? > someone not knowing the "-98" would wonder for a long time about what to do > :-( > That could be nice, at least for ST.hs (in ghc the equivalent of hugs option "-98" isn't needed) > anyway, the simplest examples i found: > > show $ runST (do { x <- newSTRef 2; writeSTRef x 3 ; readSTRef x }) > > so i can write: > > newSTRef in "reference (pointer)" "creation" > readSTRef writeSTRef in "reference (pointer)" "dereference" > > WDYT? If you understand your explanations for newSTRef etc. that's fine with me. My code in this thread (which coincidentally is a no-op) emphasizes which ones you would use "<-" with. So let me make one final adjustment so that: do{ x<-newSTRef 3; y <-readSTRef x; writeSTRef x (y+4);readSTRef x} Too long? > PS: show $ runST $ do { x <- newSTRef 2; writeSTRef x 3 ; readSTRef x } > is not working :'-( > _______________________________________________ Does typing in the following work? runST (do { x <- newSTRef 2; writeSTRef x 3 ; readSTRef x }) I can't explain and dont understand the error I get from the compiler with your code. (the haskell compilers I've used are not very helpful in error messages) Btw to get it to work in ghci you'd have to start: 1. ghci -package lang 2. load in some dummy file with 2 lines (so both Prelude and ST functions are available) ...(lines starting below!).... import ST main = print "hi" ....(lines ending)...... 3. type in runST ( ... ) Somebody would have to fill in the details for me about doing stuff in hugs. Jay From jeff@galois.com Wed Feb 13 16:42:09 2002 From: jeff@galois.com (Jeffrey R Lewis) Date: Wed, 13 Feb 2002 08:42:09 -0800 Subject: syntax...(strings/interpolation/here docs) In-Reply-To: References: Message-ID: <200202131642.g1DGg9A18127@kpacha.galois.com> On Wednesday 13 February 2002 06:36 am, C.Reinke wrote: > > > Does anybody with their elbows in the > > > code think variable interpolation and/or > > > multi-line strings are good/doable ideas? > > > Would this be the sort of change one could make > > > without a lot of previous familiarity with > > > the implementation of Hugs/Ghc? > > Unlike my rough proposal, one should aim for a combination of > (mostly) in-Haskell implementation and (some) pre-processing. As > Thomas Nordin has pointed out to me in private email, Hugs (Dec > 2001) already supports this (module lib/hugs/Quote.hs and flag +H). > > The real trick is to have the same support in all implementations.. I use here docs quite a bit. They are wonderful for writing error messages that are also readable in the code ;-) The point about same support in all implementations is of course a good one. Thomas and I are the culprits who put here docs in hugs in the first place. However, it is just as easy to support here docs using a pre-processor. I have a medium sized project that uses here docs, and can be used under both hugs and ghc. With hugs, I use the builtin feature, of course. With GHC, we just use a pre-processor. This is a bit awkward with GHC 5.02 and earlier versions, but starting with 5.03, GHC now has a proper interface for hooking in a pre-processor (don't know the details, bug Sigbjorn says it's in there). A convenient feature of here docs that makes it easy to implement as a pre-processor is that you can do the unhere doc translation so that it preserves line numbers. The only drawback to using a pre-processor is that it probably won't work with ghci (but then you probably don't need to write here docs at the command line either!). --Jeff From hdaume@ISI.EDU Wed Feb 13 22:56:25 2002 From: hdaume@ISI.EDU (Hal Daume III) Date: Wed, 13 Feb 2002 14:56:25 -0800 (PST) Subject: syntax...(strings/interpolation/here docs) In-Reply-To: <200202131642.g1DGg9A18127@kpacha.galois.com> Message-ID: > hugs and ghc. With hugs, I use the builtin feature, of course. With GHC, we > just use a pre-processor. This is a bit awkward with GHC 5.02 and earlier > versions, but starting with 5.03, GHC now has a proper interface for hooking > in a pre-processor (don't know the details, bug Sigbjorn says it's in there). Is this true? Is there any documentation on it? From ross@soi.city.ac.uk Thu Feb 14 16:03:30 2002 From: ross@soi.city.ac.uk (Ross Paterson) Date: Thu, 14 Feb 2002 16:03:30 +0000 Subject: preprocessors [was Re: syntax...(strings/interpolation/here docs)] In-Reply-To: <200202131642.g1DGg9A18127@kpacha.galois.com> References: <200202131642.g1DGg9A18127@kpacha.galois.com> Message-ID: <20020214160330.GA18941@soi.city.ac.uk> On Wed, Feb 13, 2002 at 08:42:09AM -0800, Jeffrey R Lewis wrote: > The point about same support in all implementations is of course a good one. > Thomas and I are the culprits who put here docs in hugs in the first place. > However, it is just as easy to support here docs using a pre-processor. I > have a medium sized project that uses here docs, and can be used under both > hugs and ghc. With hugs, I use the builtin feature, of course. With GHC, we > just use a pre-processor. This is a bit awkward with GHC 5.02 and earlier > versions, but starting with 5.03, GHC now has a proper interface for hooking > in a pre-processor (don't know the details, bug Sigbjorn says it's in there). That would be -F/-pgmF/-optF (they're documented). OK, some Haskell extensions can be implemented using preprocessors. It's imperfect (errors in the output hard to trace back to the source, errors in the preprocessor hard to handle properly) but it's better than nothing. But what's the best way to manage this? Suppose you have several modules, some of which need no preprocessor, while others need to be preprocessed in different ways (ignoring multiple extensions -- too hard). I've been doing this by using different filename extensions to distinguish them, plus a patched version of Hugs that can be told what filename extensions to accept, plus a preprocessor that uses the filename extensions to decide what to do. (For example, .y files could be sent through happy.) An alternative might be options in the source files, though the new GHC options are static, so that's not supported. From C.Reinke@ukc.ac.uk Thu Feb 14 16:36:02 2002 From: C.Reinke@ukc.ac.uk (C.Reinke) Date: Thu, 14 Feb 2002 16:36:02 +0000 Subject: syntax...(strings/interpolation/here docs) In-Reply-To: Message from Jeffrey R Lewis of "Wed, 13 Feb 2002 08:42:09 PST." <200202131642.g1DGg9A18127@kpacha.galois.com> Message-ID: {- > Unlike my rough proposal, one should aim for a combination of > (mostly) in-Haskell implementation and (some) pre-processing. As > Thomas Nordin has pointed out to me in private email, Hugs (Dec > 2001) already supports this (module lib/hugs/Quote.hs and flag +H). > > The real trick is to have the same support in all implementations.. -} module HereDocuments where {- :set +H -} import Quote text = `` When I mentioned pre-processing, I didn't mean doing something to generate a Haskell program, I meant simple language extension (as in: syntactic sugar). It is nice that the Hugs variant of here documents is easily implemented with pre-processing, but that should be done behind the scenes. Usually, I wouldn't make such a fuss, but here documents are really not some new and experimental feature. They're an old hat, and a very useful hat. The only question is how to integrate them into the rest of Haskell. The Lewis/Nordin suggestion implemented in Hugs looks like a good compromise, but it won't do harm to bind the sugar to an option/flag for a test period. In the end, a stable form of here documents should be part of the language (not part of what you can do to it with whatever tools in whatever contexts), directly supported by all implementations. '' main = putStrLn $ trim text -- Claus From ganesh.sittampalam@comlab.ox.ac.uk Thu Feb 14 17:38:11 2002 From: ganesh.sittampalam@comlab.ox.ac.uk (Ganesh Sittampalam) Date: Thu, 14 Feb 2002 17:38:11 +0000 Subject: syntax across languages In-Reply-To: References: Message-ID: <1dtn6uc5qoebo65pnaon815gisg6bn02lg@4ax.com> On Tue, 12 Feb 2002 14:43:22 +0000, Malcolm Wallace wrote: >> Being able to specify the extensions required in a source file would be very >> useful in a range of cases. Very often helping other people with Haskell (in >> the case where they are trying to use someone else's module) is just a >> question of saying "try '-98'" or "try '-fglasgow-exts'" or whatever. > >ghc and nhc98 already support this. [...] Ah, thanks. I appeal to everyone distributing Haskell libraries to use them, then :-) Cheers, Ganesh From mpj@cse.ogi.edu Thu Feb 14 20:25:22 2002 From: mpj@cse.ogi.edu (Mark P Jones) Date: Thu, 14 Feb 2002 12:25:22 -0800 Subject: syntax...(strings/interpolation/here docs) In-Reply-To: Message-ID: | Usually, I wouldn't make such a fuss, but here documents are really | not some new and experimental feature. They're an old hat, and a | very useful hat. The only question is how to integrate them into the | rest of Haskell. At a time when many developers pay careful attention to internationalization ("I18n"), which requires careful separation of program text (functionality) and user text (display), a feature that instead ties them more closely together seems to be a step in the wrong direction. The same argument can be made with respect to the widely recognized advantages of separating functionality (e.g., model/controller) from user interface (e.g., view). Personally, I would prefer a Haskell without Here documents. Instead of: greeting = "..." main = putStrLn $ trim text I would be happy to write: main = displayResource "greeting" leaving the system to locate the text of the greeting from a separate (perhaps locale sensitive) source at runtime, and to display it in an appropriate manner. In other words, I'd prefer to see the effort that might be spent on standardizing and implementing Here documents instead directed to designing and building I18n libraries (probably based on a more general "resource bundle" mechanism). Ultimately, it comes down to a question of what you're trying to achieve. Do you envisage Haskell as an elegant scripting language that competes with perl and ruby for quick but useful hacks? Or do you think it might better serve as a platform for writing significant user level applications with fancy user interfaces and international appeal? Of course, the two are not mutually exclusive, and the presence or absence of Here documents or resource bundles will not force the language in either way. But it will determine the "feel" of the language, and so have an impact on the way that it is perceived and used. All the best, Mark From itz@speakeasy.org Thu Feb 14 21:24:13 2002 From: itz@speakeasy.org (Ian Zimmerman) Date: 14 Feb 2002 13:24:13 -0800 Subject: syntax...(strings/interpolation/here docs) In-Reply-To: References: Message-ID: <86n0yb92pu.fsf@speakeasy.org> Mark> Ultimately, it comes down to a question of what you're trying to Mark> achieve. Do you envisage Haskell as an elegant scripting Mark> language that competes with perl and ruby for quick but useful Mark> hacks? Or do you think it might better serve as a platform for Mark> writing significant user level applications with fancy user Mark> interfaces and international appeal? Neither. The chief advantage of functional languages is supposed to be their clean semantics with straightforward formalization, which allows one to be confident in the correctness of relatively large and complex bodies of code. That advantage is forfeited when trying to interface directly to messy GUI toolkits (and _all_ GUI toolkits in existence are messy). Significant applications, yes; but only the _back-ends_ of such applications. -- Ian Zimmerman, Oakland, California, U.S.A. GPG: 433BA087 9C0F 194F 203A 63F7 B1B8 6E5A 8CA3 27DB 433B A087 The world has taken on a thickness of vulgarity that raises a spiritual man's contempt to the violence of a passion. Baudelaire From claus.reinke@talk21.com Thu Feb 14 21:45:12 2002 From: claus.reinke@talk21.com (Claus Reinke) Date: Thu, 14 Feb 2002 21:45:12 -0000 Subject: syntax...(strings/interpolation/here docs) References: Message-ID: <003901c1b5a0$e26eedc0$ae1ffea9@Standard> > | ..[here documents: .. old and very useful hat].. > At a time when many developers pay careful attention to > internationalization ("I18n"), which requires careful > separation of program text (functionality) and user text > (display), a feature that instead ties them more closely > together seems to be a step in the wrong direction. Sorry? We seem to be talking cross purposes here. What triggered this suggestion was actually a question about how to *improve* support for internationalisation in Haskell. I think that functional composition can give us a rather more expressive framework for this than the usual separation of applications into code and a text database. Few applications directly allow such a separation, especially when GUIs are involved, and even fewer improve when pressed into this scheme. Rigid code, to be patched by equally rigid text fragments, loaded from some resource-controlled database, is no replacement for text that can be parameterised by the code and code that adapts to the text (e.g., during layout or because of other variations of program behaviour necessitated by localisation). Haskell already supports unicorns (cough), and as some of these have actually been sighted in Haskell implementations, the debate on what they actually look like, or should look like, is ongoing. Haskell definitely supports abstraction and composition, so we can factor out application aspects (not just text) that need localisation, and link them (dynamically?) with the main parts of our applications. Some systematic approach would be useful, but apart from keeping track of the issues raised in the standards committees, I don't see why Haskellers should limit themselves to "the" standard way of patching C#/Java apps with translated text fragments. But that's just personal opinion. As you say, > ..the presence or absence of Here documents or resource > bundles will not force the language in either way. But > it will determine the "feel" of the language, and so have > an impact on the way that it is perceived and used. I can only see here documents facilitating string handling. Moreover, they are usually employed exactly to write text as it should be read, parameterised as necessary, but otherwise separated from the main code, and not interspersed with string construction operations. So they also help the separation you want. For what it's worth: my personal reason for wanting here documents is meta-programming in Haskell. For instance, I generate VRML scenes with embedded ECMAScript (not my choice..) from a Haskell embedding. Others generate HTML, e.g., in web server-side Haskell scripting or documentation generators, or XML, in general data processing, or Haskell code in program transformations, or C/Java/IL/IDL.. code in compilers and interface generators, or C code in C code transformations (although Galois implemented that in SML, I think), .. and so on, and so on. Haskell may not be very efficient at representing strings, but that is (a) an implementation issue and (b) hasn't hindered string processing to become one of the major application areas for Haskell. Here documents achieve at the level of strings a subset of what metaML achieves at the level of expressions. It doesn't cost much to have them, and it costs a lot not to have them - debugging program generators without them is a mess, and even with a self-made variable substitution it is unnecessarily error-prone. I'm a bit surprised that some Haskellers apparently have not experienced here documents as an entirely benign and productivity-enhancing feature. Just because it is usually found in shells and perls, that doesn't mean it wouldn't be good enough for a "real" language. But unless other Haskell application and library programmers in need of this cry out in favour, I'll grumble on in silence (hooray for Hugs, though;-). Regards, Claus PS. Unless I'm mistaken, "I18N/L10N" is a play with characters that befits the purpose rather badly: "Internationalisierung/Lokalisierung", ..(add your own translation here).. From Malcolm.Wallace@cs.york.ac.uk Fri Feb 15 11:27:05 2002 From: Malcolm.Wallace@cs.york.ac.uk (Malcolm Wallace) Date: Fri, 15 Feb 2002 11:27:05 +0000 Subject: preprocessors In-Reply-To: <20020214160330.GA18941@soi.city.ac.uk> Message-ID: > But what's the best way to manage this? Suppose you have > several modules, some of which need no preprocessor, while others need > to be preprocessed in different ways (ignoring multiple extensions -- > too hard). I've been doing this by using different filename extensions > to distinguish them, plus a patched version of Hugs that can be told > what filename extensions to accept, plus a preprocessor that uses the > filename extensions to decide what to do. (For example, .y files could > be sent through happy.) The latest version of hmake (3.01) has support for calling a preprocessor based on the filename extension, before calling the compiler on the resulting file. Currently, it recognises: .y Happy .ly literate Happy .gc GreenCard .hsc hsc2hs .chs C->HS .hs.cpp C preprocessor I'm not really sure whether the invocation magic for all of these is correct yet, but I would encourage people to try it out and send patches. It is pretty easy to add new preprocessors - there are basically four options to define for each pp in addition to the filename extension. Regards, Malcolm From ross@soi.city.ac.uk Fri Feb 15 11:39:36 2002 From: ross@soi.city.ac.uk (Ross Paterson) Date: Fri, 15 Feb 2002 11:39:36 +0000 Subject: preprocessors In-Reply-To: References: <20020214160330.GA18941@soi.city.ac.uk> Message-ID: <20020215113935.GA13407@soi.city.ac.uk> On Fri, Feb 15, 2002 at 11:27:05AM +0000, Malcolm Wallace wrote: > The latest version of hmake (3.01) has support for calling a > preprocessor based on the filename extension, before calling the > compiler on the resulting file. Currently, it recognises: > > .y Happy > .ly literate Happy > .gc GreenCard > .hsc hsc2hs > .chs C->HS > .hs.cpp C preprocessor > > I'm not really sure whether the invocation magic for all of these > is correct yet, but I would encourage people to try it out and > send patches. It is pretty easy to add new preprocessors - there > are basically four options to define for each pp in addition to the > filename extension. That's nice. Is it user-configurable? (i.e. without changing the compiler) From Malcolm.Wallace@cs.york.ac.uk Fri Feb 15 12:24:37 2002 From: Malcolm.Wallace@cs.york.ac.uk (Malcolm Wallace) Date: Fri, 15 Feb 2002 12:24:37 +0000 Subject: preprocessors In-Reply-To: <20020215113935.GA13407@soi.city.ac.uk> Message-ID: > > The latest version of hmake (3.01) has support for calling a > > preprocessor based on the filename extension, > That's nice. Is it user-configurable? (i.e. without changing the compiler) At the moment, the list of preprocessors is coded into hmake (not the compiler). The main reason for not storing it in an editable configuration file is because some of the options are functions, which don't readily lend themselves to Show and Read instances... However, like I said, there isn't much to it - anyone could edit the sources to add 5 lines for their favorite preprocessor. And I'm sure if user-configurability turns out to be a much-desired feature, we can recode the functional options somehow to be able to read them from a config file. Regards, Malcolm From christophe.certain@wanadoo.fr Sun Feb 17 08:20:07 2002 From: christophe.certain@wanadoo.fr (christophe certain) Date: Sun, 17 Feb 2002 09:20:07 +0100 Subject: add something to a list Message-ID: <3c6f67ac3d0c844a@mel-rta1.wanadoo.fr> (added by mel-rta1.wanadoo.fr) Hi, I'm a poor lonesome newbie in Haskell world, and I would like to add a string typed on the prompt to a list of strings which is already defined. It would look like something like : type Path = [String] currentPath::Path currentPath = [] getpiece ::IO String getpiece = do c <-getLine return c putpiece:: String->Path putpiece a = a:currentPath and then I could combine the two functions, but obviously it doesn't work. I dare understand that it's impossible isn't it ? Maybe the only way is to create a new [String] each time I want to add a new string ? No ? Christophe Certain From ahey@iee.org Sun Feb 17 11:38:11 2002 From: ahey@iee.org (Adrian Hey) Date: Sun, 17 Feb 2002 11:38:11 +0000 Subject: add something to a list In-Reply-To: <3c6f67ac3d0c844a@mel-rta1.wanadoo.fr> (added by mel-rta1.wanadoo.fr) References: <3c6f67ac3d0c844a@mel-rta1.wanadoo.fr> (added by mel-rta1.wanadoo.fr) Message-ID: <02021711381100.01048@localhost.localdomain> On Sunday 17 February 2002 08:20, christophe certain wrote: > Hi, > > I'm a poor lonesome newbie in Haskell world, and I would like to add a > string typed on the prompt to a list of strings which is already defined. > > It would look like something like : > > type Path = [String] > > currentPath::Path > currentPath = [] > > getpiece ::IO String > getpiece = do c <-getLine > return c > > putpiece:: String->Path > putpiece a = a:currentPath > > and then I could combine the two functions, but obviously it doesn't work. > I dare understand that it's impossible isn't it ? > > Maybe the only way is to create a new [String] each time I want to add a > new string ? No ? > > Christophe Certain You seem to expect currentPath to be updated by putpiece? This won't happen in Haskell. Once you've declared currentPath=[] it will always be []. Values never change. If you want the functional equivalent of accumulator variables they have to be an argument of a recursive function. So try this.. getPath :: Path -> IO Path getPath currentPath = do piece <- getLine if piece == "" then return currentPath else getPath (piece:currentPath) initialCurrentPath::Path initialCurrentPath = [] main :: IO () main = do path <- getPath initialCurrentPath putStrLn (show path) Regards -- Adrian Hey From co19@cornell.edu Sun Feb 17 17:04:58 2002 From: co19@cornell.edu (Cagdas Ozgenc) Date: Sun, 17 Feb 2002 19:04:58 +0200 Subject: add something to a list References: <3c6f67ac3d0c844a@mel-rta1.wanadoo.fr> (added by mel-rta1.wanadoo.fr) <02021711381100.01048@localhost.localdomain> Message-ID: <001201c1b7d5$6b00dbe0$0100a8c0@mitajara> > > You seem to expect currentPath to be updated by putpiece? This won't happen > in Haskell. Once you've declared > currentPath=[] > it will always be []. > > Values never change. If you want the functional equivalent of accumulator > variables they have to be an argument of a recursive function. So try this.. > > getPath :: Path -> IO Path > getPath currentPath = do > piece <- getLine > if piece == "" then return currentPath > else getPath (piece:currentPath) > > initialCurrentPath::Path > initialCurrentPath = [] > > main :: IO () > main = do > path <- getPath initialCurrentPath > putStrLn (show path) > > Regards > -- > Adrian Hey Hi Adrian, How can I add a function that sorts this list that I read from the user and accumulate using the function that you described? I am not asking for a sort algorithm of course, I am just wondering how to feed the IO Path as an input to a sort function? Is it suppose to look like this: sort :: IO Path -> IO Path or sort :: IO Path -> Path How do you iterate over IO Path? Thanks for taking time. From sqrtofone@yahoo.com Sun Feb 17 19:33:25 2002 From: sqrtofone@yahoo.com (Jay Cox) Date: Sun, 17 Feb 2002 13:33:25 -0600 (CST) Subject: add something to a list In-Reply-To: <001201c1b7d5$6b00dbe0$0100a8c0@mitajara> Message-ID: On Sun, 17 Feb 2002, Cagdas Ozgenc wrote: > Hi Adrian, > > How can I add a function that sorts this list that I read from the user and > accumulate using the function that you described? I am not asking for a sort > algorithm of course, I am just wondering how to feed the IO Path as an input > to a sort function? Is it suppose to look like this: > > sort :: IO Path -> IO Path It could. (to make it simpler you may need a sort' :: Path -> Path function though, as in. sort getpath = do x <- getpath -- x has type Path return (sort' x) where sort' = .... -- sort' is typed as above and produces -- a sorted list list of -- type Path > or > > sort :: IO Path -> Path The point of the IO monad is to thread the state of the "World" (which your program modifies) explicitly through your program. The pure functions are the plumbing. A function of type IO Path -> Path cannot modify the world state since the world state is not the result of function application *. > How do you iterate over IO Path? Um, I cant think of another good introductory way than that sort :: IO Path -> IO Path I mentioned above. Jay Cox * Minus the obvious facts that haskell implementions obviously do: 1. modify the world state as executing functions create new datastructures that need to be allocated, may cause garbage collection, maybe cause new heap allocation (do they?) or otherwise cause program termination (run out of stack/heap/ ... ), etc. 2. unless it uses sort unsafeIO and/or other "hacks." unsafeIO generally should not be used. PS: Anybody got any other suggestions for IO monad entry-level docs? I suppose Haskell Wiki on haskell.org might be good place to allude to. From ahey@iee.org Sun Feb 17 19:12:10 2002 From: ahey@iee.org (Adrian Hey) Date: Sun, 17 Feb 2002 19:12:10 +0000 Subject: add something to a list In-Reply-To: <001201c1b7d5$6b00dbe0$0100a8c0@mitajara> References: <3c6f67ac3d0c844a@mel-rta1.wanadoo.fr> <02021711381100.01048@localhost.localdomain> <001201c1b7d5$6b00dbe0$0100a8c0@mitajara> Message-ID: <02021719121000.01202@localhost.localdomain> On Sunday 17 February 2002 17:04, Cagdas Ozgenc wrote: > > getPath :: Path -> IO Path > > getPath currentPath = do > > piece <- getLine > > if piece == "" then return currentPath > > else getPath (piece:currentPath) > > > > initialCurrentPath::Path > > initialCurrentPath = [] > > > > main :: IO () > > main = do > > path <- getPath initialCurrentPath > > putStrLn (show path) > Hi Adrian, > > How can I add a function that sorts this list that I read from the user and > accumulate using the function that you described? I am not asking for a > sort algorithm of course, I am just wondering how to feed the IO Path as an > input to a sort function? Is it suppose to look like this: > > sort :: IO Path -> IO Path > > or > > sort :: IO Path -> Path > > How do you iterate over IO Path? > > Thanks for taking time. I don't know what iterating over something means (the opposite of iterating under something I suppose) I think you want something like this.. import List (sort) sortGet :: IO Path -> IO Path sortGet get = do got <- get return (sort got) or maybe even.. import Monad (liftM) sortGet :: IO Path -> IO Path sortGet = liftM sort Regards -- Adrian Hey From mark@chaos.x-philes.com Sun Feb 17 21:07:10 2002 From: mark@chaos.x-philes.com (Mark Carroll) Date: Sun, 17 Feb 2002 16:07:10 -0500 (EST) Subject: add something to a list In-Reply-To: Message-ID: On Sun, 17 Feb 2002, Jay Cox wrote: (snip) > PS: Anybody got any other suggestions for IO monad entry-level docs? (snip) Simon's "Tackling the Awkward Squad" paper was a revelation for me. -- Mark From cwitty@newtonlabs.com Mon Feb 18 03:38:05 2002 From: cwitty@newtonlabs.com (Carl R. Witty) Date: 17 Feb 2002 19:38:05 -0800 Subject: syntax...(strings/interpolation/here docs) In-Reply-To: "Claus Reinke"'s message of "Thu, 14 Feb 2002 21:45:12 -0000" References: <003901c1b5a0$e26eedc0$ae1ffea9@Standard> Message-ID: "Claus Reinke" writes: > Haskell definitely supports abstraction and composition, so we can > factor out application aspects (not just text) that need localisation, > and link them (dynamically?) with the main parts of our applications. > Some systematic approach would be useful, but apart from keeping > track of the issues raised in the standards committees, I don't see > why Haskellers should limit themselves to "the" standard way of > patching C#/Java apps with translated text fragments. I think there is a good reason to use standard localisation methods; it makes it cheaper/more likely to happen. It sounds like you're advocating localisation methods which would require the translators to know Haskell; this would make hiring translators more expensive (for a commercial proposition) or significantly reduce your pool of volunteers (if you rely on volunteer translators). Carl Witty From konsu@microsoft.com Mon Feb 18 04:50:22 2002 From: konsu@microsoft.com (Konst Sushenko) Date: Sun, 17 Feb 2002 20:50:22 -0800 Subject: order of evaluation ? Message-ID: This is a multi-part message in MIME format. --------------InterScan_NT_MIME_Boundary Content-Type: multipart/alternative; boundary="----_=_NextPart_001_01C1B837.C5CE3A92" ------_=_NextPart_001_01C1B837.C5CE3A92 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable hello, =20 below is the code that i wrote as an excercise for myself (I am still learning haskell). =20 it implements a straighforward way to simplify boolean expressions, and should be self-explanatory. =20 my question is, if i have an expression such as ((Const False) :&: ), will be reduced first (according to the definition 'simplify (x :&: y) =3D simplify' ((simplify x) :&: (simplify y))') or will laziness do the right thing, and emit (Const False) without looking into ? =20 i think the latter, but would appreciate a word from an expert. =20 thanks konst =20 PS: any coding suggestions, etc. are also welcome =20 =20 =20 infixr 3 :&: infixr 2 :|: =20 data Exp =3D Const Bool | Sym String | Not Exp | Exp :&: Exp | Exp :|: Exp =20 instance Eq Exp where (Const x) =3D=3D (Const y) =3D x=3D=3Dy (Sym x) =3D=3D (Sym y) =3D x=3D=3Dy (Not x) =3D=3D (Not y) =3D x=3D=3Dy (x :&: y) =3D=3D (u :&: v) =3D x=3D=3Du && y=3D=3Dv || x=3D=3Dv && = y=3D=3Du (x :|: y) =3D=3D (u :|: v) =3D x=3D=3Du && y=3D=3Dv || x=3D=3Dv && = y=3D=3Du _ =3D=3D _ =3D False =20 simplify (x :&: y) =3D simplify' ((simplify x) :&: (simplify y)) simplify (x :|: y) =3D simplify' ((simplify x) :|: (simplify y)) simplify (Not x) =3D simplify' (Not (simplify x)) simplify x =3D x =20 simplify' (Not (Const True)) =3D Const False simplify' (Not (Const False)) =3D Const True =20 simplify' (Not (Not x)) =3D x =20 simplify' ((Not x) :&: y) | x=3D=3Dy =3D Const False simplify' (x :&: (Not y)) | x=3D=3Dy =3D Const False simplify' ((Not x) :|: y) | x=3D=3Dy =3D Const True simplify' (x :|: (Not y)) | x=3D=3Dy =3D Const True =20 simplify' ((Const False) :&: _) =3D Const False simplify' (_ :&: (Const False)) =3D Const False simplify' ((Const True) :&: x) =3D x simplify' (x :&: (Const True)) =3D x =20 simplify' ((Const True) :|: _) =3D Const True simplify' (_ :|: (Const True)) =3D Const True simplify' ((Const False) :|: x) =3D x simplify' (x :|: (Const False)) =3D x =20 simplify' (x :&: y) | x=3D=3Dy =3D x simplify' (x :|: y) | x=3D=3Dy =3D x =20 simplify' x =3D x =20 ------_=_NextPart_001_01C1B837.C5CE3A92 Content-Type: text/html; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Message
hello,
 
below is the=20 code that i wrote as an excercise for myself (I am still learning=20 haskell).
 
it=20 implements a straighforward way to simplify boolean expressions, and = should be=20 self-explanatory.
 
my question=20 is, if i have an expression such as ((Const False) :&: = <subexp>), will=20 <subexp> be reduced first (according to the definition=20 'simplify (x :&: y) =3D simplify' ((simplify x) :&: = (simplify y))')=20 or will laziness do the right thing, and emit (Const False) without = looking into=20 <exp>?
 
i think the=20 latter, but would appreciate a word from an expert.
 
thanks
konst
 
PS: any=20 coding suggestions, etc. are also welcome
 
 
 


infixr 3 :&:
infixr 2 = :|:
 
data Exp =3D Const=20 Bool
         | Sym=20 String
         | Not=20 Exp
         | Exp :&:=20 Exp
         | Exp :|:=20 Exp
 
instance Eq Exp = where
   =20 (Const x) =3D=3D (Const y) =3D x=3D=3Dy
    (Sym = x)   =3D=3D (Sym=20 y)   =3D x=3D=3Dy
    (Not x)   = =3D=3D (Not=20 y)   =3D x=3D=3Dy
    (x :&: y) =3D=3D = (u :&: v) =3D=20 x=3D=3Du && y=3D=3Dv || x=3D=3Dv && = y=3D=3Du
    (x :|: y) =3D=3D=20 (u :|: v) =3D x=3D=3Du && y=3D=3Dv || x=3D=3Dv && = y=3D=3Du
   =20 _         =3D=3D=20 _         =3D False
 
simplify (x :&: y) =3D = simplify'=20 ((simplify x) :&: (simplify y))
simplify (x :|: y) =3D simplify' = ((simplify=20 x) :|: (simplify y))
simplify (Not x)   =3D simplify' (Not = (simplify=20 x))
simplify x         =3D=20 x
 
simplify' (Not (Const=20 True))     =3D Const False
simplify' (Not (Const=20 False))    =3D Const True
 
simplify' (Not (Not=20 x))          =3D = x
 
simplify' ((Not x) :&: y) | = x=3D=3Dy =3D=20 Const False
simplify' (x :&: (Not y)) | x=3D=3Dy =3D Const = False
simplify'=20 ((Not x) :|: y) | x=3D=3Dy =3D Const True
simplify' (x :|: (Not y)) | = x=3D=3Dy =3D Const=20 True
 
simplify' ((Const False) = :&: _)  =3D=20 Const False
simplify' (_ :&: (Const False))  =3D Const=20 False
simplify' ((Const True) :&: x)   =3D = x
simplify' (x=20 :&: (Const True))   =3D x
 
simplify' ((Const True) :|: = _)  =20 =3D Const True
simplify' (_ :|: (Const True))   =3D Const=20 True
simplify' ((Const False) :|: x)  =3D x
simplify' (x :|: = (Const=20 False))  =3D x
 
simplify' (x :&: y) |=20 x=3D=3Dy       =3D x
simplify' (x :|: = y) |=20 x=3D=3Dy       =3D x
 
simplify'=20 x            =          =20 =3D x
 
------_=_NextPart_001_01C1B837.C5CE3A92-- --------------InterScan_NT_MIME_Boundary-- From bjpop@cs.mu.OZ.AU Mon Feb 18 07:02:40 2002 From: bjpop@cs.mu.OZ.AU (Bernard James POPE) Date: Mon, 18 Feb 2002 18:02:40 +1100 (EST) Subject: order of evaluation ? Message-ID: <200202180702.SAA29442@mulga.cs.mu.OZ.AU> konst writes: > my question is, if i have an expression such as ((Const False) :&: > ), will be reduced first (according to the definition > 'simplify (x :&: y) = simplify' ((simplify x) :&: (simplify y))') or > will laziness do the right thing, and emit (Const False) without looking > into ? > i think the latter, but would appreciate a word from an expert. Hi Konst, There is an easy way to check, try making an erroneous computation. There is such a value in the Prelude, it is called undefined: simplify ((Const False) :&: undefined) If this bombs then you know that simplify wasn't as lazy as you thought, since it must have tried to evaluated 'undefined'. On my version of hugs I get: Program error: {undefined} The important bits of code are: simplify (x :&: y) = simplify' ((simplify x) :&: (simplify y)) simplify' (x :&: (Not y)) | x==y = Const False simplify' ((Const False) :&: _) = Const False The order of the equations for simplify' is important. Effectively pattern matching causes evaluation in Haskell. To determine whether the first equation for simplify' should be used, the second argument of :&: must be evaluated to what is called "weak head normal form" (whnf). This means that the outermost constructor of that argument must be computed. Hence the computation with undefined fails in this case. However, what happens if you swap the order of the equations for simplify'? Doing so will give you the lazyness that you originally expected (for this particular example). Swapping the order of equations is not a silver bullet however, and you must be very careful with how you order them. One of the best places to learn about the operational semantics of languages like Haskell is "The Implementation of Functional Programming Languages" by Simon Peyton Jones. I think it is out of print, but you may find copies in your local uni library if you are lucky. For this particular example, pay close attention to the Pattern Matching Compiler section, which I think was done by Wadler. Cheers, Bernie. From ketil@ii.uib.no Mon Feb 18 09:17:46 2002 From: ketil@ii.uib.no (Ketil Z. Malde) Date: 18 Feb 2002 10:17:46 +0100 Subject: laziness again... Message-ID: Hi, I'm a bit puzzled by this observatio that I made. I have a function that, pseudocoded, lookes somewhat like f i as bs cs = ins i (f (i+1) as) ++ ins i (f (i+1) bs) ++ ins i (f (i+1) cs) where ins i = manipulates the first element of the list Now, without the ins'es, the function appears to be lazy, i.e I can "take" a part of it without evalutating the rest. With the ins'es, the whole thing seems to be calculated as soon as I touch it. Is this obvious? Or is my observation wrong? -kzm -- If I haven't seen further, it is by standing in the footprints of giants From Shawn@Garbett.org Mon Feb 18 14:29:42 2002 From: Shawn@Garbett.org (Shawn P. Garbett) Date: Mon, 18 Feb 2002 08:29:42 -0600 Subject: Trouble with DtdToHaskell Message-ID: <20020218142946.ETWA25848.femail30.sdc1.sfba.home.com@there> -----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 I've got a debian install (2.2.18kernel, 2.95.4 gnu c compiler) with ghc installed using hmake. I also found DtdToHaskell was installed on my computer. I run it on any Dtd and get the following: spg@Further:~/clean$ DtdToHaskell clean.dtd module DTD_clean where import Xml2Haskell {-Type decls-} {-Instance decls-} {-Done-} This also happens if I compile DtdToHaskell myself from the source. Any ideas what's misconfigured? - -- You're in a maze of twisty little statements, all alike. Public Key available from http://www.garbett.org/public-key -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.0.6 (GNU/Linux) Comment: For info see http://www.gnupg.org iD8DBQE8cQ/ZDtpPjAQxZ6ARAopFAJ4pePWkXo3TCtadkBR67zHHWoGPRwCfT8qL 86iZ8hdUPZHhbSA3DUVhB84= =k7Ax -----END PGP SIGNATURE----- From sqrtofone@yahoo.com Mon Feb 18 16:18:03 2002 From: sqrtofone@yahoo.com (Jay Cox) Date: Mon, 18 Feb 2002 10:18:03 -0600 (CST) Subject: laziness again... In-Reply-To: Message-ID: On 18 Feb 2002, Ketil Z. Malde wrote: > > Hi, > > I'm a bit puzzled by this observatio that I made. I have a function > that, pseudocoded, lookes somewhat like > > f i as bs cs = ins i (f (i+1) as) ++ ins i (f (i+1) bs) ++ ins i (f (i+1) cs) > where ins i = manipulates the first element of the list > > Now, without the ins'es, the function appears to be lazy, i.e I can > "take" a part of it without evalutating the rest. With the ins'es, > the whole thing seems to be calculated as soon as I touch it. > > Is this obvious? Or is my observation wrong? > > -kzm um, looks like ins i returns a function of one argument which results in a list. (or ins is a function of two arguments which results in a list and ins i is just using currying; however you want to look at it) My question is if that function (ins i) is strict. Jay From sqrtofone@yahoo.com Tue Feb 19 00:49:54 2002 From: sqrtofone@yahoo.com (Jay Cox) Date: Mon, 18 Feb 2002 18:49:54 -0600 (CST) Subject: laziness again... In-Reply-To: Message-ID: On Mon, 18 Feb 2002, Jay Cox wrote: > On 18 Feb 2002, Ketil Z. Malde wrote: > > > > > Hi, > > > > I'm a bit puzzled by this observatio that I made. I have a function > > that, pseudocoded, lookes somewhat like > > > > f i as bs cs = ins i (f (i+1) as) ++ ins i (f (i+1) bs) ++ ins i (f (i+1) cs) > > where ins i = manipulates the first element of the list > > > > Now, without the ins'es, the function appears to be lazy, i.e I can > > "take" a part of it without evalutating the rest. With the ins'es, > > the whole thing seems to be calculated as soon as I touch it. > > > > Is this obvious? Or is my observation wrong? > > > > -kzm > > > um, looks like ins i returns a function of one argument which results > in a list. (or ins is a function of two arguments which results in a list > and ins i is just using currying; however you want to look at it) > > My question is if that function (ins i) is strict. > > Jay . I should have read your letter more closely. > > where ins i = manipulates the first element of the list if you mean that (ins i) :: [a] -> [a] manipulates the first element of the list it takes then of course it is strict. because in ins i = \x -> case x of (a:as) -> foo a : as [] -> [] where foo a = ... ((ins i) list) must pattern match on list. therefore (ins i) _|_ = _|_ QED. I guess the kind of strictness I was thinking about is something along the lines of what you might get if you applied deepseq to the list (if such a type of strictness has been defined by anybody!) I got a bit confused. (example definition for sake of argument) (a:xs) ++ list = a:(xs ++ list) [] ++ list = list If (ins i) had such deep strictness then when the first element of (f i as bs cs) was forced, haskell would generate all of the list created by (ins i (f (i+1) as) since (++) is strict in the first argument. however, (:) is strict in neither argument, so (++) is lazily applied. Anyway... You might follow Bernard James POPE recent posting (Subject: re: order of evaluation) about using "undefined" in the list to see how things are being evaluated, like in list = 3:4:5:undefined or list = 3:4:5:error "foo" (I got that idea from one of Simon Marlow's papers) Jay Cox PS: deepseq was mentioned earlier in either this list or the other main Haskell list. I believe it was actually a DeepSeq module of some sort. From ru@river.org Tue Feb 19 04:57:09 2002 From: ru@river.org (Richard Uhtenwoldt) Date: Mon, 18 Feb 2002 20:57:09 -0800 Subject: A View of Monads (Re: performance of monads) In-Reply-To: <3C4671C8.F0AC9A@bga.com> References: <27918.1011193548@cl.cam.ac.uk> <3C4671C8.F0AC9A@bga.com> Message-ID: Artie Gold writes: >One way to think of it is to look at a program as a partially ordered >set of calculations; some calculations need to occur before others, >other groups can occur in any order. In an imperative language you >specify a total ordering (which is overkill). This is a weak argument. First of all it is not the case that imperative coders always specify a total ordering: multitasking, threading and interrupts (and their projections into software as in Unix signals and asynchronous exceptions) are ways of specifying partial ordering when a total ordering would lose. The potential execution speedups of the partial ordering are probably quite real, emphasis of potential, and people having been trying to exploit it for decades now, yet the fast languages are still the imperative ones and the impure functional ones because they have the best fit to modern hardware designs. There is so much wealth invested in these modern cpus designs that it would cost 100s of billions of dollars to create competitors best fitted to pure functional languages. Hint: you need to write a new OS design to go with your new hardware design, then attract users and developers to the OS. And nobody's going to invest that dough there because no single organization stands to gain anywhere near what it would cost. Note that modern cpu designs use "out-of-order" execution strategies; so on micro-second timescales they ignore the total ordering when doing so suits them and when it preserves semantics. There's a case for FP, but parallel execution opportunities is not it. The case for FP is superior abstracting ability. See John Hughes, Why Functional Programming Matters. I guess you could view not having to specify instruction ordering when you do not need to as a sort of abstracting, but I have yet to see code that profits from that kind of abstraction. If that's your argument, show me code examples; that's what Hughes did in his paper. No grudge against you, Artie Gold. This is pent-up frustration at many posters who've made the same argument >"May you keep turning the pages. And may the book never end." You, too. -- Richard Uhtenwoldt From ketil@ii.uib.no Tue Feb 19 07:49:10 2002 From: ketil@ii.uib.no (Ketil Z. Malde) Date: 19 Feb 2002 08:49:10 +0100 Subject: laziness again... In-Reply-To: References: Message-ID: Jay Cox writes: >>> where ins i = manipulates the first element of the list > if you mean that (ins i) :: [a] -> [a] manipulates the first element of > the list it takes then of course it is strict. because in It is strict in the head of the list, yes. I.e. it is defined as ...where ins i ((_,x):xs) = (i,x):xs Apologies for being unprecise. > PS: deepseq was mentioned earlier in either this list or the other main > Haskell list. I believe it was actually a DeepSeq module of some sort. After some heap profiling (which produces marvellous plots, but is very expensive in running time. My tests that normally (without profiling, or just -p) run in a couple of minutes took over an hour. Also, the graphs indicate quite a bit less than top, but I ascribe that to the RTS and garbage-collectables lying around), I'm starting to suspect I'm generating a lot of unevaluated thunks. Is there any good tutorial or other material dealing with, and improving (memory) performance by, strictness in Haskell? -kzm -- If I haven't seen further, it is by standing in the footprints of giants From herrmann@infosun.fmi.uni-passau.de Tue Feb 19 11:20:04 2002 From: herrmann@infosun.fmi.uni-passau.de (Ch. A. Herrmann) Date: Tue, 19 Feb 2002 12:20:04 +0100 Subject: a universal printer for Haskell? In-Reply-To: <200202190918.UAA27407@mulga.cs.mu.OZ.AU> References: <15472.59192.358435.631995@reger.fmi.uni-passau.de> <200202190918.UAA27407@mulga.cs.mu.OZ.AU> Message-ID: <15474.13540.816210.615630@reger.fmi.uni-passau.de> Hi Haskellers, >>>>> "Bernard" == Bernard James POPE writes: Bernard> Handling functions is always going to be hard. Actually, a Bernard> related issue in Haskell is what do you do with partially Bernard> evaluated structures? Certainly in some circumstances you Bernard> don't want to force the value just so that you can write it Bernard> out. sorry if I wasn't precise enough. I don't want to force ANY evaluation on the value to be marshalled; in some cases the computation may even not terminate! Instead, the string is an encoding of the smallest part of the heap that is necessary to restore the information. My aim is to save a state which contains unevaluated closures to disk and resume the computation at a later time or to send a state to a remote location. The nice property of a functional language, in contrast to imperative languages, is that you can make a snapshot of your computation without any support by the runtime environment if, of course, those (un)marshalling functions are available. Bernard> If you compiled to byte code, life would be a lot Bernard> easier, however everything will get a lot messier if you Bernard> want to mix machine code and byte code. urgh... The problem is to encode program functions, not just functions that arise during the computation. Compiling to byte code is a different issue. Bernard> It would be nice if you could write out some data to file from Bernard> GHC and then read it in using NHC :) That'll be very complicated and require a deep discussion about an interface language. Bernard> I think Clean has a prototype persistence mechanism, I saw Bernard> a short demo late last year. I'm not sure how they Bernard> represent functional values. I think you can only read the Bernard> data from within the same program that wrote the data. That would be OK for me. It would even be OK if it is the same binary, i.e., not to be used in heterogeneous networks. Anyway, I don't like to change my favourite programming language unless it's better than Haskell and that'll be very likely Haskell-II :-) Cheers -- Christoph From erayo@cs.bilkent.edu.tr Tue Feb 19 14:50:56 2002 From: erayo@cs.bilkent.edu.tr (Eray Ozkural) Date: Tue, 19 Feb 2002 16:50:56 +0200 Subject: A View of Monads (Re: performance of monads) In-Reply-To: References: <27918.1011193548@cl.cam.ac.uk> <3C4671C8.F0AC9A@bga.com> Message-ID: -----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 Hi Richard, On Tuesday 19 February 2002 06:57, Richard Uhtenwoldt wrote: > > This is a weak argument. > > First of all it is not the case that imperative coders always specify a > total ordering: multitasking, threading and interrupts (and their > projections into software as in Unix signals and asynchronous > exceptions) are ways of specifying partial ordering when a total > ordering would lose. > Note that modern cpu designs use "out-of-order" execution strategies; > so on micro-second timescales they > ignore the total ordering when doing so suits them and > when it preserves semantics. > I might add to the above points the obvious. Imperative programming languages in general do _not_ specify a total ordering. Each statement _can_ have a side effect[*] and the compiler is free to rearrange code such that it runs faster and preserves semantics. As written in any compiler textbook from 1970's. Sincerely, [*] The compiler will know when this is possible, and when the statement is free of side effects. You can specify that no side effects occur in C++ for instance. And the compilers also know that certain expressions are always free of side effects, etc. - -- Eray Ozkural (exa) Comp. Sci. Dept., Bilkent University, Ankara www: http://www.cs.bilkent.edu.tr/~erayo GPG public key fingerprint: 360C 852F 88B0 A745 F31B EA0F 7C07 AE16 874D 539C -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.0.6 (GNU/Linux) Comment: For info see http://www.gnupg.org iD8DBQE8cmZSfAeuFodNU5wRAsG4AJ9ZXV6jVfbIRrRTCzl8YhO/AK1a7QCePCE3 /ST0chxaZYNobn2f32N94sw= =3dOx -----END PGP SIGNATURE----- From ru@river.org Tue Feb 19 17:56:07 2002 From: ru@river.org (Richard Uhtenwoldt) Date: Tue, 19 Feb 2002 09:56:07 -0800 Subject: a universal printer for Haskell? In-Reply-To: <200202181201.EAA26936@mail4.halcyon.com> References: <200202181201.EAA26936@mail4.halcyon.com> Message-ID: Ashley Yakeley writes: >This is reflection! I'd rather not have Haskell contaminated with such >things; Can you say a little more about why you think reflection is bad? Does it make the language implementation run slower? (I'd ask via private email, but when I emailed you in the past I didn't get a reply.) From ashley@semantic.org Wed Feb 20 01:35:22 2002 From: ashley@semantic.org (Ashley Yakeley) Date: Tue, 19 Feb 2002 17:35:22 -0800 Subject: a universal printer for Haskell? Message-ID: <200202200135.RAA17030@mail4.halcyon.com> At 2002-02-19 09:56, Richard Uhtenwoldt wrote: >>This is reflection! I'd rather not have Haskell contaminated with such >>things; > >Can you say a little more about why you think reflection is bad? >Does it make the language implementation run slower? It's ugly, and isn't part of the spirit of the language. You shouldn't be able to peer into types that way. If you decide to change the private structure of your types, you shouldn't have to worry about what effects it will have on the rest of the program. Consider: module A (Thing()) where { data Thing = MkThing Char; } module B where { import A; peek :: Thing -> Char; peek thing = (\(MApp _ (MChar c)) -> c) (reify thing); } B can look inside a private structure of A. The problem is not the Reify class, but the compiler's autogeneration of instances. >(I'd ask via private email, but when I emailed you in the past >I didn't get a reply.) That sounds like me... -- Ashley Yakeley, Seattle WA From erayo@cs.bilkent.edu.tr Wed Feb 20 04:50:39 2002 From: erayo@cs.bilkent.edu.tr (Eray Ozkural) Date: Wed, 20 Feb 2002 06:50:39 +0200 Subject: a universal printer for Haskell? In-Reply-To: <200202200135.RAA17030@mail4.halcyon.com> References: <200202200135.RAA17030@mail4.halcyon.com> Message-ID: -----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 On Wednesday 20 February 2002 03:35, Ashley Yakeley wrote: > At 2002-02-19 09:56, Richard Uhtenwoldt wrote: > >>This is reflection! I'd rather not have Haskell contaminated with such > >>things; > > > >Can you say a little more about why you think reflection is bad? > >Does it make the language implementation run slower? > > It's ugly, and isn't part of the spirit of the language. The above statement cannot be a basis for any argument against Bernard's proposal. Where Bernard makes a careful analysis of the matter, you introduce your prejudice. Since you are defining the spirit of the language, perhaps you could make a list of the "parts" of that spirit so that people will not come up with any proposal that violates your understanding of aesthetics. A general concept such as reflection cannot be deemed as worthless in itself. Any system that has a tiny bit of introspective powers can be said to be reflective to some extent, for instance a Haskell interpreter. Thanks, - -- Eray Ozkural (exa) Comp. Sci. Dept., Bilkent University, Ankara www: http://www.cs.bilkent.edu.tr/~erayo GPG public key fingerprint: 360C 852F 88B0 A745 F31B EA0F 7C07 AE16 874D 539C -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.0.6 (GNU/Linux) Comment: For info see http://www.gnupg.org iD8DBQE8cysgfAeuFodNU5wRAuc2AJ9UW0VRcxSqs0dS/rIN7/YBaXBO2wCfRtbB +5ZG8wk9nZH3Z7WEz7rNvqw= =NevV -----END PGP SIGNATURE----- From ashley@semantic.org Wed Feb 20 05:18:47 2002 From: ashley@semantic.org (Ashley Yakeley) Date: Tue, 19 Feb 2002 21:18:47 -0800 Subject: a universal printer for Haskell? Message-ID: <200202200518.VAA27699@mail4.halcyon.com> At 2002-02-19 20:50, Eray Ozkural wrote: >> It's ugly, and isn't part of the spirit of the language. > >The above statement cannot be a basis for any argument against Bernard's >proposal. It's an aesthetic argument that hopes for an aesthetic consensus among Haskell users (which may or may not exist). ... >Since you are defining the spirit of the language, Oh no, spirit cannot be defined, only suggested. ... >A general concept such as reflection cannot be deemed as worthless in >itself. It might reasonably be considered inappropriate to Haskell. Reflection may be useful for debugging, so I would not call it worthless. I consider reflection such as Generics to be in more or less the same aesthetic category as unsafe IO functions -- something to be generally avoided but perhaps useful in certain limited contexts such as debugging. I don't use Generics or unsafe-anything in my Haskell software. I _do_ occasionally use the 'deriving' construct, which is strictly speaking reflection though I think a relatively harmless form. What I would hate to see is widespread use of reflection in general programs. It rather seems to miss the point of Haskell's type system. >Any system that has a tiny bit of introspective powers can be said to be >reflective to some extent, for instance a Haskell interpreter. That's fine, but I don't include a Haskell interpreter in my compiled Haskell programs. And I don't want other people peeking inside my types at run-time. -- Ashley Yakeley, Seattle WA From bjpop@cs.mu.OZ.AU Wed Feb 20 06:46:01 2002 From: bjpop@cs.mu.OZ.AU (Bernard James POPE) Date: Wed, 20 Feb 2002 17:46:01 +1100 (EST) Subject: a universal printer for Haskell? Message-ID: <200202200646.RAA10737@mulga.cs.mu.OZ.AU> Hi all, This thread started with the consideration of a means (hack?) to implement a generic printer in Haskell. It has moved to the bigger issue of Meta programming, in particular reflection. I think this is a topic worthy of consideration, and something we don't seem to talk much about in these groups. > Ashley Yakeley writes: > What I would hate to see is widespread use of reflection in general > programs. It rather seems to miss the point of Haskell's type system. I think the point of Haskell's type system varies depending on who you ask. The rules may be fixed to a certain degree in Haskell 98, but future versions of the language are free to change them. Meta programming is made more difficult when you have a strong static type system, no doubt. But is that a problem of meta programming or of the type system? This is a matter of opinion. Systems such as Meta ML [1], show that the two can be made compatible. I must admit that I haven't used Meta ML, so I'm not in a position to evaluate it, although it does make for some interesting research. My point is that there are some things that can't easily be expressed in current Haskell (like generic printing) that are useful and might be aided by meta-programming technology. The interesting question is can it be done in a way that preserves whatever we want from the type system: safety, security, efficiency, error detection ... > And I don't want other people peeking inside my types at run-time. There are numerous ways to provide security for your data types. You can specifically request that they not be made visible to the meta facility, or you can use a module system to grant access to the implementation of data only in certain modules. It does not have to be program wide. The scheme I suggested for generic printing was not as safe as you might like, but it was intended to be simple and easy to implement, and there is some merit in that I think. Cheers, Bernie. From chak@cse.unsw.edu.au Wed Feb 20 06:48:53 2002 From: chak@cse.unsw.edu.au (Manuel M. T. Chakravarty) Date: Wed, 20 Feb 2002 17:48:53 +1100 Subject: syntax...(strings/interpolation/here docs) In-Reply-To: <86n0yb92pu.fsf@speakeasy.org> References: <86n0yb92pu.fsf@speakeasy.org> Message-ID: <20020220174853Q.chak@cse.unsw.edu.au> Ian Zimmerman wrote, > Mark> Ultimately, it comes down to a question of what you're trying to > Mark> achieve. Do you envisage Haskell as an elegant scripting > Mark> language that competes with perl and ruby for quick but useful > Mark> hacks? Or do you think it might better serve as a platform for > Mark> writing significant user level applications with fancy user > Mark> interfaces and international appeal? > > Neither. > > The chief advantage of functional languages is supposed to be their > clean semantics with straightforward formalization, which allows one > to be confident in the correctness of relatively large and complex > bodies of code. That advantage is forfeited when trying to interface > directly to messy GUI toolkits (and _all_ GUI toolkits in existence > are messy). I don't agree. The clean semantics of FP languages has led to language features that are very useful, especially in messy contexts. I have myself written many thousand lines of what I like to call "C in Haskell syntax", much of this as part of the Haskell binding to the GTK+ GUI toolkit. This code uses pointers, side-effects, calls to C routines as well as explicit memory allocation and deallocation all over the place. Do I think Haskell is suited for writing such code? Yes, definitely. As long as you don't need close control over your memory and runtime consumption (like in an OS kernel), I would say, Haskell is the better C.[1] Haskell's type system and excellent support for higher-order functions in combination with the facilities for data structures (pattern matching etc) make it a powerful tool for everybody who knows to use these features. For example, if you use suitable types for your functions (eg, parametrised pointers), the type checker will still pick up many more mistakes than that of an imperative language. Cheers, Manuel [1] And mind you, I have programmed much more code in imperative than in functional languages. From ashley@semantic.org Wed Feb 20 07:01:44 2002 From: ashley@semantic.org (Ashley Yakeley) Date: Tue, 19 Feb 2002 23:01:44 -0800 Subject: a universal printer for Haskell? Message-ID: <200202200701.XAA02005@mail4.halcyon.com> At 2002-02-19 22:46, Bernard James POPE wrote: >The scheme I suggested for generic printing >was not as safe as you might like, but it was intended to be simple >and easy to implement, and there is some merit in that I think. I strongly recommend you check out generic classes: I suspect you can use them to do what you want... -- Ashley Yakeley, Seattle WA From johanj@cs.uu.nl Wed Feb 20 09:01:50 2002 From: johanj@cs.uu.nl (Johan Jeuring) Date: Wed, 20 Feb 2002 10:01:50 +0100 Subject: a universal printer for Haskell? In-Reply-To: <200202200646.RAA10737@mulga.cs.mu.OZ.AU> Message-ID: <79D59EA8-25E0-11D6-8A77-0003937324F2@cs.uu.nl> > My point is that there are some things that can't easily be expressed > in current Haskell (like generic printing) that are useful and > might be aided by meta-programming technology. The interesting question > is can it be done in a way that preserves whatever we want from the type > system: safety, security, efficiency, error detection ... You don't need meta-programming technology (reflection) to do things like generic prinitng. A generic programming extension of Haskell (like Generic Haskell, or derivable classes) can do the job for you. Have a look at: http://www.generic-haskell.org/ -- Johan From patrikj@cs.chalmers.se Wed Feb 20 09:20:06 2002 From: patrikj@cs.chalmers.se (Patrik Jansson) Date: Wed, 20 Feb 2002 10:20:06 +0100 (MET) Subject: Survival of generic-classes in ghc In-Reply-To: <200202200701.XAA02005@mail4.halcyon.com> Message-ID: The page http://www.haskell.org/ghc/docs/latest/set/generic-classes.html starts with the text (Note: support for generic classes is currently broken in GHC 5.02). and I know from testing earlier versions that the generic-classes support was pretty buggy. Is there any hope of a revival? Does it already work in CVS? I suspect it will rot away if nobody works on it. Any comments from the implementors - does the idea "fit well" with ghc? Is it a lot of work to make it more stable? /Patrik PS. I guess I should try to find resources (interested students) for a project on making the ghc generic classes really work. From C.Reinke@ukc.ac.uk Wed Feb 20 15:07:27 2002 From: C.Reinke@ukc.ac.uk (C.Reinke) Date: Wed, 20 Feb 2002 15:07:27 +0000 Subject: a universal printer for Haskell? In-Reply-To: Message from Johan Jeuring of "Wed, 20 Feb 2002 10:01:50 +0100." <79D59EA8-25E0-11D6-8A77-0003937324F2@cs.uu.nl> Message-ID: > You don't need meta-programming technology (reflection) to do things like > generic prinitng. A generic programming extension of Haskell (like > Generic Haskell, or derivable classes) can do the job for you. Isn't generic programming usually based on a kind of compile-time reflection (if the argument is of this type, do this, else..)? And don't you write generic functions with the intention that the implementation will figure out the approriate type-specific variants, i.e., you write your code at a level of abstraction that is not easily reached with the standard language tools -- a meta level, where functions at different types are the first-class objects of discourse? I find it helpful to think of generic programming support as one way of integrating well-behaved subsets of reflection and other meta-programming techniques into Haskell. It is partly a trade-off: you get some of the features and avoid some of the problems of a fully reflective architecture. It is also a specialisation: by avoiding the full generality, the specific subset of features can be designed in a structured fashion, with the application domain in mind, making them easier to use for that domain. Claus (another fan of reflection and meta-programming, who would like to get their advantages without their disadvantages -- the latter are more clearly visible in a pure functional language than in Lisp) From johanj@cs.uu.nl Wed Feb 20 15:29:26 2002 From: johanj@cs.uu.nl (Johan Jeuring) Date: Wed, 20 Feb 2002 16:29:26 +0100 Subject: a universal printer for Haskell? In-Reply-To: Message-ID: <9FD8B228-2616-11D6-8A77-0003937324F2@cs.uu.nl> >> You don't need meta-programming technology (reflection) to do things >> like >> generic prinitng. A generic programming extension of Haskell (like >> Generic Haskell, or derivable classes) can do the job for you. > > Isn't generic programming usually based on a kind of compile-time > reflection (if the argument is of this type, do this, else..)? Yes, you might view it as compile-time reflection. Programs are still typable. > And don't you write generic functions with the intention that the > implementation will figure out the approriate type-specific > variants, i.e., you write your code at a level of abstraction that > is not easily reached with the standard language tools -- a meta > level, where functions at different types are the first-class > objects of discourse? If you view that as a metalevel I agree. However, it is the intention you never see the generated functions at different types: the compiler can (in priciple) completely hide those from the programmer. In that sense there is just one level: Generic haskell offers you normal Haskell functions and generic functions. > I find it helpful to think of generic programming support as one way > of integrating well-behaved subsets of reflection and other > meta-programming techniques into Haskell. > > It is partly a trade-off: you get some of the features and avoid > some of the problems of a fully reflective architecture. It is also > a specialisation: by avoiding the full generality, the specific > subset of features can be designed in a structured fashion, with the > application domain in mind, making them easier to use for that domain. Agreed. -- Johan From simonpj@microsoft.com Wed Feb 20 21:15:36 2002 From: simonpj@microsoft.com (Simon Peyton-Jones) Date: Wed, 20 Feb 2002 13:15:36 -0800 Subject: Survival of generic-classes in ghc Message-ID: <1113DDB24D4A2841951BFDF86665EE19374987@RED-MSG-10.redmond.corp.microsoft.com> | and I know from testing earlier versions that the=20 | generic-classes support was pretty buggy. Is there any hope=20 | of a revival? Does it already work in CVS? I suspect it will=20 | rot away if nobody works on it. |=20 | Any comments from the implementors - does the idea "fit well"=20 | with ghc? Is it a lot of work to make it more stable? No, it should not be a lot of work to revive, and I will do it. Keep bugging me until I do.=20 One thing that is slowing me down is a design uncertainty: how to deal cleanly with constructors. To write read, show, etc, one needs access to the constructor name, fixity etc. We dance around that a little in the paper. I'm thinking of this design: -- An example data type data List a =3D Nil | Cons a (List a) -- The "ring" type derived from it -- Note the Con wrapped around the constructors data ListO a =3D Con NilT 1 :+: Con ConsT (a :*: List a) -- Con is part of the Generics library, like 1, :*:, :+: newtype Con c a =3D Con a class ConCls c where name :: c -> String arity :: c -> Arity ..etc.. data NilT -- Phantom types data ConsT -- one per constructor instance ConCls NilT where name _ =3D "Nil" ...etc... instance ConCls ConsT wher name _ =3D "Cons" ...etc... Now you can write class Show a where show :: a -> String show {| Con c t |} (Con x) =3D (name (undefined::c)) ++ show x ...etc.. Note the "undefined::c"; it is really just a type argument to "name", so that we get the string for the right constructor. It's a bit clunky, though. Another possiblity would be to make the ConCls class look like this class ConCls c where name :: String arity :: Int=20 ...etc... Now we'd have to give an explicit type argument at the call site: show {| Constr c t |} (Con x) =3D (name {| c |}) ++ show x I quite like the thought of being able to supply explicit type arguments.... but I don't konw how to speak about the order of type parameters. What order does map takes its two type parameters in? Another question is whether we need an indication that we have reached=20 a field of the constructor. Should we have: data ListO a =3D Con NilT (Field 1) :+: Con ConsT (Field a :*: (Field = List a)) newtype Field a =3D Field a Without this, it's hard to write a generic function to count the number of fields of the data type. But in general, one might want to know when making the transition from "this" type to the argument types of the constructors. I think that the main reason I'm not making much progress is that I don't know what design choices to make. I'd be glad to discuss it with interested parties. Simon From erayo@cs.bilkent.edu.tr Wed Feb 20 22:35:48 2002 From: erayo@cs.bilkent.edu.tr (Eray Ozkural) Date: Thu, 21 Feb 2002 00:35:48 +0200 Subject: a universal printer for Haskell? In-Reply-To: <200202200646.RAA10737@mulga.cs.mu.OZ.AU> References: <200202200646.RAA10737@mulga.cs.mu.OZ.AU> Message-ID: -----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 On Wednesday 20 February 2002 08:46, Bernard James POPE wrote: > > There are numerous ways to provide security for your data types. (In)Visibility isn't security. I have more than often witnessed Java users who thought "private" keyword was for security. I think it's obvious, with many years of worldwide experience of Internet security, why obscurity is *not* security. Thanks, - -- Eray Ozkural (exa) Comp. Sci. Dept., Bilkent University, Ankara www: http://www.cs.bilkent.edu.tr/~erayo GPG public key fingerprint: 360C 852F 88B0 A745 F31B EA0F 7C07 AE16 874D 539C -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.0.6 (GNU/Linux) Comment: For info see http://www.gnupg.org iD8DBQE8dCTGfAeuFodNU5wRAjGsAJ4tq8Nqg5Vh4pANHbMZ0JT+u1iVpgCcDY7i PI0TC9Y+DnVAV8AstF2ovmk= =+xqN -----END PGP SIGNATURE----- From mrak@it.usyd.edu.au Thu Feb 21 00:45:28 2002 From: mrak@it.usyd.edu.au (Mark Wotton) Date: Thu, 21 Feb 2002 11:45:28 +1100 (EST) Subject: Haskell problem Message-ID: Hi, I'm trying out some combinatorial parsers, and I ran into a slightly inelegant construction. To parse a sequence of things, we have a function like pThen3 :: (a->b->c->d) -> Parser a -> Parser b -> Parser c -> Parser d pThen3 combine p1 p2 p3 toks = [(combine v1 v2 v3, toks3) | (v1, toks1) <- p1 toks, (v2, toks2) <- p2 toks1, (v3, toks3) <- p3 toks2] The problem with this is that this structure has to be duplicated for pThen2, pThen4, and so on. These other forms are very similar to pThen3, but there seems to be no way to capture this in Haskell's type system, as the combine function has a different signature for each pThenX. (This is actually the first time the Haskell type system has got in my way rather than helping.) Is there a way around this problem? mrak From Tom.Pledger@peace.com Thu Feb 21 01:16:43 2002 From: Tom.Pledger@peace.com (Tom Pledger) Date: Thu, 21 Feb 2002 14:16:43 +1300 Subject: Haskell problem In-Reply-To: References: Message-ID: <15476.19067.592345.234504@waytogo.peace.co.nz> Mark Wotton writes: | Hi, | | I'm trying out some combinatorial parsers, and I ran into a slightly | inelegant construction. To parse a sequence of things, we have a function | like | | pThen3 :: (a->b->c->d) -> Parser a -> Parser b -> Parser c -> Parser d | pThen3 combine p1 p2 p3 toks = | [(combine v1 v2 v3, toks3) | (v1, toks1) <- p1 toks, | (v2, toks2) <- p2 toks1, | (v3, toks3) <- p3 toks2] | | The problem with this is that this structure has to be duplicated for | pThen2, pThen4, and so on. These other forms are very similar to pThen3, | but there seems to be no way to capture this in Haskell's type system, as | the combine function has a different signature for each pThenX. (This is | actually the first time the Haskell type system has got in my way rather | than helping.) Is there a way around this problem? If you can build the list of tokens into the state of your Parser monad - which would include making Parser a a distinct type instead of an alias for [Token] -> [(a, Token)] - you could condense pThen3 down to this: pThen3 combine p1 p2 p3 toks = do v1 <- p1 v2 <- p2 v3 <- p3 return (combine v1 v2 v3) which is equivalent to the liftM3 function from the Monad library. You'd still be stuck with a family of lifting functions, but at least they're predefined. I don't see any way of getting by with a fixed number of lifting functions, unless you're willing to clutter the call sites: infixl 0 `ap` ap :: Parser (a -> b) -> Parser a -> Parser b ap = Monad.ap ... ... Monad.liftM f p1 `ap` p2 `ap` p3 `ap` p4 Regards, Tom From dpt@math.harvard.edu Thu Feb 21 02:35:05 2002 From: dpt@math.harvard.edu (Dylan Thurston) Date: Wed, 20 Feb 2002 21:35:05 -0500 Subject: Survival of generic-classes in ghc In-Reply-To: <1113DDB24D4A2841951BFDF86665EE19374987@RED-MSG-10.redmond.corp.microsoft.com> References: <1113DDB24D4A2841951BFDF86665EE19374987@RED-MSG-10.redmond.corp.microsoft.com> Message-ID: <20020221023505.GC24399@petunia.bostoncoop.net> --eRtJSFbw+EEWtPj3 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline Content-Transfer-Encoding: quoted-printable On Wed, Feb 20, 2002 at 01:15:36PM -0800, Simon Peyton-Jones wrote: > Another possiblity would be to make the ConCls class look like this > class ConCls c where > name :: String > arity :: Int=20 > ...etc... >=20 > Now we'd have to give an explicit type argument at the call site: >=20 > show {| Constr c t |} (Con x) =3D (name {| c |}) ++ show x >=20 > I quite like the thought of being able to supply explicit type > arguments.... > but I don't konw how to speak about the order of type parameters. > What order does map takes its two type parameters in? Sorry, this seems like a non-sequitur to me? 'map' has type '(a->b) -> [a] -> [b]'; supplying explicit type parameters would mean giving values to 'a' and 'b'. If I wanted to propose notation for this, I would suggest, e.g., (map :: (String -> Int) -> [String] -> [Int]) length ["Hello", "World"] 'name' (above) has type 'String'; the '{| c |}' is not providing a type parameter in the same sense. What am I missing? Best, Dylan --eRtJSFbw+EEWtPj3 Content-Type: application/pgp-signature Content-Disposition: inline -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.0.6 (GNU/Linux) Comment: For info see http://www.gnupg.org iD8DBQE8dFzZVeybfhaa3tcRAvGUAJ4pk/quXp+gMJaSxK8LLmdszIk4SQCcC3Ks yJeap3R0NXrMAf71jhA4KoE= =ee6g -----END PGP SIGNATURE----- --eRtJSFbw+EEWtPj3-- From ashley@semantic.org Thu Feb 21 09:18:05 2002 From: ashley@semantic.org (Ashley Yakeley) Date: Thu, 21 Feb 2002 01:18:05 -0800 Subject: Monadic Call/CC? Message-ID: <200202210918.BAA04719@mail4.halcyon.com> At 2002-02-20 22:15, I wrote (on the Haskell list): >Haskell? Given this: > > class (Monad m) => PeirceMonad m where > { > peirceM :: ((a -> m b) -> m a) -> m a; > }; > >...which Monads can be made PeirceMonads? This is untested, but... instance PeirceMonad IO where { peirceM foo = do { ref <- newIORef Nothing; catch (foo (\a -> do { writeIORef ref (Just a); ioError (userError "break"); })) (\ex -> do { ma <- readIORef ref; case ma of { Just a -> return a; _ -> ioError ex; }; }) } }; So you can do it if you have refs and throw/catch for your monad. I think. -- Ashley Yakeley, Seattle WA From josefs@cs.chalmers.se Thu Feb 21 14:50:19 2002 From: josefs@cs.chalmers.se (Josef Svenningsson) Date: Thu, 21 Feb 2002 15:50:19 +0100 (MET) Subject: Haskell problem In-Reply-To: Message-ID: On Thu, 21 Feb 2002, Mark Wotton wrote: > Hi, > > I'm trying out some combinatorial parsers, and I ran into a slightly > inelegant construction. To parse a sequence of things, we have a function > like > > pThen3 :: (a->b->c->d) -> Parser a -> Parser b -> Parser c -> Parser d > pThen3 combine p1 p2 p3 toks = > [(combine v1 v2 v3, toks3) | (v1, toks1) <- p1 toks, > (v2, toks2) <- p2 toks1, > (v3, toks3) <- p3 toks2] > > The problem with this is that this structure has to be duplicated for > pThen2, pThen4, and so on. These other forms are very similar to pThen3, > but there seems to be no way to capture this in Haskell's type system, as > the combine function has a different signature for each pThenX. (This is > actually the first time the Haskell type system has got in my way rather > than helping.) Is there a way around this problem? > Yes there is a way around this problem. You can use multi parameter type classes to create (and give a type to) a function such as pThenX. The details are worked out in the paper "Faking it" by Conor McBride. In that paper shows how to implement a generic zipWith in Haskell. The same technique should work for your function. The paper can be found on: http://www.dur.ac.uk/~dcs1ctm/ Cheers, /Josef From Jon.Fairbairn@cl.cam.ac.uk Thu Feb 21 15:17:48 2002 From: Jon.Fairbairn@cl.cam.ac.uk (Jon Fairbairn) Date: Thu, 21 Feb 2002 15:17:48 +0000 Subject: Haskell problem In-Reply-To: Your message of "Thu, 21 Feb 2002 15:50:19 +0100." Message-ID: <2220.1014304668@cl.cam.ac.uk> Josef Sveningsson wrote: > On Thu, 21 Feb 2002, Mark Wotton wrote: > = > > Hi, > > > > I'm trying out some combinatorial parsers, and I ran into a slightly > > inelegant construction. To parse a sequence of things, we have a func= tion > > like > > > > pThen3 :: (a->b->c->d) -> Parser a -> Parser b -> Parser c -> Parser = d > > pThen3 combine p1 p2 p3 toks =3D > > [(combine v1 v2 v3, toks3) | (v1, toks1) <- p1 toks, > > (v2, toks2) <- p2 toks1, > > (v3, toks3) <- p3 toks2] > > > > The problem with this is that this structure has to be duplicated for= > > pThen2, pThen4, and so on. These other forms are very similar to pThe= n3, > > but there seems to be no way to capture this in Haskell's type system= , as > > the combine function has a different signature for each pThenX. (This= is > > actually the first time the Haskell type system has got in my way rat= her > > than helping.) Is there a way around this problem? > > > Yes there is a way around this problem. You can use multi parameter typ= e > classes to create (and give a type to) a function such as pThenX. Or, in Standard Haskell you can do something like this: infixr `then2` infixr `thenn` then2:: Parser b -> Parser c -> ((b,c)->d) -> Parser d then2 p1 p2 comb toks =3D [(comb (a, b), rest) | (a, r1) <- p1 toks, (b, rest) <- p2 r1] thenn:: Parser a b -> ((t->d) -> Parser a d) -> ((b,t)->d) -> Parser a = d thenn p1 cp2 comb toks =3D [(cmb, rest) | (a, r1) <- p1 toks, (cmb, rest) <- cp2 (\t->comb (a,t)) r1] and use like this (p1 `thenn` p2 `thenn` p3 `then2` p4) (\(a,(b,(c,d))) -> whatever) I'm not sure if you can get rid of the `then2`, but is seems quite servicable even so. J=F3n -- = J=F3n Fairbairn Jon.Fairbairn@cl.cam.ac.u= k 31 Chalmers Road jf@cl.cam.ac.uk Cambridge CB1 3SZ +44 1223 570179 (after 14:00 only, please!) From wojtek@solidum.com Thu Feb 21 16:01:43 2002 From: wojtek@solidum.com (Wojciech Fraczak) Date: Thu, 21 Feb 2002 11:01:43 -0500 Subject: Graphs Message-ID: <15477.6631.70802.741937@uranus.solidum.com> Hi everybody, I would like to ask you, if you do not know any graph library for haskell. I would like to use haskell for prototyping some of algorithms on graphs and finite state automata/transducers. In fact what I'm looking for is a good (efficient and easy readable) data type definition for labeled graphs. Thanks, Wojtek From erayo@cs.bilkent.edu.tr Thu Feb 21 17:05:18 2002 From: erayo@cs.bilkent.edu.tr (Eray Ozkural) Date: Thu, 21 Feb 2002 19:05:18 +0200 Subject: Graphs In-Reply-To: <15477.6631.70802.741937@uranus.solidum.com> References: <15477.6631.70802.741937@uranus.solidum.com> Message-ID: -----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 I used graphs in haskell, but I don't think you'll get anywhere the kind of efficiency of a language like C++ where you have exact control over operations and structures.... There is the graph code in "functional algorithms" book.... Algorithms: a functional programming approach Fethi A. Rabhi, University of Hull, UK Guy Lapalme, Université de Montréal, Canada The code is available online. I recommend you to start with that one. Stay away from finite map stuff in edison if you can. (Although you can get it to implement graphs/hypergraphs after some amount of work) If you're going to prototype an algorithm, you will eventually have to use monads which will be harder to write than the final C++/C implementation. Why is that so? Because if you're writing the graph code in haskell, the really easier/better way is to use things like substitution, infinite graphs, etc. for an elegant and short code, in that it reflects the theoretical construction. But an algorithm designed for a serial machine is so much different. I've written graph algorithms from multilevel graph partitioning to graph clustering, so I think I know what I'm talking about :) If you're using C++, you can prototype an algorithm fairly easily. Here is how you can implement it. use list< vector > to store adjacency lists. use a vector< vector* > to index the adjacency lists. use separate vectors to hold labels. I won't go into the reasons why those are the ones to start with, eventually your super-optimized code will be similar to the above. Don't use a graph library. It will make your job harder! Avoid template libraries if you can (except stdlib...), and resist the temptation to templatize your code. You will find that it's much more easier to write graph algorithms that way. And yes, although it would be in theory be a good idea to be able to prototype your algorithm in an easier-to-use language, such a language does not exist. Unless you can show me graph code side-by-side and prove it to me I will never believe it :) For a start one would have to show me the implementation of non-trivial algorithms such as graph coarsening, all-to-all shortest paths, maximal cliques, etc. in the easier-than-C++ language contrasted with (good) C++ implementation. I'm thinking maybe it would be more-possible in ocaml, but I'm a beginner in ocaml and I don't think I'm enough of a ocaml-hacker to talk about it. Thanks, On Thursday 21 February 2002 18:01, Wojciech Fraczak wrote: > Hi everybody, > > I would like to ask you, if you do not know any graph library for > haskell. I would like to use haskell for prototyping some of > algorithms on graphs and finite state automata/transducers. In fact > what I'm looking for is a good (efficient and easy readable) data type > definition for labeled graphs. > > Thanks, - -- Eray Ozkural (exa) Comp. Sci. Dept., Bilkent University, Ankara www: http://www.cs.bilkent.edu.tr/~erayo GPG public key fingerprint: 360C 852F 88B0 A745 F31B EA0F 7C07 AE16 874D 539C -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.0.6 (GNU/Linux) Comment: For info see http://www.gnupg.org iD8DBQE8dSjSfAeuFodNU5wRAk8rAJ9CIwZUmEKHpttK2IwTXO0fnk8/egCeOV/A y3yq4cDFx1mZQPC6SbK19JU= =QoPG -----END PGP SIGNATURE----- From jmaessen@mit.edu Thu Feb 21 18:59:04 2002 From: jmaessen@mit.edu (Jan-Willem Maessen) Date: Thu, 21 Feb 2002 13:59:04 -0500 Subject: Survival of generic-classes in ghc Message-ID: <200202211859.NAA02663@lauzeta.mit.edu> * Language philosophers who are skimming this discussion will want to take a look at #### below. Simon PJ writes: > One thing that is slowing me down is a design uncertainty: how to > deal cleanly with constructors. To write read, show, etc, one needs > access to the constructor name, fixity etc. We dance around that a > little in the paper. I'm thinking of this design: ... > -- Con is part of the Generics library, like 1, :*:, :+: > newtype Con c a = Con a > > class ConCls c where > name :: c -> String > arity :: c -> Arity > ..etc.. > > data NilT -- Phantom types > data ConsT -- one per constructor > > instance ConCls NilT where > name _ = "Nil" > ...etc... > > instance ConCls ConsT wher > name _ = "Cons" > ...etc... But you're going to have to keep those ConCls dictionaries somewhere, which means either: 1) The type Con should existentially quantify over c: < data Con a = forall c. (ConCls c) => Con a [I haven't checked that this is even legal anywhere, but you get the idea] 2) Any function which needs the type "c" must carry around a dictionary for *each* constructor in the type. I'm not quite sure how to work the typing of the code generic functions in this regime, though I'm sure it could somehow be managed. As long as we're reifying everything in sight, why not simplify the design problem and reify the constructor dictionaries? >From my own strawman experiments (this is old code): > data Constructor t = Constructor CI !t > > data CI = CI Bool String Int [String] [Bool] deriving (Eq) > -- Op-ness, constructor, fixity, field names, strictnesses of fields We could do something similar for fields, of course. There need only be one copy of this info for each data constructor (and field); it's easy for the compiler to share these. The type CI is effectively a representation of the dictionary for ConCls. The "Constructor" type the works just like the existentially quantified example (1). The drawback? We need to store the constructor info CI in every reified constructor. My suspicion is this will not matter much in practice. Compiling generics should be done with one of two sets of assumptions: * Generics are a mechanism of convenience. If you want your code to go fast, you should write the code longhand (possibly using an overlapping instance for an otherwise generic function/class). In this case, the extra overhead of the constructor info is likely to be a drop in the bucket. * Generics should be specialized at the types at which they are used. This might be accomplished by careful inlining of reification functions into the bodies of generic methods (or vice versa). In this case "Constructor" should vanish. ####################### On a broader philosophical note: I'm disturbed by the idea of adding explicit type application and the like to Haskell. Haskell language extensions are rapidly becoming a riotous array of confusing syntax and twisty semantic corners. From an experimenter's standpoint, this isn't so bad. However, many of these extensions are incredibly useful, and there's a lot of code relying upon them. This creates pressure (from both users and implementors) to immortalize the existing, grubby implementations. The result? An incomprehensible, byzantine language. For example, we now have multiparameter type classes (useful) with functional dependencies (addressing a vital problem with multiparameter constraint solving). Now Simon is wants explicit type application, kind annotations, and the like. There are some things Haskell does very well---algebraic types and pattern matching are cleaner and more pleasant to use then in ML, and the class system has proven to be Haskell's most brilliant distinguishing feature. I'd like to see solutions to some of the current problems that build on these strengths. I'm not sure if it's possible to get a type language based on functions and pattern matching in the face of type inference. Cayenne makes it clear that one can write type-level code very naturally when the type language and the value language work the same way. Similarly, I observe that: * Views = coercion methods + implicitly-inserted coercions + deforestation * Generics = reification methods + functions become methods + implicitly-inserted reification + deforestation The two lists are pretty similar, and it might be worth trying to unify the efforts in some fashion---possibly by breaking down the functionality into simple pieces. Here are some possibilities: * Come up with a coherent story on implicitly-inserted coercions. Ideally fromInteger and fromRational would just be specific cases of this coherent story. (The current story is nice and coherent: if it's a numeric constant, there's a coercion, otherwise there isn't.) * Allow patterns to match at multiple types, if those types match particular constraints (such as coercability). These two together might well be enough to give you views. * Give the deriving mechanism a language-level reading. Allow "deriving"-like clauses outside the context of type declarations. * Give some way to declare "closure" of a class. This should be done with an eye on abstraction barriers. Perhaps "closed" classes may still be derived (by newtypes, or using the mechanism for generics). * Make generic functions look like closed classes; possibly this means allowing the programmer to write instances as part of the class declaration. * Perhaps Haskell needs a universal class. This class would provide the reification methods for all [boxed?] data types, and might be a place for the implementation to hide (e.g.) type-based GC methods or specialized versions of seq. I'm hoping something along these lines is enough for single-parameter generics at least. Much of this work already exists in fragmentary form. However, in many cases it's part of attempts at larger mechanisms. For example, "views" proposals have suggested using distinguished "view types", and adding coercions when patterns mention the constructor of a view type. "Closed" classes were mentioned in the paper on instance resolution at PoPL last month. And of course there's lots of good work on generics, the big problem being that the efforts have become scattershot and still doesn't seem to fit the rest of the language nicely. It's time to reduce the useful mechanisms to their essentials. -Jan-Willem Maessen Eager Haskell project From ru@river.org Thu Feb 21 22:14:28 2002 From: ru@river.org (Richard Uhtenwoldt) Date: Thu, 21 Feb 2002 14:14:28 -0800 Subject: Monadic Call/CC? In-Reply-To: <200202210918.BAA04719@mail4.halcyon.com> References: <200202210918.BAA04719@mail4.halcyon.com> Message-ID: Ashley Yakeley writes: > instance PeirceMonad IO where > { > peirceM foo = do > { > ref <- newIORef Nothing; > catch (foo (\a -> do > { > writeIORef ref (Just a); > ioError (userError "break"); > })) > (\ex -> do > { > ma <- readIORef ref; > case ma of > { > Just a -> return a; > _ -> ioError ex; > }; > }) > } > }; > >So you can do it if you have refs and throw/catch for your monad. I think. In Scheme, the reified continuation can survive the end of the execution of the call/CC construct, like the continuation survives that gets put into the variable upward in the following: > (define (putstrln x) (display x) (newline)) > (define upward 'placeholder) > (begin (call-with-current-continuation (lambda (cont) (set! upward cont))) (putstrln "zzz") ) zzz > (upward) zzz In case your Scheme is rusty, I'll translate the whole example into untested Haskell. Assumes an interactive mode like GHCi's. > upward<-newIORef Nothing > do { pierceM (\cont-> writeIORef upward (Just cont)); putStrLn "zzz" } zzz > do { (Just cont)<-readIORef upward; cont } zzz I do not know if you can get your definition and my test of it through the typechecker! Thinking about typing that last makes my head hurt. But if you can, I think you'll get an error at the last line instead of a second "zzz" line because call/cc makes rather severe demmands on an implementation. Not something an implementation is likely to be able to support unintentionally. Holler if you want me to rewrite the test to be noninteractive. From ashley@semantic.org Fri Feb 22 03:36:13 2002 From: ashley@semantic.org (Ashley Yakeley) Date: Thu, 21 Feb 2002 19:36:13 -0800 Subject: Monadic Call/CC? Message-ID: <200202220336.TAA18337@mail4.halcyon.com> >Given this: > > class (Monad m) => PeirceMonad m where > { > peirceM :: ((a -> m b) -> m a) -> m a; > }; > >...which Monads can be made PeirceMonads? Here's one: data ContMonad p a = MkContMonad ((a -> p) -> p); unContMonad (MkContMonad app) = app; instance Monad (ContMonad p) where { return a = MkContMonad (\cont -> cont a); (MkContMonad ma) >>= bf = MkContMonad (\cont -> ma (\a -> unContMonad (bf a) cont)); }; instance PeirceMonad m where { peirceM foo = MkContMonad (\cont -> unContMonad (foo (\a -> MkContMonad (\_ -> (cont a)))) cont); }; doContMonad :: ContMonad p p -> p; doContMonad cm = unContMonad cm id; test1 = doContMonad (peirceM (\continuation -> do { continuation 1; continuation 2; continuation 3; })); -- returns 1 Now here's the interesting thing. The usual way to represent "real-world" functions (i.e. with side-effects, or changing the world) from a to b is to define a special _type constructor_, 'IO', and define the function as 'a -> IO b'. But an alternative, would have been to define a special _type_, Action, and define the function as 'a -> (b -> Action) -> Action'. And then your 'main' function has type 'Action'. Nor do we have to declare special >>= and return functions as we do for IO. Here's how it's equivalent: type Action = IO (); type ActionMonad = ContMonad Action; doActionMonad :: ActionMonad () -> Action; doActionMonad cm = unContMonad cm return; liftIO :: IO a -> ActionMonad a; liftIO ioa = MkContMonad (\cont -> ioa >>= cont); ...and note that we get Peirce continuations for free: peirce foo cont = foo (\a _ -> (cont a)) cont; -- constructors removed -- Ashley Yakeley, Seattle WA From ashley@semantic.org Fri Feb 22 03:55:16 2002 From: ashley@semantic.org (Ashley Yakeley) Date: Thu, 21 Feb 2002 19:55:16 -0800 Subject: Monadic Call/CC? Message-ID: <200202220355.TAA19836@mail4.halcyon.com> At 2002-02-21 19:36, I wrote: > And then your 'main' function has type 'Action'. Sorry, And then your 'main' function has type 'Action -> Action'. -- Ashley Yakeley, Seattle WA From co19@cornell.edu Fri Feb 22 08:03:47 2002 From: co19@cornell.edu (Cagdas Ozgenc) Date: Fri, 22 Feb 2002 10:03:47 +0200 Subject: if -> is a type constructor Message-ID: <001901c1bb77$786c7280$61411bc2@mitajara> This is a multi-part message in MIME format. ------=_NextPart_000_0016_01C1BB88.386983B0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable Greetings folks. If (->) is a type constructor, what does its definition look like, what = data constructors does it have? How does it differ from other type = constructors, or maybe it doesn't? Could someone give an explanation... Thanks for taking time. ------=_NextPart_000_0016_01C1BB88.386983B0 Content-Type: text/html; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable
Greetings folks.
 
If (->) is a type constructor, what = does its=20 definition look like, what data constructors does it have? How does it = differ=20 from other type constructors, or maybe it doesn't?
 
Could someone give an = explanation...
 
Thanks for taking = time.
------=_NextPart_000_0016_01C1BB88.386983B0-- From ru@river.org Fri Feb 22 09:36:57 2002 From: ru@river.org (Richard Uhtenwoldt) Date: Fri, 22 Feb 2002 01:36:57 -0800 Subject: Monadic Call/CC? In-Reply-To: <200202220336.TAA18337@mail4.halcyon.com> References: <200202220336.TAA18337@mail4.halcyon.com> Message-ID: Ashley Yakeley writes: >Now here's the interesting thing. The usual way to represent "real-world" >functions (i.e. with side-effects, or changing the world) from a to b is >to define a special _type constructor_, 'IO', and define the function as >'a -> IO b'. But an alternative, would have been to define a special >_type_, Action, and define the function as 'a -> (b -> Action) -> >Action'. And then your 'main' function has type 'Action'. > >Nor do we have to declare special >>= and return functions as we do for >IO. Yeah, it's called continuation-passing style (CPS). (b -> Action) is the type of the continuation argument. >...and note that we get Peirce continuations for free: > > peirce foo cont = foo (\a _ -> (cont a)) cont; -- constructors removed Yeah, in CPS, call/cc is easy to write. So, congratulations, you've written call/cc in Haskell. I think. So, what I said this afternoon, namely, that call/cc is "not something an implementation is likely to be able to support unintentionally", I now have to retract. I think. I guess the call/cc you wrote last night in terms of catch and a ref didn't work too well; huh? From ashley@semantic.org Fri Feb 22 10:14:53 2002 From: ashley@semantic.org (Ashley Yakeley) Date: Fri, 22 Feb 2002 02:14:53 -0800 Subject: Monadic Call/CC? Message-ID: <200202221014.CAA10642@mail4.halcyon.com> At 2002-02-22 01:36, Richard Uhtenwoldt wrote: >Yeah, it's called continuation-passing style (CPS). Good. I have a small collection of wheels I've reinvented in my ignorance. >So, congratulations, you've written call/cc in Haskell. I think. >So, what I said this afternoon, namely, that call/cc is >"not something an implementation is likely >to be able to support unintentionally", I now have to retract. >I think. Well, I have to create my own monad and do call/cc in that. Doing call/cc in IO is another matter entirely. >I guess the call/cc you wrote last night in terms of catch and a ref >didn't work too well; huh? I havent't tested it. But I agree that it certainly won't allow continuations to survive after peirceM has returned, so can't be considered proper call/cc. -- Ashley Yakeley, Seattle WA From daan@cs.uu.nl Fri Feb 22 10:28:31 2002 From: daan@cs.uu.nl (Daan Leijen) Date: Fri, 22 Feb 2002 11:28:31 +0100 Subject: Graphs References: <15477.6631.70802.741937@uranus.solidum.com> Message-ID: <006c01c1bb8b$acdf05f0$9650d383@ajam> Hi Wojciech, > I would like to ask you, if you do not know any graph library for > haskell. I would like to use haskell for prototyping some of > algorithms on graphs and finite state automata/transducers. In fact > what I'm looking for is a good (efficient and easy readable) data type > definition for labeled graphs. You should take a look at Martin Erwig's functional graph library, http://www.cs.orst.edu/~erwig/fgl/ And also at David King's and John Launchbury's paper about graphs: http://www.cse.ogi.edu/~jl/Papers/dfs.ps I think that both libraries show that Haskell is indeed a very nice language for prototyping graph algorithms and that they allow you to specify algorithms in such a way that they match the mathematical definitions more closely. It is probably true that the same algorithm in C++ will be (much?) faster but it will also take you (much?) more time to code it correctly. i.e. use Haskell for experimentation! All the best, Daan. > Thanks, > > Wojtek > > _______________________________________________ > Haskell-Cafe mailing list > Haskell-Cafe@haskell.org > http://www.haskell.org/mailman/listinfo/haskell-cafe > > From juan@inf.ufpr.br Thu Feb 21 20:32:56 2002 From: juan@inf.ufpr.br (Juan M. Duran) Date: Thu, 21 Feb 2002 17:32:56 -0300 (BRT) Subject: Help Message-ID: Hi, I need to parse a string to a list of integer, like this: "12 32\n15...." to [12,32,15...] f :: String -> [Int] What I=B4ve found is the function "words" which does=20 words :: String -> [String] it is in the Prelude.hs then if I have something like "12 32\n15..." with words I get ["12","32","15"...] which is cool but not exactly what I need. Would you help me? Thanks J. ------------------------------------ Porque la =FAnica lucha que se pierde, es la que se abandona, =A1Ni un paso atr=E1s! From herrmann@infosun.fmi.uni-passau.de Fri Feb 22 10:36:34 2002 From: herrmann@infosun.fmi.uni-passau.de (Ch. A. Herrmann) Date: Fri, 22 Feb 2002 11:36:34 +0100 Subject: Help In-Reply-To: References: Message-ID: <15478.7986.674731.673465@reger.fmi.uni-passau.de> >>>>> "Juan" == Juan M Duran writes: Juan> then if I have something like "12 32\n15..." with words I get Juan> ["12","32","15"...] Juan> which is cool but not exactly what I need. Would you help me? just compose it with (map read). Function read takes a string and converts it to the target type, presumed this type belongs to the type class Read and the string is a correct printing of an element of this type. -- Christoph From daan@cs.uu.nl Fri Feb 22 10:44:16 2002 From: daan@cs.uu.nl (Daan Leijen) Date: Fri, 22 Feb 2002 11:44:16 +0100 Subject: Haskell problem References: <2220.1014304668@cl.cam.ac.uk> Message-ID: <00a001c1bb8e$001f5c90$9650d383@ajam> Hi all, There exist a really neat solution to this. I think that it is pioneered by Doaitse Swierstra and Luc Duponcheel in their parser combinators: http://www.cs.uu.nl/~doaitse/Papers/1996/LL1.pdf > > > I'm trying out some combinatorial parsers, and I ran into a slightly > > > inelegant construction. To parse a sequence of things, we have a function > > > like > > > > > > pThen3 :: (a->b->c->d) -> Parser a -> Parser b -> Parser c -> Parser d > > > > > > The problem with this is that this structure has to be duplicated for > > > pThen2, pThen4, and so on. These other forms are very similar to pThen3, > > > > Yes there is a way around this problem. You can use multi parameter type > > classes to create (and give a type to) a function such as pThenX. > > Or, in Standard Haskell you can do something like this: > > infixr `then2` > infixr `thenn` > > then2:: Parser b -> Parser c -> ((b,c)->d) -> Parser d > thenn:: Parser a b -> ((t->d) -> Parser a d) -> ((b,t)->d) -> Parser a d > > and use like this > > (p1 `thenn` p2 `thenn` p3 `then2` p4) (\(a,(b,(c,d))) -> whatever) > > I'm not sure if you can get rid of the `then2`, but is seems > quite servicable even so. The last solution is almost right, what we can do is to define two (arrow style) combinators, one for sequential composition and one for lifting values into the Parser type: (<*>) :: Parser (a -> b) -> Parser a -> Parser b succeed :: a -> Parser a Now, if we assign a left-associative priority to the (<*>) operator: infixl 4 <*>, we can combine it as follows: succeed (\x y z -> (x,y,z)) <*> p1 <*> p2 <*> p3 Note that the parens are as follows: (((succeed (\x y z -> (x,y,z)) <*> p1) <*> p2) <*> p3) And indeed, the first component has type: Parser (a -> b -> c -> (a,b,c)) and combines through (<*>) with (p1 :: Parser a) into (Parser (b -> c -> (a,b,c))) which combines through (<*>) and (p2 :: Parser b) into (Parser (c -> (a,b,c))) etc. Now, it helps off course to define another combinator: infix 5 <$> f <$> p = succeed f <*> p And you can write: f <$> p1 <*> p2 <*> p3 where f x y z = (x,y,z) With a little more cunning, you can also define combinators like (*>) and (<*) that leave out parser results: parens p = char '(' *> p <* char ')' The UU_parsing library embodies the epitome of this technique: http://www.cs.uu.nl/groups/ST/Software/UU_Parsing/ All the best, Daan. > -- > Jón Fairbairn Jon.Fairbairn@cl.cam.ac.uk > 31 Chalmers Road jf@cl.cam.ac.uk > Cambridge CB1 3SZ +44 1223 570179 (after 14:00 only, please!) > > > _______________________________________________ > Haskell-Cafe mailing list > Haskell-Cafe@haskell.org > http://www.haskell.org/mailman/listinfo/haskell-cafe > > From josefs@cs.chalmers.se Fri Feb 22 10:55:23 2002 From: josefs@cs.chalmers.se (Josef Svenningsson) Date: Fri, 22 Feb 2002 11:55:23 +0100 (MET) Subject: Haskell problem In-Reply-To: <00a001c1bb8e$001f5c90$9650d383@ajam> Message-ID: On Fri, 22 Feb 2002, Daan Leijen wrote: > There exist a really neat solution to this. I think that it is pioneered > by Doaitse Swierstra and Luc Duponcheel in their parser combinators: > > http://www.cs.uu.nl/~doaitse/Papers/1996/LL1.pdf > Niklas Röjemo uses this style of combinators in his paper: "Efficient parsing combinators" from 95. It can be found on: http://www.cs.chalmers.se/~rojemo/thesis.html Cheers, /Josef From dfeuer@cs.brown.edu Sat Feb 23 01:28:56 2002 From: dfeuer@cs.brown.edu (David Feuer) Date: Fri, 22 Feb 2002 20:28:56 -0500 Subject: Graphs Message-ID: <20020222202856.A17525@cslab7c.cs.brown.edu> I seem to remember an article about functional graph algorithms using extra-lazy arrays. Anyone know if these arrays have appeared in any mainstream implementation? David Feuer From ashley@semantic.org Sat Feb 23 03:03:48 2002 From: ashley@semantic.org (Ashley Yakeley) Date: Fri, 22 Feb 2002 19:03:48 -0800 Subject: Monadic Call/CC? Message-ID: <200202230303.TAA20358@mail4.halcyon.com> At 2002-02-22 01:36, Richard Uhtenwoldt wrote: >So, congratulations, you've written call/cc in Haskell. I think. Yes. test2 :: CPS (IO ()) (); test2 = do { liftM (putStr "aa\n"); ref <- liftM (newIORef Nothing); liftM (putStr "bb\n"); flag <- peirceM (\c -> do { liftM (putStr "cc\n"); liftM (writeIORef ref (Just c)); liftM (putStr "dd\n"); c True; liftM (putStr "ee\n"); return False; }); liftM (putStr "ff\n"); if (flag) then do { liftM (putStr "gg\n"); Just c' <- liftM (readIORef ref); liftM (putStr "hh\n"); c' False; liftM (putStr "ii\n"); } else do { liftM (putStr "jj\n"); } }; ContMonad> doMonadCPS test2 aa bb cc dd ff gg hh ff jj ...which shows that the continuation passed in by peirceM works both inside and outside the call. Changing "c' False" to "c' True" gave this endless iteration: ContMonad> doMonadCPS test2 aa bb cc dd ff gg hh ff gg hh ff gg hh ... I assume by the magic of Haskell's tail recursion, this won't eat up space. -- Ashley Yakeley, Seattle WA From qrczak@knm.org.pl Sat Feb 23 15:55:19 2002 From: qrczak@knm.org.pl (Marcin 'Qrczak' Kowalczyk) Date: Sat, 23 Feb 2002 15:55:19 +0000 (UTC) Subject: Monadic Call/CC? References: Message-ID: Thu, 21 Feb 2002 19:36:13 -0800, Ashley Yakeley pisze: > data ContMonad p a = MkContMonad ((a -> p) -> p); [...] It's in GHC in module MonadCont, together with a monad transformer providing continuations and some instances. -- __("< Marcin Kowalczyk * qrczak@knm.org.pl http://qrczak.ids.net.pl/ \__/ ^^ QRCZAK From jmaessen@alum.mit.edu Sat Feb 23 17:53:42 2002 From: jmaessen@alum.mit.edu (Jan-Willem Maessen) Date: Sat, 23 Feb 2002 12:53:42 -0500 Subject: Graphs Message-ID: <200202231753.MAA00764@lauzeta.mit.edu> David Feuer writes: > I seem to remember an article about functional graph algorithms using > extra-lazy arrays. Anyone know if these arrays have appeared in any > mainstream implementation? I assume you're referring to this paper by Thomas Johnsson: @Article{lazyArray, author = {Johnsson, Thomas}, title = {Efficient Graph Algorithms Using Lazy Monolithic Arrays}, journal = JFP, year = 1998, volume = 8, number = 4, pages = {323--333}, month = {July} } He uses similar techniques to do whole-program flow analysis of Haskell programs, a clever bit of coding described in the following paper: @inproceedings{grinHeap, AUTHOR = "Johnsson, Thomas", TITLE = "Analysing Heap Contents in a Graph Reduction Intermediate Language.", booktitle = Proc # "Glasgow Functional Programming Workshop", address = "Ullapool 1990", MONTH = "August", YEAR = 1991 } The LazyArray library is part of the standard hbc distribution. The Eager Haskell compiler depends on it (you can get very nice static hash tables this way, among other things). As a result, I've done a port of the library to GHC (and, I think, hugs). I should note that most of the hints required to pull off the implementation were found in the "State in Haskell" paper by Simon PJ and John Launchbury. The library is available (along with a few other useful snippets, like universal splittable supplies) here: http://www.csg.lcs.mit.edu/~earwig/haskell-lib/ -Jan-Willem Maessen From ashley@semantic.org Sat Feb 23 21:51:38 2002 From: ashley@semantic.org (Ashley Yakeley) Date: Sat, 23 Feb 2002 13:51:38 -0800 Subject: Monadic Call/CC? Message-ID: <200202232151.NAA04907@mail4.halcyon.com> At 2002-02-23 07:55, Marcin 'Qrczak' Kowalczyk wrote: >It's in GHC in module MonadCont, together with a monad transformer >providing continuations and some instances. Could this sort of thing _please_ be added to or somewhere? Is this documented somewhere? -- Ashley Yakeley, Seattle WA From dfeuer@cs.brown.edu Sat Feb 23 21:52:37 2002 From: dfeuer@cs.brown.edu (David Feuer) Date: Sat, 23 Feb 2002 16:52:37 -0500 Subject: Graphs In-Reply-To: <200202231753.MAA00764@lauzeta.mit.edu>; from jmaessen@alum.mit.edu on Sat, Feb 23, 2002 at 12:53:42PM -0500 References: <200202231753.MAA00764@lauzeta.mit.edu> Message-ID: <20020223165237.B19482@cslab7c.cs.brown.edu> On Sat, Feb 23, 2002, Jan-Willem Maessen wrote: > David Feuer writes: > > I seem to remember an article about functional graph algorithms using > > extra-lazy arrays. Anyone know if these arrays have appeared in any > > mainstream implementation? > > I assume you're referring to this paper by Thomas Johnsson: Yes indeed. Thank you. David Feuer From fjh@cs.mu.oz.au Sun Feb 24 11:26:18 2002 From: fjh@cs.mu.oz.au (Fergus Henderson) Date: Sun, 24 Feb 2002 22:26:18 +1100 Subject: if -> is a type constructor In-Reply-To: <001901c1bb77$786c7280$61411bc2@mitajara> References: <001901c1bb77$786c7280$61411bc2@mitajara> Message-ID: <20020224112618.GA23979@earth.cs.mu.oz.au> On 22-Feb-2002, Cagdas Ozgenc wrote: > If (->) is a type constructor, what does its definition look like, what data > constructors does it have? How does it differ from other type constructors, > or maybe it doesn't? It is an abstract data type. The representation is implementation-dependent. The data constructor(s) for (->) are not accessible to programs, so you can't e.g. pattern-match against them. Implementations are likely to use a specialized representation for (->). For example, they might use something similar to the following C structure. (This is from the Mercury implementation. I hope this example doesn't raise more questions than it answers ;-) /* ** A closure is a vector of words containing: ** ** one word pointing to the closure layout structure of the procedure ** one word pointing to the code of the procedure ** one word giving the number of arguments hidden in the closure (N) ** N words representing the N hidden arguments ... */ typedef struct MR_Closure_Struct { MR_Closure_Layout *MR_closure_layout; MR_Code *MR_closure_code; MR_Unsigned MR_closure_num_hidden_args; MR_Word MR_closure_hidden_args[MR_VARIABLE_SIZED]; } MR_Closure; -- Fergus Henderson | "I have always known that the pursuit The University of Melbourne | of excellence is a lethal habit" WWW: | -- the last words of T. S. Garp. From LEWIS@haskell.org Mon Feb 25 02:46:05 2002 From: LEWIS@haskell.org (LEWIS@haskell.org) Date: Sun, 24 Feb 2002 21:46:05 -0500 (EST) Subject: Magnets supplier located. Message-ID: <20020225024605.6E28F4220CB@www.haskell.org> This is a multi-part message in MIME format. --Z_MULTI_PART_MAIL_BOUNDAEY_S Content-Type: text/html Content-Transfer-Encoding: base64 PGJvZHkgYmdjb2xvcj0iI0MwQzBDMCIgdGV4dD0iIzAwODA4MCI+DQpEZWFyIFNpcnMsPGJy Pg0KPGEgaHJlZj0iaHR0cDovL3d3dy5zaW5vbWFnbmV0cy5jb20vIj5JVE0gTWFnbmV0cyBH cm91cDwvYT4gaXMgYSBtYWduZXRzIHN1cHBsaWVyIGxvY2F0ZWQuIFdlIHN1cHBseSBhIHZh cmlldHkgb2YgbWFnbmV0cyBpbmNsdWRpbmcgcGVybWFuZW50cyBtYWduZXRzLCBzaW50ZXJl ZCBhbmQgYm9uZGVkIE5kRmVCLCBTbUNvLCBmZXJyaXRlIGNvcmVzIGFuZCBtYWduZXRpYyBj b21wb25lbnRzLjxicj4gIA0KQXMgdGhlIGxhcmdlc3QgbWFnbmV0cyBiYXNlIGluIHdlc3Qg Q2hpbmEgb3VyIGZhY3RvcmllcyBpbXBsZW1lbnQgSVNPIHN0YW5kYXJkLiBPdXIgcHJvZHVj dGlvbiBmb3JjZSBjYW4gbWVldCB5b3VyIHJlZ3VsYXIgYW5kL29yIHNwZWNpYWwgbmVlZHMg d2l0aCBvdXIgc3VwZXJpb3IgcXVhbGl0eSBwcm9kdWN0cy4gQXBwbGljYXRpb24gc2VydmVk IGluY2x1ZGUgZW5lcmd5IGNvbnZlcnNhdGlvbiwgYXV0b21vdGl2ZSwgbWVkaWNhbCwgZWxl Y3Ryb25pY3MgYW5kIGNvbW11bmljYXRpb25zLjxicj4gIA0KT3VyIHNhbGVzIG9yZ2FuaXph dGlvbiBmb3IgZ3JvdXAncyBwcm9kdWN0cyBpcyA8YSBocmVmPSJodHRwOi8vd3d3Lm15LWl0 cmFkZS5jb20vIj4gU2ljaHVhbiBNaWFueWFuZyBJbnRlcm5hdGlvbmFsIFRyYWRlIENvLiwg THRkLihJVE0pPC9hPi48YnI+DQpURUwgMDA4Ni04MTYtMjIyMzA4OSBGQVg6MDA4Ni04MTYt MjIyNDU2MiBQLkMuOjYyMTAwMCA8YSBocmVmPSJtYWlsdG86Zm9yZWlnbnRyYWRlQDEyNi5j b20iPkUtbWFpbDwvYT4uDQo8L2JvZHk+ICAgIA== --Z_MULTI_PART_MAIL_BOUNDAEY_S-- From tom@regex.com.au Mon Feb 25 06:46:30 2002 From: tom@regex.com.au (Tom Bevan) Date: 25 Feb 2002 17:46:30 +1100 Subject: (no subject) Message-ID: <1014619590.24275.2.camel@bawbaw> Hi, I've come across this sort of data constructor below many times but I'm not really sure how to use it. Can someone please point me to the right section in the documentation? In particular, I want to know how to create a calendar time and how to access the fields . Tom data CalendarTime = CalendarTime { ctYear :: Int, ctMonth :: Month, ctDay, ctHour, ctMin, ctSec :: Int, ctPicosec :: Integer, ctWDay :: Day, ctYDay :: Int, ctTZName :: String, ctTZ :: Int, ctIsDST :: Bool } deriving (Eq, Ord, Read, Show) From ashley@semantic.org Mon Feb 25 07:02:14 2002 From: ashley@semantic.org (Ashley Yakeley) Date: Sun, 24 Feb 2002 23:02:14 -0800 Subject: (no subject) Message-ID: <200202250702.XAA16481@mail4.halcyon.com> At 2002-02-24 22:46, Tom Bevan wrote: >I've come across this sort of data constructor below many times but I'm >not really sure how to use it. Can someone please point me to the right >section in the documentation? http://haskell.org/onlinereport/decls.html#sect4.2.1 "Labelled Fields" >In particular, I want to know how to create a calendar time and how to >access the fields . > >Tom > >data CalendarTime = CalendarTime { > ctYear :: Int, > ctMonth :: Month, > ctDay, ctHour, ctMin, ctSec :: Int, > ctPicosec :: Integer, > ctWDay :: Day, > ctYDay :: Int, > ctTZName :: String, > ctTZ :: Int, > ctIsDST :: Bool > } deriving (Eq, Ord, Read, Show) Basically it's equivalent to this: data CalendarTime = CalendarTime Int Month Int Int Int Int Integer Day Int String Int Bool deriving (Eq, Ord, Read, Show); ctYear (CalendarTime x _ _ _ _ _ _ _ _ _ _ _) = x; ctMonth (CalendarTime _ x _ _ _ _ _ _ _ _ _ _) = x; ctDay (CalendarTime _ _ x _ _ _ _ _ _ _ _ _) = x; etc. ...but you can also use the labelled fields to construct: CalendarTime { ctYear = 2002, ctMonth = 2, ... } -- Ashley Yakeley, Seattle WA From hdaume@ISI.EDU Mon Feb 25 07:06:29 2002 From: hdaume@ISI.EDU (Hal Daume III) Date: Sun, 24 Feb 2002 23:06:29 -0800 (PST) Subject: (no subject) In-Reply-To: <1014619590.24275.2.camel@bawbaw> Message-ID: I'm not sure where the documentation is, but here's the idea on how to used named fields. I'll make a smaller example, though :) > data T = T { x :: Int, y :: Bool } now, to create a value of type T, you can write: > x = T 5 True as the datatype declaration creates the following function: > T :: Int -> Bool -> T You can also pattern match as if you had just declared it as "data T = T Int Bool". However, this datatype declaration introduces two functions into the namespace: > x :: T -> Int > y :: T -> Bool which extract values. for instance: > x (T 5 True) evaluates to 5 and > y (T 5 True) evaluates to True. You can also use field names to create values: > T { x = 5, y = True } or > T { y = True, x = 5} order is irrelevant (i'm not sure about rules if you specify the same field more than once...check in the report on that). Finally, you can update parts of labelled fields independent of everything else: > let q = T {x=4, y=True} > q' = q {x=5} > in q' will yield T 5 True. Of course, this isn't value replacement, it's just a more convenient way to create a new value based on an old one, with minor changes. I see Ashley also replied to this thread with a pointer to documentation. Hopefully the combination will help. -- Hal Daume III "Computer science is no more about computers | hdaume@isi.edu than astronomy is about telescopes." -Dijkstra | www.isi.edu/~hdaume On 25 Feb 2002, Tom Bevan wrote: > > > Hi, > > I've come across this sort of data constructor below many times but I'm > not really sure how to use it. Can someone please point me to the right > section in the documentation? > In particular, I want to know how to create a calendar time and how to > access the fields . > > Tom > > data CalendarTime = CalendarTime { > ctYear :: Int, > ctMonth :: Month, > ctDay, ctHour, ctMin, ctSec :: Int, > ctPicosec :: Integer, > ctWDay :: Day, > ctYDay :: Int, > ctTZName :: String, > ctTZ :: Int, > ctIsDST :: Bool > } deriving (Eq, Ord, Read, Show) > > _______________________________________________ > Haskell-Cafe mailing list > Haskell-Cafe@haskell.org > http://www.haskell.org/mailman/listinfo/haskell-cafe > From simonpj@microsoft.com Mon Feb 25 08:27:07 2002 From: simonpj@microsoft.com (Simon Peyton-Jones) Date: Mon, 25 Feb 2002 00:27:07 -0800 Subject: Survival of generic-classes in ghc Message-ID: <1113DDB24D4A2841951BFDF86665EE1937499A@RED-MSG-10.redmond.corp.microsoft.com> | As long as we're reifying everything in sight, why not=20 | simplify the design problem and reify the constructor dictionaries? Because the generic function may be building the contructor not taking it apart. (Think of a generic read function). So there is no reified constructor to deconstruct. This is discussed in the generic classes paper. It has to be done by recursion over the type. It's emphatically not just an efficiency issue. Simon From simonpj@microsoft.com Mon Feb 25 08:27:08 2002 From: simonpj@microsoft.com (Simon Peyton-Jones) Date: Mon, 25 Feb 2002 00:27:08 -0800 Subject: Survival of generic-classes in ghc Message-ID: <1113DDB24D4A2841951BFDF86665EE1937499C@RED-MSG-10.redmond.corp.microsoft.com> | > Another possiblity would be to make the ConCls class look like this | > class ConCls c where | > name :: String | > arity :: Int=20 | > ...etc... | >=20 | > Now we'd have to give an explicit type argument at the call site: | >=20 | > show {| Constr c t |} (Con x) =3D (name {| c |}) ++ show x | >=20 | > I quite like the thought of being able to supply explicit type=20 | > arguments.... but I don't konw how to speak about the order of type=20 | > parameters. What order does map takes its two type parameters in? |=20 | Sorry, this seems like a non-sequitur to me? |=20 | 'map' has type '(a->b) -> [a] -> [b]'; supplying explicit=20 | type parameters would mean giving values to 'a' and 'b'. If=20 | I wanted to propose notation for this, I would suggest, e.g., | (map :: (String -> Int) -> [String] -> [Int]) length=20 | ["Hello", "World"] |=20 | 'name' (above) has type 'String'; the '{| c |}' is not=20 | providing a type parameter in the same sense. Yes it is. 'name' would have type forall c. ConCls c =3D> String It requires a type argument, just like map. Simon From simonpj@microsoft.com Mon Feb 25 08:27:07 2002 From: simonpj@microsoft.com (Simon Peyton-Jones) Date: Mon, 25 Feb 2002 00:27:07 -0800 Subject: Survival of generic-classes in ghc Message-ID: <1113DDB24D4A2841951BFDF86665EE1937499B@RED-MSG-10.redmond.corp.microsoft.com> | I'm disturbed by the idea of adding explicit type application=20 | and the like to Haskell. Haskell language extensions are=20 | rapidly becoming a riotous array of confusing syntax and=20 | twisty semantic corners. From an experimenter's standpoint,=20 | this isn't so bad. However, many of these extensions are=20 | incredibly useful, and there's a lot of code relying upon=20 | them. This creates pressure (from both users and | implementors) to immortalize the existing, grubby=20 | implementations. The result? An incomprehensible, byzantine language. Yes, that's a danger. My own hope is that the practial experience of using and programming with these various features will lead us slowly to a realisation of some underlying unifying approaches or principles. That is what the rest of you message is reaching for -- which is great. But it easier to identify the problem than to come up with a satisfactory solution, and I for one do not have one. But I think it would be great to find one. Simon From johnsson@crt.se Mon Feb 25 09:01:30 2002 From: johnsson@crt.se (Thomas Johnsson) Date: Mon, 25 Feb 2002 10:01:30 +0100 Subject: Graphs In-Reply-To: <20020222202856.A17525@cslab7c.cs.brown.edu> References: <20020222202856.A17525@cslab7c.cs.brown.edu> Message-ID: <15481.64874.916955.8166@spitfire.crt.se> David Feuer writes: > I seem to remember an article about functional graph algorithms using > extra-lazy arrays. Anyone know if these arrays have appeared in any > mainstream implementation? You might mean my paper "Efficient Graph Algorithms Using Lazy Monolithic Arrays", (a JFP paper), which you can find at www.cs.chalmers.se/~johnsson . hbc has an implementation of it. --Thomas From simonmar@microsoft.com Mon Feb 25 12:50:32 2002 From: simonmar@microsoft.com (Simon Marlow) Date: Mon, 25 Feb 2002 12:50:32 -0000 Subject: Monadic Call/CC? Message-ID: <9584A4A864BD8548932F2F88EB30D1C6087334C7@TVP-MSG-01.europe.corp.microsoft.com> > At 2002-02-23 07:55, Marcin 'Qrczak' Kowalczyk wrote: >=20 > >It's in GHC in module MonadCont, together with a monad transformer > >providing continuations and some instances. >=20 > Could this sort of thing _please_ be added to > > or somewhere? Is this documented somewhere? My apologies for the lack of documentation for some of these libraries, = and the generally poor state of the doumentation for hslibs. Some of = the libraries come from external sources, and in some cases the authors = didn't provide documentation, or provided it in a form that we couldn't = use directly. For the next release of GHC, I'm hoping we can do a much better job, = though not just by writing more documentation but by generating more of = it automatically from the source code. That's the plan; we don't have = anything concrete yet. Cheers, Simon From juan@inf.ufpr.br Mon Feb 25 14:53:35 2002 From: juan@inf.ufpr.br (Juan M. Duran) Date: Mon, 25 Feb 2002 11:53:35 -0300 (BRT) Subject: Help In-Reply-To: Message-ID: This message is in MIME format. The first part should be readable text, while the remaining parts are likely unreadable without MIME-aware tools. Send mail to mime@docserver.cac.washington.edu for more info. --298362324-1931129976-1014648815=:28682 Content-Type: TEXT/PLAIN; charset=iso-8859-1 Content-Transfer-Encoding: QUOTED-PRINTABLE Hi, I'm writting a small parser in Haskell and, when it is all done, I get the following problem: Type Binding. The thing is, I have 3 main functions: 1) Read the file, its type is: [Char] ->IO [Char] (see InputOutput.hs) 2) Parse a string (using words and readDec), its type is: Integral a =3D> [Char] -> [a] (see Parse.hs) 3) Parse a list of integer, its type is: [Float] -> [[Float]] (Functions.hs) Now the problem is that I cannot run the first function, then use its results as an input of the second function and, finally, its results as the input of the third function. How can I fix this without modifing all my functions because they, independly, works fine. Juan ------------------------------------ Porque la =FAnica lucha que se pierde, es la que se abandona, =A1Ni un paso atr=E1s! --298362324-1931129976-1014648815=:28682 Content-Type: TEXT/PLAIN; charset=US-ASCII; name="Parser.hs" Content-Transfer-Encoding: BASE64 Content-ID: Content-Description: Content-Disposition: attachment; filename="Parser.hs" bW9kdWxlIFBhcnNlciB3aGVyZQ0NCg0NCnBhcnNlciB4cwkJPSBwYXJzZXIw ICh3b3JkcyB4cykNDQoNDQpwYXJzZXIwIFtdCQk9IFtdDQ0KcGFyc2VyMCAo eDp4cykJPSBpZk5lZ2F0aXZlIHg6cGFyc2VyMCB4cw0NCg0NCmlmTmVnYXRp dmUgKHg6eHMpCT0gIGlmICh4ID09ICctJykgdGhlbiAobmVnYXRpdmUgeHMp IGVsc2UgKG5vbk5lZ2F0aXZlICh4OnhzKSkNDQoNDQpuZWdhdGl2ZSB4cwkJ PSAoMCAtIGZzdCAocmVhZERlYyB4cyEhMCkpDQ0Kbm9uTmVnYXRpdmUgeHMJ PSBmc3QgKHJlYWREZWMgeHMhITApDQ0K --298362324-1931129976-1014648815=:28682 Content-Type: TEXT/PLAIN; charset=US-ASCII; name="main.hs" Content-Transfer-Encoding: BASE64 Content-ID: Content-Description: Content-Disposition: attachment; filename="main.hs" aW1wb3J0IElucHV0T3V0cHV0DQ0KaW1wb3J0IEZ1bmN0aW9ucw0NCmltcG9y dCBQYXJzZXINDQoNDQoJLS0gRnVuY3Rpb24gTWFpbg0NCg0NCi0tbWFpbgk9 IGNvbnRyb2wgKHBhcnNlciAoaW5wdXQgInR3b2JveGVzLmRhdCIpKQ0NCg0N Ci0tamUgPSBkbyB7YyA8LSBwYXJzZXIgIjEyIDIxIjsgcmV0dXJuIGN9DQ0K DQ0KCS0tIFRlc3RlcyANDQoNDQp0ZXN0ID0gIiAzICA0ICA3ICAyICA1ICAz ICAgNTRcbiA3IDEwICA5IDEwICAzICAxICA2MDBcbjEwICA5ICA0ICA4ICAx ICA2ICAzMTJcbiAzICA5ICA1IDEgIDYgIDQgIDExMVxuIDQgIDMgIDIgIDcg IDYgIDEgIC0xOFxuIDMgIDMgIDEgIDkgIDUgIDQgLTE3MVxuIDUgIDkgIDkg IDEgIDcgIDYgIDM2IDNcbiAxICAyICA5ICAzICA5ICAyICAtMzZcbiAyICA2 ICA4ICAyICA2IDEwICAtMjRcbiA4ICAxIDEwICA3ICA1ICAxICAgNDVcbiIN DQoNDQp0ZXN0Jzo6IE51bSBhID0+IFthXQ0NCnRlc3QnID0gWzMsNCw3LDIs NSwzLDU0LDcsMTAsOSwxMCwzLDEsNjAwLDEwLDksNCw4LDEsNiwzMTIsMyw5 LDUsMSw2LDQsMTExLDQsMywyLDcsNiwxLC0xOCwzLDMsMSw5LDUsNCwtMTcx LDUsOSw5LDEsNyw2LDM2LDMsMSwyLDksMyw5LDIsLTM2LDIsNiw4LDIsNiwx MCwtMjQsOCwxLDEwLDcsNSwxLDQ1XQ0NCg0NCnRlc3QxIAk9IGNvbnRyb2wg WzMsLTMsLTcsLTIsLTUsLTEzLDU0LDcsMTAsOSwxMCwzLDEsNjAwLDEsMSwx LDEsMSwxLDZdDQ0KdGVzdDIgCT0gY29udHJvbCBbMSwyLDNdDQ0KDQ0KZXNj cml0dXJhCT0gb3V0cHV0ICJvdXRwdXQiIHRlc3QxDQ0KbGV0dXJhIAk9IGlu cHV0ICJvdXRwdXQiDQ0KDQ0KYXJjaCAJPSBpbnB1dCAidHdvYm94ZXMuZGF0 Ig0NCmFyY2gyID0gcmVhZEZpbGUgInR3b2JveGVzLmRhdCINDQoNDQoNDQo= --298362324-1931129976-1014648815=:28682 Content-Type: TEXT/PLAIN; charset=US-ASCII; name="InputOutput.hs" Content-Transfer-Encoding: BASE64 Content-ID: Content-Description: Content-Disposition: attachment; filename="InputOutput.hs" bW9kdWxlIElucHV0T3V0cHV0IHdoZXJlDQ0KDQ0KaW1wb3J0IElPDQ0KaW1w b3J0IFBhcnNlcg0NCg0NCgktLSBPVVRQVVQNDQoNDQpvdXRwdXQgb3V0Zmls ZSByZXN1bHQgPSBkbw0NCgkJCQkgd3JpdGVGaWxlIG91dGZpbGUgKHNob3cg cmVzdWx0KQ0NCgkJCQkgcHV0U3RyICgiV3JpdGluZyBpbiBmaWxlICIgKysg IiciICsrIG91dGZpbGUgKysgIiciICsrICIgZG9uZS5cbiIpDQ0KDQ0KCS0t IElOUFVUDQ0KaW5wdXQgaW5maWxlCT0gZG8NDQoJICAgCSAgIAkJaGRsIDwt IG9wZW5GaWxlIGluZmlsZSBSZWFkTW9kZQ0NCgkJCQljb250ZW50IDwtIGhH ZXRDb250ZW50cyBoZGwNDQoJCQkJcmV0dXJuIGNvbnRlbnQNDQoNDQo= --298362324-1931129976-1014648815=:28682 Content-Type: TEXT/PLAIN; charset=US-ASCII; name="Functions.hs" Content-Transfer-Encoding: BASE64 Content-ID: Content-Description: Content-Disposition: attachment; filename="Functions.hs" bW9kdWxlIEZ1bmN0aW9ucyB3aGVyZQ0NCg0NCm1hcCcgZiBbXSAJCQkJPSBb XQ0NCm1hcCcgZiAodDp1OnY6dzp4Onk6ejp4cykgCT0gZiB0IHUgdiB3IHgg eSB6Om1hcCcgZiB4cw0NCg0NCm9wZXJhdGlvbiBhIGIgYyBkIGUgZiBnCQk9 IGRvIA0NCgkJCQkJICAgIHIgPC0gKG91dCBbYSxiLGMsZCxlLGZdKQ0NCgkJ CQkJICAgIGlmIChyID09IGcpIHRoZW4gDQ0KCQkJCQkgICAgIHJldHVybiBy IGVsc2UgcmV0dXJuIChhYnMgKHItZykpDQ0KY29udHJvbCB4cyANDQoJCXwg KG1vZCAobGVuZ3RoIHhzKSA3KSA9PSAwIAk9IG1hcCcgb3BlcmF0aW9uJyB4 cwkNDQoJCXwgb3RoZXJ3aXNlIAkJCT0gZXJyb3IgIkluY29ycmVjdCBzaXpl IG9mIHZlY3RvciINDQoNDQoJLS0gRlVOQ1RJT04gJ09VVCcNDQoNDQpvdXQg W2EsIGIsIGMsIGQsIGUsIGZdCT0gWyBkaXZpY2FvIFtkaXZpY2FvIFtzb21h IFtyZXN0YSBbc29tYSBbYSxiXSwgY10sIGRdLCBlXSwgZl0gXQ0NCg0NCgkt LSBGVU5DVElPTiBERUNMQVJBVElPTg0NCg0NCnNvbWEgCQk6OiBbRmxvYXRd IC0+IEZsb2F0DQ0Kc29tYSBbeCwgeV0gCT0geCArIHkNDQoNDQpyZXN0YSAJ CTo6IFtGbG9hdF0gLT4gRmxvYXQNDQpyZXN0YSBbeCwgeV0gCT0geCAtIHkN DQoNDQpkaXZpY2FvIAk6OiBbRmxvYXRdIC0+IEZsb2F0DQ0KZGl2aWNhbyBb YSwgYl0gDQ0KCQl8IGIgPT0gMAk9IGVycm9yICJEaXZpc2lvbiBieSB6ZXJv Ig0NCgkJfCBvdGhlcndpc2UJPSBhIC8gYg0NCg0NCm9wZXJhdGlvbicgYSBi IGMgZCBlIGYgZyA9IG91dCBbYSxiLGMsZCxlLGZdDQ0K --298362324-1931129976-1014648815=:28682-- From rjchaaft@cs.uu.nl Mon Feb 25 17:00:35 2002 From: rjchaaft@cs.uu.nl (Rijk J. C. van Haaften) Date: Mon, 25 Feb 2002 18:00:35 +0100 Subject: Help In-Reply-To: References: Message-ID: <4.3.0.20020225175951.00b1d560@pop.students.cs.uu.nl> You probably want to do something like this: main = do { contents <- input "twoboxes.dat" return (control (parser contents)) } At 11:53 25-02-02 -0300, Juan M. Duran wrote: >Hi, I'm writting a small parser in Haskell and, when it is all done, I get >the following problem: Type Binding. >The thing is, I have 3 main functions: >1) Read the file, its type is: [Char] ->IO [Char] (see InputOutput.hs) >2) Parse a string (using words and readDec), its type is: Integral a => >[Char] -> [a] (see Parse.hs) >3) Parse a list of integer, its type is: [Float] -> [[Float]] >(Functions.hs) > >Now the problem is that I cannot run the first function, then use its >results as an input of the second function and, finally, its results as >the input of the third function. > >How can I fix this without modifing all my functions because they, >independly, works fine. > >Juan From juan@inf.ufpr.br Mon Feb 25 15:14:09 2002 From: juan@inf.ufpr.br (Juan M. Duran) Date: Mon, 25 Feb 2002 12:14:09 -0300 (BRT) Subject: Help In-Reply-To: <4.3.0.20020225175951.00b1d560@pop.students.cs.uu.nl> Message-ID: I thing that wont works, look: contents :: IO [Char] parser :: Integral a => [Char] -> [a] control :: [Float] -> [[Float]] The two problems are: 1) The input of parser. Doesnt match with the type of input 2) The input of control (or the output of parser). Doesn match with the type of the next function. On Mon, 25 Feb 2002, Rijk J. C. van Haaften wrote: > You probably want to do something like this: > > main = > do { > contents <- input "twoboxes.dat" > return (control (parser contents)) > } > > At 11:53 25-02-02 -0300, Juan M. Duran wrote: > >Hi, I'm writting a small parser in Haskell and, when it is all done, I get > >the following problem: Type Binding. > >The thing is, I have 3 main functions: > >1) Read the file, its type is: [Char] ->IO [Char] (see InputOutput.hs) > >2) Parse a string (using words and readDec), its type is: Integral a => > >[Char] -> [a] (see Parse.hs) > >3) Parse a list of integer, its type is: [Float] -> [[Float]] > >(Functions.hs) > > > >Now the problem is that I cannot run the first function, then use its > >results as an input of the second function and, finally, its results as > >the input of the third function. > > > >How can I fix this without modifing all my functions because they, > >independly, works fine. > > > >Juan > > From Keith.Wansbrough@cl.cam.ac.uk Mon Feb 25 18:01:59 2002 From: Keith.Wansbrough@cl.cam.ac.uk (Keith Wansbrough) Date: Mon, 25 Feb 2002 18:01:59 +0000 Subject: Help In-Reply-To: Your message of "Mon, 25 Feb 2002 12:14:09 -0300." Message-ID: > I thing that wont works, look: > contents :: IO [Char] > > parser :: Integral a => [Char] -> [a] > > control :: [Float] -> [[Float]] > > The two problems are: > 1) The input of parser. Doesnt match with the type of input > 2) The input of control (or the output of parser). Doesn match > with the type of the next function. The "do" notation used by Rijk fixes the first problem; you should try it. For the second problem, you want to convert an Integral to a Float - but are you sure? Integers aren't floating point numbers! If you are sure, then do something like main = do { contents <- input "twoboxes.dat" return (control (map fromInteger (parser contents))) } fromInteger has the type Num a => Integer -> a, and since Num Float and Integral Integer, all your type constraints will be satisfied. HTH. --KW 8-) -- Keith Wansbrough http://www.cl.cam.ac.uk/users/kw217/ University of Cambridge Computer Laboratory. From rich.geary@ntlworld.com Mon Feb 25 21:42:27 2002 From: rich.geary@ntlworld.com (Rich) Date: Mon, 25 Feb 2002 21:42:27 -0000 Subject: a more practical version of getLine??? Message-ID: <01C1BE45.CCAD12C0.rich.geary@ntlworld.com> Hi, I'm writing a program for my final project at uni and I've come across the following annoying bug in my program. Basically, I have an interactive text prompt and I wish to be able to write commands into the prompt. I am currently using the function 'getLine', which as it's name suggests reads a line of text from the prompt. Unfortunately, when the delete key is used while writing to the prompt, the output differs (so typing "loaf" then 'delete' and then "d" does not seem to produce the same output as typing "load"). Also, the left and right arrow keys don't work, as they do in any normal text prompt. Any suggestins as to an alternative method to read the input??? (I'm by no means a Haskell expert btw, so I may have to be spoon fed!) thanks for your help, Rich. From heringto@cs.unc.edu Mon Feb 25 22:20:00 2002 From: heringto@cs.unc.edu (Dean Herington) Date: Mon, 25 Feb 2002 17:20:00 -0500 (EST) Subject: a more practical version of getLine??? In-Reply-To: <01C1BE45.CCAD12C0.rich.geary@ntlworld.com> Message-ID: If you're using GHC, take a look at module Readline in the util package (http://www.haskell.org/ghc/docs/latest/set/readline.html). I don't know which other Haskell systems support this module. Dean Herington On Mon, 25 Feb 2002, Rich wrote: > Hi, > > I'm writing a program for my final project at uni and I've come across the > following annoying bug in my program. Basically, I have an interactive > text prompt and I wish to be able to write commands into the prompt. I am > currently using the function 'getLine', which as it's name suggests reads a > line of text from the prompt. Unfortunately, when the delete key is used > while writing to the prompt, the output differs (so typing "loaf" then > 'delete' and then "d" does not seem to produce the same output as typing > "load"). Also, the left and right arrow keys don't work, as they do in any > normal text prompt. > > Any suggestins as to an alternative method to read the input??? (I'm by no > means a Haskell expert btw, so I may have to be spoon fed!) > > thanks for your help, > Rich. From tweed@compsci.bristol.ac.uk Tue Feb 26 10:12:05 2002 From: tweed@compsci.bristol.ac.uk (D. Tweed) Date: Tue, 26 Feb 2002 10:12:05 +0000 (GMT) Subject: a more practical version of getLine??? In-Reply-To: Message-ID: On Mon, 25 Feb 2002, Dean Herington wrote: > If you're using GHC, take a look at module Readline in the util package > (http://www.haskell.org/ghc/docs/latest/set/readline.html). I don't know > which other Haskell systems support this module. The annoying thing is the way that terminals generally act on the ASCII codes so it looks like the delete is working. Readline library sounds like the much the best option; however if it doesn't work it is possible to write a function which postprocesses the returned string and acts on the ASCII codes for backspace, arrow movement, etc, although it's a bit complex as you've got to get easy deletion of points both immediately before and after the point you are considering in the string. ___cheers,_dave_________________________________________________________ www.cs.bris.ac.uk/~tweed/|`...heat generated by its microprocessors will email:tweed@cs.bris.ac.uk|slope upward exponentially, reaching the power work tel:(0117) 954-5250 |density of a nuclear reactor before 2010'-Intel From juan@inf.ufpr.br Tue Feb 26 14:51:15 2002 From: juan@inf.ufpr.br (Juan M. Duran) Date: Tue, 26 Feb 2002 11:51:15 -0300 (BRT) Subject: Help In-Reply-To: Message-ID: The problem is fixed. I fixed it using the do notation as Rijk said, it worked perfectly. Now I got two more problems: 1) Should I use the do notation in order to write this result (type IO [[Float]]) to a file? How? 2) The Glasglow compiler doesn let me compile one library because I use the function readFloat (declare in the Prelude of Hugs 98), but Hugs lets me, why? Thanks On Mon, 25 Feb 2002, Keith Wansbrough wrote: > > I thing that wont works, look: > > contents :: IO [Char] > > > > parser :: Integral a => [Char] -> [a] > > > > control :: [Float] -> [[Float]] > > > > The two problems are: > > 1) The input of parser. Doesnt match with the type of input > > 2) The input of control (or the output of parser). Doesn match > > with the type of the next function. > > The "do" notation used by Rijk fixes the first problem; you should try it. > > For the second problem, you want to convert an Integral to a Float - but are you sure? Integers aren't floating point numbers! > > If you are sure, then do something like > > main = > do { > contents <- input "twoboxes.dat" > return (control (map fromInteger (parser contents))) > } > > fromInteger has the type Num a => Integer -> a, and since Num Float and Integral Integer, all your type constraints will be satisfied. > > HTH. > > --KW 8-) > -- > Keith Wansbrough > http://www.cl.cam.ac.uk/users/kw217/ > University of Cambridge Computer Laboratory. > > From C.T.McBride@durham.ac.uk Tue Feb 26 19:23:02 2002 From: C.T.McBride@durham.ac.uk (C T McBride) Date: Tue, 26 Feb 2002 19:23:02 +0000 (GMT) Subject: higher-kind deriving ... or not Message-ID: Hi I'm rather fond of fixpoint constructions like this one: > newtype Copy a = Copy a deriving Show > data Wonky f > = Wonky > | Manky (f (Wonky f)) > deriving Show (Clearly this is an ill-motivated example, but the real example which caused this problem is available on request...) The trouble is that when I ask either hugs -98 or ghci -fglasgow-exts to show (Wonky :: Wonky Copy) the poor compiler's brain explodes. I take it this is a known problem with instance inference, deriving, etc. Of course, it's easy to write my own show for Wonky Copy, but that's a tad annoying. I tried to guess the type of the show instance derived for Wonky. Being a naive sort of chap, I thought it might be show :: (forall a. Show a => Show (f a)) => Wonky f -> String but that's a syntax error. A little more tinkering, and it looks like it might be show :: Show (f (Wonky f)) => Wonky f -> String Is this really the type of show? If so, no wonder there's a problem. I don't want to start an argument about how to solve this problem. I do want to suggest that, for the time being, it would be better to reject `deriving Show' for type constructors like Wonky (ie those with higher-kind parameters) than to generate instances which break the compiler. Or am I just being a spoilsport? Conor From Tom.Pledger@peace.com Tue Feb 26 19:59:26 2002 From: Tom.Pledger@peace.com (Tom Pledger) Date: Wed, 27 Feb 2002 08:59:26 +1300 Subject: higher-kind deriving ... or not In-Reply-To: References: Message-ID: <15483.59678.591335.654114@waytogo.peace.co.nz> C T McBride writes: : | A little more tinkering, and it looks like it might be | | show :: Show (f (Wonky f)) => Wonky f -> String | | Is this really the type of show? That looks correct to me. | If so, no wonder there's a problem. Yes, there's a vicious circle in context reduction, between Wonky Copy and Copy (Wonky Copy). | I don't want to start an argument about how to solve this problem. I | do want to suggest that, for the time being, it would be better to | reject `deriving Show' for type constructors like Wonky (ie those with | higher-kind parameters) than to generate instances which break the | compiler. | | Or am I just being a spoilsport? It depends on your definition of sport. ;-) > data Sport f > = Sport > | Association (f Bool) > deriving Show > test = show (Sport :: Sport Maybe) Regards, Tom From Tom.Pledger@peace.com Tue Feb 26 20:09:18 2002 From: Tom.Pledger@peace.com (Tom Pledger) Date: Wed, 27 Feb 2002 09:09:18 +1300 Subject: higher-kind deriving ... or not In-Reply-To: <15483.59678.591335.654114@waytogo.peace.co.nz> References: <15483.59678.591335.654114@waytogo.peace.co.nz> Message-ID: <15483.60270.823590.214145@waytogo.peace.co.nz> Tom Pledger writes: | C T McBride writes: | : | | A little more tinkering, and it looks like it might be | | | | show :: Show (f (Wonky f)) => Wonky f -> String | | | | Is this really the type of show? | | That looks correct to me. Well, after the first context reduction, anyway. The type starts as Show a => a -> String and after substitution becomes Show (Wonky f) => Wonky f -> String and I'm not sure whether the first context reduction happens right after that, or waits until f is substituted by something more concrete. From stewartlitt@hotmail.com Wed Feb 27 01:26:16 2002 From: stewartlitt@hotmail.com (Stewart Litt) Date: Wed, 27 Feb 2002 01:26:16 +0000 Subject: java program Message-ID: dear sir/madam iam contacting you regarding a java problem which i have come across. My teacher at manchester met has set a problem for us to solve but thinking his teaching is excellent and everyone understands him wen no one does I would appreciate you helping me in this problem as it would save us from embarrassment. THE PROBLEM: Consider a simplified plan of the liverpool bus system. The system consists of a network of bus stops(at most 20) and bus lines (at most 5). Each bus stop has a unique name and each busline has a unique number. Each bus stop is connected to other bus stops by at most 3 different bus lines. Each of these bus lines connects a bus stop to exactly one other bus stop and for each bus stop and each connecting bus line it is known how many minutes the bus needs to get to the next bus stop. The objectives are to design and implement in java: 1. A representation of the bus system using suitable data structures. 2. A mechanism to go from one bus stop to a conected bus stop via a particular bus line. 3. A mechanism for searching for a connection between two given bus stops. A command line text based interface should be provided that will allow the user to issue a series of the following five commands: start: Allows to enter the current bus stop by name and resets the total journey time to zero. list: The system will show the total journey time so far, and all information on the current bus stop, that is, its name and the numbers of all outgoing bus lines. go: The system asks for the number of a busline. If the number is that of an outgoing busline, then the system finds out the busstop connected to the current bus stop and makes it the new current bus stop. If the number is not that of an outgoing bus line, then the system will indicate this by a message , but make no other changes. search: The system asks for the name of a bus stop. The system will then indicate whether there is a way to get to this bus stop from the current bus stop, but makes no other changes. exit: Stops and exits the system. Description of the liverpool bus stop below. THE LIVERPOOL BUS SYSTEM Bus Stop Outgoing bus line Connected bus stop Time in mins Bootle strand 22 South road 11 Pier head 10 Shiel road 14 22 Bootle strand 7 79 Edge hill 11 Edge hill 79 Picton clock 10 Green lane 10 Page moss 13 22 Bootle strand 18 Page moss 10 Prescot 8 Picton clock 79 Netherly 21 Shiel road 10 Green lane 5 South road 22 Green lane 9 _________________________________________________________________ MSN Photos is the easiest way to share and print your photos: http://photos.msn.com/support/worldwide.aspx From bjpop@cs.mu.OZ.AU Wed Feb 27 05:49:39 2002 From: bjpop@cs.mu.OZ.AU (Bernard James POPE) Date: Wed, 27 Feb 2002 16:49:39 +1100 (EST) Subject: higher-kind deriving ... or not In-Reply-To: from C T McBride at "Feb 26, 2002 07:23:02 pm" Message-ID: <200202270549.QAA17331@mulga.cs.mu.OZ.AU> Conor writes: > newtype Copy a = Copy a deriving Show > >data Wonky f > = Wonky > | Manky (f (Wonky f)) > deriving Show > show (Wonky :: Wonky Copy) > I don't want to start an argument about how to solve this problem. I > do want to suggest that, for the time being, it would be better to > reject `deriving Show' for type constructors like Wonky (ie those with > higher-kind parameters) than to generate instances which break the > compiler. > > Or am I just being a spoilsport? Rejecting such things might be a bit extreme, for example, you could drop the 'deriving Show' on 'Copy a', define: instance Show (Copy a) where show _ = "whatever" then: show (Wonky :: Wonky Copy) is fine and does not result in an infinite loop of context reduction. Of course this makes the example even wonkier ... (In another post Tom Pledger illustrates another example: data Sport f = Sport | Association (f Bool) deriving Show test = show (Sport :: Sport Maybe) where higher kinded arguments do not cause any trouble). The context reducer could probably do a better job at detecting when it is in an infinite loop: Show (Wonky Copy) --> Show (Copy (Wonky Copy)) --> Show (Wonky Copy) ... Cheers, Bernie. From C.T.McBride@durham.ac.uk Wed Feb 27 12:18:17 2002 From: C.T.McBride@durham.ac.uk (C T McBride) Date: Wed, 27 Feb 2002 12:18:17 +0000 (GMT) Subject: higher-kind deriving ... or not In-Reply-To: <15483.59678.591335.654114@waytogo.peace.co.nz> Message-ID: Hi again On Wed, 27 Feb 2002, Tom Pledger wrote: > Yes, there's a vicious circle in context reduction, between Wonky Copy > and Copy (Wonky Copy). > > | I don't want to start an argument about how to solve this problem. I > | do want to suggest that, for the time being, it would be better to > | reject `deriving Show' for type constructors like Wonky (ie those with > | higher-kind parameters) than to generate instances which break the > | compiler. > | > | Or am I just being a spoilsport? > > It depends on your definition of sport. ;-) > > > data Sport f > > = Sport > > | Association (f Bool) > > deriving Show > > > test = show (Sport :: Sport Maybe) Fair point, but this is just a thinly disguised first-order type constructor: type Sport f = Maybe (f Bool) Correspondingly, it's fine just to check Show for the actual instance which is used. In effect, some higher-kind parameters to datatypes are unnecessary because all their usages can abstracted as type parameters, and the corresponding applications of f passed in as arguments, just as above. However, once you introduce a fixpoint, this abstraction is no longer possible: > data Fix f = Fix (f (Fix f)) There's no equivalent first-order definition. This is where higher-kind parameters actually buy us extra stuff, and it's also the point at which the first-order constraint for show becomes hopeless. Perhaps banning such derivings for all higher-kind parametric datatypes is being a bit of a spoilsport: we can allow it exactly where it isn't necessary! Another interesting aspect of Tom's example is that the show instance exists in practice exactly because (i) Show Bool (ii) Show a => Show (f a) -- when f is Maybe These are the properties expressed by the relevant instance declarations. They are strictly stronger than Show (f Bool), but it takes a pretty bizarre f to make the distinction. Unfortunately, although we can express (ii) as a property, we can't demand it as a property, because constraints are first-order. If we could, the problem with fixpoints would go away, but instance inference would get even more complex than it already is in post 98 Haskell. There's a real question here: at what point does a problem become too complex for us to accept automation as the only means of its solution? It's clear that with typing problems, inference becomes unsustainable pretty soon after you leave the safe harbours of the Hindley-Milner system. However, lots of lovely programs have more interesting types: it would be very frustrating if Haskell forbade these programs just because their types were not inferrable---not least since, for these jobs, we usually do think of the type first and the code afterwards. Sensibly, Haskell allows us to write these types down, so the machine's task is merely checking. This hybrid approach preserves type inference for `old' code, whilst promoting more adventurous programming by allowing us to say what we mean when the machine is too dim to guess. Could there be a corresponding hybrid approach for instance inference? Conor From simonpj@microsoft.com Wed Feb 27 14:56:28 2002 From: simonpj@microsoft.com (Simon Peyton-Jones) Date: Wed, 27 Feb 2002 06:56:28 -0800 Subject: higher-kind deriving ... or not Message-ID: <1113DDB24D4A2841951BFDF86665EE19374A06@RED-MSG-10.redmond.corp.microsoft.com> | > data Wonky f | > =3D Wonky | > | Manky (f (Wonky f)) | > deriving Show |=20 | The trouble is that when I ask either hugs -98 or ghci=20 | -fglasgow-exts to |=20 | show (Wonky :: Wonky Copy) |=20 | the poor compiler's brain explodes. I fixed this a few weeks ago. GHC (5.03) now says: Foo.hs:3: No instance for `Show (f (Wonky f))' When deriving the `Show' instance for type `Wonky' | I tried to guess the type of the show instance derived for=20 | Wonky. Being a naive sort of chap, I thought it might be |=20 | show :: (forall a. Show a =3D> Show (f a)) =3D> Wonky f -> String Not naive. That's exactly the right type. See Section 7 of "Derivable type classes". http://research.microsoft.com/~simonpj/Papers/derive.htm Havn't implemented this, yet, alas. | It's clear that with typing problems, inference becomes=20 | unsustainable pretty soon after you leave the safe harbours=20 | of the Hindley-Milner system. However, lots of lovely=20 | programs have more interesting types: it would be very=20 | frustrating if Haskell forbade these programs just because=20 | their types were not inferrable---not least since, for these=20 | jobs, we usually do think of the type first and the code=20 | afterwards. Sensibly, Haskell allows us to write these types=20 | down, so the machine's task is merely checking. This hybrid=20 | approach preserves type inference for `old' code, whilst=20 | promoting more adventurous programming by allowing us to say=20 | what we mean when the machine is too dim to guess. I agree wholeheartedly with this; it's exactly the approach I'm trying to take with GHC. One obvious extension is to let the user specify the context for a derived instance decl, but still let the compiler generate the code. Havn't done this either! Simon From juan@inf.ufpr.br Wed Feb 27 14:09:18 2002 From: juan@inf.ufpr.br (Juan M. Duran) Date: Wed, 27 Feb 2002 11:09:18 -0300 (BRT) Subject: Help In-Reply-To: Message-ID: I got a function with type :: IO [[Double]], and what I want is write this output in a file, how can I do it... I mean, I cannot doit by just using writeFile.... And one more thing: the Glasglow compiler doesn let me compile because I use the function readFloat (declare in the Prelude of Hugs 98), but Hugs lets me, why? How can I solve it? Thanks From mark@chaos.x-philes.com Wed Feb 27 16:41:57 2002 From: mark@chaos.x-philes.com (Mark Carroll) Date: Wed, 27 Feb 2002 11:41:57 -0500 (EST) Subject: Help In-Reply-To: Message-ID: On Wed, 27 Feb 2002, Juan M. Duran wrote: > I got a function with type :: IO [[Double]], and what I want is write this > output in a file, how can I do it... I mean, I cannot doit by just using > writeFile.... (snip) Does something like this help at all? myfn :: IO [[Double]] myfn = return [[1.346, 4.144], [5.143, 2.453]] format_doubles :: [[Double]] -> String format_doubles x = foldr (++) "" (map format_line x) format_line :: [Double] -> String format_line [] = "\n" format_line x = foldr1 (\x y -> x ++ ", " ++ y) (map show x) ++ "\n" main = myfn >>= (\x -> return $ format_doubles x) >>= putStr Okay, it's not the most readable bit of code, but I'm guessing it covers the bit that's confusing you. All the best, Mark From C.T.McBride@durham.ac.uk Wed Feb 27 20:52:47 2002 From: C.T.McBride@durham.ac.uk (C T McBride) Date: Wed, 27 Feb 2002 20:52:47 +0000 (GMT) Subject: higher-kind deriving ... or not In-Reply-To: <15485.15496.447132.773438@waytogo.peace.co.nz> Message-ID: Hi On Thu, 28 Feb 2002, Tom Pledger wrote: > C T McBride writes: > | > data Fix f = Fix (f (Fix f)) > | > | There's no equivalent first-order definition. This is where > | higher-kind parameters actually buy us extra stuff, and it's also the > | point at which the first-order constraint for show becomes hopeless. > > Did you see the technique Mark Tullsen posted last year, for making > instances in the presence of a fixpoint? I've found it useful. > > http://haskell.cs.yale.edu/pipermail/haskell/2001-May/003942.html Thanks for the pointer. Yes, that looks like a kind of hard-coding of the lifting to higher kinds that I'm after. If I understand things correctly, it would seem that for every type class C t, indexed by types, one can manufacture the constructor class FC f which asserts that f preserves C-ness. For each C-method m :: blah[t] one gives the FC method fm :: C t => blah[f t] One can lift further, by defining classes for constructors with higher-kind parameters which take FC-ness (or whatever) to C-ness. Requiring FC f (a first-order constraint on a higher-kind thing) is a plausible fake of requiring (forall a. C a => C (f a)) (a higher-order constraint on types). If I read correctly, automating this construction, effectively yielding computation of classes from kinds, is part of Simon PJ and Ralf Hinze's `Deriving Type Classes' proposal. The functionality is clearly desirable. It does, however, come at the cost of introducing a third and still separate programming language as a component of Haskell---the language of programming over kinds. It's no good asking when this will stop, because it doesn't. It is worth asking when the different layers of this hierarchy will acquire a greater uniformity. Cheers Conor From brandon@its.caltech.edu Thu Feb 28 02:24:52 2002 From: brandon@its.caltech.edu (Brandon Michael Moore) Date: Wed, 27 Feb 2002 18:24:52 -0800 (PST) Subject: Lazy Parsing Message-ID: I'm wondering if there are any libraries out there for creating parsers that lazily build up their result. I know I could thread the remaining input through a parser by hand, but it seems like someone should have already done it. I'd like to be able to turn a stream of XML into a lazy tree of tags (probably Maybe tags, or Either errors tags), but I don't think HaXml and the like do that sort of thing. Branodn Moore From rjmh@cs.chalmers.se Thu Feb 28 06:06:43 2002 From: rjmh@cs.chalmers.se (John Hughes) Date: Thu, 28 Feb 2002 07:06:43 +0100 (MET) Subject: Lazy Parsing Message-ID: <200202280606.HAA02588@hotlips.cs.chalmers.se> There's a combinator which Phil Wadler called "guarantee" which makes a parser lazy -- guarantee p succeeds at once, with a result which will be produced, when demanded, by p. Many parsing libraries include it under one name or another... John From cxl@Informatik.Uni-Bremen.DE Thu Feb 28 10:26:17 2002 From: cxl@Informatik.Uni-Bremen.DE (Christoph Lueth) Date: Thu, 28 Feb 2002 11:26:17 +0100 Subject: Haskell in Space Message-ID: <3C7E05C9.8000209@informatik.uni-bremen.de> Dear Haskell people, as the last exercise of a second-year undergraduate Haskell course I had the students write an asteroids-type game (older readers may remember this arcade classic from the last century) using the Hugs Graphics Library. I put some solutions up on a wee web-page, because I thought it might amuse some of you who teach or learn Haskell, and because frankly one of the students' solutions simply deserved some wider attention: http://www.informatik.uni-bremen.de/~cxl/haskell-in-space Enjoy, --Christoph. From johnsson@crt.se Thu Feb 28 10:42:20 2002 From: johnsson@crt.se (Thomas Johnsson) Date: Thu, 28 Feb 2002 11:42:20 +0100 Subject: Haskell in Space In-Reply-To: <3C7E05C9.8000209@informatik.uni-bremen.de> References: <3C7E05C9.8000209@informatik.uni-bremen.de> Message-ID: <15486.2444.686264.650957@spitfire.crt.se> Cool! Speaking of Haskell and games, has anyone interfaced DirectX with Haskell? -- Thomas Christoph Lueth writes: > Dear Haskell people, > > as the last exercise of a second-year undergraduate Haskell course I had > the students write an asteroids-type game (older readers may remember > this arcade classic from the last century) using the Hugs Graphics > Library. I put some solutions up on a wee web-page, because I thought it > might amuse some of you who teach or learn Haskell, and because frankly > one of the students' solutions simply deserved some wider attention: > > http://www.informatik.uni-bremen.de/~cxl/haskell-in-space > > Enjoy, > --Christoph. > > _______________________________________________ > Haskell-Cafe mailing list > Haskell-Cafe@haskell.org > http://www.haskell.org/mailman/listinfo/haskell-cafe From jerry@gime.com Thu Feb 28 13:41:10 2002 From: jerry@gime.com (Jerry, JiJie) Date: Thu, 28 Feb 2002 21:41:10 +0800 Subject: Ground Up Message-ID: <20020228214110.E15337@ghost.gime.com> Good day everyone, I'm a haskell newbie trying to seeking advice to advance myself. My backgrounds are: * As a non-CS student, I have absolutely no knowledge of lambda calculus * And unfortunately I have to make painful decision on spending $30 on a book or three days' meal While my goals are: * Become a pragmatic haskell programmer in the shortest time * At the minimal expense What I have done for the past few weeks were: * I read almost all the free educational sources at www.haskell.org, * Subscribed to this mailing list and try to digest every mail * Read most of the "The Haskell School of Expression" (by Paul Hudak) and the non-theoretical chapters of the "An Introduction To Functional Programming Systems Using Haskell" (by AJT Davie), which are the only two introductory level haskell related books in our library However, my problems are: * I still don't understand most of the codes I found, like the various haskell libraries * I still have no clue of most (ok, almost all) of what is being discussed in this mailing list So I'm eager to know if there are cost-effective ways to achieve my goals or at least leverage myself from the beginner's level. Your advice would be greatly appreciated! Regards, Jerry From Keith.Wansbrough@cl.cam.ac.uk Thu Feb 28 13:49:17 2002 From: Keith.Wansbrough@cl.cam.ac.uk (Keith Wansbrough) Date: Thu, 28 Feb 2002 13:49:17 +0000 Subject: Ground Up In-Reply-To: Your message of "Thu, 28 Feb 2002 21:41:10 +0800." <20020228214110.E15337@ghost.gime.com> Message-ID: Jerry writes: > While my goals are: > * Become a pragmatic haskell programmer in the shortest time > * At the minimal expense > > What I have done for the past few weeks were: > * I read almost all the free educational sources at www.haskell.org, > * Subscribed to this mailing list and try to digest every mail > * Read most of the "The Haskell School of Expression" (by Paul > Hudak) and the non-theoretical chapters of the "An Introduction To > Functional Programming Systems Using Haskell" (by AJT Davie), which > are the only two introductory level haskell related books in our > library My advice would be to install GHC [*] or Hugs, and do all the exercises from the Hudak textbook. You can't learn to program by reading, you only learn by actually writing programs. Other than that, you could try reading the Haskell 98 Report to learn about the language, and skimming the documentation for the libraries to get an idea of what's available. Again, you'll learn about the libraries by using them, not by reading the docs - but you need to skim at least the contents pages of the docs so you know what's out there. Haskell 98 Report: http://www.haskell.org/definition/ Haskell 98 standard libraries docs: http://www.haskell.org/definition/ Other Haskell libraries docs: http://www.haskell.org/ghc/docs/latest/set/book-hslibs.html Hope this helps! --KW 8-) [*] If you use GHC, you'll probably find the interpeter (GHCi) easier to use and better for experimentation than the compiler (GHC). From ketil@ii.uib.no Thu Feb 28 13:53:14 2002 From: ketil@ii.uib.no (Ketil Z Malde) Date: 28 Feb 2002 14:53:14 +0100 Subject: Ground Up In-Reply-To: "Jerry, JiJie"'s message of "Thu, 28 Feb 2002 21:41:10 +0800" References: <20020228214110.E15337@ghost.gime.com> Message-ID: "Jerry, JiJie" writes: > While my goals are: > * Become a pragmatic haskell programmer in the shortest time > * At the minimal expense How far have you come? Are you comfortable with recursion? With the type system? IO? Monads in general? > * I still have no clue of most (ok, almost all) of what is being > discussed in this mailing list Me neither; don't let that worry you. I'd advise you to ignore threads about difficult issues -- a lot of stuff discussed here is rare borderline cases that are mostly of interest to implementors, and not you and me. :-) -kzm -- If I haven't seen further, it is by standing in the footprints of giants From rjchaaft@cs.uu.nl Thu Feb 28 14:05:16 2002 From: rjchaaft@cs.uu.nl (Rijk J. C. van Haaften) Date: Thu, 28 Feb 2002 15:05:16 +0100 Subject: Ground Up Message-ID: <4.3.0.20020228150425.00b12618@pop.students.cs.uu.nl> Jerry wrote >However, my problems are: >* I still don't understand most of the codes I found, like the various > haskell libraries Practice is the only answer to this problem, as Keith Wansbrough says. >* I still have no clue of most (ok, almost all) of what is being > discussed in this mailing list Though I am a CS student, being highly interested in Haskell and practising a lot, I didn't understand most of the discussions on this mailing list. I started understanding them only after I got involved in implementing a Haskell compiler. Therefore, don't worry about this point. A haskell-user doesn't need to know the details of the haskell compiler ins and outs. Rijk-Jan van Haaften From hdaume@ISI.EDU Thu Feb 28 15:46:00 2002 From: hdaume@ISI.EDU (Hal Daume III) Date: Thu, 28 Feb 2002 07:46:00 -0800 (PST) Subject: Ground Up In-Reply-To: <4.3.0.20020228150425.00b12618@pop.students.cs.uu.nl> Message-ID: Unfortunately I think I have to take issue with this statement :). > Therefore, don't worry about this point. A haskell-user doesn't > need to know the details of the haskell compiler ins and outs. I think that at the beginning, a huser doesn't need to know the ins and outs, but from personal experience, the more complicated your programs become, and the more you begin worrying about speed, the more you need to know about the compiler. Personally, I find this quite aggrevating and I think it is one of the least often expressed disadvantages to Haskell. I can see arguments against me immediately, so I'll save you time. For instance, you could argue that it is easier to get "up and running" (well, more like walking in Haskell) in Haskell than say C. I would probably agree. But lets say it comes time to fine tune my program. In C I have (admittedly made up example, but see my recent post the the mailing list on this subject): void sumProdTo(int n, int*s, int*p) { int sum = 0; int i; for (i = 1; i <= n; i++) sum += i; &s = sum; int prod = 1; for (i = 2; i <= n; i++) prod *= i; &p = prod; } and in Haskell: sumProdTo n = (sumTo n, prodTo n) where sumTo 1 = 1 sumTo n = n + sumTo (n-1) prodTo... etc. Now, I want to optimize. In C, I can fuse the loops so I'm only traversing once, which would give me moderate speed improcement. In Haskell, I could also "fuse" the loops and say: sumProdTo 1 = (1,1) sumProdTo n = (n+s,n*p) where (s,p) = sumProdTo (n-1) but this is actually *slower* but there's no way for me to know this without actually running it. in fact, in the discussion about this on the list, no one was really able to give a definitive answer as to why. there was a lot of handwaving about pointers to the heap to pointers to other things, and obviously it has to do with boxing and unboxing and stuff like that, but I think this is a problem. i'm not sure what the moral is. obviously, each of these, in theory, could have equal speed given a good enough optimizing compiler (and, perhaps, no issues of undecidability). however, since in C it's much more clear exactly what is happeneing, you know when you write your code that one thing is going to be faster than another (except when you get to uber complex things when you're worrying about cache sizes, etc, but that's out of the scope of this -- you could never even try to worry about something like that in haskell). i think the only real solution would be to put up a web page or something that contains things like "this looks like it would speed up your program but it will actually slow it down." or at least some better tips on getting your programs to run quickly. okay, i'm done. that's not to discourage the original poster to learn haskell - i use it almost exclusively; it's just that i don't think it's fair to say you don't have to understand what the compiler is doing to write code. - hal -- Hal Daume III "Computer science is no more about computers | hdaume@isi.edu than astronomy is about telescopes." -Dijkstra | www.isi.edu/~hdaume On Thu, 28 Feb 2002, Rijk J. C. van Haaften wrote: > Jerry wrote > > >However, my problems are: > >* I still don't understand most of the codes I found, like the various > > haskell libraries > Practice is the only answer to this problem, as Keith Wansbrough says. > > >* I still have no clue of most (ok, almost all) of what is being > > discussed in this mailing list > Though I am a CS student, being highly interested in Haskell and > practising a lot, I didn't understand most of the discussions on > this mailing list. > I started understanding them only after I got involved in implementing > a Haskell compiler. > > Rijk-Jan van Haaften > > _______________________________________________ > Haskell-Cafe mailing list > Haskell-Cafe@haskell.org > http://www.haskell.org/mailman/listinfo/haskell-cafe > From jenglish@flightlab.com Thu Feb 28 16:22:04 2002 From: jenglish@flightlab.com (Joe English) Date: Thu, 28 Feb 2002 08:22:04 -0800 Subject: Lazy Parsing In-Reply-To: References: Message-ID: <200202281622.g1SGM4A13079@dragon.flightlab.com> Brandon Michael Moore wrote: > I'm wondering if there are any libraries out there for creating parsers > that lazily build up their result. I know I could thread the remaining > input through a parser by hand, but it seems like someone should have > already done it. This turns out to be rather difficult to do in the general case (but see below -- XML is a special case). If you have type Parser sym result = [sym] -> Maybe (result, [sym]) a Parser can't decide whether to return 'Just (result,rest)' or 'Nothing' until it has successfully parsed the complete result. So pattern matching on the parser's return value will force the entire production. Variations on the theme -- Either instead of Maybe, list-of-successes, continuation-passing combinators, etc -- all face a similar problem. However, if your top-level grammar is of the form: things :: empty | thing things {- == thing* -} then instead of: case runParser (pMany pThing) input of Just (result,[]) -> ... you can use something like unfoldr (runParser pThing) input to build the result list incrementally. This will be less eager; instead of parsing and returning an entire list of Things, it parses one Thing at a time. Another thing to watch out for is heap drag. The list-of-successes approach tends to retain the entire input, just in case the parser needs to backtrack. Parsec [1] and UU_Parsing [?] solve this by severely restricting the amount of required lookahead. > I'd like to be able to turn a stream of XML into a lazy tree of tags > (probably Maybe tags, or Either errors tags), but I don't think HaXml and > the like do that sort of thing. That's exactly how HXML [2] works. The parser returns a lazy list of tokens (analogous to SAX events), which are folded up into a tree by a separate function. In addition it uses a CPS parser library so (as with Parsec), there is minimal heap drag. [1] Parsec: [1] HXML: (Note: HXML release 0.2 will be ready Real Soon Now, and there have been many incompatible changes since 0.1. The main thing left to be finished is the documentation, if you can live without that let me know and I'll put a snapshot up.) --Joe English jenglish@flightlab.com From karczma@info.unicaen.fr Thu Feb 28 16:36:55 2002 From: karczma@info.unicaen.fr (Jerzy Karczmarczuk) Date: Thu, 28 Feb 2002 17:36:55 +0100 Subject: Ground Up References: Message-ID: <3C7E5CA7.18CDB36F@info.unicaen.fr> Hal Daume III about Haskell optimization problems: ... > and in Haskell: > > sumProdTo n = (sumTo n, prodTo n) > where sumTo 1 = 1 > sumTo n = n + sumTo (n-1) > prodTo... > > etc. > > Now, I want to optimize. In C, I can fuse the loops so I'm only > traversing once, which would give me moderate speed improcement. In > Haskell, I could also "fuse" the loops and say: > > sumProdTo 1 = (1,1) > sumProdTo n = (n+s,n*p) > where (s,p) = sumProdTo (n-1) > > but this is actually *slower* but there's no way for me to know this > without actually running it. in fact, in the discussion about this on the > list, no one was really able to give a definitive answer as to why. there > was a lot of handwaving about pointers to the heap to pointers to other > things, and obviously it has to do with boxing and unboxing and stuff like > that, but I think this is a problem. I didn't follow that discussion, but let's be serious. Really. Your second version constructs and destroys plenty of tuples, of ephemeric data structures which live one step only, and this is obviously costly. "No way to know this?" Are you sure? WHAT is a problem? I see only one: a Haskell user should master the essentials of a reasonably professional functional style. sumProdTo n = spt n 1 1 where spt 1 s p = (s,p) spt n s p = spt (n-1) (n+s) (n*p) The only touchy point in such circumstances may be the laziness which can be dealt with. Then, the above is more equivalent to the optimized C code than your version. > i'm not sure what the moral is. ... > i think the only real solution would be to put up a web page or something > that contains things like "this looks like it would speed up your program > but it will actually slow it down." or at least some better tips on > getting your programs to run quickly. For me the moral is: I disagree with > ... it's just that i don't think it's > fair to say you don't have to understand what the compiler is doing to > write code. This is not the question of this or that *compiler*, but of understanding the basics of data processing independent of the language. I am abhorred by the idea of putting down: "this looks like it would speed up your program..." in cases where it is rather clear that it might not. Please do the same experience in C with dynamically allocated tuples. Jerzy Karczmarczuk From hdaume@ISI.EDU Thu Feb 28 17:28:31 2002 From: hdaume@ISI.EDU (Hal Daume III) Date: Thu, 28 Feb 2002 09:28:31 -0800 (PST) Subject: Ground Up In-Reply-To: <3C7E5CA7.18CDB36F@info.unicaen.fr> Message-ID: On Thu, 28 Feb 2002, Jerzy Karczmarczuk wrote: > I didn't follow that discussion, but let's be serious. Really. > Your second version constructs and destroys plenty of tuples, of > ephemeric data structures which live one step only, and this is > obviously costly. "No way to know this?" Are you sure? And yet there's no reason I shouldn't get update-in-place on those tuples. What's more, if I create my own data type for tuples which is strict in both of its arguments and use a function which is strict in the tuple (yes, even if i use proper tail recursion), it's still slower. > WHAT is a problem? > I see only one: a Haskell user should master the essentials of > a reasonably professional functional style. > > sumProdTo n = spt n 1 1 where > spt 1 s p = (s,p) > spt n s p = spt (n-1) (n+s) (n*p) This is obviously the preferred solution, but it seems there should be no performance difference between this and: sumProdTo n = spt n (1,1) where spt 1 acc = acc spt n (s,p) = spt (n-1) (n+s, n*p) but there is a huge difference, even if i put seqs in to force evaluation of the sum and product before creating the tuple. but this is obviously a made-up situation. (more down further) > > ... it's just that i don't think it's > > fair to say you don't have to understand what the compiler is doing to > > write code. > > This is not the question of this or that *compiler*, but of understanding > the basics of data processing independent of the language. I am abhorred by > the idea of putting down: "this looks like it would speed up your program..." > in cases where it is rather clear that it might not. Please do the same > experience in C with dynamically allocated tuples. so constructing and tearing apart tuples, you should say then, displays a lack of understanding of the basics of data processing in haskell. let's look at the definition of the standard library function mapAccumL: > mapAccumL :: (a -> b -> (a, c)) -> a -> [b] -> (a, [c]) > mapAccumL f s [] = (s, []) > mapAccumL f s (x:xs) = (s'',y:ys) > where (s', y ) = f s x > (s'',ys) = mapAccumL f s' xs this is clearly the same problem. it's constantly creating and tearing apart tuples. or unfoldr: > unfoldr f b = case f b of Nothing -> [] > Just (a,b) -> a : unfoldr f b the list goes on. clearly creating small intermediate structures (like tuples) is very central to haskell. in fact, for speed reasons i have frequently written my own versions of the above functions which remove the tuple creation because it simply makes it too slow. this is *not* at all what haskell is about. it's about writing functions which are small and modular and have good reuse. that's why this functions are in the standard libraries. you can also observe the frequent use of functions which take a state and return a (state,value) pair. using functions like these pushes the creation and destruction of tuples very far. given the importance tuples and other small data structures have in haskell, i found it hard to believe that using them would cause me to suffer such a severe performance penalty. i *assumed* that since they were so widely used and so integral to the language, that the compilers would do a much better job that they do with being intelligent about using them. i found this assumption to be incorrect, and that's the primary reason i think you need to know more about what's going on in the compiler to write fast programs. - Hal From koen@cs.chalmers.se Thu Feb 28 17:29:04 2002 From: koen@cs.chalmers.se (Koen Claessen) Date: Thu, 28 Feb 2002 18:29:04 +0100 (MET) Subject: Lazy Parsing In-Reply-To: <200202281622.g1SGM4A13079@dragon.flightlab.com> Message-ID: Brandon Michael Moore wondered: | I'm wondering if there are any libraries out there | for creating parsers that lazily build up their | result. Joe English answered: | type Parser sym result = [sym] -> Maybe (result, [sym]) However, a parser for a particular type T might actually just return T directly, without any Maybe in the way, if T has a failure constructor built-in. Something like: data T = Plus T T | ... | Fail Error Now, a parser for T can already start building its result without having to wait for the whole thing to succeed. This gets a bit ugly, especially when dealing with many types that are being parsed, or with the extra failure constructor always being part of the datatype. One way of adding such a constructor to any type would be: data Result a = Val a | forall b c . Apply2 (b -> c -> Result a) (Result b) (Result c) | Fail Error This gives you a way of creating an 'a' not only lazily, but one can decide oneself what to do with failure and when to do it. Example: When parsing the following faulty expression "(1+2)+blurp" And expecting an Int as a result, the parser would build the following expression: Apply2 (\x y -> Val (x+y)) (Apply2 (\x y -> Val (x+y)) (Val 1) (Val 2)) (Fail "unrecognized `blurp'") None of this is type checked and surely contains bugs, but I hope you get the idea. The hope is that a value of type `Result a' gives you more information and better space behavior than just a value of type `Maybe a'. /Koen. -- Koen Claessen http://www.cs.chalmers.se/~koen Chalmers University, Gothenburg, Sweden. From ru@river.org Thu Feb 28 17:25:35 2002 From: ru@river.org (Richard Uhtenwoldt) Date: Thu, 28 Feb 2002 09:25:35 -0800 Subject: Ground Up In-Reply-To: References: <20020228214110.E15337@ghost.gime.com> Message-ID: >> * I still have no clue of most (ok, almost all) of what is being >> discussed in this mailing list > >Me neither; don't let that worry you. I'd advise you to ignore >threads about difficult issues -- a lot of stuff discussed here is >rare borderline cases that are mostly of interest to implementors, and >not you and me. :-) I agree! Just focus on a goal, like understanding "anonymous functions", recursion, type classes or the IO monad. Since you mention you do not have money, let me make sure you know that knowing Haskell has approximately zero value in today's job market because Haskell so far has been taken up by very few employers. I'd venture that most employers of programmers have not yet even heard of Haskell. So, it's not a resume-builder like knowing C or Java or Perl or SQL is. (Of course if you are a student learning it for class or an employer or future employer *told* you to learn Haskell, then that's different.) From max630@mail.ru Thu Feb 28 21:10:29 2002 From: max630@mail.ru (Max Kirillov) Date: Fri, 1 Mar 2002 03:10:29 +0600 Subject: Ground Up In-Reply-To: <20020228214110.E15337@ghost.gime.com>; from jerry@gime.com on Thu, Feb 28, 2002 at 09:41:10PM +0800 References: <20020228214110.E15337@ghost.gime.com> Message-ID: <20020301031028.A642@max.home> Hi! I'm far not an expert in Haskell, but I'll venture to say "I'm in". I'm not an CS student and I have never been (I learned Solid State Physics). I became there in about 6 months without paying a cent. Well, I paid for dialup. I also spent a lot of time. My wife should hate Haskell. I would recommend you not to be confined by Haskell. Take a look at Lisp, ML. First, it helps to get into concepts rather than into details of syntax parsing of high-order polymorphism. I began learning FP with Erlang, and I think it helped me. Further, Haskell, though _very_ nice, is probably not "the best choice" for a "pragmatic programming". It is too alive. Different compilers are not 100% compatible each to other, and even different versions of the same compilers may be incompatible. You should be ready either to stick yourself and your co-wokers to a certain version of the compiler or to spend some significal time to keep you programs working with any compiler. Maybe you will find that it's better to use Ocaml or Scheme. Thay have own neats, and seem to be more stable. Max. On Thu, Feb 28, 2002 at 09:41:10PM +0800, Jerry, JiJie wrote: > Good day everyone, I'm a haskell newbie trying to seeking advice to > advance myself. > > My backgrounds are: > * As a non-CS student, I have absolutely no knowledge of lambda calculus > * And unfortunately I have to make painful decision on spending $30 > on a book or three days' meal > > While my goals are: > * Become a pragmatic haskell programmer in the shortest time > * At the minimal expense > > What I have done for the past few weeks were: > * I read almost all the free educational sources at www.haskell.org, > * Subscribed to this mailing list and try to digest every mail > * Read most of the "The Haskell School of Expression" (by Paul > Hudak) and the non-theoretical chapters of the "An Introduction To > Functional Programming Systems Using Haskell" (by AJT Davie), which > are the only two introductory level haskell related books in our > library > > However, my problems are: > * I still don't understand most of the codes I found, like the various > haskell libraries > * I still have no clue of most (ok, almost all) of what is being > discussed in this mailing list > > So I'm eager to know if there are cost-effective ways to achieve my > goals or at least leverage myself from the beginner's level. > > Your advice would be greatly appreciated! > > Regards, > Jerry > _______________________________________________ > Haskell-Cafe mailing list > Haskell-Cafe@haskell.org > http://www.haskell.org/mailman/listinfo/haskell-cafe > From Shawn@Garbett.org Thu Feb 28 21:55:53 2002 From: Shawn@Garbett.org (Shawn P. Garbett) Date: Thu, 28 Feb 2002 15:55:53 -0600 Subject: Changing a light bulb. Message-ID: -----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 Now after my earlier soap box tirade I'm trying to put my code where my mouth is. >>blush<< It's harder than I thought. I've broken it down into a State Model of a light bulb. The goal, to find out just how much Haskell code does it take to change the state of a light bulb? Here's a very crippled version. Is there an easy way to introduce state without changing the type of main??? I've written a much more complex example, but I got into things like main :: STT(IO) using a monad transformer. So really, the big question is, must I use a monad transformer? - ------------------------------------------------------------------------------------------------ - -- State model of a light bulb import Monad import IO main :: IO () main = do hSetBuffering stdin NoBuffering process process :: IO () process = do i <- assign initialState putChar '\n' print(s) if (s /= Exit) then process else return () data State = Dark | Light initialState :: State initialState = Dark data Stimulus = On | Off | Exit deriving (Show, Eq, Enum) charToStimulus :: Char -> Stimulus charToStimulus '1' = On charToStimulus '0' = Off charToStimulus c = Exit getStimulus :: IO Stimulus getStimulus = liftM charToStimulus getChar - -- State transformer newtype St a = MkSt (State -> (a, State)) - -- State transformer applied to state apply :: St a -> State -> (a, State) apply (MkSt f) s = f s - -- State monad instance Monad St where return x = MkSt f where f s = (x,s) p >>= q = MkSt f where f s = apply (q x) s' where (x, s') = apply p s - -- Useful State operations fetch :: St State fetch = MkSt f where f s = (s,s) assign :: State -> St () assign s' = MkSt f where f s = ((),s') done :: St () done = return () - ----------------------------------------------------------------------------------------------------------------------- - -- You're in a maze of twisty little statements, all alike. Public Key available from http://www.garbett.org/public-key -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.0.6 (GNU/Linux) Comment: For info see http://www.gnupg.org iD8DBQE8fqdpDtpPjAQxZ6ARAkCWAJ9pGcS/hQpoK12AdcEmt8Y/0rEv9ACfWGtO 1FL9VwopmgsAyUAv9RL++T8= =a9xu -----END PGP SIGNATURE-----