|
|
 Up |
|
|
  |
Author: Nyang A. PhraNyang A. Phra Date: Aug 21, 2008 05:20
Hi, all.
I'm a newcomer to purely functional programming, in the process of
wrapping my brain around the central concepts. So, here goes:
Consider a hypothetical purely functional language, with first-class
functions. For convenience, let's say a function can return multiple
values.
Now suppose I have a function random() [pardon the Algolish syntax]
that returns two values: a pseudorandom number and a new function
that, upon invocation, returns the next pseudorandom number and again
a new function, etc.
This would appear to me to preserve referential transparency; a call
to each function would always return the same value.
Or, consider rudimentary I/O in the same vein. A function
open(filename) that would return, say, two anonymous functions, for
reading and writing, such that each write would in turn return a read
function to read the altered version of the file.
You get the idea: a function that alters a state always returns a new
anonymous function to read that altered state.
|
| Show full article (1.72Kb) |
|
| | 9 Comments |
|
|
Author: Dan DoelDan Doel Date: Aug 21, 2008 07:40
Nyang A. Phra wrote:
> This would appear to me to preserve referential transparency; a call
> to each function would always return the same value.
>
> Or, consider rudimentary I/O in the same vein. A function
> open(filename...
|
| Show full article (5.19Kb) |
|
| | no comments |
|
|
Author: Nyang A. PhraNyang A. Phra Date: Aug 21, 2008 08:40
On Aug 21, 5:40 pm, Dan Doel gmail.com> wrote:> Nyang A. Phra wrote:
>> This would appear to me to preserve referential transparency; a call
>> to each function would always return the same value.
>
>> Or, consider rudimentary I/O in the same vein. A function
>> open(filename) that would return, say, two anonymous functions, for
>> reading and writing, such that each write would in turn return a read
>> function to read the altered version of the file.
>
>> You get the idea: a function that alters a state always returns a new
>> anonymous function to read that altered state.
>
>> I guess my question is, not fully grokking what referential
>> transparency is precisely good for, would this be a sufficient
>> approach (efficiency concerns aside) to I/O and side-effects in a
>> purely functional language? As I see it, this approach would preserve
>> referential transparency within each execution of a program, but not
>> between different executions at different times. As an example,
>> consider a time() function, returning the current time and a new ...
|
| Show full article (6.23Kb) |
| no comments |
|
|
Author: Dirk ThierbachDirk Thierbach Date: Aug 21, 2008 23:13
Nyang A. Phra gmail.com> wrote:> Now suppose I have a function random() [pardon the Algolish syntax]
> that returns two values: a pseudorandom number and a new function
> that, upon invocation, returns the next pseudorandom number and again
> a new function, etc.
>
> This would appear to me to preserve referential transparency; a call
> to each function would always return the same value.
Yes, and one can actually write such a pure function. However, it
probably wouldn't really do what you want: It would return the same
sequence of numbers for every run of the program. For a "random" number,
you'd expect it to be different for each run of the program.
> Or, consider rudimentary I/O in the same vein. A function
> open(filename) that would return, say, two anonymous functions, for
> reading and writing, such that each write would in turn return a read
> function to read the altered version of the file.
>
> You get the idea: a function that alters a state always returns a new
> anonymous function to read that altered state.
|
| Show full article (3.08Kb) |
| no comments |
|
|
Author: Nyang A. PhraNyang A. Phra Date: Aug 22, 2008 02:08
On 22 elo, 09:13, Dirk Thierbach
wrote:
> Nyang A. Phra gmail.com> wrote:
>>> Now suppose I have a function random() [pardon the Algolish syntax]
>> that returns two values: a pseudorandom number and a new function
>> that, upon invocation, returns the next pseudorandom number and again
>> a new function, etc.
>
>> This would appear to me to preserve referential transparency; a call
>> to each function would always return the same value.
>
> Yes, and one can actually write such a pure function. However, it
> probably wouldn't really do what you want: It would return the same
> sequence of numbers for every run of the program. For a "random" number,
> you'd expect it to be different for each run of the program.
True, so I'd probably need a seed(Int) function to start the chain
with.
> The result of referentially transparent function depends only on it's
> arguments. That means whenever you call a referentially transparent
> function with known arguments, you could replace the whole...
|
| Show full article (2.84Kb) |
| no comments |
|
|
Author: Torben Ægidius MogensenTorben Ægidius Mogensen Date: Aug 22, 2008 02:53
Dirk Thierbach writes:
> Nyang A. Phra gmail.com> wrote:>> Now suppose I have a function random() [pardon the Algolish syntax]
>> that returns two values: a pseudorandom number and a new function
>> that, upon invocation...
|
| Show full article (2.16Kb) |
| no comments |
|
|
Author: Dirk ThierbachDirk Thierbach Date: Aug 22, 2008 02:56
Nyang A. Phra gmail.com> wrote:> Yes, figures now. So I suppose I could remedy this situation by
> passing a World argument to main() each time I run a program, and then
> use that World as the mother of all things state-dependent. And with
> that, I guess I'm beginning to see the idea of uniqueness typing as
> well..
Exactly. You have to make sure the World is not duplicated, and one
particular instance of the World is never used twice to start a
side effect from. Because the real world behaves this way.
The alternative is to hide the World behind some abstract data type
and only expose accessor functions to that data type that make
sure that the World, which is threaded around inside this data type
for you automatically, is treated in that way. Then you have the IO monad.
- Dirk
|
| |
| no comments |
|
|
Author: Nyang A. PhraNyang A. Phra Date: Aug 22, 2008 05:31
On Aug 22, 12:56 pm, Dirk Thierbach
wrote:
> The alternative is to hide the World behind some abstract data type
> and only expose accessor functions to that data type that make
> sure that the World, which is threaded around inside this data type
> for you automatically, is treated in that way. Then you have the IO monad.
So that's what monads are. Cool. Thanks a lot.
|
| |
| no comments |
|
|
Author: Dirk ThierbachDirk Thierbach Date: Aug 22, 2008 06:14
Nyang A. Phra gmail.com> wrote:> On Aug 22, 12:56 pm, Dirk Thierbach
> wrote:
>> The alternative is to hide the World behind some abstract data type
>> and only expose accessor functions to that data type that make
>> sure that the World, which is threaded around inside this data type
>> for you automatically, is treated in that way. Then you have the IO monad.
> So that's what monads are.
At least with respect to IO (where in an actual implementation of course you
don't really pass the external world around as an variable, that's only
a convenient way to think about it). And since monads are an abstract data
type, you can use them for other stuff, too.
> Cool. Thanks a lot.
You're welcome.
- Dirk
|
| |
| no comments |
|
|
|
|
|
Author: Ertugrul SöylemezErtugrul Söylemez Date: Aug 22, 2008 07:26
"Nyang A. Phra" gmail.com> wrote:
> On Aug 22, 12:56 pm, Dirk Thierbach
> wrote:
>
>> The alternative is to hide the World behind some abstract data type
>> and only expose accessor functions to that data type that make sure
>> that the World, which is threaded around inside this data type for
>> you automatically, is treated in that way. Then you have the IO
>> monad.
>
> So that's what monads are. Cool. Thanks a lot.
That's what the IO monad is, a very specific monad. This is how Haskell
implements impureness in a pure way. Monads are a very generic abstract
structure from category theory.
|
| Show full article (2.89Kb) |
| no comments |
|
|
