From drokunwill@hknetmail.com Sun Apr 6 07:10:01 2003
From: drokunwill@hknetmail.com (Dr.Williams Okun.)
Date: Sun, 6 Apr 2003 08:10:01 +0200
Subject: Waiting to hear from you.
Message-ID: <20030406160345.C60E3421EE6@www.haskell.org>
Dear Sir=2C
REQUEST ASSISTANCE=2FPARTNERSHIP =2E
I am a member of a contract award and review committee =2EA contract already executed by a foreign firm in Africa in 1999 was over invoiced by us to the tune of $8=2C600=2C000=2E00 =28Eight million six hundred thousand United states dollars=29=2E
In the light of the above=2C I ask for your assistance in the transfer of this excess floating fund in a suspence account into a foreign account you may wish to provide=2C for it was a category =22A=22 contract=2C =28strictly reserved for foreign contractors=29 this informed my request=2C and also that I am forbidden by my government to run any foreign account=2E
After the sucessful transfer=2C 20% of the total sum will go to you for your assistance=2E 5% of the total sum will be set aside to compensate for any incidental expenses incured by both parties=2E
More details will be given in the course of correspondence=2E
Your confidentiality is highly required since I am still in active service =2E
Thank you for your anticipated co-operation=2E
Regards=2C
Dr=2EWilliams Okun=2E
TELEPHONE=3A234-1-776-3350=2E
FAX=3A234-1-759-7912=2E
You can contact me on my home email on=2E
drokunwill=40hknetmail=2Ecom
From chiyan@cs.bu.edu Wed Apr 16 00:02:25 2003
From: chiyan@cs.bu.edu (Chiyan Chen)
Date: Tue, 15 Apr 2003 19:02:25 -0400 (EDT)
Subject: Question about using higher order polymorphism.
Message-ID:
Hi,
I am a ph.d student working in the area of typed programming
langauges. And I am a happy Haskell user. Recently I am working on
something that involves some advanced Haskell features. So I write to
this mailing list to ask for help.
My question is, in which version of Haskell can I use higher order
polymorphism features (including first class polymorphic and first class
existential types), and how to use them (what's the syntax). Is there any
special packages or libraries that I need to install for using these
features.
For example, how should I define the following types:
data T a b = TC (exists c. (a -> c, c -> b))
data B = BC (forall a. a -> a -> a)
or more complex:
data T b = TC (exist c. forall b. (a -> c, c -> b))
Thank you for you help.
--
Chiyan Chen
From amymarie@slingshot.co.nz Wed Apr 16 05:56:48 2003
From: amymarie@slingshot.co.nz (Amy Barnes)
Date: Wed, 16 Apr 2003 16:56:48 +1200
Subject: Help!!
Message-ID:
Finally worked out my problem was not that I didn't know to load hugs, I
have a file missing -
[localhost:~] amy% hugs
dyld: hugs can't open library: /usr/lib/libncurses.5.dylib (No such
file or directory, errno = 2)
Does anyone know what this file is or how I can obtain it?
Thank you all again for your help.
Kind regards,
Amy Barnes
From joe@informatik.uni-leipzig.de Wed Apr 16 07:19:38 2003
From: joe@informatik.uni-leipzig.de (Johannes Waldmann)
Date: Wed, 16 Apr 2003 08:19:38 +0200 (MET DST)
Subject: Question about using higher order polymorphism.
In-Reply-To:
Message-ID:
> My question is, in which version of Haskell can I use higher order
> polymorphism features (including first class polymorphic and first class
> existential types), and how to use them (what's the syntax).
for ghc, check this:
http://www.haskell.org/ghc/docs/latest/html/users_guide/type-extensions.html
(i think) most of this is implemented in hugs as well.
with ghc, you need `ghc -fglasgow-exts', with hugs, use `hugs -98'.
--
-- Johannes Waldmann ---- http://www.informatik.uni-leipzig.de/~joe/ --
-- joe@informatik.uni-leipzig.de -- phone/fax (+49) 341 9732 204/207 --
From alastair@reid-consulting-uk.ltd.uk Wed Apr 16 10:42:58 2003
From: alastair@reid-consulting-uk.ltd.uk (Alastair Reid)
Date: Wed, 16 Apr 2003 10:42:58 +0100
Subject: Help!!
In-Reply-To: (Amy
Barnes's message of
"Wed, 16 Apr 2003 16:56:48 +1200")
References:
Message-ID:
Amy Barnes writes:
> Finally worked out my problem was not that I didn't know to load
> hugs, I have a file missing -
>
> [localhost:~] amy% hugs dyld: hugs can't open library:
> /usr/lib/libncurses.5.dylib (No such file or directory, errno = 2)
>
> Does anyone know what this file is or how I can obtain it?
If I recall correctly, this is for a Mac running Darwin. Right?
I can't help you with where to find the file. I have a vague idea
that there's a standard place to get unix-like tools and libraries if
you're a developer and I suspect you need to go there but I don't know
any specifics.
Another way to solve the problem might be to build your own copy of
Hugs customized to your machine rather than using a copy customized to
the machine of the person who builds the binary package. If you have
C compilers and the like installed on your machine, this is quite easy
to do - at least, it was when I did it on a Darwin machine last
summer. Just go to the Hugs website, download the source distribution
and execute the following commands (based on the file hugs98/Install
in the distribution).
tar zxvf hugs98*.tgz
cd hugs98/src/unix
./configure --prefix=$HOME
cd ..
make install
The --prefix argument on the third argument is used if you don't have
administrator privileges on your machine and assumes that $HOME/bin is
on your search path. You may also want to use '--with-readline' to
allow easier editing of commands to Hugs but that would depend on
having the readline library installed on your machine.
--
Alastair Reid alastair@reid-consulting-uk.ltd.uk
Reid Consulting (UK) Limited http://www.reid-consulting-uk.ltd.uk/alastair/
From u4435@mailer4435.net Wed Apr 16 12:36:21 2003
From: u4435@mailer4435.net (Baskuda-4435)
Date: Wed, 16 Apr 03 11:36:21 GTB Daylight Time
Subject: Sayýn hugs-users ,Baskuda.Com`da Bebek / Oyuncak Kategorisi Açýldý!
Message-ID: <20030416113912.2971D4221DC@www.haskell.org>
------=_NextPart_000_007F_5C6E4472.4FAF7581
Content-Type: text/html; charset= "windows-1254"
Content-Transfer-Encoding: base64
PGh0bWw+DQo8aGVhZD4NCjx0aXRsZT5CYXNrdWRhLkNvbWBkYSBCZWJlayAvIE95dW5jYWsg
S2F0ZWdvcmlzaSBB53lsZHkhPC90aXRsZT4NCjxtZXRhIGh0dHAtZXF1aXY9IkNvbnRlbnQt
VHlwZSIgY29udGVudD0idGV4dC9odG1sOyBjaGFyc2V0PXdpbmRvd3MtMTI1NCI+DQo8bWV0
YSBodHRwLWVxdWl2PSJDb250ZW50LVR5cGUiIGNvbnRlbnQ9InRleHQvaHRtbDsgY2hhcnNl
dD1JU08tODg1OS05Ij4NCjxtZXRhIGh0dHAtZXF1aXY9J2NvbnRlbnQtbGFuZ3VhZ2UnIGNv
bnRlbnQ9J1RSJz4NCjwvaGVhZD4NCg0KPGJvZHkgYmdjb2xvcj0iIzY2NjY2NiIgbGVmdG1h
cmdpbj0iMCIgdG9wbWFyZ2luPSIwIiBtYXJnaW53aWR0aD0iMCIgbWFyZ2luaGVpZ2h0PSIw
Ij4NCjx0YWJsZSB3aWR0aD0iNjk4IiBoZWlnaHQ9IjEwMCUiIGJvcmRlcj0iMCIgYWxpZ249
ImNlbnRlciIgY2VsbHBhZGRpbmc9IjAiIGNlbGxzcGFjaW5nPSIwIiBiZ2NvbG9yPSIjRkZG
RkZGIj4NCiAgPHRyPiANCiAgICA8dGQgYWxpZ249ImNlbnRlciIgdmFsaWduPSJ0b3AiPjx0
YWJsZSB3aWR0aD0iMTAwJSIgYm9yZGVyPSIwIiBjZWxsc3BhY2luZz0iMCIgY2VsbHBhZGRp
bmc9IjAiPg0KICAgICAgICA8dHI+IA0KICAgICAgICAgIDx0ZCBjb2xzcGFuPSI0Ij48YSBo
cmVmPSJodHRwOi8vd3d3LmJhc2t1ZGEuY29tL2Jzay5hc3B4P2NtcD1iYXNrdWRhJmFmZj1N
YWlsX095dW5jYWtfTTAwNDkiPjxpbWcgc3JjPSJodHRwOi8vd3d3LmJhc2t1ZGEuY29tL21h
Z2F6YS9lbWFpbC9NMDA0OS90MS5naWYiIHdpZHRoPSI2OTgiIGhlaWdodD0iNjMiIGJvcmRl
cj0iMCI+PC9hPjwvdGQ+DQogICAgICAgIDwvdHI+DQogICAgICAgIDx0cj4gDQogICAgICAg
ICAgPHRkPjxhIGhyZWY9Imh0dHA6Ly93d3cuYmFza3VkYS5jb20vQnNrLmFzcHg/Y21wPWJh
c2t1ZGEmY2F0SWQ9MjkzMiZhVHlwZT1zdWJDYXRlZ29yaWVzJmFmZj1NYWlsX095dW5jYWtf
TTAwNDkiPjxpbWcgc3JjPSJodHRwOi8vd3d3LmJhc2t1ZGEuY29tL21hZ2F6YS9lbWFpbC9N
MDA0OS90Mi5qcGciIHdpZHRoPSIxMjMiIGhlaWdodD0iMjg3IiBib3JkZXI9IjAiPjwvYT48
L3RkPg0KICAgICAgICAgIDx0ZD48YSBocmVmPSJodHRwOi8vd3d3LmJhc2t1ZGEuY29tL0Jz
ay5hc3B4P2NtcD1iYXNrdWRhJmNhdElkPTI5MzImYVR5cGU9c3ViQ2F0ZWdvcmllcyZhZmY9
TWFpbF9PeXVuY2FrX00wMDQ5Ij48aW1nIHNyYz0iaHR0cDovL3d3dy5iYXNrdWRhLmNvbS9t
YWdhemEvZW1haWwvTTAwNDkvdDMuanBnIiB3aWR0aD0iMTE2IiBoZWlnaHQ9IjI4NyIgYm9y
ZGVyPSIwIj48L2E+PC90ZD4NCiAgICAgICAgICA8dGQ+PGEgaHJlZj0iaHR0cDovL3d3dy5i
YXNrdWRhLmNvbS9Cc2suYXNweD9jbXA9YmFza3VkYSZjYXRJZD0yOTMyJmFUeXBlPXN1YkNh
dGVnb3JpZXMmYWZmPU1haWxfT3l1bmNha19NMDA0OSI+PGltZyBzcmM9Imh0dHA6Ly93d3cu
YmFza3VkYS5jb20vbWFnYXphL2VtYWlsL00wMDQ5L3Q0LmdpZiIgd2lkdGg9IjI2MCIgaGVp
Z2h0PSIyODciIGJvcmRlcj0iMCI+PC9hPjwvdGQ+DQogICAgICAgICAgPHRkPjxhIGhyZWY9
Imh0dHA6Ly93d3cuYmFza3VkYS5jb20vQnNrLmFzcHg/Y21wPWJhc2t1ZGEmY2F0SWQ9Mjkz
MiZhVHlwZT1zdWJDYXRlZ29yaWVzJmFmZj1NYWlsX095dW5jYWtfTTAwNDkiPjxpbWcgc3Jj
PSJodHRwOi8vd3d3LmJhc2t1ZGEuY29tL21hZ2F6YS9lbWFpbC9NMDA0OS90NS5naWYiIHdp
ZHRoPSIxOTkiIGhlaWdodD0iMjg3IiBib3JkZXI9IjAiPjwvYT48L3RkPg0KICAgICAgICA8
L3RyPg0KICAgICAgPC90YWJsZT4NCiAgICAgIDx0YWJsZSB3aWR0aD0iMTAwJSIgYm9yZGVy
PSIwIiBjZWxsc3BhY2luZz0iMCIgY2VsbHBhZGRpbmc9IjAiPg0KICAgICAgICA8dHI+IA0K
ICAgICAgICAgIDx0ZCBoZWlnaHQ9IjMwIiBjb2xzcGFuPSI1Ij4mbmJzcDs8L3RkPg0KICAg
ICAgICA8L3RyPg0KICAgICAgICA8dHI+IA0KICAgICAgICAgIDx0ZCB3aWR0aD0iMjAiIHJv
d3NwYW49IjQiPiZuYnNwOzwvdGQ+DQogICAgICAgICAgPHRkIGFsaWduPSJjZW50ZXIiPjx0
YWJsZSB3aWR0aD0iMjAyIiBoZWlnaHQ9IjI3MCIgYm9yZGVyPSIwIiBjZWxscGFkZGluZz0i
MCIgY2VsbHNwYWNpbmc9IjAiPg0KICAgICAgICAgICAgICA8dHI+IA0KICAgICAgICAgICAg
ICAgIDx0ZCB3aWR0aD0iMjAyIiBoZWlnaHQ9IjYwIiB2YWxpZ249InRvcCI+PGltZyBzcmM9
Imh0dHA6Ly93d3cuYmFza3VkYS5jb20vbWFnYXphL2VtYWlsL00wMDQ5L2IxLmdpZiIgd2lk
dGg9IjIwMiIgaGVpZ2h0PSI0MiI+PC90ZD4NCiAgICAgICAgICAgICAgPC90cj4NCiAgICAg
ICAgICAgICAgPHRyPiANCiAgICAgICAgICAgICAgICA8dGQgYWxpZ249ImNlbnRlciI+PGEg
aHJlZj0iaHR0cDovL3d3dy5iYXNrdWRhLmNvbS9ic2suYXNweD9jbXA9YmFza3VkYSZwSWQ9
NTQ0NjgxJmFUeXBlPXByb2R1Y3QmY2F0SWQ9MjkzMiZhZmY9TWFpbF9PeXVuY2FrX00wMDQ5
Ij48aW1nIHNyYz0iaHR0cDovL3d3dy5iYXNrdWRhLmNvbS9tYWdhemEvZW1haWwvTTAwNDkv
dTQuanBnIiB3aWR0aD0iMTQ1IiBoZWlnaHQ9Ijg0IiBib3JkZXI9IjAiPjwvYT48L3RkPg0K
ICAgICAgICAgICAgICA8L3RyPg0KICAgICAgICAgICAgICA8dHI+IA0KICAgICAgICAgICAg
ICAgIDx0ZCBhbGlnbj0iY2VudGVyIiB2YWxpZ249ImJvdHRvbSI+PGEgaHJlZj0iaHR0cDov
L3d3dy5iYXNrdWRhLmNvbS9ic2suYXNweD9jbXA9YmFza3VkYSZwSWQ9NTQ0NjgxJmFUeXBl
PXByb2R1Y3QmY2F0SWQ9MjkzMiZhZmY9TWFpbF9PeXVuY2FrX00wMDQ5Ij48aW1nIHNyYz0i
aHR0cDovL3d3dy5iYXNrdWRhLmNvbS9tYWdhemEvZW1haWwvTTAwNDkvZGV0YXlsaV9iaWxn
aS5naWYiIHdpZHRoPSI3NCIgaGVpZ2h0PSIxOSIgYm9yZGVyPSIwIj4gDQogICAgICAgICAg
ICAgICAgICA8aW1nIHNyYz0iaHR0cDovL3d3dy5iYXNrdWRhLmNvbS9tYWdhemEvZW1haWwv
TTAwNDkvZjEuZ2lmIiB3aWR0aD0iMjAyIiBoZWlnaHQ9IjM3IiBib3JkZXI9IjAiPjwvYT48
L3RkPg0KICAgICAgICAgICAgICA8L3RyPg0KICAgICAgICAgICAgPC90YWJsZT48L3RkPg0K
ICAgICAgICAgIDx0ZCBhbGlnbj0iY2VudGVyIj48dGFibGUgd2lkdGg9IjIwMiIgaGVpZ2h0
PSIyNzAiIGJvcmRlcj0iMCIgY2VsbHBhZGRpbmc9IjAiIGNlbGxzcGFjaW5nPSIwIj4NCiAg
ICAgICAgICAgICAgPHRyPiANCiAgICAgICAgICAgICAgICA8dGQgd2lkdGg9IjIwMiIgaGVp
Z2h0PSI2MCIgdmFsaWduPSJ0b3AiPiA8aW1nIHNyYz0iaHR0cDovL3d3dy5iYXNrdWRhLmNv
bS9tYWdhemEvZW1haWwvTTAwNDkvYjIuZ2lmIiB3aWR0aD0iMjAyIiBoZWlnaHQ9IjQyIj48
L3RkPg0KICAgICAgICAgICAgICA8L3RyPg0KICAgICAgICAgICAgICA8dHI+IA0KICAgICAg
ICAgICAgICAgIDx0ZCBhbGlnbj0iY2VudGVyIj48YSBocmVmPSJodHRwOi8vd3d3LmJhc2t1
ZGEuY29tL2Jzay5hc3B4P2NtcD1iYXNrdWRhJnBJZD01NDIxMTAmYVR5cGU9cHJvZHVjdCZj
YXRJZD0yOTg1JmFmZj1NYWlsX095dW5jYWtfTTAwNDkiPjxpbWcgc3JjPSJodHRwOi8vd3d3
LmJhc2t1ZGEuY29tL21hZ2F6YS9lbWFpbC9NMDA0OS91Ny5qcGciIHdpZHRoPSIxMTkiIGhl
aWdodD0iMTExIiBib3JkZXI9IjAiPjwvYT48L3RkPg0KICAgICAgICAgICAgICA8L3RyPg0K
ICAgICAgICAgICAgICA8dHI+IA0KICAgICAgICAgICAgICAgIDx0ZCBhbGlnbj0iY2VudGVy
IiB2YWxpZ249ImJvdHRvbSI+IDxhIGhyZWY9Imh0dHA6Ly93d3cuYmFza3VkYS5jb20vYnNr
LmFzcHg/Y21wPWJhc2t1ZGEmcElkPTU0MjExMCZhVHlwZT1wcm9kdWN0JmNhdElkPTI5ODUm
YWZmPU1haWxfT3l1bmNha19NMDA0OSI+PGltZyBzcmM9Imh0dHA6Ly93d3cuYmFza3VkYS5j
b20vbWFnYXphL2VtYWlsL00wMDQ5L2RldGF5bGlfYmlsZ2kuZ2lmIiB3aWR0aD0iNzQiIGhl
aWdodD0iMTkiIGJvcmRlcj0iMCI+PC9hPiANCiAgICAgICAgICAgICAgICAgIDxpbWcgc3Jj
PSJodHRwOi8vd3d3LmJhc2t1ZGEuY29tL21hZ2F6YS9lbWFpbC9NMDA0OS9mMi5naWYiIHdp
ZHRoPSIyMDIiIGhlaWdodD0iMzciPjwvdGQ+DQogICAgICAgICAgICAgIDwvdHI+DQogICAg
ICAgICAgICA8L3RhYmxlPjwvdGQ+DQogICAgICAgICAgPHRkIGFsaWduPSJjZW50ZXIiIHZh
bGlnbj0idG9wIj4gPHRhYmxlIHdpZHRoPSIyMDIiIGhlaWdodD0iMjcwIiBib3JkZXI9IjAi
IGNlbGxwYWRkaW5nPSIwIiBjZWxsc3BhY2luZz0iMCI+DQogICAgICAgICAgICAgIDx0cj4g
DQogICAgICAgICAgICAgICAgPHRkIHdpZHRoPSIyMDIiIGhlaWdodD0iNjAiIHZhbGlnbj0i
dG9wIj4gPGltZyBzcmM9Imh0dHA6Ly93d3cuYmFza3VkYS5jb20vbWFnYXphL2VtYWlsL00w
MDQ5L2IzLmdpZiIgd2lkdGg9IjIwMiIgaGVpZ2h0PSI0MiI+PC90ZD4NCiAgICAgICAgICAg
ICAgPC90cj4NCiAgICAgICAgICAgICAgPHRyPiANCiAgICAgICAgICAgICAgICA8dGQgYWxp
Z249ImNlbnRlciI+PGEgaHJlZj0iaHR0cDovL3d3dy5iYXNrdWRhLmNvbS9ic2suYXNweD9j
bXA9YmFza3VkYSZwSWQ9NTQ1ODg2JmFUeXBlPXByb2R1Y3QmY2F0SWQ9MjkzOSZhZmY9TWFp
bF9PeXVuY2FrX00wMDQ5Ij48aW1nIHNyYz0iaHR0cDovL3d3dy5iYXNrdWRhLmNvbS9tYWdh
emEvZW1haWwvTTAwNDkvdTMuanBnIiB3aWR0aD0iMTE4IiBoZWlnaHQ9IjEwMCIgYm9yZGVy
PSIwIj48L2E+PC90ZD4NCiAgICAgICAgICAgICAgPC90cj4NCiAgICAgICAgICAgICAgPHRy
PiANCiAgICAgICAgICAgICAgICA8dGQgYWxpZ249ImNlbnRlciIgdmFsaWduPSJib3R0b20i
PiA8YSBocmVmPSJodHRwOi8vd3d3LmJhc2t1ZGEuY29tL2Jzay5hc3B4P2NtcD1iYXNrdWRh
JnBJZD01NDU4ODYmYVR5cGU9cHJvZHVjdCZjYXRJZD0yOTM5JmFmZj1NYWlsX095dW5jYWtf
TTAwNDkiPjxpbWcgc3JjPSJodHRwOi8vd3d3LmJhc2t1ZGEuY29tL21hZ2F6YS9lbWFpbC9N
MDA0OS9kZXRheWxpX2JpbGdpLmdpZiIgd2lkdGg9Ijc0IiBoZWlnaHQ9IjE5IiBib3JkZXI9
IjAiPjwvYT4gDQogICAgICAgICAgICAgICAgICA8aW1nIHNyYz0iaHR0cDovL3d3dy5iYXNr
dWRhLmNvbS9tYWdhemEvZW1haWwvTTAwNDkvZjMuZ2lmIiB3aWR0aD0iMjAyIiBoZWlnaHQ9
IjM3Ij48L3RkPg0KICAgICAgICAgICAgICA8L3RyPg0KICAgICAgICAgICAgPC90YWJsZT48
L3RkPg0KICAgICAgICAgIDx0ZCB3aWR0aD0iMjAiIHJvd3NwYW49IjQiPiZuYnNwOzwvdGQ+
DQogICAgICAgIDwvdHI+DQogICAgICAgIDx0cj4gDQogICAgICAgICAgPHRkIGNvbHNwYW49
IjMiIGFsaWduPSJjZW50ZXIiPiZuYnNwOzwvdGQ+DQogICAgICAgIDwvdHI+DQogICAgICAg
IDx0cj4gDQogICAgICAgICAgPHRkIGFsaWduPSJjZW50ZXIiPjx0YWJsZSB3aWR0aD0iMjAy
IiBoZWlnaHQ9IjI5MCIgYm9yZGVyPSIwIiBjZWxscGFkZGluZz0iMCIgY2VsbHNwYWNpbmc9
IjAiPg0KICAgICAgICAgICAgICA8dHI+IA0KICAgICAgICAgICAgICAgIDx0ZCB3aWR0aD0i
MjAyIiBoZWlnaHQ9IjYwIiB2YWxpZ249InRvcCI+IDxpbWcgc3JjPSJodHRwOi8vd3d3LmJh
c2t1ZGEuY29tL21hZ2F6YS9lbWFpbC9NMDA0OS9iNC5naWYiIHdpZHRoPSIyMDIiIGhlaWdo
dD0iNDIiPjwvdGQ+DQogICAgICAgICAgICAgIDwvdHI+DQogICAgICAgICAgICAgIDx0cj4g
DQogICAgICAgICAgICAgICAgPHRkIGFsaWduPSJjZW50ZXIiPjxhIGhyZWY9Imh0dHA6Ly93
d3cuYmFza3VkYS5jb20vYnNrLmFzcHg/Y21wPWJhc2t1ZGEmcElkPTU0NTgyOSZhVHlwZT1w
cm9kdWN0JmNhdElkPTI5MzImYWZmPU1haWxfT3l1bmNha19NMDA0OSI+PGltZyBzcmM9Imh0
dHA6Ly93d3cuYmFza3VkYS5jb20vbWFnYXphL2VtYWlsL00wMDQ5L3UxMy5qcGciIHdpZHRo
PSIxMDAiIGhlaWdodD0iMTU1IiBib3JkZXI9IjAiPjwvYT48L3RkPg0KICAgICAgICAgICAg
ICA8L3RyPg0KICAgICAgICAgICAgICA8dHI+IA0KICAgICAgICAgICAgICAgIDx0ZCBhbGln
bj0iY2VudGVyIiB2YWxpZ249ImJvdHRvbSI+IDxhIGhyZWY9Imh0dHA6Ly93d3cuYmFza3Vk
YS5jb20vYnNrLmFzcHg/Y21wPWJhc2t1ZGEmcElkPTU0NTgyOSZhVHlwZT1wcm9kdWN0JmNh
dElkPTI5MzImYWZmPU1haWxfT3l1bmNha19NMDA0OSI+PGltZyBzcmM9Imh0dHA6Ly93d3cu
YmFza3VkYS5jb20vbWFnYXphL2VtYWlsL00wMDQ5L2RldGF5bGlfYmlsZ2kuZ2lmIiB3aWR0
aD0iNzQiIGhlaWdodD0iMTkiIGJvcmRlcj0iMCI+PC9hPiANCiAgICAgICAgICAgICAgICAg
IDxpbWcgc3JjPSJodHRwOi8vd3d3LmJhc2t1ZGEuY29tL21hZ2F6YS9lbWFpbC9NMDA0OS9m
NC5naWYiIHdpZHRoPSIyMDIiIGhlaWdodD0iMzciPjwvdGQ+DQogICAgICAgICAgICAgIDwv
dHI+DQogICAgICAgICAgICA8L3RhYmxlPjwvdGQ+DQogICAgICAgICAgPHRkIGFsaWduPSJj
ZW50ZXIiIHZhbGlnbj0idG9wIj48dGFibGUgd2lkdGg9IjIwMiIgaGVpZ2h0PSIyOTAiIGJv
cmRlcj0iMCIgY2VsbHBhZGRpbmc9IjAiIGNlbGxzcGFjaW5nPSIwIj4NCiAgICAgICAgICAg
ICAgPHRyPiANCiAgICAgICAgICAgICAgICA8dGQgd2lkdGg9IjIwMiIgaGVpZ2h0PSI2MCIg
dmFsaWduPSJ0b3AiPjxpbWcgc3JjPSJodHRwOi8vd3d3LmJhc2t1ZGEuY29tL21hZ2F6YS9l
bWFpbC9NMDA0OS9iNS5naWYiIHdpZHRoPSIyMDIiIGhlaWdodD0iNDIiPjwvdGQ+DQogICAg
ICAgICAgICAgIDwvdHI+DQogICAgICAgICAgICAgIDx0cj4gDQogICAgICAgICAgICAgICAg
PHRkIGFsaWduPSJjZW50ZXIiPjxhIGhyZWY9Imh0dHA6Ly93d3cuYmFza3VkYS5jb20vYnNr
LmFzcHg/Y21wPWJhc2t1ZGEmcElkPTU0NTkzNCZhVHlwZT1wcm9kdWN0JmNhdElkPTI5MzUm
YWZmPU1haWxfT3l1bmNha19NMDA0OSI+PGltZyBzcmM9Imh0dHA6Ly93d3cuYmFza3VkYS5j
b20vbWFnYXphL2VtYWlsL00wMDQ5L3UyLmpwZyIgd2lkdGg9IjEyNSIgaGVpZ2h0PSIxMjUi
IGJvcmRlcj0iMCI+PC9hPjwvdGQ+DQogICAgICAgICAgICAgIDwvdHI+DQogICAgICAgICAg
ICAgIDx0cj4gDQogICAgICAgICAgICAgICAgPHRkIGFsaWduPSJjZW50ZXIiIHZhbGlnbj0i
Ym90dG9tIj4gPGEgaHJlZj0iaHR0cDovL3d3dy5iYXNrdWRhLmNvbS9ic2suYXNweD9jbXA9
YmFza3VkYSZwSWQ9NTQ1OTM0JmFUeXBlPXByb2R1Y3QmY2F0SWQ9MjkzNSZhZmY9TWFpbF9P
eXVuY2FrX00wMDQ5Ij48aW1nIHNyYz0iaHR0cDovL3d3dy5iYXNrdWRhLmNvbS9tYWdhemEv
ZW1haWwvTTAwNDkvZGV0YXlsaV9iaWxnaS5naWYiIHdpZHRoPSI3NCIgaGVpZ2h0PSIxOSIg
Ym9yZGVyPSIwIj48L2E+IA0KICAgICAgICAgICAgICAgICAgPGltZyBzcmM9Imh0dHA6Ly93
d3cuYmFza3VkYS5jb20vbWFnYXphL2VtYWlsL00wMDQ5L2Y1LmdpZiIgd2lkdGg9IjIwMiIg
aGVpZ2h0PSIzNyI+PC90ZD4NCiAgICAgICAgICAgICAgPC90cj4NCiAgICAgICAgICAgIDwv
dGFibGU+PC90ZD4NCiAgICAgICAgICA8dGQgYWxpZ249ImNlbnRlciIgdmFsaWduPSJ0b3Ai
PiA8dGFibGUgd2lkdGg9IjIwMiIgaGVpZ2h0PSIyOTAiIGJvcmRlcj0iMCIgY2VsbHBhZGRp
bmc9IjAiIGNlbGxzcGFjaW5nPSIwIj4NCiAgICAgICAgICAgICAgPHRyPiANCiAgICAgICAg
ICAgICAgICA8dGQgd2lkdGg9IjIwMiIgaGVpZ2h0PSI2MCIgdmFsaWduPSJ0b3AiPiA8aW1n
IHNyYz0iaHR0cDovL3d3dy5iYXNrdWRhLmNvbS9tYWdhemEvZW1haWwvTTAwNDkvYjYuZ2lm
IiB3aWR0aD0iMjAyIiBoZWlnaHQ9IjQyIj48L3RkPg0KICAgICAgICAgICAgICA8L3RyPg0K
ICAgICAgICAgICAgICA8dHI+IA0KICAgICAgICAgICAgICAgIDx0ZCBhbGlnbj0iY2VudGVy
Ij48YSBocmVmPSJodHRwOi8vd3d3LmJhc2t1ZGEuY29tL2Jzay5hc3B4P2NtcD1iYXNrdWRh
JnBJZD01NDM5MTQmYVR5cGU9cHJvZHVjdCZjYXRJZD0yOTQzJmFmZj1NYWlsX095dW5jYWtf
TTAwNDkiPjxpbWcgc3JjPSJodHRwOi8vd3d3LmJhc2t1ZGEuY29tL21hZ2F6YS9lbWFpbC9N
MDA0OS91OC5qcGciIHdpZHRoPSIxMzYiIGhlaWdodD0iMTIwIiBib3JkZXI9IjAiPjwvYT48
L3RkPg0KICAgICAgICAgICAgICA8L3RyPg0KICAgICAgICAgICAgICA8dHI+IA0KICAgICAg
ICAgICAgICAgIDx0ZCBhbGlnbj0iY2VudGVyIiB2YWxpZ249ImJvdHRvbSI+IDxhIGhyZWY9
Imh0dHA6Ly93d3cuYmFza3VkYS5jb20vYnNrLmFzcHg/Y21wPWJhc2t1ZGEmcElkPTU0Mzkx
NCZhVHlwZT1wcm9kdWN0JmNhdElkPTI5NDMmYWZmPU1haWxfT3l1bmNha19NMDA0OSI+PGlt
ZyBzcmM9Imh0dHA6Ly93d3cuYmFza3VkYS5jb20vbWFnYXphL2VtYWlsL00wMDQ5L2RldGF5
bGlfYmlsZ2kuZ2lmIiB3aWR0aD0iNzQiIGhlaWdodD0iMTkiIGJvcmRlcj0iMCI+PC9hPiAN
CiAgICAgICAgICAgICAgICAgIDxpbWcgc3JjPSJodHRwOi8vd3d3LmJhc2t1ZGEuY29tL21h
Z2F6YS9lbWFpbC9NMDA0OS9mNi5naWYiIHdpZHRoPSIyMDIiIGhlaWdodD0iMzciPjwvdGQ+
DQogICAgICAgICAgICAgIDwvdHI+DQogICAgICAgICAgICA8L3RhYmxlPjwvdGQ+DQogICAg
ICAgIDwvdHI+DQogICAgICAgIDx0cj4gDQogICAgICAgICAgPHRkIGNvbHNwYW49IjMiIGFs
aWduPSJjZW50ZXIiPiZuYnNwOzwvdGQ+DQogICAgICAgIDwvdHI+DQogICAgICA8L3RhYmxl
PjwvdGQ+DQogIDwvdHI+DQogIDx0cj4gDQogICAgPHRkIGhlaWdodD0iMTAiID48L3RkPg0K
ICA8L3RyPg0KICA8dHI+IA0KICAgIDx0ZCBoZWlnaHQ9IjIwIiBhbGlnbj0iY2VudGVyIiB2
YWxpZ249InRvcCI+IDx0YWJsZSB3aWR0aD0iNjcwIiBib3JkZXI9IjAiIGNlbGxwYWRkaW5n
PSIxIiBjZWxsc3BhY2luZz0iMCIgYmdjb2xvcj0iIzY2NjY2NiI+DQogICAgICAgIDx0cj4g
DQogICAgICAgICAgPHRkPjx0YWJsZSB3aWR0aD0iMTAwJSIgYm9yZGVyPSIwIiBjZWxscGFk
ZGluZz0iMCIgY2VsbHNwYWNpbmc9IjYiIGJnY29sb3I9IiNGRkZGRkYiPg0KICAgICAgICAg
ICAgICA8dHI+IA0KICAgICAgICAgICAgICAgIDx0ZD48cD48Zm9udCBzaXplPSIxIiBmYWNl
PSJWZXJkYW5hIj4qQmFza3VkYS5jb21gZGFuIGUtbWFpbCBhbG1hayANCiAgICAgICAgICAg
ICAgICAgICAgaXN0ZW1peW9yc2Fu/XogPGEgaHJlZj0ibWFpbHRvOmxpc3RlQGJhc2t1ZGEu
Y29tP3N1YmplY3Q9TGlzdGVkZW5fQ2lrIj5saXN0ZUBiYXNrdWRhLmNvbTwvYT5gYSANCiAg
ICAgICAgICAgICAgICAgICAgYm/+IGJpciBlLW1haWwgeW9sbGF5/W79ei48L2ZvbnQ+PC9w
PjwvdGQ+DQogICAgICAgICAgICAgIDwvdHI+DQogICAgICAgICAgICA8L3RhYmxlPjwvdGQ+
DQogICAgICAgIDwvdHI+DQogICAgICA8L3RhYmxlPjwvdGQ+DQogIDwvdHI+DQogIDx0cj4g
DQogICAgPHRkIGhlaWdodD0iMTAiID48L3RkPg0KICA8L3RyPg0KICA8dHI+IA0KICAgIDx0
ZCBoZWlnaHQ9IjQxIiBhbGlnbj0iY2VudGVyIiB2YWxpZ249ImJvdHRvbSI+PGltZyBzcmM9
Imh0dHA6Ly93d3cuYmFza3VkYS5jb20vbWFnYXphL2VtYWlsL00wMDQ5L2FsdC5naWYiIHdp
ZHRoPSI2OTgiIGhlaWdodD0iNDEiPjwvdGQ+DQogIDwvdHI+DQo8L3RhYmxlPg0KPC9ib2R5
Pg0KPC9odG1sPiAgICA=
------=_NextPart_000_007F_5C6E4472.4FAF7581--
From simonpj@microsoft.com Thu Apr 17 09:02:45 2003
From: simonpj@microsoft.com (Simon Peyton-Jones)
Date: Thu, 17 Apr 2003 09:02:45 +0100
Subject: Existentials
Message-ID:
Dear GHC users, Hugs users, and Hugs implementors
Many of you have grown to love existential data types, which we current
write like this:
data T =3D forall a. Foo a (a -> Int)
Mark and I chose 'forall' rather than 'exists' to save grabbing another
keyword from the programmer. And indeed, the type of the constructor
Foo is
Foo :: forall a. a -> (a->Int) -> T
But every single time I explain this to someone, I find I have to make
excuses for using the term 'forall'. I say "it really means 'exists',
but we didn't want to lose another keyword".=20
I have gradually concluded that our decision was a mistake. (In
fairness to Mark, I think I was the primary advocate for it.) I reckon
that we should
Allow 'exists'=09
Deprecate 'forall' (for defining existentials, that is)
Eventually allow only 'exists'
Does anyone have any opinions on this topic? It's a small point, but
one that bites quite frequently. It might even be possible to arrange
that 'forall' and 'exists' were only keywords in types, and not in
terms, but I'm not sure it's worth the bother.
I don't think it affects NHC, because it's not H98 anyway.
Simon
From doaitse@cs.uu.nl Thu Apr 17 09:05:52 2003
From: doaitse@cs.uu.nl (Doaitse Swierstra)
Date: Thu, 17 Apr 2003 10:05:52 +0200
Subject: Existentials
In-Reply-To:
Message-ID: <685B16C1-70AB-11D7-BE5B-0003936416C0@cs.uu.nl>
I think that (in line with the other type notation conventions where
you do not have to be explicit) you should not be forced to write
anything at all, but I am sure I will remain a minority ;-}
Doaitse Swierstra
On donderdag, apr 17, 2003, at 10:02 Europe/Amsterdam, Simon
Peyton-Jones wrote:
> Dear GHC users, Hugs users, and Hugs implementors
>
> Many of you have grown to love existential data types, which we current
> write like this:
>
> data T = forall a. Foo a (a -> Int)
>
> Mark and I chose 'forall' rather than 'exists' to save grabbing another
> keyword from the programmer. And indeed, the type of the constructor
> Foo is
> Foo :: forall a. a -> (a->Int) -> T
>
> But every single time I explain this to someone, I find I have to make
> excuses for using the term 'forall'. I say "it really means 'exists',
> but we didn't want to lose another keyword".
>
> I have gradually concluded that our decision was a mistake. (In
> fairness to Mark, I think I was the primary advocate for it.) I reckon
> that we should
>
> Allow 'exists'
> Deprecate 'forall' (for defining existentials, that is)
> Eventually allow only 'exists'
>
>
> Does anyone have any opinions on this topic? It's a small point, but
> one that bites quite frequently. It might even be possible to arrange
> that 'forall' and 'exists' were only keywords in types, and not in
> terms, but I'm not sure it's worth the bother.
>
> I don't think it affects NHC, because it's not H98 anyway.
>
>
> Simon
>
>
> _______________________________________________
> Hugs-Users mailing list
> Hugs-Users@haskell.org
> http://www.haskell.org/mailman/listinfo/hugs-users
From haberg@math.su.se Thu Apr 17 10:37:55 2003
From: haberg@math.su.se (Hans Aberg)
Date: Thu, 17 Apr 2003 11:37:55 +0200
Subject: Existentials
In-Reply-To:
Message-ID:
At 09:02 +0100 2003/04/17, Simon Peyton-Jones wrote:
> Allow 'exists'
> Deprecate 'forall' (for defining existentials, that is)
> Eventually allow only 'exists'
>
>
>Does anyone have any opinions on this topic? It's a small point, but
>one that bites quite frequently.
I have to come to think about this type of questions, but in another
context, namely, when I was implementing a version of Prolog in the form of
a proof-verification system building on metamathematics (= metalogic)
rather than the standard logic. See for example, Elliott Mendelson,
"Introduction to Mathematical Logic". You might pick down a program called
"Qu-Prolog" to get an input on similar metalogical ideas in the form of a
generalized Prolog system for bound variables:
Qu-Prolog:
http://www.svrc.it.uq.edu.au/pages/QuProlog_release.html
Earlier versions
http://svrc.it.uq.edu.au/Bibliography/svrc-tr.html?00-20
http://svrc.it.uq.edu.au/Bibliography/svrc-tr.html?00-21
Ergo
http://www.svrc.it.uq.edu.au/pages/Ergo_release.html
In such a context, it looks as though the natural extension of the type
theory is axiomatic set theory. So I am therefore inclined to think that
one should do whatever is correct in math, in order to pave the way for a
natural development.
As for naming conventions, I favor a naming without prepositions and
endings, if possible. For example, "+" might be called "addition", even
though "a + b" is read "a added to b". So one might use the words "all" and
"exist" simply.
At 10:05 +0200 2003/04/17, Doaitse Swierstra wrote:
>I think that (in line with the other type notation conventions where
>you do not have to be explicit) you should not be forced to write
>anything at all, but I am sure I will remain a minority ;-}
Actually, in metamathematics, there is a difference between quantified and
unquantified formulas (variables with "all").
>Many of you have grown to love existential data types, which we current
>write like this:
>
> data T = forall a. Foo a (a -> Int)
>
>Mark and I chose 'forall' rather than 'exists' to save grabbing another
>keyword from the programmer. And indeed, the type of the constructor
>Foo is
> Foo :: forall a. a -> (a->Int) -> T
>
>But every single time I explain this to someone, I find I have to make
>excuses for using the term 'forall'. I say "it really means 'exists',
>but we didn't want to lose another keyword".
A mathematical formulation of T is perhaps:
T := V_{a in I} a x Hom(a, Int)
where V sands for the disjoint union (= coproduct in the category of sets).
So one computer approximating analogue might then be "exist".
Hans Aberg
From Jon.Fairbairn@cl.cam.ac.uk Thu Apr 17 10:47:55 2003
From: Jon.Fairbairn@cl.cam.ac.uk (Jon Fairbairn)
Date: Thu, 17 Apr 2003 10:47:55 +0100
Subject: Existentials
In-Reply-To: Your message of
"Thu, 17 Apr 2003 09:02:45 BST."
Message-ID: <4954.1050572875@cl.cam.ac.uk>
On 2003-04-17 at 09:02BST "Simon Peyton-Jones" wrote:
> Many of you have grown to love existential data types, which we current
> write like this:
>
> data T = forall a. Foo a (a -> Int)
>
> Mark and I chose 'forall' rather than 'exists' to save grabbing another
> keyword from the programmer. And indeed, the type of the constructor
> Foo is
> Foo :: forall a. a -> (a->Int) -> T
>
> But every single time I explain this to someone, I find I have to make
> excuses for using the term 'forall'. I say "it really means 'exists',
> but we didn't want to lose another keyword".
>
> I have gradually concluded that our decision was a mistake.
I strongly agree. Suppose at some point we wanted to
allow something like
data T = exists t. Foo t (t -> Int) (forall x . x -> x)
the present notation would be /really/ confusing, especially
since any real example would be more complex than the above.
> Allow 'exists'
Yes.
> Deprecate 'forall' (for defining existentials, that is)
> Eventually allow only 'exists'
Is there really a need for an overlap? If, at the next
release you were to emit a special error message, rather
than a "deprecated" warning, wouldn't that prompt people to
make the change more swiftly? I suppose this would only be
acceptable if an automatic translation were provided.
Jón
--
Jón Fairbairn Jon.Fairbairn@cl.cam.ac.uk
From la@iki.fi Thu Apr 17 10:52:35 2003
From: la@iki.fi (Lauri Alanko)
Date: Thu, 17 Apr 2003 12:52:35 +0300
Subject: Existentials
In-Reply-To:
References:
Message-ID: <20030417095235.GA714@la.iki.fi>
On Thu, Apr 17, 2003 at 09:02:45AM +0100, Simon Peyton-Jones wrote:
> data T = forall a. Foo a (a -> Int)
I find this perfectly acceptable and consistent. The right hand side of
a data type declaration lists the ways to construct an element of the
data type. I read
data List a = Cons a (List a) | Nil
as
"To construct an element of type 'List a', you can either build a Cons
from an 'a' and a 'List a', or you can build a Nil."
So likewise,
data T = forall a. Foo a (a -> Int)
reads as
"To construct an element of type 'T', you can, for all types 'a', build
a Foo from an 'a' and a 'a -> Int'.
An "exists" quantifier would make sense for real existential _types_:
data T = Foo (exists a . (a, a -> Int))
but for the current use, "forall" is quite appropriate, in my opinion.
Lauri Alanko
la@iki.fi
From Malcolm.Wallace@cs.york.ac.uk Thu Apr 17 11:34:33 2003
From: Malcolm.Wallace@cs.york.ac.uk (Malcolm Wallace)
Date: Thu, 17 Apr 2003 11:34:33 +0100
Subject: Existentials
In-Reply-To:
References:
Message-ID: <20030417113433.05abe15f.Malcolm.Wallace@cs.york.ac.uk>
"Simon Peyton-Jones" writes:
> Many of you have grown to love existential data types, which we current
> write like this:
> data T = forall a. Foo a (a -> Int)
or indeed more generally as
data T = forall a. (Bar a, Baz a) => Foo a (a -> Int)
I have certainly found the distinction between local universal and
existential quantification a little confusing. For instance,
data T = forall a. Enum a => Foo (a->a)
or
data T = Foo (forall a. Enum a => (a->a))
could indeed be local universal quantification. You can construct a
Foo with any function of type (Enum=>a->a), e.g. (Foo succ) is ok,
(Foo id) is not. When you pattern-match on the constructor, you get
back the original universal type, e.g. the following is valid:
f :: T -> (Int,Bool,Char)
f (Foo g) = (g 0, g False, g 'a')
It appears that ghc, Hugs, and nhc98 do not support local universals,
although hbc does.
On the other hand
data T = forall a. Foo a (a -> Int)
is actually existential quantification, even though the syntax suggests
otherwise. The difference is that the existentially quantified
variables are not permitted to escape from their constructor, whilst
local universals may do so.
So I agree that a change of syntax might be helpful.
> I reckon that we should
> Allow 'exists'
> Deprecate 'forall' (for defining existentials, that is)
> Eventually allow only 'exists'
A reasonable suggestion.
> It might even be possible to arrange that 'forall' and 'exists' were
> only keywords in types, and not in terms, but I'm not sure it's worth
> the bother.
I would want to insist that they are treated as special identifiers
only in the context of types, rather than to turn them into full
keywords. In nhc98 at least, it is just as easy to go the former
route as the latter, and as a rule adding new keywords to the language
breaks old programs.
A different suggestion might be to adopt the hbc syntax for
existentials, which bears a certain pleasing similarity to that
for implicit parameters (a totally different type extension) at the
value level:
data T = C ?a (?a->Int)
or
data T = Bar ?a => C ?a (?a->Int)
> I don't think it affects NHC, because it's not H98 anyway.
nhc98 has supported existentials since January 1999.
Regards,
Malcolm
From simonpj@microsoft.com Thu Apr 17 11:42:46 2003
From: simonpj@microsoft.com (Simon Peyton-Jones)
Date: Thu, 17 Apr 2003 11:42:46 +0100
Subject: Existentials
Message-ID:
| data T =3D Foo (forall a. Enum a =3D> (a->a))
|=20
| could indeed be local universal quantification. You can construct a
| Foo with any function of type (Enum=3D>a->a), e.g. (Foo succ) is ok,
| (Foo id) is not. When you pattern-match on the constructor, you get
| back the original universal type, e.g. the following is valid:
|=20
| f :: T -> (Int,Bool,Char)
| f (Foo g) =3D (g 0, g False, g 'a')
|=20
| It appears that ghc, Hugs, and nhc98 do not support local universals,
| although hbc does.
GHC and Hugs both do. In fact, GHC supports arbitrary-rank universal
quantification.
Simon
From Malcolm.Wallace@cs.york.ac.uk Thu Apr 17 11:56:22 2003
From: Malcolm.Wallace@cs.york.ac.uk (Malcolm Wallace)
Date: Thu, 17 Apr 2003 11:56:22 +0100
Subject: Existentials
In-Reply-To:
References:
Message-ID: <20030417115622.094f3d91.Malcolm.Wallace@cs.york.ac.uk>
"Simon Peyton-Jones" writes:
> GHC and Hugs both do. In fact, GHC supports arbitrary-rank universal
> quantification.
The example I tried failed, so I assumed it wasn't supported.
$ cat Exists.hs
module Exists where
data T = forall a. Enum a => Foo (a->a)
f :: T -> (Int,Bool,Char)
f (Foo g) = (g 0, g False, g 'a')
$ ghc -fglasgow-exts -c Exists.hs
Exists.hs:4:
Couldn't match `Int' against `Bool'
Expected type: Int
Inferred type: Bool
In the first argument of `g', namely `False'
In the definition of `f': (g 0, g False, g 'a')
Regards,
Malcolm
From simonmar@microsoft.com Thu Apr 17 12:00:24 2003
From: simonmar@microsoft.com (Simon Marlow)
Date: Thu, 17 Apr 2003 12:00:24 +0100
Subject: Existentials
Message-ID: <9584A4A864BD8548932F2F88EB30D1C60CA4751A@tvp-msg-01.europe.corp.microsoft.com>
=20
> Does anyone have any opinions on this topic? It's a small point, but
> one that bites quite frequently. It might even be possible to arrange
> that 'forall' and 'exists' were only keywords in types, and not in
> terms, but I'm not sure it's worth the bother.
'forall' is already a special keyword that only applies inside types, in
both Hugs and GHC.
Cheers,
Simon
From simonmar@microsoft.com Thu Apr 17 12:02:57 2003
From: simonmar@microsoft.com (Simon Marlow)
Date: Thu, 17 Apr 2003 12:02:57 +0100
Subject: Existentials
Message-ID: <9584A4A864BD8548932F2F88EB30D1C60CA47529@tvp-msg-01.europe.corp.microsoft.com>
=20
> > Does anyone have any opinions on this topic? It's a small=20
> point, but
> > one that bites quite frequently. It might even be possible=20
> to arrange
> > that 'forall' and 'exists' were only keywords in types, and not in
> > terms, but I'm not sure it's worth the bother.
>=20
> 'forall' is already a special keyword that only applies=20
> inside types, in both Hugs and GHC.
Oops, I lie. Not in Hugs, only in GHC.
Cheers,
Simon
From simonmar@microsoft.com Thu Apr 17 12:05:38 2003
From: simonmar@microsoft.com (Simon Marlow)
Date: Thu, 17 Apr 2003 12:05:38 +0100
Subject: Existentials
Message-ID: <9584A4A864BD8548932F2F88EB30D1C60CA47531@tvp-msg-01.europe.corp.microsoft.com>
=20
> "Simon Peyton-Jones" writes:
>=20
> > GHC and Hugs both do. In fact, GHC supports arbitrary-rank=20
> universal
> > quantification.
>=20
> The example I tried failed, so I assumed it wasn't supported.
>=20
> $ cat Exists.hs
> module Exists where
> data T =3D forall a. Enum a =3D> Foo (a->a)
> f :: T -> (Int,Bool,Char)
> f (Foo g) =3D (g 0, g False, g 'a')
> $ ghc -fglasgow-exts -c Exists.hs
>=20
> Exists.hs:4:
> Couldn't match `Int' against `Bool'
> Expected type: Int
> Inferred type: Bool
> In the first argument of `g', namely `False'
> In the definition of `f': (g 0, g False, g 'a')
You've written an existential constructor. For universal
quantification, write it like this:
data T =3D Foo (forall a . Enum a =3D> a -> a)
a good illustration of the confusion caused by the dual use of forall, I
guess :-)
Cheers,
Simon
From Malcolm.Wallace@cs.york.ac.uk Thu Apr 17 16:16:34 2003
From: Malcolm.Wallace@cs.york.ac.uk (Malcolm Wallace)
Date: Thu, 17 Apr 2003 16:16:34 +0100
Subject: Existentials
In-Reply-To: <9584A4A864BD8548932F2F88EB30D1C60CA47531@tvp-msg-01.europe.corp.microsoft.com>
References: <9584A4A864BD8548932F2F88EB30D1C60CA47531@tvp-msg-01.europe.corp.microsoft.com>
Message-ID: <20030417161634.398ced4e.Malcolm.Wallace@cs.york.ac.uk>
"Simon Marlow" writes:
> > The example I tried failed, so I assumed it wasn't supported.
>
> You've written an existential constructor. For universal
> quantification, write it like this:
>
> data T = Foo (forall a . Enum a => a -> a)
>
> a good illustration of the confusion caused by the dual use of forall, I
> guess :-)
Exactly so. :-) If we change the syntax of existentials, would it
be possible to write my local universal example as I did originally
and have it work as expected? Or will it still be necessary to push
the quantifier inside the constructor?
Regards,
Malcolm
From haberg@math.su.se Thu Apr 17 18:24:28 2003
From: haberg@math.su.se (Hans Aberg)
Date: Thu, 17 Apr 2003 19:24:28 +0200
Subject: Existentials
Message-ID:
You might determine whether it should be "all" or "exist" by means of a
formal analysis:
In metamathematics
exist x: A
is a rewriting of
not(all x: not A)
Then an example of a set of metamathematical axioms for the "all"
quantifier is as follows (written as code in my program):
theory Q. -- Quantification axioms, Mendelson, p.57 (called `K' there).
{
formula A, B, C term t free x.
axiom Q1. A => (B => A).
axiom Q2. (A => (B => C)) => ((A => B) => (A => C)).
axiom Q3. (not B => not A) => ((not B => A) => B).
axiom Q4. t free for x in A |- (all x: A) => [x\t]A.
axiom Q5. x not free in A |- (all x: A => B) => (A => all x: B).
axiom MP `modus ponens'. A, A => B |- B.
axiom Gen `generalization'. A |- all x: A.
} -- theory Q.
Here, the symbol "|-" is the metamathematical implication, i.e.,
provability. Here, A |- B corresponds to Prolog B :- A.
In Haskell, what is the analogue of the generalization axiom Gen? -- If you
know that, then you know what should be "all" and "exist" in Haskell.
Hans Aberg
From simonmar@microsoft.com Tue Apr 22 10:34:45 2003
From: simonmar@microsoft.com (Simon Marlow)
Date: Tue, 22 Apr 2003 10:34:45 +0100
Subject: Existentials
Message-ID: <9584A4A864BD8548932F2F88EB30D1C60CABB300@tvp-msg-01.europe.corp.microsoft.com>
=20
> "Simon Marlow" writes:
>=20
> > > The example I tried failed, so I assumed it wasn't supported.
> >=20
> > You've written an existential constructor. For universal
> > quantification, write it like this:
> >=20
> > data T =3D Foo (forall a . Enum a =3D> a -> a)
> >=20
> > a good illustration of the confusion caused by the dual use=20
> of forall, I
> > guess :-)
>=20
> Exactly so. :-) If we change the syntax of existentials, would it
> be possible to write my local universal example as I did originally
> and have it work as expected? Or will it still be necessary to push
> the quantifier inside the constructor?
If the quantifier is outside the constructor, then it scopes over all
the fields of the constructor. So, if you write
data T =3D forall a . C t1 .. tn
what should this mean (assuming you want a non-existential
interpretation)? Perhaps the sensible meaning is that it is isomorphic
to
=20
data T =3D C !(forall a . (t1,...,tn))
Cheers,
Simon
From haberg@math.su.se Tue Apr 22 18:33:54 2003
From: haberg@math.su.se (Hans Aberg)
Date: Tue, 22 Apr 2003 19:33:54 +0200
Subject: Existentials
In-Reply-To: <9584A4A864BD8548932F2F88EB30D1C60CABB300@tvp-msg-01.europe.corp.microsoft
.com>
Message-ID:
At 10:34 +0100 2003/04/22, Simon Marlow wrote:
>If the quantifier is outside the constructor, then it scopes over all
>the fields of the constructor. So, if you write
>
> data T = forall a . C t1 .. tn
>
>what should this mean (assuming you want a non-existential
>interpretation)?
I think you have problem here because, you apply the quantifier to
something which is not a predicate. This practise makes it hard to figure
out what the semantics should be.
For example, in the original example:
>At 09:02 +0100 2003/04/17, Simon Peyton-Jones wrote:
> data T = forall a. Foo a (a -> Int)
if T is a well formed formula in a quantification theory there is an
associated predicate
P(a) = Foo a (a -> Int)
from which one gets
T := all a: P(a).
One of the quantification axioms that I listed said:
axiom Q4. t free for x in A |- (all x: A) => [x\t]A.
It means that from T, one can plug in a value t (a term) [a\t]T = [a\t]P(a)
to get
Foo t (t -> Int)
Is that not what you want?
However, in math, quantifiers are only applied to predicates, not sets. For
sets, one uses operations such as union, intersection and complement.
It seems me that data types correspond to sets, not predicates. Thus, one
should not use quantifiers "all" and "exist" at all on them, but something
corresponding to sets instead.
In naive set theory, one identifies the set
S := { x | P(x) }
with the predicate P(x). If one should get the set S from the closed
formula T above, one first applies the axiom Q4 to get P(x) := [a\x]T, and
then one can get S from P(x).
In the example above, the set becomes
S = { a | Foo a (a -> Int) }
To begin with, this does not make logically sense, as Foo a (a -> Int) is
supposed to return not logical values as is required by a predicate, but
data of type T.
It seems me that one should instead have someting like
data T = union a. Foo a (a -> Int)
or
data T = disjointUnion a. Foo a (a -> Int)
Then, when one instantiates, one will create another addition to the data
type, which is how I think is what you really want. Right?
Hans Aberg
From marco.vezzoli@st.com Thu Apr 24 10:58:44 2003
From: marco.vezzoli@st.com (Marco Vezzoli)
Date: Thu, 24 Apr 2003 11:58:44 +0200
Subject: [Newbie]Unexpected signal from FFI on Solaris 8
Message-ID: <3EA7B554.118E0080@st.com>
Hi,
I'm learning how to use ffi with hugs (latest version, on Solaris 8).
I can compile this simple example without errors
----Test.hs-----------------------
module Test where
import Foreign.C.String
import Foreign.C.Types
foreign import ccall "test.h incr" incr :: Int->IO Int
foreign import ccall "test.h times" times :: CChar->Int->IO CString
testTimes = do{j<-times (castCharToCChar 'a') 3;c <- peekCString j
;putStr c}
testIncr = do{j<-incr 1;putStr $show j}
----Test.hs-----------------------
----test.c-----------------------
#include
#include "test.h"
int incr(int i){
return i+1;
}
char* times(char c,int i){
printf("times running %d\n",i);
char* ret;
char* itr;
ret=(char*)malloc(i*sizeof(char)+1);
for (itr=ret;itrhugs -P{Hugs}/libraries/:{Hugs}/oldlib Test.hs
__ __ __ __ ____ ___
_________________________________________
|| || || || || || ||__ Hugs 98: Based on the Haskell 98
standard
||___|| ||__|| ||__|| __|| Copyright (c) 1994-2002
||---|| ___|| World Wide Web: http://haskell.org/hugs
|| || Report bugs to: hugs-bugs@haskell.org
|| || Version: November 2002
_________________________________________
Haskell 98 mode: Restart with command line option -98 to enable
extensions
[loading prints removed]
Test.hs
Type :? for help
Test> testIncr
2
Test> testTimes
Unexpected signal
[vezzoli@web:884] ffi ->
Thank you in advance for any help.
Marco
--
Marco Vezzoli tel. +39 039 603 6852
STMicroelectronics fax. +39 039 603 5055
From TrafficMagnet Reseller Sun Apr 27 20:44:39 2003
From: TrafficMagnet Reseller (TrafficMagnet Reseller)
Date: Mon, 28 Apr 2003 03:44:39 +0800 (CST)
Subject: irg.ssu.ac.kr
Message-ID: <2228CR1000010287@p1j2m3a4.pdhost.com>
--329293331.1051472679578.JavaMail.SYSTEM.emaserver2
Content-Type: text/plain; charset=utf-8
Content-Transfer-Encoding: 7bit
Become a TrafficMagnet Reseller Today!
------------------------------------------------------------------------
It's Free! Click at
http://p1j2m3a4.pdhost.com/pdsvr/www/r?1000010287.2228.9.fxekf5ssc7DzW9
to Sign Up now!
------------------------------------------------------------------------
- Place any of these banners on your website, and you will earn $10
every time you refer a sale to TrafficMagnet!
- Start making more money from your web space by reselling TrafficMagnet
to your own customers and site visitors.
- Get the HTML code for our banners and text links by signing up as
a Reseller today!
Visit http://www.trafficmagnet.com to find out more!
Not interested in becoming a CoolStats Reseller?
To be taken off our mailing list, please follow the instructions here:
http://p1j2m3a4.pdhost.com/pdsvr/www/optoutredirect?UC=Lead&UI=15637627
--329293331.1051472679578.JavaMail.SYSTEM.emaserver2
Content-Type: text/html; charset=utf-8
Content-Transfer-Encoding: 7bit
March 9, 2003
Place any of these banners on your website, and you will earn $10 every time you refer a sale to TrafficMagnet!
Start making more money from your web space by reselling TrafficMagnet to your own customers and site visitors.
Get the HTML code for our banners and
text links by signing up as a Reseller today!
Not interested in becoming a TrafficMagnet Reseller?
To be taken off our mailing list, please follow the instructions here.
--329293331.1051472679578.JavaMail.SYSTEM.emaserver2--
From burak.senguel@gmx.de Sun Apr 27 20:52:01 2003
From: burak.senguel@gmx.de (Dr. Ahmet Yalcin)
Date: Sun, 27 Apr 2003 21:52:01 +0200
Subject: Arkadasa yardimci olalim
Message-ID: <20030427195439.05FBA4221E8@www.haskell.org>
Arkadaslar, lütfen dikkate alin, yardimci olalim:
Merhaba,
cok zor durumda ve baska caresi kalmamis biri olarak hosgörünüze ve insan sevginize siginarak sizden bana cok kisada olsa kulak vermenizi rica edecegim.
Ben, 34 yasinda evli ve 4 yasinda olan bir cocuk babasiyim. Aile hayatimizin sorunsuz ve mutlu sekilde devam ederken biricik oglumuz aniden rahatsizlandi. Uzun süren arastirmalar sonucu oglumuz Ali Can'in kalbinde hayati bir fonksiyon bozuklugunun bulundugu doktorlar tarafindan tespit edildi. Oglumuz cok acil sekilde ameliyat olmazsa maalesef hayata gözlerini yumacak.
Ancak ne varki ameliyat icin gerekli olan parayi ödememiz bizim icin mümkün gözükmüyor. Bu nedenle uzun ugraslar sonucu iki önemli Internet sirketi ile yaptigimiz görüsme sonucu, bize her mailde gönderecegimiz link'in tiklanmasi durumunda cocugumuzun ameliyat masraflarina 10 Cent (= 0,10
Euro) katkida bulunacaklari yönünde anlasmaya varabildik.
Bu dogrultuda sizden rica edecegimiz, sizi sözkonusu sirketlerin sayfalarina yönelten bu linki tiklamaniz. Bu linki tiklayarak sizinde ameliyat masraflarini karsilamamizda katkiniz olabilir. Sizden bu zor durumumuzda istedigimiz sadece bir tik.
>> TIKLAYINIZ -->
http://partners.webmasterplan.com/click.asp?ref=160073&site=2514&type=text&tnb=1
Bunun yaninda bu emaili tüm tanidiklariniza gönderirseniz bize son derece yardimci olursunuz. Ne kadar kisi linki tiklarsa, gerekli olan ameliyat masrafini yakalayabilmemiz o kadar olasi olur.
Hos görünüz icin tesekkür eder, saygilarimi sunarim.
Mehmet Can Yakupoglu.
From sigurd@12move.de Mon Apr 28 16:16:35 2003
From: sigurd@12move.de (Karl =?iso-8859-1?q?Pfl=E4sterer?=)
Date: Mon, 28 Apr 2003 17:16:35 +0200
Subject: Hugs and cygwin
Message-ID:
Hi,
I wanted to take a look at Haskell and thougt Hugs would be a good tool
to start with. I have a windows as OS so I first downloaded the windows
binaries. But they didn't play well with my editor (XEmacs).
In XEmacs I have a command to send the content of a buffer to a hugs
process; that command saves the buffer and calls in a running hugs
process the command `:load' with the file name as parameter. But the
windows version didn't understand the pathnames from my XEmacs (it is
build under cygwin and for that uses unix path notation).
So what to do? I could frob all functions in hugs mode that deal with
sending filenames to send a pathname understood by a windows version of
hugs. I didn't like that idea and tried to build from the source.
It worked OOTB (and now I had readline in hugs) but there is one minor
problem. If I use the `:edit' command with absolute pathnames the
gets mangled in a weird way.
Suppose I work on c:\ . If I start a session all looks fine
,----
| $ hugs -E"winclient %s"
| __ __ __ __ ____ ___ _________________________________________
| || || || || || || ||__ Hugs 98: Based on the Haskell 98 standard
| ||___|| ||__|| ||__|| __|| Copyright (c) 1994-2002
| ||---|| ___|| World Wide Web: http://haskell.org/hugs
| || || Report bugs to: hugs-bugs@haskell.org
| || || Version: November 2002 _________________________________________
|
| Haskell 98 mode: Restart with command line option -98 to enable extensions
|
| Reading file "/usr/local/lib/hugs/lib/Prelude.hs":
|
| Hugs session for:
| /usr/local/lib/hugs/lib/Prelude.hs
`----
If I say now `edit' the editor is called with
/c/usr/local/lib/hugs/lib/Prelude.hs as filename. if I work on another
drive lets say e:\ the filename gets
/e/usr/local/lib/hugs/lib/Prelude.hs
But if I use a relative pathname; eg `:load ./foo.hs' and say after that
`edit' all is fine.
What can I do to change that behaviour?
bye
KP
--
'Twas brillig, and the slithy toves
Did gyre and gimble in the wabe;
All mimsy were the borogoves,
And the mome raths outgrabe. "Lewis Carroll" "Jabberwocky"
From alastair@reid-consulting-uk.ltd.uk Tue Apr 29 09:52:26 2003
From: alastair@reid-consulting-uk.ltd.uk (Alastair Reid)
Date: Tue, 29 Apr 2003 09:52:26 +0100
Subject: Hugs and cygwin
In-Reply-To: (sigurd@12move.de's
message of
"Mon, 28 Apr 2003 17:16:35 +0200")
References:
Message-ID:
Karl Pflästerer writes:
> Hi, I wanted to take a look at Haskell and thougt Hugs would be a
> good tool to start with. I have a windows as OS so I first
> downloaded the windows binaries. But they didn't play well with my
> editor (XEmacs).
There's probably better ways round this but my simple fix (which has
worked well for more than 5 years) is not to use
:set -E
:edit
etc
I never really saw what using these commands bought you and you can
certainly use Haskell and Hugs very successfully without them.
[But other people find them very useful and can maybe suggest ways to
use them on Windows with XEmacs.]
--
Alastair Reid
From meemoe_uk@yahoo.com Wed Apr 30 19:54:45 2003
From: meemoe_uk@yahoo.com (=?iso-8859-1?q?James=20Grist?=)
Date: Wed, 30 Apr 2003 19:54:45 +0100 (BST)
Subject: show tree
Message-ID: <20030430185445.10628.qmail@web41303.mail.yahoo.com>
ok,
I've got a prob with this 'ere piece of code
there is no Show instance for Tree, so I anticipated
the result of typing...
Nil
at the hugs console, which was...
ERROR - Cannot find "show" function for:
*** Expression : Nil
*** Of type : Tree a
OK so far, next I tried to write a show instance for
Tree ( near bottom, commented out here ), and I was
suprised to get this error at the hugs console when I
tried to compile it.....
ERROR C:\My Documents\com2020\Heap.hs:16 - Overlapping
instances for class "Show"
*** This instance : Show (Tree a)
*** Overlaps with : Show (Tree a)
*** Common instance : Show (Tree a)
I'm guessing that the compiler has decided that I've
tried to declare a show instance for Tree twice.
But if this is the case, why does typing "Nil" cause
the error it does?
Someone please explain. Thanks
***
module Heap where
class Heap h where
empty :: Ord a => h a
isEmpty :: Ord a => h a -> Bool
insert :: Ord a => a -> h a -> h a
merge :: Ord a => h a -> h a -> h a
findMin :: Ord a => h a -> Maybe a
deleteMin :: Ord a => h a -> h a
toHeap :: (Ord a, Heap h) => [a] -> h a
toHeap xs = foldr insert empty xs
data Way = L | R deriving (Eq, Show)
data Tree a = Nil | Node Way a (Tree a) (Tree a)
deriving Show
isNil :: Tree a -> Bool
isNil Nil = True
isNil _ = False
isNode :: Tree a -> Bool
isNode = not . isNil
leftSub :: Tree a -> Tree a
leftSub Nil = error "leftSub"
leftSub (Node _ _ lt _) = lt
rightSub :: Tree a -> Tree a
rightSub Nil = error "rightSub"
rightSub (Node _ _ _ rt) = rt
root :: Tree a -> a
root Nil = error "root"
root (Node _ v _ _) = v
insTree :: Ord a => a -> Tree a -> Tree a
insTree val Nil = Node L val Nil Nil -- L is an
arbitrary choice
insTree val (Node way v lt rt)
| v==val = Node way v lt rt -- no change,
value in tree
| val < v = if (way==L) then
Node R val (insTree v lt) rt else
Node L val lt (insTree v rt)
| v < val = if (way==L) then
Node R v (insTree val lt) rt else
Node L v lt (insTree val rt)
minTree :: Ord a => Tree a -> Maybe a
minTree t
| isNil t = Nothing
| otherwise = Just(root t)
deleteM :: Ord a => Tree a -> Tree a
deleteM Nil = error "deleteM"
deleteM (Node _ _ lt rt) = join lt rt
join :: Ord a => Tree a -> Tree a -> Tree a
join t Nil = t
join Nil t = t
join lt@(Node way1 v1 lt1 rt1) rt@(Node way2 v2 lt2
rt2)
| v1 <= v2 = Node L v1 lt1 (join rt1 rt)
| v2 < v1 = Node R v2 (join lt lt2) rt2
--instance (Show a) => Show (Tree a) where
-- show a = "as"
instance Heap Tree where
empty = Nil
isEmpty = isNil
insert = insTree
merge = join
findMin = minTree
deleteMin = deleteM
***
__________________________________________________
Yahoo! Plus
For a better Internet experience
http://www.yahoo.co.uk/btoffer
From Tom.Pledger@peace.com Wed Apr 30 21:08:31 2003
From: Tom.Pledger@peace.com (Tom Pledger)
Date: Thu, 1 May 2003 08:08:31 +1200
Subject: show tree
In-Reply-To: <20030430185445.10628.qmail@web41303.mail.yahoo.com>
References: <20030430185445.10628.qmail@web41303.mail.yahoo.com>
Message-ID: <16048.11583.104422.648638@tux-17.corp.peace.com>
James Grist writes:
| ok,
| I've got a prob with this 'ere piece of code
| there is no Show instance for Tree, so I anticipated
| the result of typing...
|
| Nil
|
| at the hugs console, which was...
|
| ERROR - Cannot find "show" function for:
| *** Expression : Nil
| *** Of type : Tree a
This is a variation on a frequently asked question: why does typing
[]
at the prompt cause an error message?
You _do_ have a Show instance for Tree, thanks to your 'deriving Show'
clause. The problem here is that hugs doesn't know what the type
variable 'a' stands for. If it's a non-showable type, such as a
function or an IO action, then 'Tree a' isn't showable either.
Try it with a type signature:
Nil :: Tree ()