Hi,
Daan said:
>
> Personally, I feel that this problem might be better solved by
> making a lot of the implicit assumptions (and semantics) of type
> classes more explicit, and bring them under user control. Of course,
> I do have not have any idea of how this should be done concretely ;-)
John Meacham wrote (snipped):
> I should say that efficiency is the only thing I have been concerned
> about in this conversation.
Well, I think my proposal can be made efficient if you try, using hash tables.
There is a reason why I think top-level <- is inefficient,
because it imposes a single sc
John Meacham wrote (snipped):
> recursive top level declarations are no more tricky than are normal
> recursive lets.
Perhaps I am missing something, but surely one very important problem with
<- at top level is that calling for the value of something defined by <-
causes the corresponding action t
I have recently taken over maintainership of Haskell-mode, and after making
a bunch of changes, I figured it would be a good idea to make a new release.
You can find this new release at:
http://www-perso.iro.umontreal.ca/~monnier/elisp/
If you think it should also be found at
http://www.
Keean Schupke wrote:
Daan Leijen wrote:
You are right, I feel like that too: one should expect that the type
checker can figure this out, and perhaps it is even really useful.
On the other hand, suppose you decide later to export the
class, and suddenly your code would no longer type check.
I must
Daan Leijen wrote:
You are right, I feel like that too: one should expect that the type
checker can figure this out, and perhaps it is even really useful.
On the other hand, suppose you decide later to export the
class, and suddenly your code would no longer type check.
I must have missed a mail...
Daan Leijen wrote:
You are right, I feel like that too: one should expect that the type
checker can figure this out, and perhaps it is even really useful.
On the other hand, suppose you decide later to export the
class, and suddenly your code would no longer type check.
The fact that adding an expo
Lennart Augustsson wrote:
Daan Leijen wrote:
A "closed class" directive however is an explicit specification that
makes the intention of the designer explicit in the program. Since
it would solve the puzzle in a rather elegant and explicit way, I
thought that it was interesting to mention.
Indeed,
Jules Bean wrote:
By the same token, you can just stick the function strangeReadFile ::
FilePath -> String into the language. As long as it is memoized, always
returning the same value, it doesn't break beta-reduction. I call it
'strange' because the time that the file is actually read is not
g
Tomasz Zielonka wrote:
On Thu, Nov 25, 2004 at 07:52:43PM +0100, Lennart Augustsson wrote:
As I'm sure you have gathered from all the answers you can't have the
latter and keep Haskell pure. But there is an interesting alternative
(at least theoretically). You could have a function like
mkCatchJu
On 25 Nov 2004, at 19:24, Tomasz Zielonka wrote:
On Thu, Nov 25, 2004 at 07:52:43PM +0100, Lennart Augustsson wrote:
As I'm sure you have gathered from all the answers you can't have the
latter and keep Haskell pure. But there is an interesting alternative
(at least theoretically). You could have
On Thu, Nov 25, 2004 at 07:52:43PM +0100, Lennart Augustsson wrote:
> As I'm sure you have gathered from all the answers you can't have the
> latter and keep Haskell pure. But there is an interesting alternative
> (at least theoretically). You could have a function like
>
> mkCatchJust :: IO ((E
John Goerzen wrote:
So why do we have:
catchJust :: (Exception -> Maybe b) -> IO a -> (b -> IO a) -> IO a
instead of:
catchJust :: (Exception -> Maybe b) -> (c -> a) -> c -> (b -> a) -> a
As I'm sure you have gathered from all the answers you can't have the
latter and keep Haskell pure. But there
Graham Klyne wrote:
I have a concern with this, if I understand the issue correctly.
Suppose I have a source module that compiles and runs correctly.
Now suppose I add a restricted (selective) import statement to the file,
explicitly introducing a name that I know does not clash with anything
in
Of course it can. I might do it myself. :)
-- Lennart
Keean Schupke wrote:
I have already asked Simon PJ if this can be implemented in GHC... So if
more people
ask for it, it might get done!
Keean
Lennart Augustsson wrote:
Here is a small puzzle.
-- The following generates a type err
Daan Leijen wrote:
Keean Schupke wrote:
No, closed classes are different, here we are talking about lazy
overlap resolution, so
if at _call_ time only one instance fits we choose it. Closing a class
is different.
A "closed class" directive however is an explicit specification that
makes the inte
John Meacham wrote:
>I should say that efficiency is the only thing I have been concerned
>about in this conversation. As I said in the mdo proposal, there is no
>efficient and safe way to do global variables in haskell.
I think George Russell's library (with a simple extension) can be used
to cre
Thanks Adrian, for some reason I did not get the original reply to this
post.
This was my point, I may _want_ two copies of the library. Lets say I
want to
write a virtual machine emulator in haskell, and I then wish to use your
library to drive the virtualised hardware... There must be some way
I have a concern with this, if I understand the issue correctly.
Suppose I have a source module that compiles and runs correctly.
Now suppose I add a restricted (selective) import statement to the file,
explicitly introducing a name that I know does not clash with anything in
my module. I expect
Keean Schupke wrote:
No, closed classes are different, here we are talking about lazy overlap
resolution, so
if at _call_ time only one instance fits we choose it. Closing a class
is different.
A "closed class" directive however is an explicit specification that
makes the intention of the designe
No, closed classes are different, here we are talking about lazy overlap
resolution, so
if at _call_ time only one instance fits we choose it. Closing a class
is different.
Keean.
Daan Leijen wrote:
Lennart Augustsson wrote:
[snip]
So in what sense is this really ambiguous?
I think it would b
I have already asked Simon PJ if this can be implemented in GHC... So if
more people
ask for it, it might get done!
Keean
Lennart Augustsson wrote:
Here is a small puzzle.
-- The following generates a type error:
f :: Char -> Char
f c =
let x = g c
in h x
-- But this definition does n
On Wednesday 24 Nov 2004 11:50 am, Keean Schupke wrote:
> There is no problem getting multiple copies of the channels... I take it
> you are not familiar with the internals of OSs
IME there is no uniformity wrt OS internals, and I can't claim to be
familiar with them all. It's also fairly safe to
No, with exactly the type signatures they have I don't think
you can. But the untyped version of them can be implemented.
And that is good enough to convince me that the beta rule is
still valid.
-- Lennart
Josef Svenningsson wrote:
-Original Message-
From: [EMAIL PROTECTED] [mail
> -Original Message-
> From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED] On
> Behalf Of Marcin 'Qrczak' Kowalczyk
> Sent: den 25 november 2004 11:49
> To: [EMAIL PROTECTED]
> Subject: Re: [Haskell] Real life examples
>
> Lennart Augustsson <[EMAIL PROTECTED]> writes:
>
> > An "easy" way
Lennart Augustsson <[EMAIL PROTECTED]> writes:
> An "easy" way to prove it is to provide an equivalent implementation
> that uses only pure functions. As far as I remember Control.Monad.ST
> can be written purely. And I think the same is true for Data.Dynamic.
I think neither of them can.
--
| This is a great example, thanks for posting it. However, I feel like
| the real problem in this example is the lexically-scoped type
| variables declared with your function f.
Paul's message gives me an excuse to consult the Haskell list about the
design of lexically scoped type variables. I h
On Wednesday 24 Nov 2004 9:37 pm, John Meacham wrote:
> On Wed, Nov 24, 2004 at 03:48:56PM +, Keean Schupke wrote:
> > Having admited to wavering on the edge of accepting top level TWIs,
> > perhaps one of the supporters would like to comment on qualified
> > importing... IE what
> > happens to
On Thu, Nov 25, 2004 at 09:54:41AM +0100, George Russell wrote:
> John Meacham wrote (snipped):
> > George Russell's library is precicly an invalid use of unsafePerformIO.
> > Internally, it does the invalid unsafePerformIO (newIORef) trick which
> > is exactly the problem we are trying to solve. h
On Thu, Nov 25, 2004 at 10:07:20AM +0100, George Russell wrote:
> John Meacham wrote:
> > Now, my mdo proposal as written would have "hello" outputed exactly once
> > at module start up time no matter what, whether x is demanded or not. it
> > is equivalant to a program transformation that collects
I don't necessarily agree that you can do this trick
in all implementations of Dynamic and Typable.
You're relying on more things than the interface to
Dynamic promises. Your fromDynamic could very well
return Nothing. And should!
But that doesn't matter. The unsafeCast function doesn't
really w
Lennart wrote (snipped):
> An "easy" way to
> prove it is to provide an equivalent implementation that uses only
> pure functions. As far as I remember Control.Monad.ST can be written
> purely. And I think the same is true for Data.Dynamic.
I don't see how it can be, since you can use Data.Dynami
John Meacham wrote:
> Now, my mdo proposal as written would have "hello" outputed exactly once
> at module start up time no matter what, whether x is demanded or not. it
> is equivalant to a program transformation that collects all the top
> level initializers and declarations, puts them all in a m
John Meacham wrote (snipped):
> George Russell's library is precicly an invalid use of unsafePerformIO.
> Internally, it does the invalid unsafePerformIO (newIORef) trick which
> is exactly the problem we are trying to solve. hiding it in a module doesn't
> make it go away.
Why does it matter to yo
[EMAIL PROTECTED] wrote:
G'day all.
Quoting Lennart Augustsson <[EMAIL PROTECTED]>:
Here is a small puzzle.
You can understand this one because the closed world hypothesis doesn't
apply to type context inference.
I have no problem understanding the technical reason for this.
But I now think it's
Ben Rudiak-Gould wrote:
Lennart Augustsson wrote:
> What do you mean when you say the interface is pure?
>
> If your module is really pure then there should be an implemenation
> of it (which could have really bad complexity) with the same observable
> behaviour that uses only pure Haskell. I
36 matches
Mail list logo
