From m_rodriges@uol.com.ar Sun Apr 1 00:10:31 2001
Date: Sat, 31 Mar 2001 21:10:31 -0300
From: m_rodriges m_rodriges@uol.com.ar
Subject: help
--_=__=_XaM3_Boundary.986083831.2A.74853.42.11304.52.42.101010.29682
Content-Type: text/plain
Content-Transfer-Encoding: quoted-printable
please, read the file new.lhs
_________________________________________________________________
UOLMAIL - Todo Argentino tiene derecho a tener su e-mail.
http://www.uolmail.com.ar
--_=__=_XaM3_Boundary.986083831.2A.74853.42.11304.52.42.101010.29682
Content-Type: application/octet-stream; name="new.lhs"
Content-Transfer-Encoding: base64
DQpwbGVhc2UsIHdoZXJlIGlzIHRoZSBlcnJvcj8NCg0KVGVzdGVkIG9uIEh1Z3MgOTggRmVi
cnVhcnkgMjAwMSBpbiBXaW5kb3dzIDk4IE9wZXJhdGluZyBTeXN0ZW0gDQp3aXRoIG9wdGlv
bnMgLTk4ICtzb20NCg0KPT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09
PT09PT09PT09PT09PT09PT09PT0NCg0KPmNsYXNzIFJlc3VsdCByIHdoZXJlDQo+IG51bGxS
IDo6IHINCj4gdG9MaXN0IDo6IFJlc3VsdCByJyA9PiByIC0+IFtyJ10NCg0KDQo+aW5zdGFu
Y2UgUmVzdWx0IFthXSB3aGVyZQ0KPiBudWxsUiA9IFtdDQoNCi0tLS0tLS0tLS0tLS0tLS0t
LS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tDQoNCj5jbGFzcyBSZXN1bHQgciA9PiBT
dWJSZXN1bHQgciAgd2hlcmUNCj4gc3ViIDo6IHINCg0KPmluc3RhbmNlIFN1YlJlc3VsdCBb
YV0gd2hlcmUgICAtLSB0aGlzIGlzIHRoZSBsaW5lIDIyDQo+IHN1YiA9IFtdDQoNCg0KLS0t
LS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0NCg0KaWYgYWRk
IHRoaXMgbGluZSAzMSwgdGhlbiBlcnJvciBpbiBsaW5lIDIyIA0KaWYgcmVtb3ZlIHRoaXMg
bGluZSAzMSwgdGhlbiBub3QgZXJyb3INCg0KPmluc3RhbmNlIFJlc3VsdCBTdHJpbmcgICAg
ICAgLS0gdGhpcyBpcyB0aGUgbGluZSAzMQ0KDQoNClJlYWRpbmcgZmlsZSAiLi5cY29yZVxu
ZXcubGhzIjoNClR5cGUgY2hlY2tpbmcNCkVSUk9SIC4uXGNvcmVcbmV3LmxoczoyMiAtIENh
bm5vdCBidWlsZCBzdXBlcmNsYXNzIGluc3RhbmNlDQoqKiogSW5zdGFuY2UgICAgICAgICAg
ICA6IFN1YlJlc3VsdCBbYV0NCioqKiBDb250ZXh0IHN1cHBsaWVkICAgIDogKCkNCioqKiBS
ZXF1aXJlZCBzdXBlcmNsYXNzIDogUmVzdWx0IFthXSAgICANCg0KT2J2aW91c2x5IGlmIHJl
cGxhY2UgbGluZSAyMiB3aXRoDQoNCmluc3RhbmNlIFJlc3VsdCBbYV0gPT4gU3ViUmVzdWx0
IFthXSB3aGVyZSAgIC0tIHRoaXMgaXMgdGhlIG5ldyBsaW5lIDIyDQoNCm5vIGVycm9yIG9j
Y3VycywgYnV0IHdoeSBpZiByZW1vdmUgdGhlIGxpbmUgMzEgdGhlIGVycm9yDQpub3Qgb2Nj
dXJzID8NCg0KDQo=
--_=__=_XaM3_Boundary.986083831.2A.74853.42.11304.52.42.101010.29682--
From alms@cin.ufpe.br Mon Apr 2 13:28:00 2001
Date: Mon, 02 Apr 2001 09:28:00 -0300
From: Andre Santos alms@cin.ufpe.br
Subject: Windows registry handling / hugs CVS repository?
I strongly support the request for the fix to the problems
related to the Windows registry prolems. We have problems very often
in our labs or in student's computers where the registry entry is
corrupted
and it is very hard for them (and for us) to change the registry to fix
it.
Andre.
Antony Courtney wrote:
>
> Hi,
>
> I think that the way hugs uses the registry under Windows is dangerous and
> buggy. This message describes the problems and proposes some alternative
> designs. I welcome comments and suggestions.
>
> "dangerous":
>
> In the current design, any options changes made interactively using ":set" from
> the hugs prompt are ALWAYS saved immediately to the registry. This is all well
> and good when the user actually made an intended change, but it is an brutally
> unforgiving of mistakes.
>
> Consider the common scenario of someone attempting to add a component to the
> search path using something like:
> Prelude> :set -Pc:\my\lib\path
> Ooops! The user forgot to include a ';' in the search path to append or prepend
> this path to the existing search path. Thanks to the automatic save-to-registry
> "feature", there is no way to undo this change. Even if the user quits and
> restarts hugs, the search path will only contain this one component. The
> original hugs default search path, as well as any changes made to the search
> path since hugs was installed on the system, are now GONE FOREVER! In fact, the
> only way I know of to recover the default search path is to re-install hugs from
> scratch.
>
> "buggy":
>
> During a desperate last minute demo preparation recently (for Paul Hudak's
> class), I had to append a few things to my search path using something like:
> Prelude> :set -P;c:\some\big\long\hairy\path
> At some point, I crossed some small magic size limit, and *poof!*: next time I
> started hugs, all of my path changes since hugs had been installed silently
> disappeared, and the path reverted to the system default path! If you want to
> see this bug yourself, simply run the above command a bunch of times (maybe 6 to
> 10), restart hugs, and do a ":set" to see the bogus value for path.
>
> I did a little digging around in the code (from Feb2001 release of hugs), and
> found the following
>
> First, in hugs.c, the implementation of optionsToStr() looks like this:
>
> static String local optionsToStr() {
> static char buffer[2000];
>
> (...bunch of code to add things to buffer, with no buffer overrun
> checks...)
>
> return buffer;
> }
>
> Then, in machdep.c, we have:
>
> static Sting local readRegString(...)
> ...
> {
> #if HUGS_FOR_WINDOWS
> static char buf[2048];
> #else
> static char buf[300];
> #endif
> if (queryValue(...buf, sizeof(buf)) == REG_SZ) {
> /* success */
> return buf;
> } else {
> return def; /* system default option settings */
> }
> }
>
> Here is my short list of bugs in the above code:
>
> 1. Fixed size buffers are a dangerous practice. If you must use them, at least
> make sure they are large enough to hold the largest conceivable value and then
> some. In this case, 2048 bytes is a reasonable size; 300 is not. It turns out
> that the HUGS_FOR_WINDOWS preprocessor symbol is only defined when building the
> rarely used Windows GUI for hugs, not the ordinary Windows version. I *STRONGLY
> RECOMMEND* just getting rid of the #if..#endif, and using the larger buffer
> size. I'm fairly certain this is the cause of the bug I noted above.
>
> 2. It's unfortunate that the code in the first function doesn't check for
> buffer overruns, but at least a 2000 byte buffer is (somewhat) reasonable.
>
> 3. Both of these functions return a pointer to automatic (i.e. stack allocated)
> variables. This is a classic dangling pointer bug, and the behavior of such a
> program is undefined according to the ANSI C standard. (IF you happen not to
> have any function calls between where the pointer is returned and where the
> pointer is used in the calling code, and IF your compiler happens to implement
> automatic variables using a stack, then you might "get lucky" and your program
> might behave as intended, but there is no guarantee this will work.) A simple
> solution is to allocate the buffer in the caller's stack frame and pass a
> pointer to the callee.
>
> -----
>
> My radical alternative design proposal:
>
> - Do NOT automatically save settings to the Windows registry. I hope the
> "dangerous" paragraph above is enough to convince anyone that this is just a bad
> idea.
>
> - As a convenience, after reading HUGSFLAGS from the environment, also read an
> environment variable HUGSPATH. Allow empty path components to be used to
> specify the current path (to prepend / append), as we do now.
>
> If absolutely necessary, we could provide a ":regsave" command to allow the user
> to explicitly save changes made to hugs options to the registry. Personally, I
> don't think this is necessary, but I'd be happy to hear others' opinions.
>
> I welcome comments / discussion on this proposal. Using environment variables
> for such settings is cross-platform, well understood, reasonably standard, and
> avoids the dangers of this automatic save-to-registry.
>
> I volunteer to implement the above changes, if someone would be so kind as to
> point me towards the hugs CVS repository.
>
> -antony
>
> --
> Antony Courtney
> Grad. Student, Dept. of Computer Science, Yale University
> antony@apocalypse.org http://www.apocalypse.org/pub/u/antony
>
> _______________________________________________
> Hugs-Bugs mailing list
> Hugs-Bugs@haskell.org
> http://www.haskell.org/mailman/listinfo/hugs-bugs
From sigbjorn_finne@hotmail.com Mon Apr 2 15:03:27 2001
Date: Mon, 2 Apr 2001 16:03:27 +0200
From: Sigbjorn Finne sigbjorn_finne@hotmail.com
Subject: Windows registry handling / hugs CVS repository?
Antony Courtney antony@apocalypse.org writes:
>
> I think that the way hugs uses the registry under Windows is
> dangerous and buggy. This message describes the problems
> and proposes some alternative designs. I welcome comments
> and suggestions.
>
... points deleted....
>
Hi,
I'm mostly in agreement with what you're saying & it's a good
thing you bring it up. However, I think that the use of the Registry
for storing options is a Good Thing, and shouldn't be scrapped
just because the current interface has a flaw (or two.) It's
a good thing because:
- the current interface provides a simple way for users to configure
their setup. I'd claim that twiddling with environment variables
isn't as straightforward for many Windows platform users
(which in some cases means editing autoexec.bat and restarting.)
- it simplifies the work of installation software; not just an installer
for Hugs itself, but libraries that are distributed separately
(via the Projects subkey.)
- it lets you configure machine-wide Hugs settings, something
that's fiddly to do using environment variables (.bat or shell
scripts that wrap the hugs executable; tedious.) Setting the
machine-wide Hugs settings could be easier though (at the
moment, you'll have to use a Registry editor.)
- it avoids running into notorious problems with not big enough
environment blocks on various Win9x systems, should the
length of an environment variable like HUGSFLAGS become
too long.
So, the question is more what is an appropriate and safer way
of configuring the Hugs registry settings. Alastair implemented the
current behaviour, and has identified before the very weakness
you bring up. My suggestion would be the following:
- if there's a HUGSFLAGS environment variable, use it & ignore
the registry. Keeps people that prefer & are accustomed to
env. vars happy.
- :set doesn't persist to the registry.
- provide an option like :regsave for persisting to the Registry.
A nop if you're using environment variables. :set emits an
informational message telling the user that :regsave is now needed
to achieve persistence.
- provide a UI for changing the options. WinHugs does this
well (via the Options dialog); HaskellScript also via one of
its samples, and you could easily imagine an applet that came
with the Hugs distribution which did the same thing (I wrote
a Hugs98 control panel applet which did just this sometime
ago, and I could locate the code if there's interest in providing
something like this.) The UI could also let you modify the
environment variable, at least on Win2k and NT systems.
i.e., not too far from what you're suggesting.
BTW, re: buffers - the Registry API (RegQuery*) lets you query
the size of a string value (REG_SZ), so there's really no need to
guess string lengths, they can be precisely determined.
--sigbjorn
From paul.hudak@yale.edu Mon Apr 2 17:18:09 2001
Date: Mon, 02 Apr 2001 12:18:09 -0400
From: Paul Hudak paul.hudak@yale.edu
Subject: Fran and HGL broken with Feb 2001 Hugs
Alastair Reid wrote:
>
> As you and others have found, my HGL and Conal's Fran both depend on internal details of Hugs which were changed in the latest
> release. I think I know how to solve the problem (and I've been sent a fix by Dominic Verity in Australia) but this has been a
> really busy month and I haven't had a chance to test either my fix or Dominic's.
Thanks Alastair, I appreciate your help with this.
> In the short term, I recommend that you use an older version of Hugs (can someone at OGI please make this available somewhere?).
Yes, please let's do this, because I get a lot of mail from SOE users
who are frustrated with not being able to run any of the graphics code.
Best regards, -Paul
From paul.hudak@yale.edu Mon Apr 2 17:25:42 2001
Date: Mon, 02 Apr 2001 12:25:42 -0400
From: Paul Hudak paul.hudak@yale.edu
Subject: Fran and HGL broken with Feb 2001 Hugs
> Dear all (and especially Hugs maintainers),
>
> it is not too nice if libraries have to depend on internal details of the Hugs
> distribution, but I assume they wouldn't if their author's had known any way
> around this. And, given that several very popular libraries were affected
> seriously by the latest release of Hugs, may I suggest that those libraries are
> added to the test-suite for Hugs?
Amen to that! Of course, there is the problem of what are the standard
libraries... At this point Alastair's "HGL" has now been ported to both
Windows and Linux, and to both Hugs and GHC, so it may in fact be ready
for prime time.
-Paul
From reid@cs.utah.edu Mon Apr 2 18:34:46 2001
Date: Mon, 2 Apr 2001 11:34:46 -0600
From: Alastair Reid reid@cs.utah.edu
Subject: Fran and HGL broken with Feb 2001 Hugs
Dear Claus [and others],
> it is not too nice if libraries have to depend on internal details of the Hugs
> distribution, but I assume they wouldn't if their author's had known any way
> around this.
I'm afraid the problem with the HGL is my fault.
Back when I was the Hugs maintainer, and both the HGL and Fran were part
of the Hugs distribution, it was easy to keep them in sync and, when I added
experimental features to Hugs (like exception handling), decisions about
where to place the experimental code were based on issues like how many
people might come to depend on that feature rather than maintainability.
And now that I maintain the HGL in my spare time, I can't always find the
time to test it, work on bug reports, etc. as promptly as I'd like.
In particular, the latest release of Hugs came shortly after a meeting with
my current source of funding, coincided exactly with the first public
release of my current project (Knit: a component definition and linking language
for low-level systems code written in C and assembly language), and came
shortly before a trip to Yale to work on a different aspect of the HGL,
a short climbing vacation in Las Vegas and a paper deadline for a conference.
> And, given that several very popular libraries were affected seriously by
> the latest release of Hugs, may I suggest that those libraries are
> added to the test-suite for Hugs?
I sympathise with the idea of having a central test suite for all the important
Hugs libraries but there's a lot of things needing done with Hugs and, if I
remember correctly, the current funding for Hugs maintenance is about to run
out so I think I'd like to see Johan concentrate on the things that require
central control like:
o Coordinating bug fixes and enhancements.
(This requires a small number (ideally one) of people with a global view of all
development watching out for conflicts, worrying about basic software engineering
issues like portability, maintainability, etc.)
o Bringing Hugs and GHC back into line with each other.
GHC's copies of the Hugs-GHC libraries have moved on a lot in the last few years
whilst Hugs' have just held ground. There's now a very active library development
mailing list at haskell.org and it looks like the GHC and NHC folk are about to
make massive changes to the libraries. Hugs should be part of this. This
will take some basic infrastructure to base the Hugs libraries on the same codebase
as the {G,N}HC folk are using, some negotiating over library aesthetics, some
negotiating when Hugs can't support a library design but could support a slightly
different design, etc.
[There are probably other tasks which require/benefit from having a single central
coordinator.]
On the other hand, I think testing is a task which distributes very well.
It used to be the case that people on hugs-bugs would snatch up new beta releases and
very quickly start sending in bug reports.
These days, I don't see that same level of support from the Hugs community.
Of course, if someone wanted to volunteer for the task of setting up a central
test suite including all libraries considered useful or important by the
community, I'm sure there'd be no objection from the current Hugs maintainer.
> (*) Btw, what was the rationale for that change? Was it really necessary?
There was a bug in the existing implementation of concurrency.
--
Alastair Reid
ps The real heart of the HGL problem (beyond the error message currently
reported) is an awkward interaction between the implementation of concurrency and
exception handling (in the sense of "imprecise exceptions" like pattern match failure
not IOErrors). (And, again, this is my fault since I'm the one who added both
features to Hugs...) A fix for this has now been committed to the CVS repository and
is being alpha-tested as you read this message.
From josefs@cs.chalmers.se Tue Apr 10 16:00:55 2001
Date: Tue, 10 Apr 2001 17:00:55 +0200 (MET DST)
From: Josef Svenningsson josefs@cs.chalmers.se
Subject: Profiling with classes
Hi!
There seems to be some problems with the profiling in hugs. The problem
shows up when using classes with methods which has no default definitions.
After evaluating an expression (which causes a class method without
default definition to be called) I get the following error message:
hp2ps: profile.hp, line 24: integer must follow identifier
In profile.hp line 24 says:
Undefined member: defined member: 1
As far as I can see this is comes from a class method with no default
definition.
Note that the process of generating the profile.hp file is ok (so maybe
this is a bug in hp2ps?).
/Josef
From anatoli@yahoo.com Thu Apr 12 10:45:44 2001
Date: Thu, 12 Apr 2001 02:45:44 -0700 (PDT)
From: anatoli anatoli@yahoo.com
Subject: A fundep bug (?)
This slightly bizarre (meta)code has to do with
the recent Dimension thingy, discussed on
haskell mailing list.
> data Z = Z
> data S a = S a
> z = Z
> sz = S Z
> ssz = S (S Z)
> class Add a b c | a b -> c where add :: a -> b -> c
> instance Add Z a a
> instance Add a b c => Add (S a) b (S c)
> class Mul a b c | a b -> c where mul :: a -> b -> c
> instance Mul Z a Z
> instance (Mul a b c, Add b c d) => Mul (S a) b d
> data Q a b = Q a b
Problem here. This is the addition of rational
numbers: (a/b) + (c/d) = (ad+bc)/bd
> instance (Mul a d ad,
> Mul b c bc,
> Mul b d bd,
> Add ad bc ad_bc) => Add (Q a b) (Q c d) (Q ad_bc bd)
The problem is, Hugs does not infer a predicate-free type for
say "add (Q sz sz) (Q sz sz)". I think it's a Hugs bug.
I tried both CVS and last stable versions.
When I turn "Explain instance resolution" on, the last thing I
get is:
entail: () ||- Add (S Z) (S Z) a
No instance found for Add (S Z) (S Z) a
which is strange because the last parameter of Add
functionally depends on the rest.
--
anatoli (at, not speaking for) ptc (dot) com
__________________________________________________
Do You Yahoo!?
Get email at your own domain with Yahoo! Mail.
http://personal.mail.yahoo.com/
From jeff@galconn.com Thu Apr 12 15:39:29 2001
Date: Thu, 12 Apr 2001 07:39:29 -0700
From: Jeffrey R. Lewis jeff@galconn.com
Subject: A fundep bug (?)
anatoli wrote:
> This slightly bizarre (meta)code has to do with
> the recent Dimension thingy, discussed on
> haskell mailing list.
>
> > data Z = Z
> > data S a = S a
>
> > z = Z
> > sz = S Z
> > ssz = S (S Z)
>
> > class Add a b c | a b -> c where add :: a -> b -> c
>
> > instance Add Z a a
> > instance Add a b c => Add (S a) b (S c)
>
> > class Mul a b c | a b -> c where mul :: a -> b -> c
>
> > instance Mul Z a Z
> > instance (Mul a b c, Add b c d) => Mul (S a) b d
>
> > data Q a b = Q a b
>
> Problem here. This is the addition of rational
> numbers: (a/b) + (c/d) = (ad+bc)/bd
>
> > instance (Mul a d ad,
> > Mul b c bc,
> > Mul b d bd,
> > Add ad bc ad_bc) => Add (Q a b) (Q c d) (Q ad_bc bd)
>
> The problem is, Hugs does not infer a predicate-free type for
> say "add (Q sz sz) (Q sz sz)". I think it's a Hugs bug.
> I tried both CVS and last stable versions.
>
> When I turn "Explain instance resolution" on, the last thing I
> get is:
>
> entail: () ||- Add (S Z) (S Z) a
> No instance found for Add (S Z) (S Z) a
>
> which is strange because the last parameter of Add
> functionally depends on the rest.
> --
> anatoli (at, not speaking for) ptc (dot) com
This looks like a bug that I've been aware of for a while, where context reduction isn't getting iterated enough to rattle out all of the functional dependencies. I think this has an easy fix, and will take a look at it at some point.
--Jeff
From dario.bahena@correo.unam.mx Fri Apr 13 06:48:04 2001
Date: Fri, 13 Apr 2001 00:48:04 -0500
From: dario.bahena@correo.unam.mx dario.bahena@correo.unam.mx
Subject: Question abou=?ISO-8859-1?Q?t_hugs=B4s_DEBU?=G_SHOWSC
hi haskellers ...
I磎 trying to use the hugs磗 flag DEBUG_SHOWSC. Everything seems to work
fine, except for one(simple?) detail:
When you use Int or Double literals, hugs always add extra variables,
related to the fromInt/fromDouble aplication.
For example:
f = 666
should be translated to:
f = fromInt 666
but hugs returns :
f = fromInt v35 666
What is the var. v35 for???, the function fromInt receives just one argument.
If the function has parameters, the resulting function has extra-parameters,
which seems to be out-of-place in both sides of the binding ...
here you are a couple of examples:
the function:
f x = 666
generates the output:
f o2 o1 = fromInt o2 666
And the reported type for f is: Num a => b -> a , which is inconsistent with
the previous result.
the function:
f x = 666 + x
generates :
f o2 o1 = (+) o2 (fromInt o2 666) o1
which has similar troubles to the previous example.
What are these extra-variables for? Are they a debug-feature? what磗 the
meaning?
And finally, the obligated question: how can I avoid them? I suppose that
I have to take a look at the source code, but: what磀 be the part which
is responsible for this(parser,static,type... no please,compiler)?
Thanks in advance.
saludos
dario estepario ...
-------------------------------------------------
Obt閚 tu correo en www.correo.unam.mx
UNAMonos Comunic醤donos
From CAngus@Armature.com Fri Apr 13 09:44:48 2001
Date: Fri, 13 Apr 2001 09:44:48 +0100
From: Chris Angus CAngus@Armature.com
Subject: =?iso-8859-1?Q?RE=3A_Question_about_hugs=B4s_DEBUG=5FSHOWSC?=
is this not the dictionary passing (or whatever)to achieve overloading.
> -----Original Message-----
> From: dario.bahena@correo.unam.mx =
[mailto:dario.bahena@correo.unam.mx]
> Sent: 13 April 2001 06:48
> To: hugs-users@haskell.org
> Cc: hugs-bugs@haskell.org; haskell@haskell.org
> Subject: Question about hugs=B4s DEBUG_SHOWSC
>=20
>=20
> hi haskellers ...
>=20
> I=B4m trying to use the hugs=B4s flag DEBUG_SHOWSC. Everything=20
> seems to work
> fine, except for one(simple?) detail:
>=20
> When you use Int or Double literals, hugs always add extra variables,
> related to the fromInt/fromDouble aplication.=20
>=20
> For example:
>=20
> f =3D 666
>=20
> should be translated to:
>=20
> f =3D fromInt 666
>=20
> but hugs returns :
>=20
> f =3D fromInt v35 666
>=20
> What is the var. v35 for???, the function fromInt receives=20
> just one argument.
>=20
>=20
> If the function has parameters, the resulting function has=20
> extra-parameters,
> which seems to be out-of-place in both sides of the binding ...=20
> here you are a couple of examples:
>=20
> the function:
>=20
> f x =3D 666=20
>=20
> generates the output:
>=20
> f o2 o1 =3D fromInt o2 666
>=20
> And the reported type for f is: Num a =3D> b -> a , which is=20
> inconsistent with
> the previous result.
>=20
> the function:
>=20
> f x =3D 666 + x
>=20
> generates :
>=20
> f o2 o1 =3D (+) o2 (fromInt o2 666) o1
>=20
> which has similar troubles to the previous example.
>=20
> What are these extra-variables for? Are they a debug-feature?=20
> what=B4s the=20
> meaning?
>=20
> And finally, the obligated question: how can I avoid them? I=20
> suppose that
> I have to take a look at the source code, but: what=B4d be the=20
> part which
> is responsible for this(parser,static,type... no please,compiler)?
>=20
> Thanks in advance.
>=20
> saludos
> dario estepario ...
>=20
> -------------------------------------------------
> Obt=E9n tu correo en www.correo.unam.mx
> UNAMonos Comunic=E1ndonos
>=20
> _______________________________________________
> Haskell mailing list
> Haskell@haskell.org
> http://www.haskell.org/mailman/listinfo/haskell
>=20
From srineet@email.com Mon Apr 16 10:59:00 2001
Date: Mon, 16 Apr 2001 15:29:00 +0530
From: Srineet srineet@email.com
Subject: vim for NT Console hangs with the new Feb 2001 Hugs
Hi,
Maybe this is not the right place to send this bug report, but my vim
5.7, for windows NT console, hangs when loaded with :e from Hugs. This
happens only with the Feb 2001 release and not with the Feb 2000 release.
Please let me know if you want anymore detailed information, or you want me
to report this to some other address. Thanks. Bye.
- Srineet.
P.S. Please give me mutually recursive modules soon! :)
From rysiek@ipipan.gda.pl Mon Apr 16 20:31:25 2001
Date: Mon, 16 Apr 2001 21:31:25 +0200
From: Ryszard Kubiak rysiek@ipipan.gda.pl
Subject: isAlphanum
Dear Hugs Maintainers,
I would like to ask if it is done for purpose that the function
isAlpnanum is called isAlphaNum in Hugs. Here is what the February
2001 version of Hugs tells us:
Prelude> :t isAlphanum
ERROR - Undefined variable "isAlphanum"
Prelude> :t isAlphaNum
isAlphaNum :: Char -> Bool
The report on the library Char says that the function should be called
isAplhanum. Also, Hugs manual mentions it in that form. Various
libraries, like Regexp, rely on this statement and one has to
manipulate their sources to get them work with Hugs.
I would also like to ask when the library Directory is expected to
be included into Hugs' distribution.
Best Regards,
Rysiek
From reid@cs.utah.edu Mon Apr 16 20:38:57 2001
Date: Mon, 16 Apr 2001 13:38:57 -0600
From: Alastair Reid reid@cs.utah.edu
Subject: isAlphanum
> I would like to ask if it is done for purpose that the function
> isAlpnanum is called isAlphaNum in Hugs.
The online library report at haskell.org calls it isAlphaNum (not isAlphanum) so it looks as
though Hugs is correct.
--
Alastair
From jbell@mathsoft.com Mon Apr 16 22:43:04 2001
Date: Mon, 16 Apr 2001 17:43:04 -0400
From: Jonathon Bell jbell@mathsoft.com
Subject: Possible bug?
Hi chaps,
Hugs (Feb 2001) fails to compile the following, complaining that the
instances are not consistent with the dependencies:
class Foo f a r | f a->r where
foo::f->a->r
instance Foo (a->r) (c a) (c r)
instance Foo ((a,b)->r) (c a,c b)(c r)
My intention is to overload the uncurried function foo for based on both its
arity and the kind of tuple it is passed. Could you please explain what i am
doing wrong here?
Thank you so much,
_______________________________
Jonathon Bell jbell@mathsoft.com
MathSoft, Inc. www.mathsoft.com
101 Main St, Cambridge, MA 02142
(617) 577-1017 x745
From eb.fm@3339.com Tue Apr 17 01:58:46 2001
Date: Mon, 16 Apr 2001 19:58:46 -0500
From: 'eb.fm - 金蜘蛛电子商务频道' eb.fm@3339.com
Subject: eb.fm 响亮的名字，精彩的世界!
This is a MIME encoded message
--PMA------52f8f9b48c4271eda254630e50d61123
Content-Type: text/html
Content-Transfer-Encoding: base64
PGh0bWw+CjxoZWFkPgo8dGl0bGU+vfDWqdbrtefX08nMzvHGtbXAPC90aXRsZT4KPG1ldGEgaHR0
cC1lcXVpdj0iQ29udGVudC1UeXBlIiBjb250ZW50PSJ0ZXh0L2h0bWw7IGNoYXJzZXQ9Z2IyMzEy
Ij4KPHN0eWxlIHR5cGU9InRleHQvY3NzIj4KPCEtLQouYmIgeyAgYmFja2dyb3VuZC1yZXBlYXQ6
IHJlcGVhdC15OyBiYWNrZ3JvdW5kLXBvc2l0aW9uOiBsZWZ0IHRvcH0KLS0+Cjwvc3R5bGU+Cjxz
Y3JpcHQgbGFuZ3VhZ2U9IkphdmFTY3JpcHQiPgo8IS0tCmZ1bmN0aW9uIE1NX3JlbG9hZFBhZ2Uo
aW5pdCkgeyAgLy9yZWxvYWRzIHRoZSB3aW5kb3cgaWYgTmF2NCByZXNpemVkCiAgaWYgKGluaXQ9
PXRydWUpIHdpdGggKG5hdmlnYXRvcikge2lmICgoYXBwTmFtZT09Ik5ldHNjYXBlIikmJihwYXJz
ZUludChhcHBWZXJzaW9uKT09NCkpIHsKICAgIGRvY3VtZW50Lk1NX3BnVz1pbm5lcldpZHRoOyBk
b2N1bWVudC5NTV9wZ0g9aW5uZXJIZWlnaHQ7IG9ucmVzaXplPU1NX3JlbG9hZFBhZ2U7IH19CiAg
ZWxzZSBpZiAoaW5uZXJXaWR0aCE9ZG9jdW1lbnQuTU1fcGdXIHx8IGlubmVySGVpZ2h0IT1kb2N1
bWVudC5NTV9wZ0gpIGxvY2F0aW9uLnJlbG9hZCgpOwp9Ck1NX3JlbG9hZFBhZ2UodHJ1ZSk7Ci8v
IC0tPgo8L3NjcmlwdD4KPC9oZWFkPgoKPGJvZHkgYmFja2dyb3VuZD0iaHR0cDovL2ViLmZtL2lt
YWdlcy9iLmdpZiIgbGVmdG1hcmdpbj0iMCIgdGV4dD0iIzAwMDA2NiI+Cgo8ZGl2IGFsaWduPSJy
aWdodCI+IAogIDx0YWJsZSB3aWR0aD0iMTAwJSIgYm9yZGVyPSIwIiBjZWxsc3BhY2luZz0iMSIg
Y2VsbHBhZGRpbmc9IjAiIGJnY29sb3I9IiM5OUNDNjYiPgogICAgPHRyPgogICAgICA8dGQ+CiAg
ICAgICAgPHRhYmxlIHdpZHRoPSIxMDAlIiBib3JkZXI9IjAiIGNlbGxzcGFjaW5nPSIwIiBjZWxs
cGFkZGluZz0iMCIgYmdjb2xvcj0iIzAwMzMzMyI+CiAgICAgICAgICA8dHI+IAogICAgICAgICAg
ICA8dGQgd2lkdGg9IjMyJSI+PGEgaHJlZj0iaHR0cDovL2ViLmZtLz9lbWFpbF9pZD0xMzk4NyI+
PGltZyBzcmM9Imh0dHA6Ly9lYi5mbS9pbWFnZXMvdGl0bGUuZ2lmIiB3aWR0aD0iMjEyIiBoZWln
aHQ9IjYxIj48L2E+PC90ZD4KICAgICAgICAgICAgPHRkIHdpZHRoPSI2OCUiPiAKICAgICAgICAg
ICAgICA8ZGl2IGFsaWduPSJyaWdodCI+PGEgaHJlZj0iaHR0cDovL2ViLmZtLz9lbWFpbF9pZD0x
Mzk4NyI+PGltZyBzcmM9Imh0dHA6Ly9lYi5mbS9pbWFnZXMvYmFubmVyLmdpZiIgd2lkdGg9IjQ2
OCIgaGVpZ2h0PSI2MCI+PC9hPjwvZGl2PgogICAgICAgICAgICA8L3RkPgogICAgICAgICAgPC90
cj4KICAgICAgICA8L3RhYmxlPgogICAgICA8L3RkPgogICAgPC90cj4KICA8L3RhYmxlPgo8L2Rp
dj4KPHRhYmxlIHdpZHRoPSIxMDAlIiBib3JkZXI9IjAiIGNlbGxzcGFjaW5nPSIwIiBjZWxscGFk
ZGluZz0iMCIgaGVpZ2h0PSIxIiBiZ2NvbG9yPSIjRkY5OTAwIj4KICA8dHI+CiAgICA8dGQgaGVp
Z2h0PSIxIj48L3RkPgogIDwvdHI+CjwvdGFibGU+Cjx0YWJsZSB3aWR0aD0iMTAwJSIgYm9yZGVy
PSIwIiBjZWxsc3BhY2luZz0iMCIgY2VsbHBhZGRpbmc9IjAiIGJnY29sb3I9IiMwMDAwMDAiPgog
IDx0cj4KICAgIDx0ZD4mbmJzcDs8L3RkPgogIDwvdHI+CjwvdGFibGU+Cjx0YWJsZSB3aWR0aD0i
MTAwJSIgYm9yZGVyPSIwIiBjZWxsc3BhY2luZz0iMSIgY2VsbHBhZGRpbmc9IjAiIGJnY29sb3I9
IiNGRjk5MDAiPgogIDx0ciBiZ2NvbG9yPSIjRkZGRkZGIiB2YWxpZ249InRvcCI+IAogICAgPHRk
IGhlaWdodD0iNTE1IiB3aWR0aD0iNzglIj4gCiAgICAgIDx0YWJsZSB3aWR0aD0iMTAwJSIgYm9y
ZGVyPSIwIiBjZWxsc3BhY2luZz0iMCIgY2VsbHBhZGRpbmc9IjAiIGhlaWdodD0iNTAwIj4KICAg
ICAgICA8dHI+IAogICAgICAgICAgPHRkIGJhY2tncm91bmQ9Imh0dHA6Ly9lYi5mbS9pbWFnZXMv
YmIuZ2lmIiB2YWxpZ249InRvcCIgd2lkdGg9IjIwJSIgY2xhc3M9ImJiIiBoZWlnaHQ9IjQ5OSI+
Jm5ic3A7PC90ZD4KICAgICAgICAgIDx0ZCB2YWxpZ249InRvcCIgaGVpZ2h0PSI0OTkiPiAKICAg
ICAgICAgICAgPHRhYmxlIGJvcmRlcj0iMCIgY2VsbHNwYWNpbmc9IjEiIGNlbGxwYWRkaW5nPSIw
IiB3aWR0aD0iOTAlIiBoZWlnaHQ9IjU1NCI+CiAgICAgICAgICAgICAgPHRyPiAKICAgICAgICAg
ICAgICAgIDx0ZCBoZWlnaHQ9Ijg2Ij4gPGZvbnQgc2l6ZT0iMiIgc3R5bGU9ImxpbmUtaGVpZ2h0
OiAxNTAlIj48YnI+PGJyPtfwvrS1xEh1Z3MgW2VuZ2xpc2hdzfjVvri61PDIy6O6PGJyPgogICAg
ICAgICAgICAgICAgICAgIKGhoaE8L2ZvbnQ+PGZvbnQgc2l6ZT0iMiIgc3R5bGU9ImxpbmUtaGVp
Z2h0OiAxNTAlIj7E+rrDo6E8YnI+CiAgICAgICAgICAgICAgICAgIKGhoaHO0sPH09DQ0uSvwMC1
vbnzzfjVvqOsvvW1w8TjtcTN+NW+t8ezo9PQzNjJq6OssqK21MTj1NrN+NW+1sbX98nPtcTFrMGm
se3KvtDAyc2ho9LytMvO0sPHs8/R+8T6vNPI69fu0MLNxrP2tcQgZWIuZm0gvfDWqdbrtefX08nM
zvHGtbXAoaPU2tXiwO+jrMTjsru1q72rxNy5u86qxOO1xM341b61w7W9obDP7MHBtcShsdPr1tqy
u82stcTT8sP7oaO2+MfSxNy5u7vxtcO5+sTazeLW+MP7xvPStc/yxOO1xM341b7NtrfFueO45rXE
u/q74aGjz9a+zbW9ztLDx8341b7By73iuPy24NDFz6I8YSBocmVmPSJodHRwOi8vZWIuZm0vP2Vt
YWlsX2lkPTEzOTg3Ij5odHRwOi8vZWIuZm08L2E+oaM8L2ZvbnQ+PC90ZD4KICAgICAgICAgICAg
ICA8L3RyPgogICAgICAgICAgICAgIDx0cj4KICAgICAgICAgICAgICAgIDx0ZCBoZWlnaHQ9IjE0
NiI+PGZvbnQgc2l6ZT0iMiI+oaGhoTwvZm9udD4gCiAgICAgICAgICAgICAgICAgIDx0YWJsZSB3
aWR0aD0iNzUlIiBib3JkZXI9IjAiIGNlbGxzcGFjaW5nPSIwIiBjZWxscGFkZGluZz0iMCIgYWxp
Z249ImNlbnRlciI+CiAgICAgICAgICAgICAgICAgICAgPHRyPgogICAgICAgICAgICAgICAgICAg
ICAgPHRkPiA8Zm9udCBzaXplPSIyIiBjb2xvcj0iI0ZGMDAwMCI+t7bA/aO6PC9mb250Pjxmb250
IHNpemU9IjIiPjxhIGhyZWY9Imh0dHA6Ly9iZWFyaW5nLmViLmZtLyI+PGZvbnQgY29sb3I9IiNG
RjAwMDAiPmh0dHA6Ly9iZWFyaW5nLmViLmZtPC9mb250PjwvYT48L2ZvbnQ+PGZvbnQgc2l6ZT0i
MiIgY29sb3I9IiNGRjAwMDAiPiAKICAgICAgICAgICAgICAgICAgICAgICAgoaGhoaGhPC9mb250
Pjxmb250IHNpemU9IjIiPjxhIGhyZWY9Imh0dHA6Ly9jb2xvci5lYi5mbS8iPjxmb250IGNvbG9y
PSIjRkYwMDAwIj5odHRwOi8vY29sb3IuZWIuZm08L2ZvbnQ+PC9hPjwvZm9udD48YnI+PGJyPgoJ
CQkJCQmhoaGhoaE8Zm9udCBzaXplPSIyIj48YSBocmVmPSJodHRwOi8v1uGz0C5lYi5mbS8iPjxm
b250IGNvbG9yPSIjRkYwMDAwIj5odHRwOi8v1uGz0C5lYi5mbTwvZm9udD48L2E+PC9mb250PqGh
oaGhoTxmb250IHNpemU9IjIiPjxhIGhyZWY9Imh0dHA6Ly/S1cr1LmViLmZtLyI+PGZvbnQgY29s
b3I9IiNGRjAwMDAiPmh0dHA6Ly/S1cr1LmViLmZtPC9mb250PjwvYT48L2ZvbnQ+CgkJCQkJCTwv
dGQ+CiAgICAgICAgICAgICAgICAgICAgPC90cj4KICAgICAgICAgICAgICAgICAgPC90YWJsZT4K
ICAgICAgICAgICAgICAgICAgPGZvcm0gbmFtZT13aG9pcyBhY3Rpb249aHR0cDovL2ViLmZtL3N0
ZXAyLnBocCAgbWV0aG9kPXBvc3Q+CiAgICAgICAgICAgICAgICAgICAgPGNlbnRlcj4KICAgICAg
ICAgICAgICAgICAgICAgIDx0YWJsZSB3aWR0aD0iMzg3IiBib3JkZXI9IjAiIGNlbGxzcGFjaW5n
PSIxIiBjZWxscGFkZGluZz0iMCIgaGVpZ2h0PSI0MyI+CiAgICAgICAgICAgICAgICAgICAgICAg
IDx0cj4gCiAgICAgICAgICAgICAgICAgICAgICAgICAgPHRkIHdpZHRoPSI1MSUiIGhlaWdodD0i
NDkiPiZuYnNwOzwvdGQ+CiAgICAgICAgICAgICAgICAgICAgICAgICAgPHRkIHJvd3NwYW49IjIi
Pjxmb250IHNpemU9IjIiPjxpbWcgc3JjPSJodHRwOi8vZWIuZm0vaW1hZ2VzL2ZyZWVlbmQuZ2lm
IiB3aWR0aD0iMTA1IiBoZWlnaHQ9IjcyIj48L2ZvbnQ+PC90ZD4KICAgICAgICAgICAgICAgICAg
ICAgICAgPC90cj4KICAgICAgICAgICAgICAgICAgICAgICAgPHRyPiAKICAgICAgICAgICAgICAg
ICAgICAgICAgICA8dGQgd2lkdGg9IjUxJSI+IAogICAgICAgICAgICAgICAgICAgICAgICAgICAg
PHRhYmxlIHdpZHRoPSIyMDQiIGJvcmRlcj0iMCIgY2VsbHNwYWNpbmc9IjEiIGNlbGxwYWRkaW5n
PSIwIiBiZ2NvbG9yPSIjOTk5OTk5Ij4KICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgPHRy
IGJnY29sb3I9IiM2NjY2NjYiPiAKICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICA8dGQg
d2lkdGg9IjIwMCIgYmdjb2xvcj0iIzY2OTlGRiI+IAogICAgICAgICAgICAgICAgICAgICAgICAg
ICAgICAgICAgPGRpdiBhbGlnbj0iY2VudGVyIj48Zm9udCBzaXplPSIyIiBjb2xvcj0iI0ZGRkZG
RiI+sum/tMT6tcTT8sP7yse38dPQ0Kc8L2ZvbnQ+PGZvbnQgY29sb3I9IiNGRkZGRkYiPjogCiAg
ICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgIDwvZm9udD48L2Rpdj4KICAgICAgICAg
ICAgICAgICAgICAgICAgICAgICAgICA8L3RkPgogICAgICAgICAgICAgICAgICAgICAgICAgICAg
ICA8L3RyPgogICAgICAgICAgICAgICAgICAgICAgICAgICAgPC90YWJsZT4KICAgICAgICAgICAg
ICAgICAgICAgICAgICA8L3RkPgogICAgICAgICAgICAgICAgICAgICAgICA8L3RyPgogICAgICAg
ICAgICAgICAgICAgICAgPC90YWJsZT4KICAgICAgICAgICAgICAgICAgICA8L2NlbnRlcj4KICAg
ICAgICAgICAgICAgICAgICA8Y2VudGVyPgogICAgICAgICAgICAgICAgICAgICAgPHRhYmxlIGNl
bGxzcGFjaW5nPTQgY2VsbHBhZGRpbmc9MCB3aWR0aD00MjAgYm9yZGVyPTAgaGVpZ2h0PSIyMSI+
CiAgICAgICAgICAgICAgICAgICAgICAgIDx0Ym9keT4gCiAgICAgICAgICAgICAgICAgICAgICAg
IDx0cj4gCiAgICAgICAgICAgICAgICAgICAgICAgICAgPHRkIHdpZHRoPSIxMyUiIGhlaWdodD0i
MTMiPjxpbWcgc3JjPSJodHRwOi8vZWIuZm0vaW1hZ2VzL2Ytc3RlcC0xLmdpZiIgd2lkdGg9IjUw
IiBoZWlnaHQ9IjM4Ij48L3RkPgogICAgICAgICAgICAgICAgICAgICAgICAgIDx0ZCB3aWR0aD0i
MiUiIGhlaWdodD0iMTMiPiZuYnNwOzwvdGQ+CiAgICAgICAgICAgICAgICAgICAgICAgICAgPHRk
IHdpZHRoPSIxMiUiIGhlaWdodD0iMTMiPjxiPjxmb250IGZhY2U9IkFyaWFsLCBIZWx2ZXRpY2Es
IHNhbnMtc2VyaWYiIHNpemU9Ii0xIiBjb2xvcj0iI0ZGMDA2NiI+d3d3LjwvZm9udD48L2I+PC90
ZD4KICAgICAgICAgICAgICAgICAgICAgICAgICA8dGQgd2lkdGg9IjQ4JSIgaGVpZ2h0PSIxMyI+
PGZvbnQgc2l6ZT0iMiIgZmFjZT0iQXJpYWwsIEhlbHZldGljYSwgc2Fucy1zZXJpZiIgY29sb3I9
IiNGRjAwNjYiPjxpbnB1dCBzaXplPTE2IG5hbWU9ZG9tYWluX2NvbnRlbnQ+PGlucHV0IHR5cGU9
aGlkZGVuIG5hbWU9ZG9tYWluX2lkIHZhbHVlPTE+PGlucHV0IHR5cGU9aGlkZGVuIG5hbWU9ZW1h
aWxfaWQgdmFsdWU9IjEzOTg3Ij4uZWIuZm08L2ZvbnQ+PC90ZD4KICAgICAgICAgICAgICAgICAg
ICAgICAgICA8dGQgd2lkdGg9IjI1JSIgaGVpZ2h0PSIxMyI+IAogICAgICAgICAgICAgICAgICAg
ICAgICAgICAgPGlucHV0IHR5cGU9aW1hZ2Ugc3JjPSJodHRwOi8vZWIuZm0vaW1hZ2VzL2NoZWNr
LmdpZiIgCiAgICAgICAgICAgICAgICAgICAgICAgICAgICAgIHdpZHRoPSI0NiIgaGVpZ2h0IjI3
IiBib3JkZXI9IjAiIG5hbWU9Y2hrX2RvbWFpbj4KICAgICAgICAgICAgICAgICAgICAgICAgICA8
L3RkPgogICAgICAgICAgICAgICAgICAgICAgICA8L3RyPgogICAgICAgICAgICAgICAgICAgICAg
ICA8L3Rib2R5PiAKICAgICAgICAgICAgICAgICAgICAgIDwvdGFibGU+CiAgICAgICAgICAgICAg
ICAgICAgPC9jZW50ZXI+CiAgICAgICAgICAgICAgICAgIDwvZm9ybT4KICAgICAgICAgICAgICAg
IDwvdGQ+CiAgICAgICAgICAgICAgPC90cj4KICAgICAgICAgICAgICA8dHI+IAogICAgICAgICAg
ICAgICAgPHRkIGhlaWdodD0iMjA2Ij4gCiAgICAgICAgICAgICAgICAgIDxwPiZuYnNwOzwvcD4K
ICAgICAgICAgICAgICAgICAgPG9sPgogICAgICAgICAgICAgICAgICAgIDxsaT48Zm9udCBzaXpl
PSIyIiBzdHlsZT0ibGluZS1oZWlnaHQ6IDE1MCUiPteisuGhsLXn19PJzM7xxrW1wKGx0/LD+6Os
s8nOqrulwarN+LXn19PJzM7xysC957XEs8nUsaGjPGJyPgogICAgICAgICAgICAgICAgICAgICAg
ZWK8tGUtYnVzaW5lc3O159fTyczO8aOsZWIuZm3Kx9K7uPahsM/swcG1xKGx0+vW2rK7zay1xMP7
19ajrNK7uPa6w7XE0/LD+9K7tqjKx8jd0te8x7XEus3T0MTauq21xKGjPGJyPgogICAgICAgICAg
ICAgICAgICAgICAgPC9mb250PjwvbGk+CiAgICAgICAgICAgICAgICAgICAgPGxpPjxmb250IHNp
emU9IjIiIHN0eWxlPSJsaW5lLWhlaWdodDogMTUwJSI+vLTXory0yfrQp6OsyejWw7W9xOO1xM34
1b6hozxicj4KICAgICAgICAgICAgICAgICAgICAgIMGiuMu8+9Owo6zXorLhxOO1xGViLmZt0/LD
+7rzo6y8tL/JyrnTw6GjPGJyPgogICAgICAgICAgICAgICAgICAgICAgPC9mb250PjwvbGk+CiAg
ICAgICAgICAgICAgICAgICAgPGxpPjxmb250IHNpemU9IjIiIHN0eWxlPSJsaW5lLWhlaWdodDog
MTUwJSI+vNu48dPFu92jrM/I16LPyLXDoaM8YnI+CiAgICAgICAgICAgICAgICAgICAgICDTos7E
tefX08nMzvHGtbXA0/LD+9eisuG30b32zqoyONSqo6/E6qOs1tDOxLXE1rvQ6DQ41Kqjr8TqoaM8
YnI+CiAgICAgICAgICAgICAgICAgICAgICA8L2ZvbnQ+PC9saT4KICAgICAgICAgICAgICAgICAg
ICA8bGk+PGZvbnQgc2l6ZT0iMiIgc3R5bGU9ImxpbmUtaGVpZ2h0OiAxNTAlIj7E+ta70qrV/cq9
16Ky4SjWp7i216Ky4bfRKdK7uPbT8sP7vLS/ybPJzqrO0sPHtcS6z9f3u++w6aGjPGJyPgogICAg
ICAgICAgICAgICAgICAgICAgs8nOqs7Sw8e1xLrP1/e777Dp1q6686OssO/W+s7Sw8fDv9eisuHS
u7j20/LD+6OsxOO9q7vhu/G1w6O60ru49tOizsS159fTyczO8dPyw/ujpDEw1KqjrNK7uPbW0M7E
tefX08nMzvHT8sP7o6QxNtSqtcS9sb3woaPE48v50OjSqtf2tcTWu8rHt8XSu7j2zbyx6rvyQmFu
bmVy1NrE47XEzfjVvsnPo6zO0sPHvau4+tfZus28x8K8tNPE47XEzfjVvsnPteO797n9wLS1xNei
suHT8sP7sqKzybmm1qe4tteisuG30bXEv827p6OszazKscq1yrHWp7i2vbG98LW9xPq1xNXKu6fW
0KGjIAogICAgICAgICAgICAgICAgICAgICA8L2ZvbnQ+IDwvbGk+CiAgICAgICAgICAgICAgICAg
IDwvb2w+CiAgICAgICAgICAgICAgICAgIDxkaXYgYWxpZ249InJpZ2h0Ij48Zm9udCBzaXplPSIy
IiBzdHlsZT0ibGluZS1oZWlnaHQ6IDE1MCUiPr3w1qnW67Xn19PJzM7xxrW1wDwvZm9udD48YnI+
CiAgICAgICAgICAgICAgICAgICAgPGEgaHJlZj0iaHR0cDovL2ViLmZtLz9lbWFpbF9pZD0xMzk4
NyI+PGZvbnQgc2l6ZT0iMiI+aHR0cDovL2ViLmZtPC9mb250PjwvYT48YnI+CiAgICAgICAgICAg
ICAgICAgIDwvZGl2PgogICAgICAgICAgICAgICAgPC90ZD4KICAgICAgICAgICAgICA8L3RyPgog
ICAgICAgICAgICA8L3RhYmxlPgogICAgICAgICAgPC90ZD4KICAgICAgICA8L3RyPgogICAgICA8
L3RhYmxlPgogICAKICAgIDwvdGQ+CiAgPC90cj4KPC90YWJsZT4KPHRhYmxlIHdpZHRoPSIxMDAl
IiBib3JkZXI9IjAiIGNlbGxzcGFjaW5nPSIwIiBjZWxscGFkZGluZz0iMCIgYmdjb2xvcj0iI0ZG
NjYwMCI+CiAgPHRyIGJnY29sb3I9IiM2Njk5Q0MiPiAKICAgIDx0ZD4mbmJzcDsgPC90ZD4KICA8
L3RyPgo8L3RhYmxlPgo8dGFibGUgd2lkdGg9IjEwMCUiIGJvcmRlcj0iMCIgY2VsbHNwYWNpbmc9
IjAiIGNlbGxwYWRkaW5nPSIwIiBiZ2NvbG9yPSIjMDAwMDAwIiBoZWlnaHQ9IjgiPgogIDx0cj4g
CiAgICA8dGQgaGVpZ2h0PSIyIj4gCiAgICAgIDxkaXYgYWxpZ249ImNlbnRlciI+PC9kaXY+CiAg
ICAgIDwvdGQ+CiAgPC90cj4KPC90YWJsZT4KPHRhYmxlIHdpZHRoPSIxMDAlIiBib3JkZXI9IjAi
IGNlbGxzcGFjaW5nPSIwIiBjZWxscGFkZGluZz0iMCIgaGVpZ2h0PSIxIiBiZ2NvbG9yPSIjRkY5
OTAwIj4KICA8dHI+IAogICAgPHRkIGhlaWdodD0iMSI+PC90ZD4KICA8L3RyPgo8L3RhYmxlPgp0
CjwvYm9keT4KPC9odG1sPgo=
--PMA------52f8f9b48c4271eda254630e50d61123--
From sigbjorn_finne@hotmail.com Tue Apr 17 10:18:08 2001
Date: Tue, 17 Apr 2001 11:18:08 +0200
From: Sigbjorn Finne sigbjorn_finne@hotmail.com
Subject: isAlphanum
Ryszard Kubiak rysiek@ipipan.gda.pl writes:
>
... isAlphaNum (which Haskell 1.4 correctly named it) wibble deleted...
>
> I would also like to ask when the library Directory is expected to
> be included into Hugs' distribution.
Hi,
I've got an implementation of this module (and the other missing ones),
but won't check in the changes until I've had a chance to test the code
on a wider selection of machines/setups. So, unless someone beats
me to it, Directory should be available before the end of May.
--sigbjorn
From reid@cs.utah.edu Tue Apr 17 20:56:53 2001
Date: Tue, 17 Apr 2001 13:56:53 -0600
From: Alastair Reid reid@cs.utah.edu
Subject: isAlphanum
> I've got an implementation of this module (and the other missing ones),
> but won't check in the changes until I've had a chance to test the code
> on a wider selection of machines/setups.
This is maybe a good time to advertise the existence of a test suite for
the Hugs distribution.
I recently revived the Yale Hugs test suite which
checks error messages in Hugs, various parts of the runtime system, the
Prelude and standard libraries and the Hugs-GHC extensions. (The test
suite is in the CVS repository - instructions for using it are in
the commit messages.)
The only problem is that Hugs has changed in the last 2-3 years and the
test suite has stayed still. This means there's no tests for new libraries,
no tests for new syntax and no tests for type system extensions.
What I'd like to see happen is for anyone contributing code (or who _has_
contributed code) to provide a small test for the code.
It'd also be a good idea for library maintainers whose library depends on
some particular feature of Hugs to submit a (small) test which checks the
essence of the thing they depend on. For example, the HGL (and, I think, Fran
and Yale's FRP code) depend on the producer-consumer pattern working in Hugs
and on exception handling working - so I added test cases for this.
btw The word "small" is important here. The testsuite runs in 1-1.5 minutes on
my laptop. If it was 10-15 minutes, I'd run it a lot less.
--
Alastair Reid
ps To run the test suite:
cd hugs98/tests
make -C ../src hugs # make sure hugs is in hugs98/src
sh testSuite static tcheck rts libs
[You may have to reconfigure without --with-readline first.]
The output will be a bunch of lines preceeded by --!!!
Lines not preceded by --!!! are errors.
Errors are detected by comparing the actual output from Hugs with
a file containing the expected output. Errors are in the form of
context diffs.
From fokkinga@cs.utwente.nl Wed Apr 18 14:24:15 2001
Date: Wed, 18 Apr 2001 15:24:15 +0200
From: Maarten Fokkinga fokkinga@cs.utwente.nl
Subject: bug?
-- Hugs Version February 2001.
-- dummy1 and dummy2 behave differently when evaluated on the command
line.
-- So, a type synonym and its definition are not completely
interchangeable.
import IO
type IOString = IO String
dummy1 :: IOString ; dummy1 = return "Dummy"
dummy2 :: IO String ; dummy2 = return "Dummy"
--
Maarten Fokkinga
University of Twente (fac INF), PO Box 217, 7500 AE Enschede, NL
http://www.cs.utwente.nl/~fokkinga/ phone: +31 53 4893711
mailto:fokkinga@cs.utwente.nl fax: +31 53 4892927
From reid@cs.utah.edu Wed Apr 18 18:31:07 2001
Date: Wed, 18 Apr 2001 11:31:07 -0600 (MDT)
From: Alastair Reid reid@cs.utah.edu
Subject: Syntax for implicit parameters
Some months ago, there was talk about making sure GHC and Hugs use the
same syntax for implicit parameters and (most importantly) that that
syntax should not introduce the keyword "with".
As far as I can see (from looking at both parsers and trying
examples), this discussion has not been acted on. Hugs seems to
allow:
dlet ?x = 'a' in ?x + 1
?x + 1 with ?x = 'a'
and GHC 5.0 only seems to support:
?x + 1 with ?x = 'a'
Can the GHC people, the Hugs people and the implicit parameter
designers come to some sort of agreement and implement the result?
--
Alastair Reid reid@cs.utah.edu http://www.cs.utah.edu/~reid/
From Erik Meijer" As I was not involved in that discussion, why should the keyword "with" not
be introduced?
Just curious,
Erik
----- Original Message -----
From: "Alastair Reid" <reid@cs.utah.edu>
To: <hugs-bugs@haskell.org>; <glasgow-haskell-bugs@haskell.org>
Sent: Wednesday, April 18, 2001 10:31 AM
Subject: Syntax for implicit parameters
>
> Some months ago, there was talk about making sure GHC and Hugs use the
> same syntax for implicit parameters and (most importantly) that that
> syntax should not introduce the keyword "with".
>
> As far as I can see (from looking at both parsers and trying
> examples), this discussion has not been acted on. Hugs seems to
> allow:
>
> dlet ?x = 'a' in ?x + 1
> ?x + 1 with ?x = 'a'
>
> and GHC 5.0 only seems to support:
>
> ?x + 1 with ?x = 'a'
>
> Can the GHC people, the Hugs people and the implicit parameter
> designers come to some sort of agreement and implement the result?
>
>
> --
> Alastair Reid reid@cs.utah.edu http://www.cs.utah.edu/~reid/
>
> _______________________________________________
> Hugs-Bugs mailing list
> Hugs-Bugs@haskell.org
> http://www.haskell.org/mailman/listinfo/hugs-bugs
From jbell@mathsoft.com Wed Apr 18 19:19:59 2001
Date: Wed, 18 Apr 2001 14:19:59 -0400
From: Jonathon Bell jbell@mathsoft.com
Subject: possible bug
Hello there,
I've been experimenting with the use of type dependencies in type classes
and have come across something i find surprising. Could it in fact be a bug
in the implementation? I'm using Hugs Feb 2001, with switches +o and -98:
> class Bug f a r | f a -> r where
>
> bug::f->a->r
>
> instance Bug (Int->r) Int r
>--instance ...
> instance (Bug f a r) => Bug f (c a) (c r)
>
> f:: Bug(Int->Int) a r => a->r
> f = bug(id::Int->Int)
The above compiles fine and at the prompt ..
Main> f (f [0::Int])
...runs with an expected program error that member 'bug' has not been
defined. Fine. But
Main> f (f (f [0::Int]))
-- ...fails to compile with an unresolved overloading:
*** ERROR - Unresolved overloading
*** Type : (Bug (Int->Int) Int a, Bug(Int->Int) a v => [b]
*** Expression : f (f (f [0]))
which is a surprise. it appears as though the compiler is failing to exploit
the dependency '|f a->r'
from which it could infer that 'a' in the above message must in fact be
'Int', etc...
Many thanks for investigating this...
________________________________
Jonathon Bell jbell@mathsoft.com
MathSoft, Inc. www.mathsoft.com
101 Main St, Cambridge, MA 02142
(617) 577-1017 x745
From reid@cs.utah.edu Wed Apr 18 20:08:28 2001
Date: Wed, 18 Apr 2001 13:08:28 -0600 (MDT)
From: Alastair Reid reid@cs.utah.edu
Subject: Syntax for implicit parameters
Marcin Kowalczyk (qrczak@knm.org.pl) writes:
> I would like to replace "with" and "dlet" with "let". But SimonPJ
> said he won't do it in ghc unless Hugs does it too, and Mark P Jones
> said he won't do it in Hugs now (without deep reasons: no
> people/hours to do that, and no plans to release next Hugs version
> this year).
I'd really, really like to see a fresh release of Hugs which includes
the recently added support for imprecise exception handling (a la
GHC). This is what HGL (and Fran) need to work with Hugs.
I volunteer to implement whatever implicit parameter syntax is decided
in Hugs.
--
Alastair Reid reid@cs.utah.edu http://www.cs.utah.edu/~reid/
From nordland@cse.ogi.edu Wed Apr 18 21:20:19 2001
Date: Wed, 18 Apr 2001 13:20:19 -0700
From: Johan Nordlander nordland@cse.ogi.edu
Subject: Syntax for implicit parameters
> Marcin Kowalczyk (qrczak@knm.org.pl) writes:
>> I would like to replace "with" and "dlet" with "let". But SimonPJ
>> said he won't do it in ghc unless Hugs does it too, and Mark P Jones
>> said he won't do it in Hugs now (without deep reasons: no
>> people/hours to do that, and no plans to release next Hugs version
>> this year).
>
> I'd really, really like to see a fresh release of Hugs which includes
> the recently added support for imprecise exception handling (a la
> GHC). This is what HGL (and Fran) need to work with Hugs.
>
> I volunteer to implement whatever implicit parameter syntax is decided
> in Hugs.
>
>
> --
> Alastair Reid reid@cs.utah.edu
> http://www.cs.utah.edu/~reid/
There is really going to be a fresh Hugs release, I'm not sure
where this other information stems from. Mark isn't actively
working on Hugs anymore, but a lot of other people (including
Alastair, Sigbjorn, Jeff, and myself) are providing bug fixes
and added features when time permits. And there really is a
need for a new release because of this unfortunate
incompatibility between the Feb 2001 release and HGL/Fran.
The let/dlet/with issue is still open, but there's really
nothing that precludes anyone from just making a decision.
Alastair is most welcome to implement something that will make
Hugs compatible with GHC.
I think a suitable target date for a new release is somewhere in
early June.
All the best,
Johan
From jeff@galconn.com Wed Apr 18 22:03:11 2001
Date: Wed, 18 Apr 2001 14:03:11 -0700
From: Jeffrey R. Lewis jeff@galconn.com
Subject: Syntax for implicit parameters
Johan Nordlander wrote:
> There is really going to be a fresh Hugs release ...
Cool.
>
>
> The let/dlet/with issue is still open, but there's really
> nothing that precludes anyone from just making a decision.
> Alastair is most welcome to implement something that will make
> Hugs compatible with GHC.
The thing is, hugs *is* currently compatible w/ GHC on this.
--Jeff
From nordland@cse.ogi.edu Wed Apr 18 22:45:28 2001
Date: Wed, 18 Apr 2001 14:45:28 -0700
From: Johan Nordlander nordland@cse.ogi.edu
Subject: Syntax for implicit parameters
>> The let/dlet/with issue is still open, but there's really
>> nothing that precludes anyone from just making a decision.
>> Alastair is most welcome to implement something that will make
>> Hugs compatible with GHC.
>
> The thing is, hugs *is* currently compatible w/ GHC on this.
Should read: compatible with whatever the designers/implementors
of the implicit parameters feature wants it to be!
-- Johan
From gruenbacher-lists@geoinfo.tuwien.ac.at Thu Apr 19 10:56:27 2001
Date: Thu, 19 Apr 2001 11:56:27 +0200 (CEST)
From: Andreas Gruenbacher gruenbacher-lists@geoinfo.tuwien.ac.at
Subject: Floating point conversion bug
Hello,
I recently ran into a problem using numbers that require Double precision
floating point. Hugs seems to always convert to single precision Float.
Here is an example:
> f :: Float
> d, d2 :: Double
> f = 3.141592654
> d = 3.141592654
> d2 = fromRational (3141592654 % 1000000000)
> main = do
> putStrLn (show (round (f * 1000000000)))
> putStrLn (show (round (d * 1000000000)))
> putStrLn (show (round (d2 * 1000000000)))
Surprisingly, this gives:
3141592832
3141592832
3141592832
Here is a similar C program:
> int main(void)
> {
> float f = 3.141592654;
> double d = 3.141592654;
>
> printf("%.9f\n", f);
> printf("%.9f\n", d);
> }
3.141592741
3.141592654
Also, I would expect that at least the single precision case is identical
in both examples, but it's not. Weird...
Besides, how can I influence how floating point numbers are converted to
strings (precision, format, etc.)?
Thanks,
Andreas.
------------------------------------------------------------------------
Andreas Gruenbacher gruenbacher@geoinfo.tuwien.ac.at
Research Assistant Phone +43(1)58801-12723
Institute for Geoinformation Fax +43(1)58801-12799
Technical University of Vienna Cell phone +43(664)4064789
From atze@cs.uu.nl Thu Apr 19 19:01:32 2001
Date: Thu, 19 Apr 2001 20:01:32 +0200
From: Atze Dijkstra atze@cs.uu.nl
Subject: Precompiled binaries for Hugs on MacOS X
Hi,
this is not a bugreport but a message to let you know I did make a
precompiled version of Hugs for MacOS X (no other appropriate email
address being available), as an installable package. See
http://www.cs.uu.nl/~atze/Download/Hugs98-Feb2001.pkg.sit (and/or
http://www.cs.uu.nl/~atze/Programming/). I did test the install on a
clean machine. Feel free to include it on the Hugs download page.
--
- Atze -
Atze Dijkstra, Dept. of Computer Science, Utrecht University /|\
Tel.: +31-30-2534093/1454 | WWW : http://www.cs.uu.nl/~atze / | \
Fax : +31-30-2513971 | Email: atze@cs.uu.nl /--| \
atze.dijkstra@hetnet.nl / |___|
From nordland@cse.ogi.edu Thu Apr 19 19:45:44 2001
Date: Thu, 19 Apr 2001 11:45:44 -0700
From: Johan Nordlander nordland@cse.ogi.edu
Subject: Precompiled binaries for Hugs on MacOS X
> Hi,
>
> this is not a bugreport but a message to let you know I did
> make a precompiled version of Hugs for MacOS X (no other
> appropriate email address being available), as an installable
> package. See
> http://www.cs.uu.nl/~atze/Download/Hugs98-Feb2001.pkg.sit
> (and/or http://www.cs.uu.nl/~atze/Programming/). I did test the
> install on a clean machine. Feel free to include it on the Hugs
> download page.
> --
> - Atze -
>
> Atze Dijkstra, Dept. of Computer Science, Utrecht University /|\
> Tel.: +31-30-2534093/1454 | WWW :
> http://www.cs.uu.nl/~atze / | \
> Fax : +31-30-2513971 | Email:
> atze@cs.uu.nl /--| \
>
> atze.dijkstra@hetnet.nl / |___|
Thanks!
Any source modifications you did would be greatly appreciated as
well. Please send them to me directly and I'll edit them into
the main distribution.
All the best,
Johan
From simonpj@microsoft.com Thu Apr 19 17:12:54 2001
Date: Thu, 19 Apr 2001 09:12:54 -0700
From: Simon Peyton-Jones simonpj@microsoft.com
Subject: Syntax for implicit parameters
I only added 'with' because I did not want to steal *two* new keywords.
One is bad enough! I proposed using 'let' (not dlet), with the '?' to
distinguish dynamic from lexical bindings, but did not achieve
consensus.
Lack of consensus =3D> the status quo stays. =20
My order of preference:
1. [happy]. Use 'let'
2. [consent]. Use 'dlet' or 'with'
3. [hate] Use both 'dlet' and 'with'
Would the Hugs folk be willing to adopt (2)?
Simon
| -----Original Message-----
| From: Alastair Reid [mailto:reid@cs.utah.edu]
| Sent: 18 April 2001 18:31
| To: hugs-bugs@haskell.org; glasgow-haskell-bugs@haskell.org
| Subject: Syntax for implicit parameters
|=20
|=20
|=20
| Some months ago, there was talk about making sure GHC and Hugs use the
| same syntax for implicit parameters and (most importantly) that that
| syntax should not introduce the keyword "with".
|=20
| As far as I can see (from looking at both parsers and trying
| examples), this discussion has not been acted on. Hugs seems to
| allow:
|=20
| dlet ?x =3D 'a' in ?x + 1
| ?x + 1 with ?x =3D 'a'
|=20
| and GHC 5.0 only seems to support:
|=20
| ?x + 1 with ?x =3D 'a'
|=20
| Can the GHC people, the Hugs people and the implicit parameter
| designers come to some sort of agreement and implement the result? =20
|=20
|=20
| --=20
| Alastair Reid reid@cs.utah.edu =20
http://www.cs.utah.edu/~reid/
_______________________________________________
Glasgow-haskell-bugs mailing list
Glasgow-haskell-bugs@haskell.org
http://www.haskell.org/mailman/listinfo/glasgow-haskell-bugs
From jeff@galconn.com Fri Apr 20 07:52:09 2001
Date: Thu, 19 Apr 2001 23:52:09 -0700
From: Jeffrey R. Lewis jeff@galconn.com
Subject: Syntax for implicit parameters
Simon Peyton-Jones wrote:
> I only added 'with' because I did not want to steal *two* new keywords.
> One is bad enough! I proposed using 'let' (not dlet), with the '?' to
> distinguish dynamic from lexical bindings, but did not achieve
> consensus.
>
I only added `with' to GHC originally because `dlet' was essentially deprecated (although I never bothered to remove it from hugs).
>
> Lack of consensus => the status quo stays.
>
> My order of preference:
>
> 1. [happy]. Use 'let'
> 2. [consent]. Use 'dlet' or 'with'
> 3. [hate] Use both 'dlet' and 'with'
>
> Would the Hugs folk be willing to adopt (2)?
That would certainly be fine by me.
--Jeff
From chak@cse.unsw.edu.au Fri Apr 20 16:04:13 2001
Date: Sat, 21 Apr 2001 01:04:13 +1000
From: Manuel M. T. Chakravarty chak@cse.unsw.edu.au
Subject: Syntax for implicit parameters
"Jeffrey R. Lewis" <jeff@galconn.com> wrote,
> > Lack of consensus => the status quo stays.
> >
> > My order of preference:
> >
> > 1. [happy]. Use 'let'
> > 2. [consent]. Use 'dlet' or 'with'
> > 3. [hate] Use both 'dlet' and 'with'
> >
> > Would the Hugs folk be willing to adopt (2)?
>
> That would certainly be fine by me.
What exactly does (2) imply? Does it mean we get `with'
back or not?
Manuel
From jeff@galconn.com Fri Apr 20 16:56:22 2001
Date: Fri, 20 Apr 2001 08:56:22 -0700
From: Jeffrey R. Lewis jeff@galconn.com
Subject: Syntax for implicit parameters
"Manuel M. T. Chakravarty" wrote:
> "Jeffrey R. Lewis" <jeff@galconn.com> wrote,
>
> > > Lack of consensus => the status quo stays.
> > >
> > > My order of preference:
> > >
> > > 1. [happy]. Use 'let'
> > > 2. [consent]. Use 'dlet' or 'with'
> > > 3. [hate] Use both 'dlet' and 'with'
> > >
> > > Would the Hugs folk be willing to adopt (2)?
> >
> > That would certainly be fine by me.
>
> What exactly does (2) imply? Does it mean we get `with'
> back or not?
I'm afraid I misspoke. I meant (2) with `with'. Sorry ;-) I'm happy to nuke `dlet'.
--Jeff
From paul.stoeber@in.stud.tu-ilmenau.de Fri Apr 20 18:25:35 2001
Date: Fri, 20 Apr 2001 19:25:35 +0200 (MDT)
From: paul.stoeber@in.stud.tu-ilmenau.de paul.stoeber@in.stud.tu-ilmenau.de
Subject: maybe a bug in hugs version February 2001
Prelude says:
data Either a b = Left a | Right b
deriving (Eq, Ord, Read, Show)
^^^^
Interactive session:
Prelude> Left 3
ERROR - Cannot find "show" function for:
*** Expression : Left 3
*** Of type : Either Integer a
Test script:
> data Foo a b = Bar a | Baz b
> showFoo (Bar x) = "Bar: " ++ show x
> showFoo (Baz x) = "Baz: " ++ show x
Interactive session:
Main> showFoo (Bar 3)
ERROR - Unresolved overloading
*** Type : Show a => [Char]
*** Expression : showFoo (Bar 3)
From chak@cse.unsw.edu.au Sat Apr 21 03:24:48 2001
Date: Sat, 21 Apr 2001 12:24:48 +1000
From: Manuel M. T. Chakravarty chak@cse.unsw.edu.au
Subject: Syntax for implicit parameters
"Jeffrey R. Lewis" <jeff@galconn.com> wrote,
> "Manuel M. T. Chakravarty" wrote:
>
> > "Jeffrey R. Lewis" <jeff@galconn.com> wrote,
> >
> > > > Lack of consensus => the status quo stays.
> > > >
> > > > My order of preference:
> > > >
> > > > 1. [happy]. Use 'let'
> > > > 2. [consent]. Use 'dlet' or 'with'
> > > > 3. [hate] Use both 'dlet' and 'with'
> > > >
> > > > Would the Hugs folk be willing to adopt (2)?
> > >
> > > That would certainly be fine by me.
> >
> > What exactly does (2) imply? Does it mean we get `with'
> > back or not?
>
> I'm afraid I misspoke. I meant (2) with `with'. Sorry ;-) I'm happy to nuke `dlet'.
The problem is that implict parameters than clash with both
the HaXML and the new FFI libraries, ie, you can't use both
in a module. Not nice.
Manuel
From Sven.Panne@informatik.uni-muenchen.de Sat Apr 21 13:05:45 2001
Date: Sat, 21 Apr 2001 14:05:45 +0200
From: Sven Panne Sven.Panne@informatik.uni-muenchen.de
Subject: Syntax for implicit parameters
Simon Peyton-Jones wrote:
> [...]
> 1. [happy]. Use 'let'
> 2. [consent]. Use 'dlet' or 'with'
> 3. [hate] Use both 'dlet' and 'with'
>
> Would the Hugs folk be willing to adopt (2)?
I'm getting a little bit lost in this thread: Everybody seems to
agree that stealing identifiers is bad, stealing a *very* useful
identifier ('with') is *very* bad, and Alastair promised to synch
Hugs with GHC, so why don't we adopt (1)?
Confused,
Sven
From reid@moab.cs.utah.edu Sat Apr 21 20:32:49 2001
Date: Sat, 21 Apr 2001 13:32:49 -0600 (MDT)
From: Alastair Reid reid@moab.cs.utah.edu
Subject: Haskell 98 non-conformance in qualifiers
The following program (from the testsuite) is not legal Haskell'98 but
is accepted by Hugs. The error is that you can't use the qualifier M
inside M (at least, not without first explicitly importing M).
tests/static/mod75.hs:
--!!! Qualifying with local module name
module M where
f x = M.f x
Looking at the code (static.c:findQualifier) it is clear that this
"bug" is the intended behaviour. If someone (e.g., Johan) could add
this to the list of known errors, I'll make the test suite stop
reporting this as a bug.
--
Alastair Reid reid@cs.utah.edu http://www.cs.utah.edu/~reid/
From reid@moab.cs.utah.edu Sat Apr 21 20:49:37 2001
Date: Sat, 21 Apr 2001 13:49:37 -0600 (MDT)
From: Alastair Reid reid@moab.cs.utah.edu
Subject: Haskell98 nonconformance: contexts on member functions
The H98 report explicitly says (section 4.3.1) that the type of member
functions may only add constraints to the type variables which are
local to the member.
Hugs accepts this (illegal program from the testsuite) without
reporting an error.
tests/static/mod39.hs:
--!!! Illegal constraints on member funs
module M where
class C a where f :: Eq a => a
If someone can do one of the following, I'll update the testsuite (so
it isn't reported as an error) accordingly:
1) Add this to the list of Hugs' non-conformance to the standard.
2) Make this report an error in Haskell 98 mode.
3) Make this report an error in both Haskell 98 and Hugs mode
--
Alastair Reid reid@cs.utah.edu http://www.cs.utah.edu/~reid/
From reid@moab.cs.utah.edu Sat Apr 21 21:03:26 2001
Date: Sat, 21 Apr 2001 14:03:26 -0600 (MDT)
From: Alastair Reid reid@moab.cs.utah.edu
Subject: Closed out some errors in the testsuite
[For the benefit of those not on the cvs-hugs list]
I've closed out all errors reported by the testsuite except those
mentioned in the previous 2 bug reports by the simple expedient of
deciding that Hugs was behaving correctly in all cases and updating
the expected output files accordingly.
One of the suspicious behaviours I decided to accept is, perhaps, a
little controversial: the builtin printer prefixes data constructor
names with the name of the type that the constructor belongs to. This
shows up in error messages and if you turn off "use 'show' to display
results"
Prelude> case Just 'a' of { Nothing -> 'b' }
Program error: {v1294 (Maybe_Just 'a')}
Prelude> :set -u
Prelude> Just 'a'
Maybe_Just 'a'
It is not completely clear to me whether:
1) the typename prefix is a good idea
2) the underscore should be replaced by some other punctuation such
as '.' or '@' or '/' or whatever.
I'd be interested in hearing people's opinions.
Historical note: I think the prefix was originally added to improve
the quality of heap profiling output. Since then it has been extended
to cover more and more kinds of entity (member functions, classes,
types, whatever).
--
Alastair Reid reid@cs.utah.edu http://www.cs.utah.edu/~reid/
From reid@moab.cs.utah.edu Sat Apr 21 21:12:06 2001
Date: Sat, 21 Apr 2001 14:12:06 -0600 (MDT)
From: Alastair Reid reid@moab.cs.utah.edu
Subject: background colour on Hugs home page
The Hugs homepage used to explicitly set the background colour to white.
A couple of years back, this got removed with the result that anyone
viewing the home page with a browser which uses grey as the default
background colour (i.e., users of Netscape) see a page that just looks
crap.
Can someone please add an explicit background colour back in?
--
Alastair Reid reid@cs.utah.edu http://www.cs.utah.edu/~reid/
From sigbjorn_finne@hotmail.com Sun Apr 22 21:34:30 2001
Date: Sun, 22 Apr 2001 22:34:30 +0200
From: Sigbjorn Finne sigbjorn_finne@hotmail.com
Subject: Haskell 98 non-conformance in qualifiers
Alastair Reid reid@cs.utah.edu writes:
>
> The following program (from the testsuite) is not legal Haskell'98 but
> is accepted by Hugs. The error is that you can't use the qualifier M
> inside M (at least, not without first explicitly importing M).
>
> tests/static/mod75.hs:
> --!!! Qualifying with local module name
> module M where
> f x = M.f x
That's legal Haskell 98 and should be accepted; see Section 5.5.1 of
the Report; bullet 1.
--sigbjorn
From rysiek@ipipan.gda.pl Sun Apr 22 22:41:59 2001
Date: Sun, 22 Apr 2001 23:41:59 +0200
From: Ryszard Kubiak rysiek@ipipan.gda.pl
Subject: isAlphanum
Thank you for your answer, Alastair:
> The online library report at haskell.org calls it isAlphaNum (not
> isAlphanum) so it looks as though Hugs is correct.
I've just checked that the name isAlphanum was used in older versions
of Haskell and Hugs while Haskell 98 introduces isAlphaNum. It's time
for me to remove the old versions of Prelude.hs from my computer!
There are, however, pieces of Haskell software around where the old
name is used. One example is the Regexp library by Meurig Sage. I will
write him about it. Another example is section 9.1 of online Hugs 98
manual.
Best Regards,
Rysiek
From Keith.Wansbrough@cl.cam.ac.uk Mon Apr 23 15:01:17 2001
Date: Mon, 23 Apr 2001 15:01:17 +0100
From: Keith Wansbrough Keith.Wansbrough@cl.cam.ac.uk
Subject: [repeat post] Re: Syntax for implicit parameters
[sorry for duplication; I missed out hugs-bugs before]
> Simon Peyton-Jones wrote:
> > [...]
> > 1. [happy]. Use 'let'
> > 2. [consent]. Use 'dlet' or 'with'
> > 3. [hate] Use both 'dlet' and 'with'
> >
> > Would the Hugs folk be willing to adopt (2)?
Please correct me if I'm wrong:
The two syntaxes are:
(i) let ?x = foo in bar
(ii) bar with ?x = foo
Surely we could use *zero* extra identifiers by writing:
(ia) let ?x = foo in bar
(iia) bar where ?x = foo
i.e., s/dlet/let/ and s/with/where/ .
I thought this was mentioned at the Haskell Implementors' Meeting.
--KW 8-)
--
Keith Wansbrough <kw217@cl.cam.ac.uk>
http://www.cl.cam.ac.uk/users/kw217/
Cambridge University Computer Laboratory.
From dac086@hotmail.com Mon Apr 23 19:23:03 2001
Date: Mon, 23 Apr 2001 11:23:03 -0700
From: Mark Dacoron dac086@hotmail.com
Subject: problems????????????? error
I am getting an error when trying to run this specific line in hugs
the line is
" half [1..35] where half x = take (length x 'div' 2) x"
and the error that i am getting is
"Improperly terminated character constant"
I do not know what is going on ????
please help
Mark Dacoron
_________________________________________________________________
Get your FREE download of MSN Explorer at http://explorer.msn.com
From jeff@galconn.com Mon Apr 23 20:22:40 2001
Date: Mon, 23 Apr 2001 12:22:40 -0700
From: Jeffrey R. Lewis jeff@galconn.com
Subject: problems????????????? error
Mark Dacoron wrote:
> I am getting an error when trying to run this specific line in hugs
> the line is
> " half [1..35] where half x = take (length x 'div' 2) x"
>
> and the error that i am getting is
> "Improperly terminated character constant"
>
> I do not know what is going on ????
> please help
> Mark Dacoron
> _______________________________
You are using the wrong kind of single quote for div: it should be `div`.
--Jeff
From reid@cs.utah.edu Mon Apr 23 22:32:06 2001
Date: Mon, 23 Apr 2001 15:32:06 -0600
From: Alastair Reid reid@cs.utah.edu
Subject: [repeat post] Re: Syntax for implicit parameters
> Surely we could use *zero* extra identifiers by writing:
>
> (ia) let ?x = foo in bar
> (iia) bar where ?x = foo
>
> i.e., s/dlet/let/ and s/with/where/ .
>
> I thought this was mentioned at the Haskell Implementors' Meeting.
I believe that is the favoured change amongst those that want change.
I've recently come across a new twist in the story though:
o let and where have a "letrec" semantics. That is:
let x = 1 in (let x=x in x)
is an infinite loop because it can be alpha renamed to:
let x = 1 in (let y=y in y)
o with and dlet have a non-recursive "let" semantics. That is:
dlet ?x=1 in (dlet ?x=?x in ?x)
has the value 1 because it can be renamed to:
dlet ?x=1 in (dlet ?y=?x in ?y)
The problem is that if they have the same syntax, then they probably
ought to have the same semantics wrt recursive/non-recursive bindings.
The semantics of dlet/with is entirely intentional on the part of the
designers of implicit parameters. For example, if you use implicit
parameters in an interpreter, you can use code like this to extend
the environment when processing a let expression:
eval (Let v e1 e2) = eval e2 with ?env = (v, eval e1) : ?env
(The IP paper has a different example based on pretty-printers but
I happen to find this one more compelling since I write code like
this all the time.)
--
Alastair
ps I don't happen to agree with the IP designers but I hope I understand
their argument well enough to have given a fair example of why
a non-recursive dlet/with is desirable. Apologies if not.
From reid@cs.utah.edu Mon Apr 23 23:24:34 2001
Date: Mon, 23 Apr 2001 16:24:34 -0600
From: Alastair Reid reid@cs.utah.edu
Subject: [repeat post] Re: Syntax for implicit parameters
I wrote:
> eval (Let v e1 e2) = eval e2 with ?env = (v, eval e1) : ?env
[Blush] Andy Gill pointed out that this example was ambiguous because
it wasn't clear if I wanted this "Let" to be recursive or non-recursive.
My intention was that this was a non-recursive let.
--
Alastair Reid
From mpj@cse.ogi.edu Thu Apr 26 09:04:17 2001
Date: Thu, 26 Apr 2001 01:04:17 -0700
From: Mark P Jones mpj@cse.ogi.edu
Subject: Syntax for implicit parameters
| Marcin Kowalczyk (qrczak@knm.org.pl) writes:
| > I would like to replace "with" and "dlet" with "let". But SimonPJ
| > said he won't do it in ghc unless Hugs does it too, and Mark P Jones
| > said he won't do it in Hugs now (without deep reasons: no
| > people/hours to do that, and no plans to release next Hugs version
| > this year).
|=20
| I'd really, really like to see a fresh release of Hugs ...
Noticing that Alastair listed my email address in his message, and
that Marcin "called me by name" in his comments above, I think it's
time for a gentle reminder: I don't work on Hugs any more!
In fact, as I announced at the time, I stopped working on Hugs in
January 2000. After working on it for almost a decade, I figured
that it was time for me to move on. That decision was not easy,
in part because of the time and energy that I have invested in
its development; because of the pleasure that your success stories
bring; and because of the dissappointment that I feel when I hear
from people who are frustrated by its limitations and weaknesses.
I am astonished, quite frankly, that Hugs is still in widespread
use today. I never expected it to last this long, or to have come
along quite so far. And yet, of course, it is still lacking in many
ways. But the system has acquired a life of its own, and no longer
reflects my views, needs, or efforts as it once did.
I still retain an interest in Haskell, and (for now at least)
I continue to read (and sometimes reply to) messages on the Hugs
mailing lists. And I do talk to Johan quite frequently about Hugs;
after all, his office is just a few doors away from mine. (Johan
is the current maintainer of Hugs, although I sometimes think people
don't realize that it's only a small part of his work, and not a
full-time activity.) I don't/won't/can't control Hugs as Marcin
suggests so it's not up to me to decide whether a change gets made
... nor am I the one that will make any changes.
[Incidentally, if I did control Hugs, I wouldn't make the suggested
change to "dlet"/"with" at this point. Marcin says I have no "deep
reasons" ... Hmm, I don't know about "deep", but I do have reasons
for this, both technical and pragmatic. But I'm not going to go into
detail because I don't think it will serve any useful purpose, and
because, if I'm going to let go, then I really do have to let go ...]
Please do with Hugs as you all see fit! Its future is in your hands
now, not mine! I hope you'll all have fun with it!
All the best,
Mark
From v-julsew@microsoft.com Thu Apr 26 17:19:14 2001
Date: Thu, 26 Apr 2001 09:19:14 -0700
From: Julian Seward (Intl Vendor) v-julsew@microsoft.com
Subject: Possible space leak from calloc call?
Using Feb 2001 in RedHat 7.1, loading the Prelude and then
exiting:
=3D=3D6469=3D=3D 48000 bytes in 1 blocks are possibly lost in loss =
record 41 of
41
=3D=3D6469=3D=3D at 0x4004E458: calloc
=3D=3D6469=3D=3D by 0x80818B3: expandSubst (subst.c:161)
=3D=3D6469=3D=3D by 0x808195F: newTyvars (subst.c:184)
=3D=3D6469=3D=3D by 0x80618A6: initTCKind (static.c:2690)
I don't know if this is either significant, or avoidable.
J
From simonmar@microsoft.com Fri Apr 27 10:37:24 2001
Date: Fri, 27 Apr 2001 10:37:24 +0100
From: Simon Marlow simonmar@microsoft.com
Subject: Syntax for implicit parameters
> [Incidentally, if I did control Hugs, I wouldn't make the suggested
> change to "dlet"/"with" at this point. Marcin says I have no "deep
> reasons" ... Hmm, I don't know about "deep", but I do have reasons
> for this, both technical and pragmatic. But I'm not going to go into
> detail because I don't think it will serve any useful purpose, and
> because, if I'm going to let go, then I really do have to let go ...]
Mark - I think the reason that you're being asked to comment on this
discussion is because we'd like to know what these reasons are! It
would be a pity if us implementors made a unilateral decision on syntax
that ended up being misguided.
Cheers,
Simon
From simonpj@microsoft.com Sun Apr 29 20:16:26 2001
Date: Sun, 29 Apr 2001 12:16:26 -0700
From: Simon Peyton-Jones simonpj@microsoft.com
Subject: Forall syntax
Dear Huggy people,
I've just noticed that Hugs uses slightly different
syntax than GHC for explicit for-alls in types.=20
In Hugs you say
forall a,b,c. ...type....
In GHC you say
forall a b c. ...type...
It's a pity to have unnecessary syntactic differences.
Could we make them the same?
I'd like to suggest that GHC is more consistent with
the rest of Haskell. At the term level we don't use
commas when we quantify:
\ a b c -> .... not \ a,b,c -> .....
It's a pretty easy change to make. What think you?
=09
Simon
From andyjgill@home.com Mon Apr 30 04:12:23 2001
Date: Sun, 29 Apr 2001 20:12:23 -0700
From: Andy Gill andyjgill@home.com
Subject: Forall syntax
Simon, et. al,
forall tends to be used with one argument, hence the reason its not
really biting right now. If no-one objects, I'll change it this week
at some point, to match GHC. The "lambda does not use comma" seems
convincing to me.
Andy
-----Original Message-----
From: hugs-bugs-admin@haskell.org [mailto:hugs-bugs-admin@haskell.org]On
Behalf Of Simon Peyton-Jones
Sent: Sunday, April 29, 2001 12:16 PM
To: hugs-bugs@haskell.org
Cc: simonpj@microsoft.com
Subject: Forall syntax
Dear Huggy people,
I've just noticed that Hugs uses slightly different
syntax than GHC for explicit for-alls in types.
In Hugs you say
forall a,b,c. ...type....
In GHC you say
forall a b c. ...type...
It's a pity to have unnecessary syntactic differences.
Could we make them the same?
I'd like to suggest that GHC is more consistent with
the rest of Haskell. At the term level we don't use
commas when we quantify:
\ a b c -> .... not \ a,b,c -> .....
It's a pretty easy change to make. What think you?
Simon
_______________________________________________
Hugs-Bugs mailing list
Hugs-Bugs@haskell.org
http://www.haskell.org/mailman/listinfo/hugs-bugs
From mpj@cse.ogi.edu Mon Apr 30 08:52:23 2001
Date: Mon, 30 Apr 2001 00:52:23 -0700
From: Mark P Jones mpj@cse.ogi.edu
Subject: Forall syntax
Hi Simon, Andy, et al.
| [Hugs and GHC should agree on a syntax for forall expressions ... one
| that doesn't require commas between variable names ...]
|
| forall tends to be used with one argument, hence the reason its not
| really biting right now.
The reason it's not biting is that the problem doesn't exist! :-) I =
have
strong recollections that I noticed and fixed this inconsistency while
traveling on a train through the French countryside in September 1999
... even if my memory is failing me, the most recent Hugs seems to =
accept
forall's without commas between arguments. Perhaps Simon is using an =
old
version of Hugs, looking at some out of date documentation, or has found
a specific instance where the change was missed?
All the best,
Mark
From simonpj@microsoft.com Mon Apr 30 09:08:38 2001
Date: Mon, 30 Apr 2001 01:08:38 -0700
From: Simon Peyton-Jones simonpj@microsoft.com
Subject: Forall syntax
| forall tends to be used with one argument, hence the reason=20
| its not really biting right now. If no-one objects, I'll=20
| change it this week at some point, to match GHC. The "lambda=20
| does not use comma" seems convincing to me.
Great, thank you.
Simon
From simonpj@microsoft.com Mon Apr 30 09:11:37 2001
Date: Mon, 30 Apr 2001 01:11:37 -0700
From: Simon Peyton-Jones simonpj@microsoft.com
Subject: Forall syntax
| The reason it's not biting is that the problem doesn't exist!=20
| :-) I have strong recollections that I noticed and fixed=20
| this inconsistency while traveling on a train through the=20
| French countryside in September 1999 ... even if my memory is=20
| failing me, the most recent Hugs seems to accept forall's=20
| without commas between arguments. Perhaps Simon is using an=20
| old version of Hugs, looking at some out of date=20
| documentation, or has found a specific instance where the=20
| change was missed?
I was probably using a (very) out of date version of Hugs.
I should have mentioned that. It didn't occur to me that the
syntax might have changed, though it should have. =20
Apologies for wasting time.
Simon
From simonpj@microsoft.com Mon Apr 30 13:22:13 2001
Date: Mon, 30 Apr 2001 05:22:13 -0700
From: Simon Peyton-Jones simonpj@microsoft.com
Subject: Syntax for implicit parameters
Erik Meijer, John Launchbury and I discussed the syntax of implicit
parameters at WG2.8 last week.
We emerged with agreement on the following: instead of 'with' use
let dynamic
?x =3D 3
?y =3D ?y+?x
in =09
...
* 'dynamic' is a special-id, only significant immediately following
a let.
* The bindings are non-recursive, and nested top to bottom
Reasons:
- All other Haskell constructs are prefix form, and extend as far
to the right as possible: let, case, lambda. Using the same
convention
eliminates the question of what=20
let x =3D 4 in E with ?y =3D 4
might mean
The exception to prefix form is 'where' but it scopes over groups=20
of right-hand sides, not expressions
- We wanted a clear clue that this is not a standard-Haskell recursive
let
=20
- We didn't want to take an extra keyword.
I (very much) hope this is acceptable to everyone. It's not worth
a major use of brain cells, but it would be great to make GHC and
Hugs agree.
Simon
PS: I recall that Alastair volunteered to make the change to Hugs.
From office_management@desertmail.com Tue Apr 24 07:50:22 2001
From: office_management@desertmail.com (office_management@desertmail.com)
Date: Mon, 23 Apr 2001 23:50:22 -0700
Subject: ===Myth - all HGH products are the same=== 136432211111110000
Message-ID:
Have You Heard of Human Growth Hormone (HGH)?
Released by your own pituitary gland, HGH starts declining
in your 20s, even more in your 30s and 40s, eventually resulting
in the shrinkage of major organs -- plus, all
other symptoms related to old age.
All HGH (Human Growth Hormone) products are not the same.
There are three different types of products.
Yet, all three are advertised as if they where the same.
The three types are:
1) Homeopathic HGH
2) Pre-cursor HGH
3) Real or synthetic HGH (delivered by injection
or, by an oral spray method).
Do you know the differences?
Call us and we'll explain them to you.
Our toll free number is 1-888-621-7300.
For more information on HGH read on............
In Thousands of Clinical Studies Human Growth Hormone
has been proven to accomplish the following:
+ Reduce Body Fat and Build Lean Muscle
WITHOUT EXERCISE!
+ Enhance Sexual Performance
+ Remove Wrinkles and Cellulite
+ Lower Blood Pressure and Improve Cholesterol Profile
+ Improve Sleep, Vision and Memory
+ Restore Hair Color and Growth
+ Strengthen the Immune System
+ Increase Energy and Cardiac Output
+ Turn back your body's Biological Time Clock 10 - 20 years
+ Live Longer and Stronger
All natural and organic plant based
Feel 10 Years Younger in 10 Weeks
We are the manufacturer and we sell directly to Doctors,
Chiropractors, and consumers world wide the highest grade
HGH Oral Spray available.
With internet marketing, we are able to save advertising
cost and pass those savings along to you.
But you must act now.
To receive more information call us now.
Toll Free 1-888-621-7300
We must speak to you in person to qualify your usage.
All of your questions will be addressed and answered in a friendly,
no pressure manner. Our main purpose is to provide you with
information so you can make an educated decision.
For more information call
1-888-621-7300
If you are on line write down our
phone number and call us when you can.
Soon, you and your loved ones will be very glad you did.
Read what people are saying:
"The effects of 6 months of GH on
lean body mass and fat were equivalent
in magnitude to the changes incurred
during 10-20 years of aging."
Dr. Daniel Rudman, MD,
New England Journal of Medicine.
"Within four months, my body fat decreased
form 30% down to 21%! I noticed my skin
is more supple and my overall mental
outlook improved significantly."
D.W., New Jersey
"We have been on the spray for just 3 weeks
now, and besides the tremendous energy we
both feel, my husbands allergies and spells
of depression have lifted. I am healing
extremely fast after an accident and have
lost 7 lbs. without trying!"
C.B., Flagstaff. AZ
Thanks for reading our letter,
The HGH Staff
USA Division
PS: The HGH Staff guarantees the
highest quality and lowest price.
We manufacture and ship directly to your door.
Call us now 1-888-621-7300
***********************************************************
======= End of message ========
To Qualify for a Free HGH Consultation
call the HGH Staff -- Today.
***********************************************************
The following statement is provided to be
in compliance with commercial email laws.
If you do not wish to receive further
mailings, please click reply
and type remove in the subject box.
Then click send.
This message is in full compliance with
U.S. Federal requirements for commercial
email under bill S.1618 Title lll, Section 301,
Paragraph (a)(2)(C) passed by the 105th U.S.
Congress and is not considered SPAM
since it includes a remove mechanism.
***********************************************************
This message is not intended for residents in the
states of CA, NC, NV, RI, TN, VA & WA.
Screening of addresses has been done to the best
of our technical ability.
***********************************************************
Call us now 1-888-621-7300
for your free HGH consultation