[Haskell-cafe] "show" for functional types

Robert Dockins robdockins at fastmail.fm
Wed Apr 5 13:06:26 EDT 2006


On Apr 5, 2006, at 12:42 PM, Josef Svenningsson wrote:

> Sorry to barge in in the middle of your discussion here..

Hey, if we wanted a private conversation, we'd take it off-list. :-)

> On 4/5/06, Robert Dockins <robdockins at fastmail.fm> wrote:
>> There is a fair bit of disagreement about what referential
>> transparency means.  I found the following link after googling around
>> a bit; it seems to address some of these issues.
>>
>> http://www.cs.indiana.edu/~sabry/papers/purelyFunctional.ps
>>
> Do you have any reference to the fact that there is any diagreement
> about the term? I know it has been used sloppily at times but I think
> it is pretty well defined. See section 4 of the following paper:
> http://www.dina.kvl.dk/~sestoft/papers/SondergaardSestoft1990.pdf

http://en.wikipedia.org/wiki/Referential_transparency
http://lambda-the-ultimate.org/node/1237

It may be that experts have a well defined notion of what it means,  
but I think that non-experts (ie, most people) have a pretty vague  
idea of exactly what it means.


> Readers digest:
> First we need a denotational semantics and a corresponding equality
> which I call '='. A language is then referentially transparent if for
> all expressions e,e1 and e2, if e1 = e2 then e[x:=e1] = e[x:=e2].
> Here e[x:=e'] denotes substitution where the variable x is replaced
> with e' in the expression e.
>
> So it's a standard substitutivity property. The only problem here is
> that Haskell has a pretty hairy denotational semantics and I don't
> think anyone has spelled it out in detail.

I think that may be the main problem, at least in this context.  We  
can take a nice lovely definition of rt, as above, but its  
meaningless without a good semantic model.  So we're forced to  
approximate and hand-wave, which is where the disagreement comes in.

> The thing which I think
> comes closest is the following paper which investigates the
> denotational implications of have seq as a primitive:
> http://www.crab.rutgers.edu/~pjohann/seqFinal.pdf
>
> Cheers,
>
> /Josef

Thanks for these paper links; I'll be reading them as soon as I find  
a few moments.

Rob Dockins

Speak softly and drive a Sherman tank.
Laugh hard; it's a long way to the bank.
           -- TMBG





More information about the Haskell-Cafe mailing list