On 28-Jul-1999, Lennart Augustsson <[EMAIL PROTECTED]> wrote:
> Fergus Henderson wrote:
> > ... This is OK in Mercury because in Mercury
> > although the operational semantics is required to be sound w.r.t. the
> > declarative semantics, it is not required to be complete; in cases
> > where the d
On 28-Jul-1999, Lennart Augustsson <[EMAIL PROTECTED]> wrote:
> Fergus Henderson wrote:
>
> > equal x y = unsafePerformIO $ do
> > ptrEq <- ptrEqual x y
> > return (ptrEq || deep_equals x y)
> >
> > Note that unlike `req', `equal' here _is_ referentially tr
Lennart Augustsson wrote:
> > ... This is OK in Mercury because in Mercury
...
> Well, given that I think I'll stick to functional languages. ;-)
I appreciate your ;-)
Indeed, for lots of logic programmers, Mercury is a functional
language in a logic syntax disguise.
You can be a functional
At 16:49 +0100 1999/07/28, D. Tweed wrote:
>... I see now that you were describing how you could
>implement `language defined references' with semantics which mean that the
>problems that were pointed out don't happen.
Right.
I think that in a computer language one tends to think of the semantic
Fergus Henderson wrote:
> I'm not sure off-hand what the best fix would be. One possible solution
> would be to force evaluation of the arguments if they are equal:
>
> equal x y = unsafePerformIO $ do
> ptrEq <- ptrEqual x y
> return (if ptrEq then x `
Frank A. Christoph <[EMAIL PROTECTED]> wrote:
> Fergus wrote:
> > If you put the call to `unsafePerformIO' in an
> > unsafe primitive such as `req', then when your code is compiled with
> > some optimizing compiler which assumes that functions are referentially
> > transparent the resulting execut
On 27-Jul-1999, Hans Aberg <[EMAIL PROTECTED]> wrote:
> I think there is not a big problem with breaking "referential
> transparency"; the same think happens in pure math often and it is part of
> a normal procedure of constructing mathematical objects:
>
> Referential transparency means that
>
On Wed, 28 Jul 1999, Hans Aberg wrote:
> At 14:02 +0100 1999/07/28, D. Tweed wrote:
> >> As for a math description of references, one could take the view that one
> >> always constructs objects a, with references r. Then what is indicated in
> >> the language is often the object pairs (a, r) modu
At 14:02 +0100 1999/07/28, D. Tweed wrote:
>> As for a math description of references, one could take the view that one
>> always constructs objects a, with references r. Then what is indicated in
>> the language is often the object pairs (a, r) modulo the equivalence
>> relation that the referenc
On 27-Jul-1999, D. Tweed <[EMAIL PROTECTED]> wrote:
> On Tue, 27 Jul 1999, Simon Marlow wrote:
> > > req a b = unsafePerformIO $ do
> > >a' <- makeStableName a
> > >b' <- makeStableName b
> > >return (a' == b')
> >
> > That's exactly what to use in a situation like this. Pointer equa
On 27-Jul-1999, Simon Marlow <[EMAIL PROTECTED]> wrote:
> > > I would like to have a comparison instruction that compares the internal
> > > reference of two objects.
> > > Let's call it "req".
> > >
> > > req :: a -> a -> Bool
> >
> > By coincidence, I was just looking at GHC's documentation on
On 27-Jul-1999, Frank A. Christoph <[EMAIL PROTECTED]> wrote:
> > I would like to have a comparison instruction that compares the internal
> > reference of two objects.
> > Let's call it "req".
> >
> > req :: a -> a -> Bool
>
> By coincidence, I was just looking at GHC's documentation on stable n
On 27-Jul-1999, Theo Norvell <[EMAIL PROTECTED]> wrote:
> On Tue, 27 Jul 1999, Andreas C. Doering wrote:
>
> > >> let x=[1..] in x==x
> > >> would not terminate in the first case but succeed in the second.
> > >
> > > But, much worse
> > >
> > > let x = (a,b) in x `req` x = True
>
On 27-Jul-1999, Andreas C. Doering <[EMAIL PROTECTED]> wrote:
> [Simon Peyton-Jones wrote:]
> >[Andreas Doering wrote:]
> >> let x=[1..] in x==x
> >> would not terminate in the first case but succeed in the second.
> >
> > But, much worse
> >
> > let x = (a,b) in x `req` x = True
>
Fergus wrote:
> On 27-Jul-1999, Simon Marlow <[EMAIL PROTECTED]> wrote:
> > > > I would like to have a comparison instruction that compares
> the internal
> > > > reference of two objects.
> > > > Let's call it "req".
> > > >
> > > > req :: a -> a -> Bool
> > >
> > > By coincidence, I was just loo
At 17:15 +1000 1999/07/28, Fergus Henderson wrote:
>This comment applies as much to mathematics as to Haskell.
>In mathematics, `x = y => f(x) = f(y)' is an axiom,
>and so if you define a function which violates this axiom,
>you have an inconsistent system.
>If you want your mathematics to be base
On Wed, 28 Jul 1999, Hans Aberg wrote:
> At 17:15 +1000 1999/07/28, Fergus Henderson wrote:
> Actually, it is just an illusion that referential transparency is broken by
>
> > ref 27 <=> ref 27
> >
> >yields False.
>
> Because the semantic runtime meaning of this is that two different objects,
Fergus Henderson wrote:
> equal x y = unsafePerformIO $ do
> ptrEq <- ptrEqual x y
> return (ptrEq || deep_equals x y)
>
> Note that unlike `req', `equal' here _is_ referentially transparent.
No, it's not. If x and y are both bottom you can get unexpected
> So the two conditions
> if a `eq` b then F(a) `eq` F(b)
> if a `req` b then G(a) `req` G(b)
> will only lead to different classes of functions (homomorphisms with
> respect to different properties). The latter will in math more correspond
> to consider all underlying set functions, w
At 14:11 +0200 1999/07/27, Koen Claessen wrote:
>The contructs we add to the language are:
>
> type Ref a = ...
>
> ref :: a -> Ref a
> deref :: Ref a -> a
> (<=>) :: Ref a -> Ref a -> Bool
>
>This basically gives you ML-style but non-updatable references, but you
>can compare them for equal
> I would like to have a comparison instruction that compares the internal
> reference of two objects.
> Let's call it "req".
>
> req :: a -> a -> Bool
By coincidence, I was just looking at GHC's documentation on stable names
and pointers, and it seems relevant here.
http://research.microsoft.co
Andreas C. Doering wrote:
| I would like to have a comparison instruction that compares the internal
| reference of two objects.
It might be of interest here to talk about a paper that Dave Sands and I
have recently submitted to a conference, about something we call
"observable sharing".
It
"D. Tweed" wrote:
> On Tue, 27 Jul 1999, Simon Marlow wrote:
> > > req a b = unsafePerformIO $ do
> > >a' <- makeStableName a
> > >b' <- makeStableName b
> > >return (a' == b')
> >
> > That's exactly what to use in a situation like this. Pointer equality loses
> > referential transpa
On Tue, 27 Jul 1999, Simon Marlow wrote:
> > req a b = unsafePerformIO $ do
> >a' <- makeStableName a
> >b' <- makeStableName b
> >return (a' == b')
>
> That's exactly what to use in a situation like this. Pointer equality loses
> referential transparency in general (as Simon P.J. po
On Tue, 27 Jul 1999, Andreas C. Doering wrote:
> >> let x=[1..] in x==x
> >> would not terminate in the first case but succeed in the second.
> >
> > But, much worse
> >
> > let x = (a,b) in x `req` x = True
> > but
> > (a,b) `req` (a,b) = False
> >
> >
Andreas C. Doering <[EMAIL PROTECTED]> writes:
>
> I would like to have a comparison instruction that compares the internal
> reference of two objects.
> Let's call it "req".
>
> req :: a -> a -> Bool
>
> -- of course it is an equivalence operation
> req x x = True
> req x y = req
>> let x=[1..] in x==x
>> would not terminate in the first case but succeed in the second.
>
> But, much worse
>
> let x = (a,b) in x `req` x = True
> but
> (a,b) `req` (a,b) = False
>
> So referential transparency is lost. This is a high price to pay.
Hello,
I come up again with a topic I mentioned some years ago.
I would like to have a comparison instruction that compares the internal
reference of two objects.
Let's call it "req".
req :: a -> a -> Bool
-- of course it is an equivalence operation
req x x = True
req x y = req y x
(req x
> > I would like to have a comparison instruction that compares
> the internal
> > reference of two objects.
> > Let's call it "req".
> >
> > req :: a -> a -> Bool
>
> By coincidence, I was just looking at GHC's documentation on
> stable names
> and pointers, and it seems relevant here.
>
> ht
> The expression
>
> let x=[1..] in x==x
> would not terminate in the first case but succeed in the second.
But, much worse
let x = (a,b) in x `req` x = True
but
(a,b) `req` (a,b) = False
So referential transparency is lost. This is a high price t
30 matches
Mail list logo
