From Christian.Laaser@icn.siemens.de Thu Mar 1 08:54:27 2001
Date: Thu, 1 Mar 2001 09:54:27 +0100
From: Laaser Christian Christian.Laaser@icn.siemens.de
Subject: AW: "Compiled code too complex" error message - Problem solved.
Thank you very much for your message.
I think the new Feb 2001 distribution doesn't use the large version.
Look at the code extract from options.h:
#define SMALL_HUGS 0
#define REGULAR_HUGS 0
#define LARGE_HUGS 0
If I understand it correctly LARGE_HUGS should normally be defined as 1 =
so that the large version is used by default.
I can confirm that changing NUM_FIXUPS to 1000 solves my problem
because I used Feb 2001 distribution with the modified hugs.exe=20
Karl M. Syring sent me and the interpreter is working fine.
Christian
> -----Urspr> =FCngliche Nachricht-----
> Von: Alastair Reid [SMTP:reid@cs.utah.edu]
> Gesendet am: Montag, 26. Februar 2001 18:22
> An: Laaser Christian; 'Mark P Jones'
> Cc: hugs-bugs@haskell.org; kort@wins.uva.nl; Lescher Christian
> Betreff: RE: AW: What does "Compiled code too complex" error message =
of Hugs mean?
>=20
> Laaser Christian writes:
>=20
> > I installed the new Feb 2001 distribution and I saw that NUM_FIXUPS
> > with value 1000 is only possible for large version of hugs =
interpreter.
> > It would be great if I could get this version because the standard
> > interpreter
> > only has a NUM_FIXUPS of 400 and so I get the error message
> > "Compiled code too complex".
>=20
> Almost every machine in existence uses the large version so I'm a bit =
surprised
> by this report. Can you confirm:
>=20
> a) That your machine _does not_ use the large version.
> (Look at the values of SMALL_HUGS, REGULAR_HUGS and LARGE_HUGS in
> hugs98/src/options.h)
>=20
> b) That changing NUM_FIXUPS to 1000 fixes your problem.
>=20
> If you are indeed using the regular version, is there any reason why =
you can't
> use the large version?
>=20
> --
> Alastair Reid
From haberg@matematik.su.se Thu Mar 1 09:38:11 2001
Date: Thu, 1 Mar 2001 10:38:11 +0100
From: Hans Aberg haberg@matematik.su.se
Subject: Feb2001 hugs98 on MacOS
At 15:56 -0800 2001/02/28, Johan Nordlander wrote:
>With all due respect, but here's some reasons why the previous Hugs
>maintainers
>might have been reluctant to let your variant of Hugs into the main source
>tree:
>it's big, it's unstructured, it's a mix of various unrelated features, and it
>carries some serious implications to the overall program reliability that
>I know
>no maintainer would accept (read unsafe asynchrony).
One could think that you are describing the Hugs kernel sources themselves. :-)
My guess is that you simply didn't understand it at the first glance, and
it will take more than a first glance to for anybody to understand it:
I and Pablo over some years gradually merged and added a series of features
to produce that version.
>We now have basic MacOS support included in the distribution.
My guess that version you produced will produce some intense traffic on the
Hugs_Bugs list, due to its limitations.
> What I'm offering
>you and anybody else interested is to submit extension proposals, one at a
>time,
>and I'll add them to the main sources if they seem to be useful, well-written,
>and free of unwanted side-effects. I'm not interested in buying a whole
>package. And if I'm to spend time understanding/fixing (say) a stack-checking
>extension, I'd rather do that if it would benefit all Hugs users, not just
>those
>who run the Mac version. The same holds for profiling.
Well, you seem to be a guy with a lot of time. -- I do not have that much time.
>So please see if you can find the time to break down your additions into more
>manageable units, that are based on the Feb 2001 sources. I'll seriously
>consider each one of them.
It would take too long time trying to baby-feed you with all those details.
Please understand that this MacOS programming is extremely time-consuming,
and I found those pieces interesting at the time I did them, but I am not
interested in spend all that time explaining the code, simply because
somebody is too lazy to read the code itself.
> In their absence I'll probably try to add some
>simple drag-and-drop support, but not much more.
I hope you noticed that the DropUNIX package you once implemented isn't
safe, as strange things happen when dropping files on Hugs while running.
I think you are in for a long haul if you want to redo the GUI we so far
have implemented.
Hans Aberg
From haberg@matematik.su.se Thu Mar 1 10:11:34 2001
Date: Thu, 1 Mar 2001 11:11:34 +0100
From: Hans Aberg haberg@matematik.su.se
Subject: Feb2001 hugs98 on MacOS
At 15:35 -0700 2001/02/28, Alastair Reid wrote:
>2) Events cause direct calls into Haskell code. (It's pretty easy to do this
>nowadays using the foreign export dynamic feature of the ffi.) The only trick
>here is that, because Hugs doesn't support preemption, events must only be
>delivered at certain safe points. For example, the program might contain a
>main loop which queries for events, dispatches a call into Haskell code to
>handle the event and then returns the result of the event handler to the C
>world. Or, if events appear as asynchronous calls into a C thread, the
>Haskell
>program might run with events disabled in most of the code and only enable
>them
>by calling into a C function which enables events, waits for the program to
>complete (during which time it is handling events, of course), and then
>disables events again.
Right. This is the way to do it. As for the AppleEvent's, it is simpler
still, because they are not completely asynchronous (asynchronously
independent threads), but stacked:
First, let's define what an AppleEvent is. It is a high level event, that
is, binary structures that programs use to communicate with each other.
(They are iterated typed binary structures, like that can be produced by a
C++ polymorphic hierarchy, except that they are largely passive, that is,
do not contain function pointers.)
If a program should be able receive an AppleEvent, it must make up its mind
which ones. So at startup-time, one registers which ones. When a registered
AppleEvent arrive, the OS looks up which registered function pointer to
call. This selected function pointer may or may not engage the Hugs kernel
when executed. So there are some standard AppleEvent's which do not engage
the Hugs kernel at all, as they are intercepted.
Now, the way I hooked it up, not handled AppleEvent's are translated into a
string. Hugs then looks for a primitive in a module Event. If the module is
not present, then the Hugs kernel is not engaged. (Thus, only those that
load this module Event may experience any problems with asynchronizity.)
If, on the other hand, the module Event is loaded, the suitable primitive
is activated. -- There are in fact two primitives, depending whether a
reply is expected or not (which gives rise to different Haskell typing).
Now, when the primitive is executed, it will, if no global data is used,
merely use some additional stack space, and after termination, the stack
will be restored to what it was before.
The only trick needed is to make sure execution does not start at an
unfortunate moment (middle of a stack maintenance function or something).
>I'm yet to hear of a reason why AppleEvents cannot be dealt with using one of
>these approaches (i.e., without requiring substantial internal changes to
>Hugs).
So there is some tweaking needed. The reason I did not do it, is that I am
not at all at home with the Hugs kernel and its workings. I was hoping
someone familiar with the Hugs kernel would do it in the future.
But it seems that with a little tweaking, one could produce something
reasonably safe.
-- In addition, I can remark that AppleEvent's are said to unique to the
MacOS, and some say that in some industries, like graphics, the use of
AppleEvent's has made the platform a preferred one.
The connection with Haskell is roughly this:
Functional languages translate code into "functional covers", that can
later execute. I built such a functional cover which understands lambda
calculus using a C++ polymorphic hierarchy. The AppleEvent's are similar to
such a hierarchy, except that they are passive data.
But this gives me the hunch that there ought to be a closer relation
between Haskell and AppleEvent's.
-- I do not, however, have the time, to explore this in detail myself.
(AppleEvent's are quite complicated. Each program can have its own
dictionary, and so there might be different ways to express the same thing,
depending which program should receive the event.)
But I think it is might be an interesting computing topic.
Hans Aberg
From haberg@matematik.su.se Thu Mar 1 10:24:34 2001
Date: Thu, 1 Mar 2001 11:24:34 +0100
From: Hans Aberg haberg@matematik.su.se
Subject: Feb2001 hugs98 on MacOS
At 15:47 -0700 2001/02/28, Alastair Reid wrote:
>Some advice to people submitting changes:
>
>Back in the days when I was maintaining Hugs, changes were substantially more
>likely to be merged into the main base if they were decomposed into a
>number of
>small, independent changes whose impact and consequences could be
>understood in
>isolation from the other changes.
>
>For example, Hans' stack overflow changes sound like a feature that all Hugs
>users could benefit from (i.e., not just MacOS users) but it really needs
>to be
>submitted as a separate set of patches if Johan is to correctly integrate them
>and if various individuals around the world are to submit modifications which
>make the stack overflow code work on other platforms (Sparcs, x86s, etc.)
I think so too, that some such stuff should be of general applicability.
The things that do not fall into this category, and is platform specific,
should be moved, and be put into a separate set of sources. (As I have done
with some of the Mac stuff that formerly was in the Hugs kernel sources.)
The reason this does not happen entirely so, is that the Hugs kernel code
is very monolithic, with nearly all names not exported, .c files exotically
included in .c files, instead of putting the relevant names in a header.
So it is hard to do something as intrusive as making an MacOS
implementation of it without putting in the right hooks.
As for the code itself, the only reasonable is to put it in as it is, and
move then move the portions when one knows where they should be. -- It is
too big, to do anything else. (One will end up on the equation that Johan
is experimenting with, trying to reimplement rather a lot of work.)
-- As for myself, I do not really have time even to patch up new version
every time the is a new release of the Hugs kernel.
So if you want to make your own, entirely new reimplementation, I can only
wish you good luck! :-)
Hans Aberg
* Email: Hans Aberg <mailto:haberg@member.ams.org>
* Home Page: <http://www.matematik.su.se/~haberg/>
* AMS member listing: <http://www.ams.org/cml/>
From v-julsew@microsoft.com Thu Mar 1 10:41:56 2001
Date: Thu, 1 Mar 2001 02:41:56 -0800
From: Julian Seward (Intl Vendor) v-julsew@microsoft.com
Subject: Feb2001 hugs98 on MacOS
| Some advice to people submitting changes:
|=20
| Back in the days when I was maintaining Hugs, changes were
substantially more
| likely to be merged into the main base if they were decomposed into a
number of
| small, independent changes whose impact and consequences could be
understood in
| isolation from the other changes.
The same issue crops up from time to time for the Linux kernel
development community, wherein the keepers of the kernel
(Torvalds, Cox, et al) are much more likely to accept patches in the
form Alastair describes, precisely for the reason he mentions,
and those whose large, all-encompassing patches are rejected
get hot under the collar. Assimilation of large chunks of code
implementing new subsystems (ie, the ReiserFS file system) is
slow indeed.
So this is not by any means a new problem.
I tend to sympathise with Alastair/Johan. For us, keeping GHC=20
working on one platform is not too difficult. Trying to ensure=20
that it keeps going on all supported platforms without inordinate=20
amounts of effort, is IMO easily the biggest engineering challenge
we face.
</red-herring>
J
From haberg@matematik.su.se Thu Mar 1 11:54:59 2001
Date: Thu, 1 Mar 2001 12:54:59 +0100
From: Hans Aberg haberg@matematik.su.se
Subject: Feb2001 hugs98 on MacOS
At 15:35 -0700 2001/02/28, Alastair Reid wrote:
>I'm yet to hear of a reason why AppleEvents cannot be dealt with using one of
>these approaches (i.e., without requiring substantial internal changes to
>Hugs).
One difference between the low events and the high-level AppleEvent events
is that the former are put in a queue, and the latter are interrupts. Thus
low-level events wait for somebody bothering about them.
But with the AppleEvent, one ends up with a function that is executing.
This function must then decide whether it is an appropriate moment to
engage the Hugs kernel or not. If it is an inappropriate moment, it must
decide what to do: Either prepare the kernel appropriately, skip it, or
whatever.
Hans Aberg
From haberg@matematik.su.se Thu Mar 1 12:25:47 2001
Date: Thu, 1 Mar 2001 13:25:47 +0100
From: Hans Aberg haberg@matematik.su.se
Subject: Feb2001 hugs98 on MacOS
At 02:41 -0800 2001/03/01, Julian Seward (Intl Vendor) wrote:
>I tend to sympathise with Alastair/Johan. For us, keeping GHC
>working on one platform is not too difficult. Trying to ensure
>that it keeps going on all supported platforms without inordinate
>amounts of effort, is IMO easily the biggest engineering challenge
>we face.
Well, as the MacOS implementation, it was developed in small chunks at
need, but the Hugs team seemed to not bother to put it in for the last few
years. Thus, they now have a large backlog.
The MacOS intrusions are not that big: The MacOS (pre-X) is distinctively
different from any other platform in that it does not have a shell, and
that forces the need of hooks. The MacOS does not provide stack-checks, so
that has to be implemented by intrusion into the code. Nor does it have
pre-emptive multitasking, only cooperative, which means that one must
intrude into the code to release time to other programs. Etc.
As Alan said, these things ought really to be a part of the Hugs
distribution, as they might be of importance to other platforms. In fact,
some of the MacOS stuff was implemented by riding on the code intrusions
already made for the MS Windows.
It seems me that Johan Nordlander, the first person for a few years
bothering about this Mac stuff at all, is new to it, so he has picked out
everything that he does not immediately understand. However, he then pretty
much breaks everything that makes the MacOS version useful. To fix it up on
the course he lays out will take up a lot of time, as Mac programming is
very time consuming. (Kevin Hammond spend more time on the Mac GUI than
what spent on the Hugs kernel at that time!)
On the other hand, there is now a MacOS X, which has existed half-a-year in
a beta, and gets public by the end of March. MacOS X does have pre-emptive
multitasking, stack-checks, threading (it is built up around a Mach 3
kernel), and the other stuff expected of a modern OS plus some. So much of
that special pre-MacOS X will not be needed.
So, on the one hand, Johan Nordlander at this late date lays out an
extremely time-consuming course for himself, hoping others to join, while
on the same time, it looks it is not worth spending any time at it at all
as far as pre-MacOS X implementation goes.
Some of the stuff may survive if there still are cooperative multitasking
platforms under which Hugs may run.
Hans Aberg
From ashley@semantic.org Thu Mar 1 13:06:24 2001
Date: Thu, 1 Mar 2001 05:06:24 -0800
From: Ashley Yakeley ashley@semantic.org
Subject: Bug in Hugs 98 MacOS Feb-2001: Crash while Compiling Multiple-Argument Fundep
Product: Hugs 98 MacOS Feb-2001
Hugs Preferences:
-98 -h1000000
To Repro:
attempt to load a file with this line:
class C a b c | a,b -> c where
Results:
Hugs 98 crashes with a "Type 2 Error"
Expected:
Is this valid extended Haskell? Compile it or give an error.
--
Ashley Yakeley, Seattle WA
From llenium@ntlworld.com Thu Mar 1 19:40:14 2001
Date: Thu, 1 Mar 2001 19:40:14 -0000
From: Jamie Stevenson llenium@ntlworld.com
Subject: Hugs 2001 release running under Windows 2000
Hello
I am trying to run Hugs Feb 2001 release under Windows 2000. File system is
NTFS. Hugs is sitting in its own folder (Hugs98) on the my c drive.
Can't run it - if you can give me any comments I would be greatly
appreciative.
e-mail: stevensj@dcs.gla.ac.uk
Many thanks
Jamie Stevenson
From jbell@mathsoft.com Thu Mar 1 19:42:44 2001
Date: Thu, 1 Mar 2001 14:42:44 -0500
From: Jonathon Bell jbell@mathsoft.com
Subject: possible bug?
i'm tinkering with the Feb 2001 release of hugs, and came across the
following problem while attempting to create my own prelude:
module MyPrelude where
import Prelude((:))
hd(x:xs) = x
...
The compiler complains of a syntax error occuring in the import declaration:
(unexpected symbol ":"). I may well be mistaken since i am somewhat new to
haskell programming, but it seems to me that i ought to be able to
explicitly import the list type constructor just like any other identifier.
Thanks for a doing a great job supporting hugs, and keep up the good work...
________________________________
Jonathon Bell jbell@mathsoft.com
MathSoft, Inc. www.mathsoft.com
101 Main St, Cambridge, MA 02142
(617) 577-1017 x745
From josefs@cs.chalmers.se Fri Mar 2 09:39:33 2001
Date: Fri, 2 Mar 2001 10:39:33 +0100 (MET)
From: Josef Svenningsson josefs@cs.chalmers.se
Subject: possible bug?
On Thu, 1 Mar 2001, Jonathon Bell wrote:
> i'm tinkering with the Feb 2001 release of hugs, and came across the
> following problem while attempting to create my own prelude:
>
> module MyPrelude where
>
> import Prelude((:))
>
> hd(x:xs) = x
> ...
>
> The compiler complains of a syntax error occuring in the import declaration:
> (unexpected symbol ":").
Here's a similar one:
\begin{code}
module Foo where
import List (\\)
apa bepa cepa = bepa \\ cepa
\end{code}
This module gives:
ERROR bug.hs:3 - Syntax error in import declaration (unexpected symbol
"\\")
Both examples are correct haskell programs according to the report.
/Josef
From koen@cs.chalmers.se Fri Mar 2 10:05:19 2001
Date: Fri, 2 Mar 2001 11:05:19 +0100 (MET)
From: Koen Claessen koen@cs.chalmers.se
Subject: possible bug?
Josef Svenningsson wrote:
| module Foo where
|
| import List (\\)
|
| apa bepa cepa = bepa \\ cepa
Shouldn't this be:
import List((\\))
(Double parantheses: one for the module import, one for the
operator.)
/Koen
From josefs@cs.chalmers.se Fri Mar 2 10:09:29 2001
Date: Fri, 2 Mar 2001 11:09:29 +0100 (MET)
From: Josef Svenningsson josefs@cs.chalmers.se
Subject: possible bug?
Koen Claessen wrote:
> Josef Svenningsson wrote:
>
> | module Foo where
> |
> | import List (\\)
> |
> | apa bepa cepa = bepa \\ cepa
>
> Shouldn't this be:
>
> import List((\\))
>
> (Double parantheses: one for the module import, one for the
> operator.)
>
You're right, ofcourse. (*slapping the forehead*)
Sorry to bother you all.
/Josef
From sigbjorn_finne@hotmail.com Fri Mar 2 10:35:23 2001
Date: Fri, 2 Mar 2001 11:35:23 +0100
From: Sigbjorn Finne sigbjorn_finne@hotmail.com
Subject: possible bug?
Jonathon Bell jbell@mathsoft.com writes:
>
> i'm tinkering with the Feb 2001 release of hugs, and came across the
> following problem while attempting to create my own prelude:
>
> module MyPrelude where
>
> import Prelude((:))
>
> hd(x:xs) = x
> ...
>
> The compiler complains of a syntax error occuring in the import
declaration:
> (unexpected symbol ":"). I may well be mistaken since i am somewhat new to
> haskell programming, but it seems to me that i ought to be able to
> explicitly import the list type constructor just like any other identifier
No, the cons operator has special status in H98 (in earlier version of
Haskell,
this wasn't the case); it is considered to be part of the syntax for lists,
just
like [] and [x1,x2] is. See the discussion of reservedops in Section 2.4 of
the report.
hth
--sigbjorn
From sievers@ips.cs.tu-bs.de Fri Mar 2 14:10:42 2001
Date: Fri, 2 Mar 2001 15:10:42 +0100 (MET)
From: Christian Sievers sievers@ips.cs.tu-bs.de
Subject: problem with hiding?
Hello,
there may be a bug with hiding imports.
I tried to load Functional Metapost
(http://www.informatik.uni-bonn.de/~ralf/FuncMP.tar.gz)
and expected all sorts of problems as it is described to be written in
Haskell 1.4, but not this one:
Prelude> :l FMPMain
[...]
ERROR FMPMain.lhs - Entity "space" imported from module "FMPPP"
already defined in module "FMPPicture"
However, the file FMPMain.lhs contains the line
> import FMPPicture hiding (text, empty, space)
I cannot see what's going here: simple tests with hiding worked well.
I'm using the Feb 2001 version.
All the best
Christian Sievers
From nordland@cse.ogi.edu Fri Mar 2 18:53:12 2001
Date: Fri, 02 Mar 2001 10:53:12 -0800
From: Johan Nordlander nordland@cse.ogi.edu
Subject: problem with hiding?
Christian Sievers wrote:
>
> Hello,
>
> there may be a bug with hiding imports.
>
> I tried to load Functional Metapost
> (http://www.informatik.uni-bonn.de/~ralf/FuncMP.tar.gz)
> and expected all sorts of problems as it is described to be written in
> Haskell 1.4, but not this one:
>
> Prelude> :l FMPMain
> [...]
> ERROR FMPMain.lhs - Entity "space" imported from module "FMPPP"
> already defined in module "FMPPicture"
>
> However, the file FMPMain.lhs contains the line
> > import FMPPicture hiding (text, empty, space)
>
> I cannot see what's going here: simple tests with hiding worked well.
> I'm using the Feb 2001 version.
>
> All the best
> Christian Sievers
The reason this example doesn't work is because of the module FMPMpsyntax, which
imports FMPPicture selectively, and then reexports FMPPicture in the module
header. Hugs doesn't implement this correctly, it reexports all identifiers of
every module mentioned in its export list.
I'm afraid this is a known bug that's been there since Hugs started to support
modules. It's on my list of things to do, but not very highly prioritized. But
I can always be persuaded...
All rthe best,
Johan
From andreas.marth@daimlerchrysler.com Fri Mar 2 21:02:06 2001
Date: Fri, 2 Mar 2001 22:02:06 +0100
From: andreas.marth@daimlerchrysler.com andreas.marth@daimlerchrysler.com
Subject: strange bug
--Boundary=_0.0_=0057440008851988
Content-Type: text/plain; charset=ISO-8859-1; name="MEMO 03/02/01 22:01:22"
Content-Transfer-Encoding: quoted-printable
Content-Disposition: inline
Hallo everybody!
The file bug1.hs includes an example where acording to main sT=3D=3DsXX=
P is True,=20
but sXXP=3D=3DsT is False.
The file bug2.hs doesn't have the problem after inlinige one where clau=
se.
The file bug3.hs also doesn't have the problem after adding a type sign=
ature to=20
the function "h0CMt".
So what exactly is the problem here?
Thanks,
Andreas
=
--Boundary=_0.0_=0057440008851988
Content-Type: application/octet-stream; name=bug1.hs
Content-Transfer-Encoding: base64
Content-Disposition: attachment; filename=bug1.hs
aW1wb3J0IEFycmF5CgpkYXRhIENNIGEgPSBaTSB8IE0gKEFycmF5IChJbnQsSW50KSBhKSAKCWRl
cml2aW5nIChTaG93LEVxKQoKZGF0YSBSRCA9ICAgIE5CICEoRG91YmxlLEludCxJbnQpCgpnZXRE
YXRhIG4gZGw9Y2FzZSBlcmcgb2YKICAgICAgICAgICAgICAgICAgICAgICAgW2hdICAgICAtPiBo
CiAgICAgICAgICAgICAgICAgICAgICAgIF8gICAgICAgLT4gZXJyb3IgKCJlcnJvciBpbiBnZXRE
YXRhIikKICAgICAgICAgICAgICAgICAgICB3aGVyZSBlcmc9W2R8KHgsZCk8LWRsLHg9PW5dCgpz
WFhQIDo6IEFycmF5IChJbnQsSW50KSAoQ00gRG91YmxlKQpzWFhQID0gbGlzdEFycmF5ICgoMSwx
KSwoMSw0KSkgW00gKGxpc3RBcnJheSAoKDEsMSksKDEsMSkpIFsxLjBdKSxaTSxaTSxaTV0KCnhC
ZGkgOjogQXJyYXkgSW50IChBcnJheSBJbnQgRG91YmxlKQp4QmRpPSBsaXN0QXJyYXkgKDEsNCkg
W2FycmF5ICgxLDEpIFsoMSwxMCldLGFycmF5ICgxLDEpIFsoMSw1KV0sYXJyYXkgKDEsMikgWygx
LDMuNSksKDIsMS41KV0sYXJyYXkgKDEsMSkgWygxLDApXV0gICAKCm1haW4gID0gZG8JbGV0IHNU
ID0gZm9vIHhCZGkgWygiUk4xIixbKDAuMCwzLjI0ZS0wNildKV0gKCJSTjEiLE5CICgxLjAsMSwx
KSkKCQlwdXRWYWwgInNUPT1zWFhQIiAoc1Q9PXNYWFApCgkJcHV0VmFsICJzWFhQPT1zVCIgKHNY
WFA9PXNUKQoJCXB1dFZhbCAiYm5kcyBzVCBzWFhQIiAoKChib3VuZHMpIHNUKT09KChib3VuZHMp
IHNYWFApKQoJCXB1dFZhbCAiYm5kcyAraWQgc1Qgc1hYUCIgKCgoYm91bmRzLmlkKSBzVCk9PSgo
Ym91bmRzKSBzWFhQKSkKCQlwdXRWYWwgImlkICtibmRzIHNUIHNYWFAiICgoKGlkLmJvdW5kcykg
c1QpPT0oKGJvdW5kcykgc1hYUCkpCgkJcmV0dXJuICgpCgpmb28gOjogQXJyYXkgSW50IChBcnJh
eSBJbnQgRG91YmxlKS0+WyhTdHJpbmcsWyhEb3VibGUsRG91YmxlKV0pXS0+KFN0cmluZyxSRCkt
PkFycmF5IChJbnQsSW50KSAoQ00gRG91YmxlKQpmb28geGggcmRsaCAocm4scmQpID0gY2FzZSBy
ZCBvZgogCQkJKE5CIChmLHAscykpICAgICAJCQktPiBoCgkJCQl3aGVyZQoJCQkJaAk9IGhDTXQg
WyhwLGhNYXQpXQoJCQkJaE1hdAk9IGVNYXQgcyBmCgkJCXdoZXJlCgkJCShsYix1YikJCT0gYm91
bmRzIHhoCgkJCS0taDBDTXQgOjogQXJyYXkgKEludCwgSW50KSAoQ00gRG91YmxlKQoJCQloMENN
dAk9IGFjY3VtQXJyYXkgKFxhIF8tPiBhKSBaTSAoKDEsbGIpLCgxLHViKSkgW10KCQkJZU1hdCBn
IHcJPSBhY2N1bUFycmF5ICgrKSAwICgoMSwxKSwoZyxnKSkgWygoaSxpKSx3KXxpPC1bMS4uZ11d
CgkJCWhDTXQgcG9fYXJMCT0gaDBDTXQgLy8gKG1hcCAoXChwbyxhcikgLT4gKCgxLHBvKSxNIGFy
KSkgcG9fYXJMKQoKcHV0VmFsIDo6IChTaG93IGEpID0+IFN0cmluZyAtPiBhIC0+IElPICgpCnB1
dFZhbCBzIGEgPSBwdXRTdHIgKHMrKyIgIisrc2hvdyBhKysiXG4iKQ==
--Boundary=_0.0_=0057440008851988
Content-Type: application/octet-stream; name=bug2.hs
Content-Transfer-Encoding: base64
Content-Disposition: attachment; filename=bug2.hs
aW1wb3J0IEFycmF5CgpkYXRhIENNIGEgPSBaTSB8IE0gKEFycmF5IChJbnQsSW50KSBhKSAKCWRl
cml2aW5nIChTaG93LEVxKQoKZGF0YSBSRCA9ICAgIE5CICEoRG91YmxlLEludCxJbnQpCgpnZXRE
YXRhIG4gZGw9Y2FzZSBlcmcgb2YKICAgICAgICAgICAgICAgICAgICAgICAgW2hdICAgICAtPiBo
CiAgICAgICAgICAgICAgICAgICAgICAgIF8gICAgICAgLT4gZXJyb3IgKCJlcnJvciBpbiBnZXRE
YXRhIikKICAgICAgICAgICAgICAgICAgICB3aGVyZSBlcmc9W2R8KHgsZCk8LWRsLHg9PW5dCgpz
WFhQIDo6IEFycmF5IChJbnQsSW50KSAoQ00gRG91YmxlKQpzWFhQID0gbGlzdEFycmF5ICgoMSwx
KSwoMSw0KSkgW00gKGxpc3RBcnJheSAoKDEsMSksKDEsMSkpIFsxLjBdKSxaTSxaTSxaTV0KCnhC
ZGkgOjogQXJyYXkgSW50IChBcnJheSBJbnQgRG91YmxlKQp4QmRpPSBsaXN0QXJyYXkgKDEsNCkg
W2FycmF5ICgxLDEpIFsoMSwxMCldLGFycmF5ICgxLDEpIFsoMSw1KV0sYXJyYXkgKDEsMikgWygx
LDMuNSksKDIsMS41KV0sYXJyYXkgKDEsMSkgWygxLDApXV0gICAKCm1haW4gID0gZG8JbGV0IHNU
ID0gZm9vIHhCZGkgWygiUk4xIixbKDAuMCwzLjI0ZS0wNildKV0gKCJSTjEiLE5CICgxLjAsMSwx
KSkKCQlwdXRWYWwgInNUPT1zWFhQIiAoc1Q9PXNYWFApCgkJcHV0VmFsICJzWFhQPT1zVCIgKHNY
WFA9PXNUKQoJCXB1dFZhbCAiYm5kcyBzVCBzWFhQIiAoKChib3VuZHMpIHNUKT09KChib3VuZHMp
IHNYWFApKQoJCXB1dFZhbCAiYm5kcyAraWQgc1Qgc1hYUCIgKCgoYm91bmRzLmlkKSBzVCk9PSgo
Ym91bmRzKSBzWFhQKSkKCQlwdXRWYWwgImlkICtibmRzIHNUIHNYWFAiICgoKGlkLmJvdW5kcykg
c1QpPT0oKGJvdW5kcykgc1hYUCkpCgkJcmV0dXJuICgpCgpmb28gOjogQXJyYXkgSW50IChBcnJh
eSBJbnQgRG91YmxlKS0+WyhTdHJpbmcsWyhEb3VibGUsRG91YmxlKV0pXS0+KFN0cmluZyxSRCkt
PkFycmF5IChJbnQsSW50KSAoQ00gRG91YmxlKQpmb28geGggcmRsaCAocm4scmQpID0gY2FzZSBy
ZCBvZgogCQkJKE5CIChmLHAscykpICAgICAJCQktPiBoCgkJCQl3aGVyZQoJCQkJaAk9IGhDTXQg
WyhwLGhNYXQpXQoJCQkJaE1hdAk9IGVNYXQgcyBmCi0tCQkJd2hlcmUKCQkJCShsYix1YikJCT0g
Ym91bmRzIHhoCgkJCQktLWgwQ010IDo6IEFycmF5IChJbnQsIEludCkgKENNIERvdWJsZSkKCQkJ
CWgwQ010CT0gYWNjdW1BcnJheSAoXGEgXy0+IGEpIFpNICgoMSxsYiksKDEsdWIpKSBbXQoJCQkJ
ZU1hdCBnIHcJPSBhY2N1bUFycmF5ICgrKSAwICgoMSwxKSwoZyxnKSkgWygoaSxpKSx3KXxpPC1b
MS4uZ11dCgkJCQloQ010IHBvX2FyTAk9IGgwQ010IC8vIChtYXAgKFwocG8sYXIpIC0+ICgoMSxw
byksTSBhcikpIHBvX2FyTCkKCnB1dFZhbCA6OiAoU2hvdyBhKSA9PiBTdHJpbmcgLT4gYSAtPiBJ
TyAoKQpwdXRWYWwgcyBhID0gcHV0U3RyIChzKysiICIrK3Nob3cgYSsrIlxuIik=
--Boundary=_0.0_=0057440008851988
Content-Type: application/octet-stream; name=bug3.hs
Content-Transfer-Encoding: base64
Content-Disposition: attachment; filename=bug3.hs
aW1wb3J0IEFycmF5CgpkYXRhIENNIGEgPSBaTSB8IE0gKEFycmF5IChJbnQsSW50KSBhKSAKCWRl
cml2aW5nIChTaG93LEVxKQoKZGF0YSBSRCA9ICAgIE5CICEoRG91YmxlLEludCxJbnQpCgpnZXRE
YXRhIG4gZGw9Y2FzZSBlcmcgb2YKICAgICAgICAgICAgICAgICAgICAgICAgW2hdICAgICAtPiBo
CiAgICAgICAgICAgICAgICAgICAgICAgIF8gICAgICAgLT4gZXJyb3IgKCJlcnJvciBpbiBnZXRE
YXRhIikKICAgICAgICAgICAgICAgICAgICB3aGVyZSBlcmc9W2R8KHgsZCk8LWRsLHg9PW5dCgpz
WFhQIDo6IEFycmF5IChJbnQsSW50KSAoQ00gRG91YmxlKQpzWFhQID0gbGlzdEFycmF5ICgoMSwx
KSwoMSw0KSkgW00gKGxpc3RBcnJheSAoKDEsMSksKDEsMSkpIFsxLjBdKSxaTSxaTSxaTV0KCnhC
ZGkgOjogQXJyYXkgSW50IChBcnJheSBJbnQgRG91YmxlKQp4QmRpPSBsaXN0QXJyYXkgKDEsNCkg
W2FycmF5ICgxLDEpIFsoMSwxMCldLGFycmF5ICgxLDEpIFsoMSw1KV0sYXJyYXkgKDEsMikgWygx
LDMuNSksKDIsMS41KV0sYXJyYXkgKDEsMSkgWygxLDApXV0gICAKCm1haW4gID0gZG8JbGV0IHNU
ID0gZm9vIHhCZGkgWygiUk4xIixbKDAuMCwzLjI0ZS0wNildKV0gKCJSTjEiLE5CICgxLjAsMSwx
KSkKCQlwdXRWYWwgInNUPT1zWFhQIiAoc1Q9PXNYWFApCgkJcHV0VmFsICJzWFhQPT1zVCIgKHNY
WFA9PXNUKQoJCXB1dFZhbCAiYm5kcyBzVCBzWFhQIiAoKChib3VuZHMpIHNUKT09KChib3VuZHMp
IHNYWFApKQoJCXB1dFZhbCAiYm5kcyAraWQgc1Qgc1hYUCIgKCgoYm91bmRzLmlkKSBzVCk9PSgo
Ym91bmRzKSBzWFhQKSkKCQlwdXRWYWwgImlkICtibmRzIHNUIHNYWFAiICgoKGlkLmJvdW5kcykg
c1QpPT0oKGJvdW5kcykgc1hYUCkpCgkJcmV0dXJuICgpCgpmb28gOjogQXJyYXkgSW50IChBcnJh
eSBJbnQgRG91YmxlKS0+WyhTdHJpbmcsWyhEb3VibGUsRG91YmxlKV0pXS0+KFN0cmluZyxSRCkt
PkFycmF5IChJbnQsSW50KSAoQ00gRG91YmxlKQpmb28geGggcmRsaCAocm4scmQpID0gY2FzZSBy
ZCBvZgogCQkJKE5CIChmLHAscykpICAgICAJCQktPiBoCgkJCQl3aGVyZQoJCQkJaAk9IGhDTXQg
WyhwLGhNYXQpXQoJCQkJaE1hdAk9IGVNYXQgcyBmCgkJCXdoZXJlCgkJCShsYix1YikJCT0gYm91
bmRzIHhoCgkJCWgwQ010IDo6IEFycmF5IChJbnQsIEludCkgKENNIERvdWJsZSkKCQkJaDBDTXQJ
PSBhY2N1bUFycmF5IChcYSBfLT4gYSkgWk0gKCgxLGxiKSwoMSx1YikpIFtdCgkJCWVNYXQgZyB3
CT0gYWNjdW1BcnJheSAoKykgMCAoKDEsMSksKGcsZykpIFsoKGksaSksdyl8aTwtWzEuLmddXQoJ
CQloQ010IHBvX2FyTAk9IGgwQ010IC8vIChtYXAgKFwocG8sYXIpIC0+ICgoMSxwbyksTSBhcikp
IHBvX2FyTCkKCnB1dFZhbCA6OiAoU2hvdyBhKSA9PiBTdHJpbmcgLT4gYSAtPiBJTyAoKQpwdXRW
YWwgcyBhID0gcHV0U3RyIChzKysiICIrK3Nob3cgYSsrIlxuIik=
--Boundary=_0.0_=0057440008851988--
From nordland@cse.ogi.edu Fri Mar 2 21:47:24 2001
Date: Fri, 02 Mar 2001 13:47:24 -0800
From: Johan Nordlander nordland@cse.ogi.edu
Subject: strange bug
andreas.marth@daimlerchrysler.com wrote:
>
> Hallo everybody!
>
> The file bug1.hs includes an example where acording to main sT==sXXP is True,
> but sXXP==sT is False.
> The file bug2.hs doesn't have the problem after inlinige one where clause.
> The file bug3.hs also doesn't have the problem after adding a type signature to
> the function "h0CMt".
>
> So what exactly is the problem here?
>
> Thanks,
> Andreas
Hi Andreas,
Thanks for your report. Would it be possible for you to try to trim down the
examples somewhat? That would speed up my process of finding the bug
considerably. You know the code you've written, so you're in a much better
position to do that then I am.
As a general rule, bug reports will get much quicker attention if the
illustrating examples are minimal.
All the best,
Johan
From Andreas.Marth@gmx.de Sat Mar 3 13:43:05 2001
Date: Sat, 3 Mar 2001 14:43:05 +0100
From: Andreas Marth Andreas.Marth@gmx.de
Subject: strange bug
This is a multi-part message in MIME format.
------=_NextPart_000_000C_01C0A3F0.423D0E30
Content-Type: multipart/alternative;
boundary="----=_NextPart_001_000D_01C0A3F0.423D0E30"
------=_NextPart_001_000D_01C0A3F0.423D0E30
Content-Type: text/plain;
charset="iso-8859-1"
Content-Transfer-Encoding: quoted-printable
Hi again!
I cut the example a bit further down. Read the comments at the end of =
the file.
-------------------------------------------------------------------------=
--------------------------------------
>import Array
>
>data CM a =3D ZM | M (Array (Int,Int) a) deriving (Show,Eq)
>
>data RD =3D NB !(Double,Int)
>
>main =3D do let arr =3D foo (NB (1.0,1))
> putStr ("arr=3D=3DarrS "++show (arr=3D=3DarrS)++"\n")
> putStr ("arrS=3D=3Darr "++show (arrS=3D=3Darr)++"\n")
> putStr ("bnds arr arrS "++show ((bounds arr)=3D=3D(bounds =
arrS))++"\n")
> putStr ("bnds +id arr arrS "++show (((bounds.id) arr)=3D=3D((bounds) =
arrS))++"\n")
> putStr ("id +bnds arr arrS "++show (((id.bounds) arr)=3D=3D((bounds) =
arrS))++"\n")
>
>foo :: RD -> Array (Int,Int) (CM Double)
>foo rd =3D case rd of
> NB (f,p) -> h where h=3DhCMt [(p,listArray ((1,1),(1,1)) [f])]
> where
> --h0CMt :: Array (Int, Int) (CM Double)
> h0CMt =3D accumArray (\a _-> a) ZM ((1,1),(1,2)) []
> hCMt po_arL =3D h0CMt // (map (\(po,ar) -> ((1,po),M ar)) po_arL)
>
>arrS :: Array (Int,Int) (CM Double)
>arrS =3D listArray ((1,1),(1,2)) [M (listArray ((1,1),(1,1)) [1.0]),ZM]
>-- This is the array that foo (NB (1.0,1)) shows in Hugs.
>-- But (foo (NB (1.0,1)))=3D=3DarrS is False.
>-- All in main is only to show the strange behaviour.
>-- If I write NB (f,p) -> hCMt [(p,listArray ((1,1),(1,1)) [f])] =
instead of line 16
>-- the bug disappears. That is also the reason why I have to keep the =
data declaration RD.
>-- If I put the type signature of line 18 in scope the bug also =
disappears.
>-- If I write=20
>-- hCMt po_arL =3D (accumArray (\a _-> a) ZM ((1,1),(1,2)) []) // (map =
(\(po,ar) -> ((1,po),M ar)) po_arL)
>-- instead of line 19 and 20 it also vanishes.=20
>-- So I thing now it is the shortest example that I can find. (Apart =
from deleting main.)
------=_NextPart_001_000D_01C0A3F0.423D0E30
Content-Type: text/html;
charset="iso-8859-1"
Content-Transfer-Encoding: quoted-printable
<!DOCTYPE HTML PUBLIC "-//W3C//DTD HTML 4.0 Transitional//EN">
<HTML><HEAD>
<META content=3D"text/html; charset=3Diso-8859-1" =
http-equiv=3DContent-Type>
<META content=3D"MSHTML 5.00.2314.1000" name=3DGENERATOR>
<STYLE></STYLE>
</HEAD>
<BODY bgColor=3D#ffffff>
<DIV><FONT face=3DArial size=3D2>Hi again!</FONT></DIV>
<DIV> </DIV>
<DIV><FONT face=3DArial size=3D2>I cut the example a bit further down. =
Read the=20
comments at the end of the file.</FONT></DIV>
<DIV><FONT face=3DArial=20
size=3D2>----------------------------------------------------------------=
-----------------------------------------------</FONT></DIV>
<DIV><FONT face=3DArial size=3D2>>import Array</FONT></DIV>
<DIV><FONT face=3DArial size=3D2>></FONT></DIV>
<DIV><FONT face=3DArial size=3D2>>data CM a =3D ZM | M (Array =
(Int,Int) a)=20
deriving (Show,Eq)</FONT></DIV>
<DIV><FONT face=3DArial size=3D2>></FONT></DIV>
<DIV><FONT face=3DArial size=3D2>>data RD =3D NB=20
!(Double,Int)</FONT></DIV>
<DIV><FONT face=3DArial size=3D2>></FONT></DIV>
<DIV><FONT face=3DArial size=3D2>>main =3D do let arr =3D =
foo (NB=20
(1.0,1))<BR>> putStr ("arr=3D=3DarrS "++show=20
(arr=3D=3DarrS)++"\n")<BR>> putStr ("arrS=3D=3Darr "++show =
(arrS=3D=3Darr)++"\n")<BR>> putStr ("bnds arr arrS "++show =
((bounds=20
arr)=3D=3D(bounds arrS))++"\n")<BR>> putStr ("bnds +id arr =
arrS=20
"++show (((bounds.id) arr)=3D=3D((bounds) =
arrS))++"\n")<BR>> putStr=20
("id +bnds arr arrS "++show (((id.bounds) arr)=3D=3D((bounds)=20
arrS))++"\n")</FONT></DIV>
<DIV><FONT face=3DArial size=3D2>></FONT></DIV>
<DIV><FONT face=3DArial size=3D2>>foo :: RD -> Array (Int,Int) (CM =
Double)<BR>>foo rd =3D case rd of<BR>> NB=20
(f,p) -> h where h=3DhCMt [(p,listArray ((1,1),(1,1))=20
[f])]<BR>> where<BR>> --h0CMt :: =
Array=20
(Int, Int) (CM Double)<BR>> h0CMt =3D =
accumArray (\a=20
_-> a) ZM ((1,1),(1,2)) []<BR>> hCMt =
po_arL =3D h0CMt=20
// (map (\(po,ar) -> ((1,po),M ar)) po_arL)</FONT></DIV>
<DIV><FONT face=3DArial size=3D2>></FONT></DIV>
<DIV><FONT face=3DArial size=3D2>>arrS :: Array (Int,Int) (CM =
Double)<BR>>arrS=20
=3D listArray ((1,1),(1,2)) [M (listArray ((1,1),(1,1)) =
[1.0]),ZM]<BR>>-- This=20
is the array that foo (NB (1.0,1)) shows in Hugs.<BR>>-- But (foo (NB =
(1.0,1)))=3D=3DarrS is False.<BR>>-- All in main is only to show the =
strange=20
behaviour.<BR>>-- If I write NB (f,p) -> hCMt [(p,listArray=20
((1,1),(1,1)) [f])] instead of line 16<BR>>-- the bug disappears. =
That is=20
also the reason why I have to keep the data declaration RD.<BR>>-- If =
I put=20
the type signature of line 18 in scope the bug also =
disappears.<BR>>-- If I=20
write <BR>>-- hCMt po_arL =3D (accumArray (\a _-> a) ZM =
((1,1),(1,2))=20
[]) // (map (\(po,ar) -> ((1,po),M ar)) po_arL)<BR>>-- instead of =
line 19=20
and 20 it also vanishes. <BR>>-- So I thing now it is the shortest =
example=20
that I can find. (Apart from deleting main.)</FONT></DIV>
<DIV> </DIV></BODY></HTML>
------=_NextPart_001_000D_01C0A3F0.423D0E30--
------=_NextPart_000_000C_01C0A3F0.423D0E30
Content-Type: application/octet-stream;
name="bug1.hs"
Content-Transfer-Encoding: quoted-printable
Content-Disposition: attachment;
filename="bug1.hs"
import Array
data CM a =3D ZM | M (Array (Int,Int) a) deriving (Show,Eq)
data RD =3D NB !(Double,Int)
main =3D do let arr =3D foo (NB (1.0,1))
putStr ("arr=3D=3DarrS "++show (arr=3D=3DarrS)++"\n")
putStr ("arrS=3D=3Darr "++show (arrS=3D=3Darr)++"\n")
putStr ("bnds arr arrS "++show ((bounds arr)=3D=3D(bounds =
arrS))++"\n")
putStr ("bnds +id arr arrS "++show (((bounds.id) arr)=3D=3D((bounds) =
arrS))++"\n")
putStr ("id +bnds arr arrS "++show (((id.bounds) arr)=3D=3D((bounds) =
arrS))++"\n")
foo :: RD -> Array (Int,Int) (CM Double)
foo rd =3D case rd of
NB (f,p) -> h where h=3DhCMt [(p,listArray ((1,1),(1,1)) [f])]
where
--h0CMt :: Array (Int, Int) (CM Double)
h0CMt =3D accumArray (\a _-> a) ZM ((1,1),(1,2)) []
hCMt po_arL =3D h0CMt // (map (\(po,ar) -> ((1,po),M ar)) po_arL)
arrS :: Array (Int,Int) (CM Double)
arrS =3D listArray ((1,1),(1,2)) [M (listArray ((1,1),(1,1)) [1.0]),ZM]
-- This is the array that foo (NB (1.0,1)) shows in Hugs.
-- But (foo (NB (1.0,1)))=3D=3DarrS is False.
-- All in main is only to show the strange behaviour.
-- If I write NB (f,p) -> hCMt [(p,listArray ((1,1),(1,1)) [f])] instead =
of line 16
-- the bug disappears. That is also the reason why I have to keep the =
data declaration RD.
-- If I put the type signature of line 18 in scope the bug also =
disappears.
-- If I write=20
-- hCMt po_arL =3D (accumArray (\a _-> a) ZM ((1,1),(1,2)) []) // (map =
(\(po,ar) -> ((1,po),M ar)) po_arL)
-- instead of line 19 and 20 it also vanishes.=20
-- So I thing now it is the shortest example that I can find. (Apart =
from deleting main.)
------=_NextPart_000_000C_01C0A3F0.423D0E30--
From haberg@matematik.su.se Sat Mar 3 14:31:56 2001
Date: Sat, 3 Mar 2001 15:31:56 +0100
From: Hans Aberg haberg@matematik.su.se
Subject: Feb2001 hugs98 on MacOS
At 15:35 -0700 2001/02/28, Alastair Reid wrote:
>I'm yet to hear of a reason why AppleEvents cannot be dealt with using one of
>these approaches (i.e., without requiring substantial internal changes to
>Hugs).
In view of that the high-level AppleEvent events are interrupts, one ends
up the same kind of problem of atomizity (code which cannot be interrupted
by other threads) as in a pre-emptive environment.
Here are some problems:
1) If the Hugs code is sloppily written, this can cause problems. For
example, Hugs uses its own stack, so if it first writes the stack and then
increases the stack pointer, this would cause a problem if the interrupt
occurs between the write & the pointer increment. Similar problems can
occur if a variable is temporarily used for something else than its
intended use. For example, the console package that came with the Mac CW
compiler uses the cursor position for something else while reading a
character, which means that if an interrupt happens then, the cursor
position value becomes wrong.
2) Some operations may not allow the Hugs engine to compute at all, say a
GC cleanup.
3) If Hugs code is impure, that is, using global temporary registers (as I
think it does), this is a problem if the interrupt happens in the middle of
the execution of an impure function.
The remedy for 1), is to rewrite the code so that it becomes semantically
correct (disregarding simplifications that might work in a single-threaded
environment). And as for 3), it is best to rewrite the code so that it
becomes pure.
However, there is an interesting way in which the Hugs kernel might be made
to simulate simple form of concurrency, even though the kernel is not
written for it:
When an interrupt happens, the function that is handling it is allowed to
register a function pointer in a queue, whereafter it terminates. Then the
Hugs kernel sources are sprayed (just as in the case of cooperative
multi-tasking) with places where the function pointers in this queue (if
non-empty) can be executed.
It should be relatively simple to implement: One only needs to identify
some places in the code where it is admissible to execute those function
pointers. (One exception is when the Hugs kernel is idle, in which those
function pointers should be executed immediately and not enqueued.)
That is, if one want to allow a high-level event to be treated by the Hugs
kernel while the Hugs kernel is actively running.
Hans Aberg
From sigbjorn_finne@hotmail.com Sat Mar 3 19:21:54 2001
Date: Sat, 3 Mar 2001 20:21:54 +0100
From: Sigbjorn Finne sigbjorn_finne@hotmail.com
Subject: problem with hiding?
This is a multi-part message in MIME format.
------=_NextPart_000_0084_01C0A41F.9666E100
Content-Type: text/plain;
charset="iso-8859-1"
Content-Transfer-Encoding: 7bit
Johan Nordlander nordland@cse.ogi.edu writes:
>
>> Christian Sievers wrote:
>> Hello,
>>
>> there may be a bug with hiding imports.
>>
>> I tried to load Functional Metapost
>> (http://www.informatik.uni-bonn.de/~ralf/FuncMP.tar.gz)
>> and expected all sorts of problems as it is described to be written
>> in Haskell 1.4, but not this one:
>>
>> Prelude> :l FMPMain
>> [...]
>> ERROR FMPMain.lhs - Entity "space" imported from module "FMPPP"
>> already defined in module "FMPPicture"
>>
>> However, the file FMPMain.lhs contains the line
>> > import FMPPicture hiding (text,empty,space)
>>
>> I cannot see what's goin here: simple tests with hiding worked well.
>> I'm using the Feb 2001 version.
>
>
> The reason this example doesn't work is because of the module
> FMPMpsyntax, which imports FMPPicture selectively, and then reexports
> FMPPicture in the module header. Hugs doesn't implement this correctly,
> it reexports all identifiers of every module mentioned in its export list.
I've been bitten by this infelicity numerous times too, and started a while
ago to modify the sources so as to fix it, but never got around to
completing
the job. The above report caused me to finally do something about it, so
attached is a patch which fixes this problem for Hugs98 (wrt Feb 2001
sources.) Hopefully the patch is in a decent enough shape for it to
be included & that it will prove useful to others.
BTW, the FuncMP source code highlighted that the version of GHC used
to develop FuncMP didn't implement module re-exportation properly - I
had to tweak one of the modules (FMPMpsyntax) quite a bit to have it
work with Hugs98 (and ghc-4.08)
--sigbjorn
------=_NextPart_000_0084_01C0A41F.9666E100
Content-Type: application/x-gzip;
name="module-patch.gz"
Content-Transfer-Encoding: base64
Content-Disposition: attachment;
filename="module-patch.gz"
H4sICMo/oToAA21vZHVsZS1wYXRjaADNWetv20YS/6wA+R/GLq6ibFrWw5IsG/7gJk7PgB9F5PRw
QIEDRa4iwhSp4y4jGYX7t9/MvriU6dhunF6FwJGWO7Mzs795cmdnB7gIRBy2w/Yf3T8aNwWDD2wK
vTF0eke98VGnA71Op/P2zd7ent3amAQCLoMcoA/d8dFB/6hzSNu6b9/sVD9yAfoj/6AL6jdoLvBr
FkcAkGRhkEA4Z+Ht+WKZ5eIi5qJxmn/mnvdLEOet1jERvX2zVUsYS5qzVMTiTlNdZlGRMP8dSxJN
/DjhVbBgjSodLT1Jd3MXZukGoVyTlGQrpTN+23sNnUmZv7fOtRc/6A38Qe9QXz2ZRa70S8PQh7TH
/+ZxFLEU4ASuzi+OYX8HGKkYMw4rBqsgFSAy2sVw886+stCuy2GRRWhP7nC4mTNgsxkLRfyFaT0g
od3EoELMDB2tG9HiGXgLqerNPOaTMI+Xwlu0WvC73NI4+/jxcvKz12nBtrII/Lb9D/7bNuQsLHKO
hyZ3+lgOseAsmW37jxmrP/QHw771k0ZpkJzxLPnCSrB4Cx94GnnImn7qu2uYkx6heH99g//UXvrc
A0s4g9+fQ2tOKokJnvSZZbl3DGmWXhVJ4mk2rWOj9okoF1t01hY0JJwZHjWPSgL5hAy+FeLjc37J
FlOWe8xXdmi15AZ5K44DoGxM0VaEorvP3mdHMA/Sz5CliBwxZ/YqJARQcFjmWcg4j3ETW5foQOTl
CDzDDXYgm0kGSLOAbQUJ+JBl28YcGpH3dcHqodt6PCvykKHotF9DR61JAysDHauroQ9fxSKcg7ea
B+Kce0yZUh8NYYDXeHV6eQZw5Hh5ecqxlKlB1pvmLLg93qC9+fe76ytLK736+cTvLk4nE0v8Lgk4
d4gfpY3YLCgSgXSpYHkaJN62a6LtCtTkHxlA+mN/MO7ZAPI9vWRXBpiGjiNJli0h+8JyCYSm5tJU
gJkHyyVL0cdTmGZiLukQNdM8SDHOcx+mhfAl4jAcxWHM0vAOjw94hkRZmtz5GOQMVZSlTYRnkmGa
jQVkhVgFecTb+rmMXI2Xuh2RwiOOJ599zfUsAzfIIki498AXfbPDMr6X/99/Y9TZNbh5ccApKZ+S
3rHKAz3uHwQ+GWNgyiCYovdSbgrSCL/lbE/FEowAWUqRQ8ULRAEL0InVLye23DKGIok8CG9NnKlP
WvgwwAuMKZkoOX2HDacYh5DBbJkE6FKIK3TQVGqKzBGaG5KhyAQ9hwVuFbRxJfkE5hgWtStxbtdm
XrTBuZQ4Z02OmuWMZEClUyt5xMJEIp/04hiWtAF8ezN07mIap8yJ0VJhBXnnWHP9jJ8oJh6m2Ryj
tQqhrba6M7LMsQEIwxtkEhVsAxCE+JhTxeXhzcunP/4IM4Se+XlyAgsDfookuIjQkb4eXWNS8TRG
VJwhEgUWE+vMSffmq/2izjYCVsRCm+qMkGYCLxx5RXeYqRhHRX0IoggR0HYsAvCUMQzel6TrwjfI
9p+iKx3vvi67yXDyt8lujpvnTBR5CuzP5LmHbKTVsEo+v2j9idz3XH7PyYe7lp1mpQpWCzL5p766
HI78wajswsiCkDp3IBdCVGBOCI8iaeK0LK0IsMal5DbpLPLb1kmqL8wtiJXYpiA2gQRmebbQeDXP
DMTRAhgEIkqilQ1UMoMsIgRbi5tsInIvVeK1aQVjtS4OxkN/2C2Lg1dWknb9gFu2zn++uv549p/L
6/efLs4m8pbRaZtp0wRQDgGQhBtqB+jQGCq1dk2u8LHjlp5teF/IZKItUA3Zvoz9zXm2YIZW88Jo
0mZtX0ZQTbqiqCylokgehKLA5HEn43GQs6hlOQR3MtJgJmP/xT0gdCLRuciwY82cQtJKK4U1s+Eg
lZOneU2F/ma7BZOMipom5jDKMvCZgpmyirqBeGbo6RTSyRyFB5PYMYcoxkRIsUmdYcRqSg7Ntmaw
b1MY3pZBBvKCrRP1U92lXNI9yA9UhFiycjWNSKz/K5Lr/few4w8OD6z/ytgFInTArZakqieIbRXd
RPhMdOPGhz6sWNYq/g0aCyOZ1lk577DX9YfOaOA7aPgVB7apd8KYm2RaVJssEIDtDZiVSmigqYVv
Q9pfZe96iI3H/rBTDiBkNgPX/nrF2F+lu+eavw5fiuFr6xuGWrAqvg4wOQyGFl+vrd5rgqvUQIPL
LHwTuv4qa9eiazg88IfDQ4suWbGoVpDsqqx1dnVDNTeV4LYIbOgCcoEpG6WK8GccebLebukSy057
+Dwrkoi6Z0x1mKl0YrUtGPVGSE0bdJuhxjYNpxxf2INJRMd8n9JbzH4bFtFH1KaDbY28UXfkj3rV
oecrqv7RlAg0xQoe1TTm1i7Yz313xetBcIghZjwqZ5zaL86s/G6BZLtc2fWKOT4vO1Kw9FhAFCkV
LvEsNuJQg0RFod2h8LGigkqDgn1h+Z1kWqoyvSsNuOeSYy0lBVs5JR2NZnKqnPAoGg/DZ+zXuSxm
VnlG1VFJj80b1vayDTbTw0s9WYarli7V9EVdeevWtqPdvm0jlJzUzUXF0vSf1MAtWm39zNf/61mX
7Akaph1Sj/QbitFBzx8NRuUk7TvfRY0+cvS+LgfvW2UHRl3++gVd/ho1Xssuf13OmcGG7bLNX1fb
/HWlzadR5UMjk8Ppra55abNp9O1h9/Z7+c3xsQfCvfBKS96PX26t54063Y6Pf/rOy5hRZ0Rro8NK
ZNqXaKex0WIZJ4QDQvQyZ0kRsTY896PiC320QogZbi6w1Fq+BVOQ497jO8tBBIp3ahsoaJZQ0JPY
WM1ToeCIP+xk1PSrCKn5QCXCGKOuYurMnxRlajTlLA2ZkzWqTVgb/iW7GmqFMCrHfM6i6ixrWQhj
N6e182lCVxGYpnOCbI2tFxfFdIoiZ4Wom3rVmKYy3jGDAJP51a1zkeXBZ/bMt7t67+br3YOj7vBr
r3e7vd7Y7/b6PQdaZq1fgZaBtvzvn6tWmyKF0QEcLWo3G9CoT/myrnazY5ynOcsC2TB+ajP1a3av
3VxrmX5ndODjn5FjGfw5oLVxGXjl65FFkN8aB4hbbVlUMRPG63ZUPKN2R3WO9wgb5wrMLrChbBNH
8xfgaP4QR4ODr+FoMOj6g8GB+7aYVoZVDDmBRb25dRRwg8QHetdSjtttrvLp3WyWR9I71V0KPe12
nNjO3+37W6IUwS35dZzquBJHLJchwaF0x9cQpBE053GEVE3ehk86JtW+KHB4lK8MVCxDU0gZY+5T
MgmAF1POBEycGHWKTx+IUSnhf/JVsNkMck3DoYmbHRYb4Yu2IosFC1Jtsomutyl8WV0qsVDmfyRS
g+yEWJzWRTd1k05al6NM/Ps/nBghoKIiAAA=
------=_NextPart_000_0084_01C0A41F.9666E100--
From sievers@ips.cs.tu-bs.de Sat Mar 3 19:25:11 2001
Date: Sat, 3 Mar 2001 20:25:11 +0100 (MET)
From: Christian Sievers sievers@ips.cs.tu-bs.de
Subject: problem with hiding?
Johan Nordlander wrote:
> The reason this example doesn't work is because of the module FMPMpsyntax, which
> imports FMPPicture selectively, and then reexports FMPPicture in the module
> header. Hugs doesn't implement this correctly, it reexports all identifiers of
> every module mentioned in its export list.
>
> I'm afraid this is a known bug that's been there since Hugs started to support
> modules. It's on my list of things to do, but not very highly prioritized. But
> I can always be persuaded...
Thanks a lot.
For now I won't try this (I only wanted to let you know), but rather
try to work around it. But if you could improve the error message...
Still I find it strange because from the documentation I got the
impression that it worked with Hugs 1.4.
But then, that occurence of fst in FMPMain.lhs seems wrong, too.
Bye
Christian Sievers
From simonpj@microsoft.com Mon Mar 5 10:19:31 2001
Date: Mon, 5 Mar 2001 02:19:31 -0800
From: Simon Peyton-Jones simonpj@microsoft.com
Subject: problem with hiding?
| BTW, the FuncMP source code highlighted that the version of GHC used
| to develop FuncMP didn't implement module re-exportation properly - I
| had to tweak one of the modules (FMPMpsyntax) quite a bit to have it
| work with Hugs98 (and ghc-4.08)
Is this a bug report for GHC 4.08?
Simon
From sigbjorn_finne@hotmail.com Tue Mar 6 09:51:25 2001
Date: Tue, 6 Mar 2001 10:51:25 +0100
From: Sigbjorn Finne sigbjorn_finne@hotmail.com
Subject: Minor tweaks
This is a multi-part message in MIME format.
------=_NextPart_000_00AA_01C0A62B.6471D480
Content-Type: text/plain;
charset="iso-8859-1"
Content-Transfer-Encoding: 7bit
Attached is a patch to Feb2001 which does the following
* flushes stderr when :set -h<size> and :set {+,-}98 is used.
As is, the informational messages that's printed on stderr may
not appear until later with some terminal & CRT combos.
* allows the use of "~/" in :cd commands. ~/ is substituted with
whatever the environment variable HOME contains. It doesn't
do other forms of tilde expansion, but if there's interest I could
always add support for ~login/
i.e., first tweak is a bugfix, the second is a feature tweak.
BTW, is there a technical reason why toggling between Haskell98
and Hugs mode can only be done at startup time?
--sigbjorn
------=_NextPart_000_00AA_01C0A62B.6471D480
Content-Type: application/octet-stream;
name="misc-patch"
Content-Transfer-Encoding: quoted-printable
Content-Disposition: attachment;
filename="misc-patch"
*** hugs.c.~1~ Tue Feb 29 02:29:00 2000
--- hugs.c Sun Mar 4 15:39:24 2001
***************
*** 672,675 ****
--- 672,676 ----
(!state && haskell98))) {
FPrintf(stderr,"Haskell 98 compatibility cannot be changed =
while the interpreter is running\n");
+ FFlush(stderr);
} else {
haskell98 =3D state;
***************
*** 696,707 ****
hpSize =3D MAXIMUMHEAP;
if (heapBuilt() && hpSize !=3D heapSize) {
#if HUGS_FOR_WINDOWS
! MessageBox(hWndMain, "Change to heap size will not take =
effect until you rerun Hugs", appName, MB_ICONHAND | MB_OK); =20
#endif =20
#if USE_REGISTRY
! FPrintf(stderr,"Change to heap size will not take effect until =
you rerun Hugs\n");
#else
FPrintf(stderr,"Cannot change heap size\n");
#endif
} else {
heapSize =3D hpSize;
--- 697,711 ----
hpSize =3D MAXIMUMHEAP;
if (heapBuilt() && hpSize !=3D heapSize) {
+ #define HEAP_RESIZE_MSG "Change to heap size will not take effect =
until you rerun Hugs"
#if HUGS_FOR_WINDOWS
! MessageBox(hWndMain, HEAP_RESIZE_MSG, appName, MB_ICONHAND =
| MB_OK);
#endif =20
#if USE_REGISTRY
! FPrintf(stderr,HEAP_RESIZE_MSG "\n");
#else
FPrintf(stderr,"Cannot change heap size\n");
#endif
+ #undef HEAP_RESIZE_MSG
+ FFlush(stderr);
} else {
heapSize =3D hpSize;
***************
*** 984,991 ****
* =
------------------------------------------------------------------------*=
/
=20
static Void local changeDir() { /* change directory =
*/
! String s =3D readFilename();
! if (s && chdir(s)) {
! ERRMSG(0) "Unable to change to directory \"%s\"", s
EEND;
}
--- 988,1027 ----
* =
------------------------------------------------------------------------*=
/
=20
+ /*
+ * Poor man's path expansion: expand out ~/=20
+ */
+ static Void local expandPath(origPath,expandedPath,maxLen)
+ String origPath;
+ String expandedPath;
+ unsigned int maxLen;
+ {
+=20
+ if (!origPath) {
+ return;
+ }
+=20
+ /* If the original path starts with "~/", expand it. */
+ if (*origPath =3D=3D '~' && *(origPath+1) =3D=3D '/') {
+ unsigned int origLen;
+ String home =3D getenv("HOME");
+ origLen =3D (origPath ? strlen(origPath) : 0);
+ /* The expansion of $HOME will fit in iff
+ * (maxLength - length(unexpanded) - length("~")) >=3D =
length("$HOME")
+ */
+ if ( (maxLen - origLen - 1) >=3D strlen(home) ) {
+ strcpy(expandedPath, home);
+ strcat(expandedPath, origPath+1);
+ return;
+ }
+ }
+ strcpy(expandedPath, origPath);
+ }
+=20
static Void local changeDir() { /* change directory =
*/
! String path =3D readFilename();
! char expandedPath[FILENAME_MAX+1];
! expandPath(path, expandedPath,FILENAME_MAX);
! if (path && chdir(expandedPath)) {
! ERRMSG(0) "Unable to change to directory \"%s\"", path
EEND;
}
------=_NextPart_000_00AA_01C0A62B.6471D480--
From mpj@cse.ogi.edu Tue Mar 6 17:29:52 2001
Date: Tue, 6 Mar 2001 09:29:52 -0800
From: Mark P Jones mpj@cse.ogi.edu
Subject: Minor tweaks
Hi Sigbjorn!
| BTW, is there a technical reason why toggling between Haskell98
| and Hugs mode can only be done at startup time?
It was a design philosophy rather than an essential feature. Would it
make sense to allow somebody to :set -98, then :load a file containing
rank-2 polymorphism, overlapping instances, etc..., then :set +98 and
:also a standard Haskell 98 file? What language would they be using
at that point? I concluded that it would be better to give Hugs two
distinct identities, rather than a confusing and schizophrenic
personality that drew no clear lines between +/-98.
That said, you could easily hack the code to allow users to switch
modes without restarting the interpreter. But it wasn't designed to
run that way, so I wouldn't trust it to work correctly either ...
All the best,
Mark
From haberg@matematik.su.se Tue Mar 6 19:19:01 2001
Date: Tue, 6 Mar 2001 20:19:01 +0100
From: Hans Aberg haberg@matematik.su.se
Subject: Minor tweaks
At 09:29 -0800 2001/03/06, Mark P Jones wrote:
>| BTW, is there a technical reason why toggling between Haskell98
>| and Hugs mode can only be done at startup time?
>
>It was a design philosophy rather than an essential feature. Would it
>make sense to allow somebody to :set -98, then :load a file containing
>rank-2 polymorphism, overlapping instances, etc..., then :set +98 and
>:also a standard Haskell 98 file? What language would they be using
>at that point?
...
>That said, you could easily hack the code to allow users to switch
>modes without restarting the interpreter. But it wasn't designed to
>run that way, so I wouldn't trust it to work correctly either ...
I had a C/C++ compiler where one could alter the implementation of some
basic types. For example, "double" could be IEEE of local-OS implementation.
This appears fine, but unfortunately the linker did know nothing about
this, meaning that different settings would make the object codes
incompatible. For example, one could not use the library without
recompiling, and then still remains the question what object code the
library calls (like some low level OS code).
The errors produced are quite mysterious: Values become mysteriously
screwed, despite that the sources are perfectly OK. Some code could refuse
to compile, and it can be hard to figure out why, in view that all sources
are OK.
So unless the linker knows about the problem and either issues
understandable error or knows how to do the right conversions, such
language settings features are quite useless.
The language C++ has an interesting construct that allows one to mix it
with other languages: The implementer of the compiler can add a language X
by supporting it in the construct
extern "X" { ... }
meaning that the stuff { ... } has the extern linkage of the language X.
C++ has the requirement the language C should be included, but one can add
other language, Pascal, Haskell 98, etc. (By the way, should it be
extern "Haskell 98" { ... }
or
extern "Haskell98" { ... }
-- That is, is the official name "Haskell 98" or "Haskell98"?)
Anyway, by the use of this construct, the linker always knows which
external linkage each code segment has, and so it is possible to join it
together in a correct manner. (Adding suitable initializer/terminalizers in
the case of C++.)
In fact, Haskell could benefit from having such an "extern" language hook.
-- In effect, this could serve as the foreign interface that some Haskell
implementations have other constructs for. -- But then I agther it is not a
"minor tweak" anymore... :-)
Hans Aberg
From jrood@mediaone.net Fri Mar 9 21:53:01 2001
Date: Fri, 09 Mar 2001 16:53:01 -0500
From: John Rood jrood@mediaone.net
Subject: Something wrong with Windows 98 installation??
Dear sir or madam,
I have downloaded your file hugs98-Feb2001.msi. However I can't quite
figure out what to do with it.
I am running Windows 98 and expected to be able to click on your file
and have it set itself up automatically. However, when I click on this,
Windows responds by asking me what type of file (i.e. utility) I want to
use to open this filename suffix. That is, my Windows 98 doesn't
recognize what *.msi is supposed to mean.
Thinking this means my machine somehow doesn't know how to do a setup
(which I actually know not to be the case in fact, i.e. my machine has
successfully set up plenty of other things automatically), I tried to
download the "installer" which you have a link to.
That is, I clicked on the link in the following sentence of your
documentation:
In the unlikely event that your machine doesn't already have the Windows
Installer
engine/runtime installed, runtime redistributables can be found
here. [<--link]
However, this too was unsuccessful, leading to a missing page at
Microsoft.
How AM I supposed to set this thing up on my machine?
-John Rood
From sigbjorn_finne@hotmail.com Fri Mar 9 23:43:09 2001
Date: Sat, 10 Mar 2001 00:43:09 +0100
From: Sigbjorn Finne sigbjorn_finne@hotmail.com
Subject: Something wrong with Windows 98 installation??
John Rood jrood@mediaone.net writes:
>
> That is, I clicked on the link in the following sentence of your
> documentation:
>
> In the unlikely event that your machine doesn't already have
> the Windows Installer engine/runtime installed, runtime
> redistributables can be found here. [<--link]
>
> However, this too was unsuccessful, leading to a missing page at
> Microsoft.
>
> How AM I supposed to set this thing up on my machine?
Hi,
you're on the right track, your machine doesn't seem to have the
installer runtime installed. The download page pointed to is the
right one, but either someone's temporarily messed things up
at MS, or the page is really being moved (and the KB and
other MS docs will be similarly updated, which sounds kind
of silly, but stranger things have happened..)
When pages & sites go AWOL all of a sudden, I normally turn
to Google's cache for help - you can get at a copy of the missing
page at
http://www.google.com/search?q=cache:www.microsoft.com/msdownload/platformsd
k/instmsi.htm+instmsi&hl=en
The binaries that this page points to, do seem to point the real goods.
hth,
--sigbjorn
From tell.me.more@pobox.com Sun Mar 11 15:34:40 2001
Date: Sun, 11 Mar 2001 10:34:40 -0500
From: tell.me.more@pobox.com tell.me.more@pobox.com
Subject: ADV: ===>> FREE 1 yr. USA Magazine Sub sent worldwide-200+
Choices! Up to $81.
With your first purchase of any size of any new or renewal subscription AT
OUR GUARANTEED LOWEST RATE (we BEAT all competitor's prices before you pay
us and will even go back 6 months later if you find a better deal and
refund you the difference!); customers living overseas pay only for FPH
(foreign postage & handling) on the free subscription.
____________________________________________________________
FOR MORE INFO:
Just fill out the below form and return to us via email, with the subject
line of "TELL ME MORE" at:
tell.me.more@pobox.com
____________________________________________________________
TO BE REMOVED FROM OUR LIST:
Just send a blank email message with the subject line of: "REMOVE" from
the email address
that you would like to have removed to:
tell.me.more@pobox.com
____________________________________________________________
Remove requests will be immediately honored and requests for more
information will be fulfilled within 24 hours.
____________________________________________________________
***For more information, IF YOU DO NOT GET A REPLY within 24 hours, or the
email bounces due to our servers being overloaded from those replying, or
if it bounces for any other reason, then just fax us at:
1-602-294-5643 in the USA
or write us via smail at: or send via smail (first class mail or airmail)
to:
Tempting Tear-Outs / Att.
Free-catalogue-by-email Dept
PMB 200
3835 Richmond Ave.
Staten Island NY 10312-3828
USA
____________________________________________________________
When replying for more information, your subject line must say "TELL ME
MORE" and the body of your message must include only this form, completely
filled out*:
(*If you can't figure out how to cut and past this text, just type it out
in the same format):
*------------cut here/begin-------------------------------------------*
***For more information, IF YOU DO NOT GET A REPLY within 24 hours, or the
email bounces due to our servers being overloaded from those replying, or
if it bounces for any other reason, then just fax us at:
1-602-294-5643 in the USA
Yes, please send me more info. I realize I am not committing myself to
buying
anything at this time and I would just like more info on the offer and a
FREE copy of your magazine subscription catalogue. Here are my details:
Name (First Middle Last):
Internet email address:
Smail home address:
City-State-Zip:
Country:
Work Tel. #:
Work Fax #:
Home Tel. #:
Home Fax #:
Cellular (Mobile) Tel. #:
Beeper (Pager) Tel. #:
How did you hear about us (name of person/company who referred you or the
area of
the internet that you saw us mentioned in): Referred by: Tempting
Tear-Outs
031001-ls
Name of USA mags you currently get on the newsstand or in the store:
Name of USA mags you currently get on a subscription basis, through the
mail:
Name of USA mags you would like price quotes on when we call you:
Catalogue version desired (list number of choice below):
*------------cut here/end--------------------------------------------*
CATALOGUE VERSION CHOICES:
1. This version can be read by everyone, no matter what type of
computer you use, or what type of software you use. It is a simple
format, with just our entire catalogue pasted into the body of a
single email message, 712K in size. If you use pine or elm on a unix
system or an advanced software version such as Eudora Pro 3.0 or
later, you will most likely receive it as a single email message.
However, if your software limits incoming email messages to a
certain size, say 32K or so, then your software will split it into
multiple email message parts. Whether you receive it as a single
email message or multiple part email messages, you can easily
paste it into one whole text document with your word processor, in
about 10 minutes or so.
2. For more advanced computer users: attached plain ascii text file
~712K - you must know how to download an attached text file and
then be able to locate it on your hard drive or system home
directory; it can then be opened with any pc or mac word processing
software. If in doubt, don't ask for this version. This isn't for
internet *newbies.* Better to order option 1 and spend a few minutes
pasting them into one whole text document with your word processor,
than to waste hours trying to figure how to deal with this option.
This version is great for doing keyword searches and jumping around
within the catalogue with your word processing software, if your
normal email reading software doesn't allow this.
WHO WE ARE:
Tempting Tear-Outs is an advertising company that brings potential new
customers to the companies they advertise for.
MORE ABOUT THE COMPANY MAKING THE FREE OFFER AND THE FREE OFFER ITSELF:
The company making the offer is a magazine subscription agency based in the
USA. They have over 1,100 popular USA titles available to be shipped to
ANY country, including of course, to anywhere in the USA! They offer a
FREE 1 yr. subscription to your choice of over 200 of the titles in their
catalogue to any new customer using them for the first time. The
dollar value of the freebies, based on the subscription prices directly
from the publishers, ranges from $6.97 all the way up to $81.00!
For new customers in the USA, there is no charge for FPH (foreign postage &
handling), so the freebie is 100% free! For new customers living
overseas, the only charge on the freebie would be for the FPH (foreign
postage & handling).
Their president has been in the magazine subscription business since 1973
and they are very customer-service oriented. They will even help you with
address changes on your magazines, even if you move from one country to
another country. They have thousands of happy customers in over 59
countries.
Their price guarantee is very simple: they guarantee that their
subscription prices are the lowest available and they will BEAT any
legitimate, verifiable offer before you pay them or match it afterwards, by
refunding you the difference in price PLUS the cost of the postage stamp
you would use sending in the special offer to them, even 6 months after you
pay them, as long as it was current at the time of your offer. Does that
sound fair? Wouldn't it be great if everything you bought came with
that price guarantee?
Sometimes they are less than half of the next best deal out there,
sometimes just a little cheaper, but always you get the lowest rates
without having to shop around. With 1,100+ titles on their list, they
would like to think that they have also the best selection around!
Within the USA, for their USA customers, they are cheaper than all their
competitors and even the publishers themselves. This is their price
guarantee. The 1 yr. freebie that you get with your first order is
completely free!
Overseas, (even after you factor in the cost of the FPH (foreign postage &
handling) and the conversion from USA Dollars to your currency), on the
average, they are generally around one-fourth to one-half of what the
newsstands overseas charge locally for USA magazines. On some titles they
are as little as one-tenth of what the newsstands charge. They are also
the cheapest subscription source for delivery overseas, including directly
from the publishers themselves! Some publishers don't even offer
subscriptions overseas.........but overseas subscriptions are this
company's specialty! They feel that magazines should not be a luxury
overseas. In the USA, people buy magazines and then toss them after
reading them for just a few minutes or hours. They are so cheap in the
USA! Well, this company would like to make it the same way for their
overseas customers. They are also cheaper than all their competitors in
the USA and overseas, including the publishers themselves! It is also
*highly unlikely* you will find any of their USA competitors calling you
overseas, in order to offer that personal touch, just to sell you a couple
of magazines! But that is what this company specializes in and loves
doing! Around one-half their business comes from overseas, so they are
very patient with new customers who only speak limited English as a 2nd
language. Subscription prices quoted for overseas consist of the
subscription price, plus the FPH. You add the two together and that is
your total cost. The exception is the 1 yr. freebie you get with your
first order. On that title, you pay *only* the FPH for the 1 yr. term.
Their prices are so cheap because when you deal with them, you cut-out all
the middlemen.
HERE IS HOW YOU CAN GET MORE INFO AND GET STARTED WITH THEM:
Simply email, fax or smail back to us the reply form listed at the top of
this message. We will then forward your form on to the subscription
agency. They will then email their "big and juicy" catalogue to you, in
whichever of the two formats you chose. The catalogue is FREE and makes
for hours of fascinating reading, on its own. It includes the complete list
of freebies, a complete list of all the titles they sell, as well as
detailed descriptions on most of the titles, along with lists of titles by
category of interest and their terms of sale.
They will then give you a friendly, no-pressure, no obligation, 5-minute
call to go over how they work and to answer any questions that you might
have, as well as give you up-to-the minute price quotes on any titles you
might be considering. They will call you in whatever country you live
in, taking the time difference into account. As they like to
emphasize the personal touch they give to each new customer, all first-time
orders can only be done via phone, so they can answer all your questions
completely and personally. Once you have placed your first order via
phone, you will be able to place future orders and make inquiries on your
account, get price quotes, etc., all via email, if that is most convenient
for you.
Within the USA, they accept payment via check over the phone, Mastercard,
Visa, American Express, Diner's Club and Carte Blanche. Overseas, they
accept Mastercard, Visa, American Express, Diner's Club and Carte Blanche,
even if your credit card is a local one in local currency (that most
merchants in the USA would not normally be willing to accept).
That's our introduction of our client that we represent. We hope that we
have piqued your interest and that you will take the next step to get their
free catalogue! Thank you for your time and interest.
--
Tempting Tear-Outs.
For more info on marketing & consulting rates, please write us on your
company letterhead, w/business card, via smail to: Tempting Tear-Outs,
3835 Richmond Ave. #200, Staten Island NY 10312-3828, USA.
This email message has been sent to you by: Tempting Tear-Outs, 3835
Richmond Ave. #200, Staten Island NY 10312-3828, USA.
From haberg@matematik.su.se Sun Mar 11 20:27:48 2001
Date: Sun, 11 Mar 2001 21:27:48 +0100
From: Hans Aberg haberg@matematik.su.se
Subject: Mini-Prolog interpreter & ^C
The "readme" file of the mini-Prolog interpreter says:
Unfortunately, typing a control C to interrupt a query with an infinite loop
will exit the Prolog interpreter completely -- sorry, but I don't know a way
around this at the moment.
-- A way to implement this, it seems me, is to design Hugs so that a ^C
generates a Haskell exception; an unhandled exception should then cause an
interrupt.
This way, it becomes possible for a program to handle an interrupt without
exiting.
Hans Aberg
From reid@cs.utah.edu Mon Mar 12 21:58:56 2001
Date: Mon, 12 Mar 2001 14:58:56 -0700
From: Alastair Reid reid@cs.utah.edu
Subject: Mini-Prolog interpreter & ^C
> The "readme" file of the mini-Prolog interpreter says:
> Unfortunately, typing a control C to interrupt a query with an infinite loop
> will exit the Prolog interpreter completely -- sorry, but I don't know a way
> around this at the moment.
>
> -- A way to implement this, it seems me, is to design Hugs so that a ^C
> generates a Haskell exception; an unhandled exception should then cause an
> interrupt.
The readme you quote is fairly old.
GHC provides exactly the kind of exception handling you want.
Look for mention of asynchronous exceptions in their documentation and/or read the paper about asynchronous exceptions on Simon
Peyton Jones home page.
Hugs provides a more limited form of exception handling which lets you catch some exceptions but not others. Unfortunately the
mechanism is not well documented, makes it hard to generate good error messages and interacts badly with the recently improved
concurrency implementation in Hugs. I don't remember if ctrl-C is on the list of exceptions it can catch. Fixing these
deficiencies would be one way of fixing the current problems using the HGL (http://haskell.org/graphics) with the recent Hugs
release. It remains to be seen whether I go down that path.
--
Alastair Reid
From biotechinfo2007@yahoo.com Mon Mar 12 17:55:00 2001
Date: Mon, 12 Mar 2001 17:55:00
From: biotechinfo2007@yahoo.com biotechinfo2007@yahoo.com
Subject: FREE Biotech Stock Info! 68
<html>
<head>
<meta http-equiv="Content-Type" content="text/html; charset=windows-1252">
<meta name="GENERATOR" content="Microsoft FrontPage 4.0">
<meta name="ProgId" content="FrontPage.Editor.Document">
<title>Do you want to capitalize on the Biotech Revolution</title>
</head>
<body>
<p class="MsoNormal" style="mso-margin-top-alt:auto;mso-margin-bottom-alt:auto" align="center"><img border="0" src="http://www.geocities.com/mailtestbox2000/Kiloh_logo.gif" width="204" height="170"></p>
<p class="MsoNormal" style="mso-margin-top-alt:auto;mso-margin-bottom-alt:auto"><span style="font-family:Arial">Do
you want to capitalize on the Biotech Revolution? Would you like to add
groundbreaking biotech, pharmaceutical and medical device companies to your
portfolio mix? Does hearing about exciting IPO and private placement offerings
from life sciences companies interest you?</span></p>
<p class="MsoNormal" style="mso-margin-top-alt:auto;mso-margin-bottom-alt:auto"><span style="font-family:Arial">The
exclusive <b>Ruddy-Carlisle Biotech Infoline</b> service keeps you abreast of
investment opportunities in the life sciences space. Just sign up for it once
and get important information instantly delivered to study at your leisure. Our
service is <b><u>100% FREE</u></b>! <b><span style="color:blue"><a href="mailto:biotechsubscribe@yahoo.com">Sign
up!</a></span></b></span></p>
<p class="MsoNormal" style="mso-margin-top-alt:auto;mso-margin-bottom-alt:auto"><b><i><span style="font-size:11.0pt;mso-bidi-font-size:12.0pt;font-family:Arial;color:#003366">Ruddy-Carlisle
Biotech Infoline:</span></i></b></p>
<ul type="disc">
<li class="MsoNormal" style="color:#003366;mso-margin-top-alt:auto;mso-margin-bottom-alt:
auto;mso-list:l0 level1 lfo1;tab-stops:list .5in"><b><i><span style="font-size:11.0pt;mso-bidi-font-size:12.0pt;font-family:Arial">Instantly
delivers key life sciences investment information directly to you! </span></i></b><o:p>
</o:p>
</li>
<li class="MsoNormal" style="color:#003366;mso-margin-top-alt:auto;mso-margin-bottom-alt:
auto;mso-list:l0 level1 lfo1;tab-stops:list .5in"><b><i><span style="font-size:11.0pt;mso-bidi-font-size:12.0pt;font-family:Arial">Learn
about biotech, pharmaceutical & medical device investment opportunities
before others! </span></i></b><o:p>
</o:p>
</li>
<li class="MsoNormal" style="color:#003366;mso-margin-top-alt:auto;mso-margin-bottom-alt:
auto;mso-list:l0 level1 lfo1;tab-stops:list .5in"><b><i><span style="font-size:11.0pt;mso-bidi-font-size:12.0pt;font-family:Arial">Includes
IPO & private placement information! </span></i></b><o:p>
</o:p>
</li>
<li class="MsoNormal" style="mso-margin-top-alt:auto;mso-margin-bottom-alt:auto;
mso-list:l0 level1 lfo1;tab-stops:list .5in"><b><i><span style="font-size:
11.0pt;mso-bidi-font-size:12.0pt;font-family:Arial;color:#003366">100%
FREE!</span></i></b></li>
</ul>
<p class="MsoNormal" style="mso-margin-top-alt:auto;mso-margin-bottom-alt:auto"><span style="font-family:Arial">For
the entire last decade there were only three profitable biotech companies. At
the end of this year, ten are projected. At the end of 2003, <u>over forty</u>
are projected! The genomic promise is about to be delivered and investors know
it. The <b>Ruddy-Carlisle Biotech Infoline </b>provides you with critical,
decision-making, information that aids the chance of investment success in this
lucrative space. <b><span style="color:blue"><a href="mailto:biotechsubscribe@yahoo.com">Sign
up!</a></span></b></span></p>
<p class="MsoNormal" style="mso-margin-top-alt:auto;mso-margin-bottom-alt:auto"><b><span style="font-family:Arial">Please
Note-</span></b><span style="font-family:Arial"> Your information will only be
shared with companies that are in the life sciences space <u>and</u> pass our
rigorous inspection. Only the best opportunities will come to you.
Ruddy-Carlisle respects your privacy. <b><span style="color:blue"><a href="mailto:biotechsubscribe@yahoo.com">Sign
up!</a></span></b></span></p>
<p class="MsoNormal" style="mso-margin-top-alt:auto;mso-margin-bottom-alt:auto"> </p>
<p class="MsoNormal" style="mso-margin-top-alt:auto;mso-margin-bottom-alt:auto"> </p>
<b><span style="font-size:10.0pt;mso-bidi-font-size:12.0pt;font-family:Arial;
mso-fareast-font-family:"Times New Roman";mso-ansi-language:EN-US;mso-fareast-language:
EN-US;mso-bidi-language:AR-SA">
</p>
</p>List Removal Instructions</span></b><span style="font-size:10.0pt;mso-bidi-font-size:12.0pt;font-family:Arial;mso-fareast-font-family:
"Times New Roman";mso-ansi-language:EN-US;mso-fareast-language:EN-US;
mso-bidi-language:AR-SA">- Simply click here: <b><span style="color:blue"><a href="mailto:remobiotech@yahoo.com">remove</a></span></b>
to be instantly and permanently removed from our list. Send the blank email to
the address specified. Please do not try to reply to this message.</span>
</body>
</html>
From haberg@matematik.su.se Tue Mar 13 09:50:00 2001
Date: Tue, 13 Mar 2001 10:50:00 +0100
From: Hans Aberg haberg@matematik.su.se
Subject: Mini-Prolog interpreter & ^C
At 14:58 -0700 2001/03/12, Alastair Reid wrote:
>The readme you quote is fairly old.
By computer standards, very, very old, something like 1996. Do you remember
what did you do in 1996? :-)
>GHC provides exactly the kind of exception handling you want.
>Look for mention of asynchronous exceptions in their documentation and/or
>read the paper about asynchronous exceptions on Simon
>Peyton Jones home page.
Yes, I know that Haskell should support exceptions. On the other hand, I
may attempt to translate the mini-Prolog Haskell code into C++ for learning
purposes, so then I do not need it... :-)
>Hugs provides a more limited form of exception handling which lets you
>catch some exceptions but not others. Unfortunately the
>mechanism is not well documented, makes it hard to generate good error
>messages and interacts badly with the recently improved
>concurrency implementation in Hugs. I don't remember if ctrl-C is on the
>list of exceptions it can catch.
The reason that I mention it, is that I recall that ^C on Hugs just causes
a regular interrupt signal and not an exception.
The implementation of ^C as an Haskell exception would probably require
first to pick up this signal (as it is usually hardwired to the console),
and then rethrow it as a Haskell exception. Then the Hugs evaluation
mechanism would take the Haskell program down when it encounters an
unhandled exception, mention that it was an interrupt exception that was
not handled.
> Fixing these
>deficiencies would be one way of fixing the current problems using the HGL
>(http://haskell.org/graphics) with the recent Hugs
>release. It remains to be seen whether I go down that path.
If one writes an entirely new console interface, then one can of course let
^C directly generate a Haskell exception.
Hans Aberg
From sigbjorn_finne@hotmail.com Wed Mar 14 13:56:59 2001
Date: Wed, 14 Mar 2001 14:56:59 +0100
From: Sigbjorn Finne sigbjorn_finne@hotmail.com
Subject: Something wrong with Windows 98 installation??
There really seems to have been a conscious change
over at MS regarding this, all downloads are now
offered via the 'MSDN download center', so I suggest
the link to the Windows Installer runtime is changed to:
http://msdn.microsoft.com/code/sample.asp?url=/msdn-files/027/001/455/msdnco
mpositedoc.xml#top
for Win9x (Win95, Win98, WinME) systems, and
http://msdn.microsoft.com/code/sample.asp?url=/msdn-files/027/001/456/msdnco
mpositedoc.xml
for NT4 (Service Pack 3 and later.)
hth
--sigbjorn
----- Original Message -----
From: "Sigbjorn Finne" <sigbjorn_finne@hotmail.com>
To: <jrood@mediaone.net>
Cc: "Hugs Bugs" <hugs-bugs@haskell.org>
Sent: Saturday, March 10, 2001 00:43
Subject: Re: Something wrong with Windows 98 installation??
>
> John Rood jrood@mediaone.net writes:
> >
> > That is, I clicked on the link in the following sentence of your
> > documentation:
> >
> > In the unlikely event that your machine doesn't already have
> > the Windows Installer engine/runtime installed, runtime
> > redistributables can be found here. [<--link]
> >
> > However, this too was unsuccessful, leading to a missing page at
> > Microsoft.
> >
> > How AM I supposed to set this thing up on my machine?
>
> Hi,
>
> you're on the right track, your machine doesn't seem to have the
> installer runtime installed. The download page pointed to is the
> right one, but either someone's temporarily messed things up
> at MS, or the page is really being moved (and the KB and
> other MS docs will be similarly updated, which sounds kind
> of silly, but stranger things have happened..)
>
> When pages & sites go AWOL all of a sudden, I normally turn
> to Google's cache for help - you can get at a copy of the missing
> page at
>
>
http://www.google.com/search?q=cache:www.microsoft.com/msdownload/platformsd
> k/instmsi.htm+instmsi&hl=en
>
> The binaries that this page points to, do seem to point the real goods.
>
> hth,
> --sigbjorn
>
>
>
From nordland@cse.ogi.edu Wed Mar 14 18:10:07 2001
Date: Wed, 14 Mar 2001 10:10:07 -0800
From: Johan Nordlander nordland@cse.ogi.edu
Subject: Something wrong with Windows 98 installation??
Sigbjorn Finne wrote:
>
> There really seems to have been a conscious change
> over at MS regarding this, all downloads are now
> offered via the 'MSDN download center', so I suggest
> the link to the Windows Installer runtime is changed to:
>
> http://msdn.microsoft.com/code/sample.asp?url=/msdn-files/027/001/455/msdnco
> mpositedoc.xml#top
>
> for Win9x (Win95, Win98, WinME) systems, and
>
> http://msdn.microsoft.com/code/sample.asp?url=/msdn-files/027/001/456/msdnco
> mpositedoc.xml
>
> for NT4 (Service Pack 3 and later.)
>
> hth
> --sigbjorn
Thanks, Sigbjorn! The Hugs download page is now updated accordingly.
-- Johan
From jbell@mathsoft.com Fri Mar 16 17:27:08 2001
Date: Fri, 16 Mar 2001 12:27:08 -0500
From: Jonathon Bell jbell@mathsoft.com
Subject: (no subject)
Hi guys,
Thanks for the great work on hugs. I have a possible minor bug. Consider the
following:
import Prelude()
foo = [(i,j) | i<-[0] | j<-[0]]
Evaluating 'foo' generates the runtime error:
Program error: {foo_zip}
presumably because a call is implicilty being made to the standard prelude
function zip which i have hidden. This arose because i am using hugs to
develop my own 'prelude' to simulate an initial environment for a domain
specific language i am creating, and in this custom langauge zip is defined
differently. Interestingly, impilcit calls to map' and 'filter' made by the
list comprehensions don't appear to suffer from the same problem.
Regards,
________________________________
Jonathon Bell jbell@mathsoft.com
MathSoft, Inc. www.mathsoft.com
101 Main St, Cambridge, MA 02142
(617) 577-1017 x745
From jeff@galconn.com Fri Mar 16 17:49:58 2001
Date: Fri, 16 Mar 2001 09:49:58 -0800
From: Jeffrey R. Lewis jeff@galconn.com
Subject: (no subject)
Jonathon Bell wrote:
> Hi guys,
>
> Thanks for the great work on hugs. I have a possible minor bug. Consider the
> following:
>
> import Prelude()
>
> foo = [(i,j) | i<-[0] | j<-[0]]
>
> Evaluating 'foo' generates the runtime error:
>
> Program error: {foo_zip}
>
> presumably because a call is implicilty being made to the standard prelude
> function zip which i have hidden. This arose because i am using hugs to
> develop my own 'prelude' to simulate an initial environment for a domain
> specific language i am creating, and in this custom langauge zip is defined
> differently. Interestingly, impilcit calls to map' and 'filter' made by the
> list comprehensions don't appear to suffer from the same problem.
Standard list comprehensions are translated directly to the `kernel' language - they don't actually generate implicit calls to map and filter. Parallel comprehensions, however, *do* generate calls to `zip', unfortunately they reference whatever `zip' happens to be in scope. You are right to identify this as a bug. It should generate calls to the Prelude zip. Or, even better, just directly generate `kernel' code.
--Jeff
From sigbjorn_finne@hotmail.com Sat Mar 17 19:59:29 2001
Date: Sat, 17 Mar 2001 20:59:29 +0100
From: Sigbjorn Finne sigbjorn_finne@hotmail.com
Subject: Qualified names in instance decls
This is a multi-part message in MIME format.
------=_NextPart_000_0180_01C0AF25.28B73540
Content-Type: text/plain;
charset="iso-8859-1"
Content-Transfer-Encoding: 7bit
In an effort to fix problems rather than just work around them,
here's a patch to Feb2001 sources(*), which permits
the use of qualified names in instance declarations. Hopefully
in a good enough shape to be used; mildly tested.
--sigbjorn
(*) - not quite, diffs are wrt Feb2001 sources after having
applied the module re-exportation fix I suggested earlier.
------=_NextPart_000_0180_01C0AF25.28B73540
Content-Type: application/octet-stream;
name="inst-patch"
Content-Transfer-Encoding: quoted-printable
Content-Disposition: attachment;
filename="inst-patch"
*** parser.y.~1~ Tue Feb 29 02:29:00 2000
--- parser.y Sat Mar 17 20:42:06 2001
***************
*** 1,8 ****
/* =
-------------------------------------------------------------------------=
-
* Hugs parser (included as part of input.c)
*
! * Expect 15 shift/reduce conflicts when passing this grammar through =
yacc,
* but don't worry; they should all be resolved in an appropriate =
manner.
*
* The Hugs 98 system is Copyright (c) Mark P Jones, Alastair Reid, =
the
* Yale Haskell Group, and the Oregon Graduate Institute of Science =
and
--- 1,8 ----
/* =
-------------------------------------------------------------------------=
-
* Hugs parser (included as part of input.c)
*
! * Expect 16 shift/reduce conflicts when passing this grammar through =
yacc,
* but don't worry; they should all be resolved in an appropriate =
manner.
*
* The Hugs 98 system is Copyright (c) Mark P Jones, Alastair Reid, =
the
* Yale Haskell Group, and the Oregon Graduate Institute of Science =
and
***************
*** 421,429 ****
=20
/*- Class declarations: =
---------------------------------------------------*/
=20
topDecl : TCLASS crule fds wherePart {classDefn(intOf($1),$2,$4,$3); =
sp-=3D4;}
! | TINSTANCE irule wherePart {instDefn(intOf($1),$2,$3); sp-=3D3;}
| DEFAULT '(' dtypes ')' {defaultDefn(intOf($1),$3); sp-=3D4;}
| TCLASS error {syntaxError("class declaration");}
| TINSTANCE error {syntaxError("instance declaration");}
| DEFAULT error {syntaxError("default declaration");}
--- 421,429 ----
=20
/*- Class declarations: =
---------------------------------------------------*/
=20
topDecl : TCLASS crule fds wherePart {classDefn(intOf($1),$2,$4,$3); =
sp-=3D4;}
! | TINSTANCE irule iwherePart {instDefn(intOf($1),$2,$3); sp-=3D3;}
| DEFAULT '(' dtypes ')' {defaultDefn(intOf($1),$3); sp-=3D4;}
| TCLASS error {syntaxError("class declaration");}
| TINSTANCE error {syntaxError("instance declaration");}
| DEFAULT error {syntaxError("default declaration");}
***************
*** 611,618 ****
--- 611,630 ----
pair($1,ap(RSIGN,
ap($4,$3)))));}
| pat0 rhs {$$ =3D gc2(ap(PATBIND,pair($1,$2)));}
;
+ idecls : '{' idecls0 end {$$ =3D gc3($2);}
+ | '{' idecls1 end {$$ =3D gc3($2);}
+ ;
+ idecls0 : /* empty */ {$$ =3D gc0(NIL);}
+ | idecls0 ';' {$$ =3D gc2($1);}
+ | idecls1 ';' {$$ =3D gc2($1);}
+ ;
+ idecls1 : idecls0 idecl {$$ =3D gc2(cons($2,$1));}
+=20
+ idecl : qfunlhs rhs {$$ =3D gc2(ap(FUNBIND,pair($1,$2)));}
+ | qvar rhs {$$ =3D =
gc2(ap(PATBIND,pair($1,$2)));}
+ ;
funlhs : funlhs0 {$$ =3D $1;}
| funlhs1 {$$ =3D $1;}
| npk {$$ =3D $1;}
;
***************
*** 627,634 ****
--- 639,659 ----
| '(' npk ')' apat {$$ =3D gc4(ap($2,$4));}
| var apat {$$ =3D gc2(ap($1,$2));}
| funlhs1 apat {$$ =3D gc2(ap($1,$2));}
;
+ qfunlhs : qfunlhs0 {$$ =3D $1;}
+ | qfunlhs1 {$$ =3D $1;}
+ ;
+ qfunlhs0 : pat10_vI qvarop pat0 {$$ =3D gc3(ap2($2,$1,$3));}
+ | infixPat qvarop pat0 {$$ =3D gc3(ap2($2,$1,$3));}
+ | NUMLIT qvarop pat0 {$$ =3D gc3(ap2($2,$1,$3));}
+ | var qvarop_mi pat0 {$$ =3D gc3(ap2($2,$1,$3));}
+ ;
+ qfunlhs1 : '(' qfunlhs0 ')' apat {$$ =3D gc4(ap($2,$4));}
+ | '(' qfunlhs1 ')' apat {$$ =3D gc4(ap($2,$4));}
+ | qvar apat {$$ =3D gc2(ap($1,$2));}
+ | qfunlhs1 apat {$$ =3D gc2(ap($1,$2));}
+ ;
rhs : rhs1 wherePart {$$ =3D gc2(letrec($2,$1));}
| error {syntaxError("declaration");}
;
rhs1 : '=3D' exp {$$ =3D gc2(pair($1,$2));}
***************
*** 642,649 ****
--- 667,680 ----
wherePart : /* empty */ {$$ =3D gc0(NIL);}
| WHERE decls {$$ =3D gc2($2);}
;
=20
+ /* Body of instance decls, differs from wherePart in that
+ qualified names can be bound on the LHS.
+ */
+ iwherePart : /* empty */ {$$ =3D gc0(NIL);}
+ | WHERE idecls {$$ =3D gc2($2);}
+ ;
/*- Patterns: =
-------------------------------------------------------------*/
=20
pat : npk {$$ =3D $1;}
| pat_npk {$$ =3D $1;}
*** static.c.~2~ Sat Mar 3 19:43:08 2001
--- static.c Sat Mar 17 20:41:46 2001
***************
*** 1984,2007 ****
String where; /* Check validity of bindings bs */
Class c; /* for class c (or an inst of c) */
List bs; { /* sort into approp. member order */
List nbs =3D NIL;
=20
for (; nonNull(bs); bs=3Dtl(bs)) {
Cell b =3D hd(bs);
Cell body =3D snd(snd(b));
Name mnm;
=20
! if (!isVar(fst(b))) { /* Only allow function bindings */
ERRMSG(rhsLine(snd(body)))
"Pattern binding illegal in %s declaration", where
EEND;
}
=20
! if (isNull(mnm=3DmemberName(c,textOf(fst(b))))) {
ERRMSG(rhsLine(snd(hd(body))))
"No member \"%s\" in class \"%s\"",
! textToStr(textOf(fst(b))), textToStr(cclass(c).text)
EEND;
}
snd(b) =3D body;
nbs =3D numInsert(mfunOf(mnm)-1,b,nbs);
--- 1984,2015 ----
String where; /* Check validity of bindings bs */
Class c; /* for class c (or an inst of c) */
List bs; { /* sort into approp. member order */
List nbs =3D NIL;
+ Text nm;
=20
for (; nonNull(bs); bs=3Dtl(bs)) {
Cell b =3D hd(bs);
Cell body =3D snd(snd(b));
Name mnm;
=20
! if ( !(isVar(fst(b)) || isQVar(fst(b))) ) { /* Only allow function =
bindings */
ERRMSG(rhsLine(snd(body)))
"Pattern binding illegal in %s declaration", where
EEND;
}
+ =09
+ /* Get at the unqualified name of the method */
+ if (isVar(fst(b))) {
+ nm =3D textOf(fst(b));
+ } else {
+ nm =3D qtextOf(fst(b));
+ }
=20
! if (isNull(mnm=3DmemberName(c,nm))) {
ERRMSG(rhsLine(snd(hd(body))))
"No member \"%s\" in class \"%s\"",
! textToStr(nm), textToStr(cclass(c).text)
EEND;
}
snd(b) =3D body;
nbs =3D numInsert(mfunOf(mnm)-1,b,nbs);
***************
*** 5081,5089 ****
Int line =3D rhsLine(rhs);
Cell lhs =3D fst(snd(d));
Cell v =3D getHead(lhs);
Cell newAlt =3D pair(getArgs(lhs),rhs);
! if (!isVar(v)) {
internal("FUNBIND");
}
if (nonNull(lastVar) && textOf(v)=3D=3DtextOf(lastVar)) {
if (argCount!=3DlastArity) {
--- 5089,5097 ----
Int line =3D rhsLine(rhs);
Cell lhs =3D fst(snd(d));
Cell v =3D getHead(lhs);
Cell newAlt =3D pair(getArgs(lhs),rhs);
! if ( !(isVar(v) || isQVar(v)) ) {
internal("FUNBIND");
}
if (nonNull(lastVar) && textOf(v)=3D=3DtextOf(lastVar)) {
if (argCount!=3DlastArity) {
------=_NextPart_000_0180_01C0AF25.28B73540--
From nordland@cse.ogi.edu Mon Mar 19 23:56:15 2001
Date: Mon, 19 Mar 2001 15:56:15 -0800
From: Johan Nordlander nordland@cse.ogi.edu
Subject: FW: hugs & text editor
Hi Martin,
I'm sorry for letting this slip my mind. However, you're right that the
new version has a slightly different behaviour when it comes to the
editor settings. In an attempt to handle file paths containing space,
Hugs Feb-2001 encloses the file name substituted for %s in the editor
string within double quotes. This usually works just as intended, but
for UEdit that means that the setting
-E"uedit32 %s/%d/1"
will result in an invocation command similar to this:
uedit32 "C:\Program Files\Hugs98\demos\Calendar.hs"/13/1
That is, the line and column modifiers appear outside the quoted file
name, which is something UEdit doesn't seem to handle very well. The
workaround would appear to be to set the quotes explicitly:
-E"uedit32 \"%s/%d/1\""
but that has (until today!) just resulted in two layers of quotes, which
confuses UEdit even more.
However, today I've checked in a fix that suppresses the automatic
quoting when explicit quotes are in scope. That seems to make UEdit
happy, i.e., using the setting above the resulting editor command will
look something like
uedit32 "C:\Program Files\Hugs98\demos\Calendar.hs/13/1"
Explicit quotes around the editor name also continues to be an option,
if you want to specify a full pathname that contains spaces.
The fix will be part of the next Hugs release. However, if you want to
get hold of it immediately (well, tomorrow...), you can check out the
latest Hugs sources using anonymous cvs and compile it yourself. See
http://cvs.haskell.org/ for further directions.
All the best,
Johan
Martin Raubal wrote:
>
> Hi there!
>
> We have the following problem with the Feb. 2001 version of Hugs: When
> having an error and linking Hugs with a text editor, such as UEdit, it used
> to be the case that the cursor in the text editor is automatically set to
> the line of the error. This does not work with the new version, the cursor
> is always at the beginning and one needs to search for the line given in
> Hugs.
>
> Any help?
>
> cheers,
> martinn
From satoru-t@is.aist-nara.ac.jp Wed Mar 21 07:56:21 2001
Date: Wed, 21 Mar 2001 16:56:21 +0900
From: Satoru Takabayashi satoru-t@is.aist-nara.ac.jp
Subject: division with huge numbers
Hi,
I got an unexpected result with division with huge numbers.
% hugs
Prelude> :version
-- Hugs Version February 2001
Prelude> 21099067259124990080755354669061414400 / 708801874985091845381344307009569161216
0.0
Is it a bug or just a limitation? I think it should be something like:
% guile # a scheme interpreter
guile> (/ 21099067259124990080755354669061414400 708801874985091845381344307009569161216)
0.0297672283380582
Thanks,
--
Satoru Takabayashi
http://namazu.org/~satoru/
From uk1o@rz.uni-karlsruhe.de Wed Mar 21 10:56:38 2001
Date: Wed, 21 Mar 2001 11:56:38 +0100
From: Hannah Schroeter uk1o@rz.uni-karlsruhe.de
Subject: division with huge numbers
Hello!
On Wed, Mar 21, 2001 at 04:56:21PM +0900, Satoru Takabayashi wrote:
> Hi,
> I got an unexpected result with division with huge numbers.
> % hugs
> Prelude> :version
> -- Hugs Version February 2001
> Prelude> 21099067259124990080755354669061414400 / 708801874985091845381344307009569161216
> 0.0
> Is it a bug or just a limitation? I think it should be something like:
> % guile # a scheme interpreter
> guile> (/ 21099067259124990080755354669061414400 708801874985091845381344307009569161216)
> 0.0297672283380582
I just tested it. At least my installation of hugs seems to treat
Double equally as Float (single precision IEEE).
And in single precision float, your divisor is already too large and
thus is converted to infinity.
The scheme interpreter you tested seems to treat both numbers as bigint,
divides them and *then* converts the result to double float.
You can do this in Haskell, too:
let a = 21099067259124990080755354669061414400
b = 708801874985091845381344307009569161216
in fromRational (a/b :: Rational) :: Double
However, scheme48 yields:
> (define a 21099067259124990080755354669061414400)
> (define b 708801874985091845381344307009569161216)
> (/ a b)
169584838438183112145988897481525/5697031531194475351894806994354176
And clisp (a Common Lisp implementation):
[1]> (defconstant *a* 21099067259124990080755354669061414400)
*A*
[2]> (defconstant *b* 708801874985091845381344307009569161216)
*B*
[3]> (/ *a* *b*)
169584838438183112145988897481525/5697031531194475351894806994354176
Kind regards,
Hannah.
From satoru-t@is.aist-nara.ac.jp Wed Mar 21 14:25:52 2001
Date: Wed, 21 Mar 2001 23:25:52 +0900
From: Satoru Takabayashi satoru-t@is.aist-nara.ac.jp
Subject: division with huge numbers
Hannah Schroeter <uk1o@rz.uni-karlsruhe.de> wrote:
>You can do this in Haskell, too:
>let a = 21099067259124990080755354669061414400
> b = 708801874985091845381344307009569161216
>in fromRational (a/b :: Rational) :: Double
Thank you very much!
It just worked fine and solved my problem.
-- Satoru Takabayashi
From conal@microsoft.com Tue Mar 27 05:08:33 2001
Date: Mon, 26 Mar 2001 21:08:33 -0800
From: Conal Elliott conal@microsoft.com
Subject: Fran broken with Feb 2001 Hugs
Hi Sean. Some bad news. The Feb'01 Hugs release has a representation
change for IO, breaking Fran's Compatibility.safeTry, which I had copied
from Alastair Reid's graphics library. I noticed that the graphics
library is broken for the same reason. I worked around that problem,
but then I get "Program error: no more threads (deadlock?)" on even the
most trivial Fran example. That kind of error is usually very hard to
track down.
Hugs-bugsers: any guesses about the thread deadlock problem? Also, as a
possible temp solution for Sean, is the previous version of Hugs still
available somewhere? Thanks,
- Conal
From links@gcards.com Tue Mar 27 14:13:09 2001
Date: Tue, 27 Mar 2001 19:43:09 +0530
From: Sharonne links@gcards.com
Subject: Link Exchange !
Hi
I came across your site and liked your site very much.
Incidentally I have a greeting cards site at :
http://www.gcards.com/hugsnkiss/index.html
Virtual Hugs and Kiss Cards at Gcards.com
It would be great if you could exchange links.
My button and banner is located at :-
http://www.gcards.com/banner/index.html
You can also cut and paste the HTML code
given below for a small button to appear
on your page.
With best wishes
Sharonne
http://www.gcards.com
Send a Card in a Flash!!!
========= HTML CODE ============
<div align="center">
<a href="http://www.gcards.com/hugsnkiss/index.html">
<img src="http://www.gcards.com/banner/button1.gif"
width="88" height="31" alt="Click to send Gcards to say YOU CARE !" border="0">
</a>
</div>
========= HTML CODE ============
From links@gcards.com Tue Mar 27 14:13:10 2001
Date: Tue, 27 Mar 2001 19:43:10 +0530
From: Sharonne links@gcards.com
Subject: Link Exchange !
Hi
I came across your site and liked your site very much.
Incidentally I have a greeting cards site at :
http://www.gcards.com/hugsnkiss/index.html
Virtual Hugs and Kiss Cards at Gcards.com
It would be great if you could exchange links.
My button and banner is located at :-
http://www.gcards.com/banner/index.html
You can also cut and paste the HTML code
given below for a small button to appear
on your page.
With best wishes
Sharonne
http://www.gcards.com
Send a Card in a Flash!!!
========= HTML CODE ============
<div align="center">
<a href="http://www.gcards.com/hugsnkiss/index.html">
<img src="http://www.gcards.com/banner/button1.gif"
width="88" height="31" alt="Click to send Gcards to say YOU CARE !" border="0">
</a>
</div>
========= HTML CODE ============
From links@gcards.com Tue Mar 27 14:22:52 2001
Date: Tue, 27 Mar 2001 19:52:52 +0530
From: Sharonne links@gcards.com
Subject: Link Exchange !
Hi
I came across your site and liked your site very much.
Incidentally I have a greeting cards site at :
http://www.gcards.com/hugsnkiss/index.html
Virtual Hugs and Kiss Cards at Gcards.com
It would be great if you could exchange links.
My button and banner is located at :-
http://www.gcards.com/banner/index.html
You can also cut and paste the HTML code
given below for a small button to appear
on your page.
With best wishes
Sharonne
http://www.gcards.com
Send a Card in a Flash!!!
========= HTML CODE ============
<div align="center">
<a href="http://www.gcards.com/hugsnkiss/index.html">
<img src="http://www.gcards.com/banner/button1.gif"
width="88" height="31" alt="Click to send Gcards to say YOU CARE !" border="0">
</a>
</div>
========= HTML CODE ============
From links@gcards.com Tue Mar 27 14:22:54 2001
Date: Tue, 27 Mar 2001 19:52:54 +0530
From: Sharonne links@gcards.com
Subject: Link Exchange !
Hi
I came across your site and liked your site very much.
Incidentally I have a greeting cards site at :
http://www.gcards.com/hugsnkiss/index.html
Virtual Hugs and Kiss Cards at Gcards.com
It would be great if you could exchange links.
My button and banner is located at :-
http://www.gcards.com/banner/index.html
You can also cut and paste the HTML code
given below for a small button to appear
on your page.
With best wishes
Sharonne
http://www.gcards.com
Send a Card in a Flash!!!
========= HTML CODE ============
<div align="center">
<a href="http://www.gcards.com/hugsnkiss/index.html">
<img src="http://www.gcards.com/banner/button1.gif"
width="88" height="31" alt="Click to send Gcards to say YOU CARE !" border="0">
</a>
</div>
========= HTML CODE ============
From ralf@cs.uu.nl Thu Mar 29 14:56:30 2001
Date: Thu, 29 Mar 2001 16:56:30 +0200
From: Ralf Hinze ralf@cs.uu.nl
Subject: Parsing error
Dear Hugs maintainers,
the version of hugs in the repository stumbles over the following
program (which the february 2001 version compiles without problems):
> data Dir = C | N | NE | E | SE | S | SW | W | NW
> deriving (Eq, Read, Show, Enum, Ord)
> instance Num Dir where
> a + b = toEnum (fromEnum a + fromEnum b)
> a - b = toEnum (fromEnum a - fromEnum b)
Parsing
ERROR error.lhs:6 - Syntax error in declaration (unexpected `-')
Just to let you know ...
Cheers, Ralf
From sigbjorn_finne@hotmail.com Thu Mar 29 16:29:11 2001
Date: Thu, 29 Mar 2001 18:29:11 +0200
From: Sigbjorn Finne sigbjorn_finne@hotmail.com
Subject: Parsing error
Ralf Hinze ralf@cs.uu.nl writes:
>
> the version of hugs in the repository stumbles over the following
> program (which the february 2001 version compiles without problems):
>
....
> > instance Num Dir where
> > a + b = toEnum (fromEnum a + fromEnum b)
> > a - b = toEnum (fromEnum a - fromEnum b)
>
>
> Parsing
> ERROR error.lhs:6 - Syntax error in declaration (unexpected `-')
Sorry, my fault - the use of infix (-) was wrongly disallowed as part
of the patch which permitted the use of qualified method names in
instance decls.
My proposed fix is to add the following rule to parser.y
qvarop_mipl : QVAROP {$$ = $1;}
| '-' {$$ = gc1(varMinus);}
| '`' QVARID '`' {$$ = gc3($2);}
| varop_mi {$$ = $1;}
;
and change the last alternative for the rule 'qfunlhs0' from
| var qvarop_mi pat0 {$$ = gc3(ap2($2,$1,$3));}
to
| var qvarop_mipl pat0 {$$ = gc3(ap2($2,$1,$3));}
Many thanks for reporting this, you can get the above code
to work if you parenthesise the operator (which is what the
Hugs Prelude consistently does, which is why this didn't show
up before now.)
--sigbjorn
From reid@cs.utah.edu Thu Mar 29 18:30:04 2001
Date: Thu, 29 Mar 2001 11:30:04 -0700
From: Alastair Reid reid@cs.utah.edu
Subject: Fran and HGL broken with Feb 2001 Hugs
Dear Sean and Thierry [copied to Paul Hudak, Conal Elliott and Hugs Bugs],
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.
In the short term, I recommend that you use an older version of Hugs (can someone at OGI please make this available somewhere?). I
really, really hope that this weekend I'll have a chance to get back to the HGL and make a fix available - but that's exactly what I
thought last weekend and the weekend before that...
Sorry for the delay in dealing with this.
--
Alastair Reid
From C.Reinke@ukc.ac.uk Thu Mar 29 19:54:15 2001
Date: Thu, 29 Mar 2001 20:54:15 +0100
From: C.Reinke C.Reinke@ukc.ac.uk
Subject: Fran and HGL broken with Feb 2001 Hugs
Alastair 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.
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?
It is just too risky to hope that all library authors will test their (in some
cases several years old) libraries whenever any of the Haskell implementations
gets updated, so this would better be automated (as, I believe, it is for GHC).
It cannot be the task of the Hugs maintainers to fix the libraries in the test
suite if they break due to a change to Hugs internals (*), but neither should a
new release of Hugs come out with all those widely used libraries broken.
In other words, new releases of Hugs could be tested against the suite and any
problems encountered could be fixed "behind the scenes" before the releases
reach the general public. In the worst case, if no easy fixes can be found, a
decision would have to be made between breaking all those popular libraries and
not introducing some potentially useful new features.
In case anyone wonders: here in Canterbury, as soon as the first of us found
only one of those libraries broken, a warning went round not to use the new
Hugs for the time being, and that early adopter had to try and restore his old
Hugs environment..(**) No-one here is using the new release! And I know of
other fp places following the same cautious approach, waiting for the situation
to stabilize instead of risking their research and teaching (!!!) environments.
Just some thoughts of a Hugs+libraries fan,
Claus
(*) Btw, what was the rationale for that change? Was it really necessary?
(**) no, it wasn't me, but I agree. I needed to have a look at the new built-in
Observe stuff, and I had been hoping for the new FFI stuff, but not at the
risk of so seriously upsetting my Hugs enviroment, so I only downloaded the
source release and kept my old Hugs installation.
From k20000042@172.16.1.4 Fri Mar 30 11:21:51 2001
Date: Fri, 30 Mar 2001 12:21:51 +0100
From: Muhammad Bilal k20000042@172.16.1.4
Subject: BUGGGGGGGGGGGGGGGGGGGGGGGGGG
HI
I HAVE FOUND A NEW BUG IN THE HASKELL THAT IS WE HAVE HEARED THAT THE
APPENDER IS OF TWO EQUAL ORDER LIST I-e
[[2,3]] ++ [[2,3]]
[[2,3]] ++ [[]]
BUT NOW ACCORDING TO OUR ASSIGNMENT WE HAVE TO MADE THE CARTESIAN PRODUCT
AND I FIND THAT IT IS ALSO WORKING IN APPENDING. from my point of view IT
IS A BUG IN HASKELL ACCORDING TO MY LIMITED INFORMATION.
PLZ SOLVE THIS
[] ++ [[1,2]]
[[2,3]] ++ []
BUT WHEN WE PUT THE FULL LIST INSTEAD OF EMPTY THEN IT GIVES THE ERROR BUT
IT SHOULD BE POSSIBLE TO GIVE ERROR IN EMPTY LIST.
SALAM
MUHAMMED BILAL
bilalnz@yahoo.com
From antony@apocalypse.org Sat Mar 31 20:41:11 2001
Date: Sat, 31 Mar 2001 15:41:11 -0500
From: Antony Courtney antony@apocalypse.org
Subject: Windows registry handling / hugs CVS repository?
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
