Walter Bright wrote:
> Andrei Alexandrescu's talk just given at ACCU:
> 
> http://www.digitalmars.com/d/2.0/accu-functional.pdf

The next step after allowing modification of 'automatic state' is to allow nested functions which modify local variables, which should be easy enough to check.
Seems to me that D remains an imperative language, but allows you to insert functional programming "walls" between parts of the program. Will be fascinating to see how much of the benefits of FP this gives us.

I suspect that ultimately, a go-between "possibly pure"* qualifier for functions will be desirable, just as const acts as "possibly invariant".
But that's just a hunch.

*an amoral function -- pure if used in pure surroundings, impure if surrounded in bad company. <g>

> I suspect that ultimately, a go-between "possibly pure"* qualifier for functions will be desirable, just as const acts as "possibly invariant".
> But that's just a hunch.
>
> *an amoral function -- pure if used in pure surroundings, impure if surrounded in bad company. <g>

Huh?  Is this just a joke or are you being serious?  Are you talking about a templated function?  I don't see the point of "possibly pure".

-Craig 

Jarrod wrote:
> I guess what I'm trying to say is functional languages are good at what they do because they are functional languages. D is not a functional language, and as such trying to use it as one is probably just going to end up painful. If you want D to work like a functional language, turn it into a functional language Walter. Force all data to be immutable by default, all functions to be pure unless they prove otherwise, add native support for lists and tuples and add a bunch of list manipulation functions..
> Heck, why not make a functional dialect of D? Call it "D flat" and have it compile alongside D or something. No need to mix the two.
> 
> The current imperative/OO style of D is brilliant, fun to use, flexible and just packed with lovely features. Please don't go killing it on me by trying to make it an ugly jack of all trades.

Agreed. People are mixing languages a decent amount these days; I'd like to see an official, supported way to integrate, say, Erlang with D, so that I can have Erlang parallelize stuff and D do the actual work.

Craig Black wrote:
>> I suspect that ultimately, a go-between "possibly pure"* qualifier for functions will be desirable, just as const acts as "possibly invariant".
>> But that's just a hunch.
>>
>> *an amoral function -- pure if used in pure surroundings, impure if surrounded in bad company. <g>
> 
> Huh?  Is this just a joke or are you being serious?  Are you talking about a templated function?  I don't see the point of "possibly pure".
> 
> -Craig

If you have a pure function, it must only take invariant arguments, and it can be automatically parallelized.

If you have a function that is amoral, it would be pure if you gave it all invariant arguments, but you could give it const or mutable arguments as well.

An amoral function has all the same contracts as a pure function, but none of the limitations on its arguments.

On 05/04/2008, Christopher Wright <dhasenan@gmail.com> wrote:
>  If you have a function that is amoral, it would be pure if you gave it all
> invariant arguments, but you could give it const or mutable arguments as
> well.

That's probably not possible. Consider the declaration:

    pure invariant(C) f(invariant(C) x)

Exactly how could the compiler deduce a version with const or mutable
arguments? Would it be (a)

    invariant(C) f(const(C) x)

or would it be (b)

    const(C) f(const(C) x)

? If you answered (a), consider that the function body might have been:

    pure invariant(C) f(invariant(C) x)
    {
        return x;
    }

Conversely, if you answered (b), consider that the function body might
have been:

    pure invariant(C) f(invariant(C) x)
    {
        return x.idup;
    }

(assuming idup is implemented for class C)

Walter Bright wrote:
> Andrei Alexandrescu's talk just given at ACCU:
> 
> http://www.digitalmars.com/d/2.0/accu-functional.pdf

I've made a version of this file with a white background instead of black, so it can be printed.  Would I be violating anyone's copyright or anything if I post the link to the modified file here?

== Quote from Craig Black (craigblack2@cox.net)'s article
> > I suspect that ultimately, a go-between "possibly pure"* qualifier for functions will be desirable, just as const acts as "possibly invariant". But that's just a hunch.
> >
> > *an amoral function -- pure if used in pure surroundings, impure if surrounded in bad company. <g>
> Huh?  Is this just a joke or are you being serious?  Are you talking about a templated function?  I don't see the point of "possibly pure".

With the const design, functional code can call imperative code and vice-
versa.  ie. a functional routine could pass its invariant data to an imperative
routine accepting const parameters, and an imperative routine could .idup
or whatever to call a functional routine.  But 'pure' is currently a one-way
street.  Imperative code could call pure code, but the reverse is not true.
Don's "possibly pure" was a way to allow things to work in the opposite
direction, much like 'const' does.


Sean

== Quote from Christopher Wright (dhasenan@gmail.com)'s article
> Jarrod wrote:
> > I guess what I'm trying to say is functional languages are good at what
> > they do because they are functional languages. D is not a functional
> > language, and as such trying to use it as one is probably just going to
> > end up painful. If you want D to work like a functional language, turn it
> > into a functional language Walter. Force all data to be immutable by
> > default, all functions to be pure unless they prove otherwise, add native
> > support for lists and tuples and add a bunch of list manipulation
> > functions..
> > Heck, why not make a functional dialect of D? Call it "D flat" and have
> > it compile alongside D or something. No need to mix the two.
> >
> > The current imperative/OO style of D is brilliant, fun to use, flexible and just packed with lovely features. Please don't go killing it on me by trying to make it an ugly jack of all trades.
> Agreed. People are mixing languages a decent amount these days; I'd like to see an official, supported way to integrate, say, Erlang with D, so that I can have Erlang parallelize stuff and D do the actual work.

Same here.  I have no interest in "one language to rule them all."  I prefer a specialized tool for the task at hand.


Sean

torhu wrote:
> I've made a version of this file with a white background instead of black, so it can be printed.  Would I be violating anyone's copyright or anything if I post the link to the modified file here?

That would be up to Andrei, not me. You'll need to email him to ask permission.

* Jarrett Billingsley <kb3ctd2@yahoo.com> [08-04-05 05:15]:
>I'm not one to be listened to, but I think the idea behind monads is to wrap an inherently impure action (like IO) in a functional shell.  In an imperative language, you do something like:

Monads are an imperative sublanguage. IO Monads (which are the ones able
to do impure things) are safe, because there is no way to extract the
information wrapped in the monad.

So if you do a read, you don't get a "String", you get an "IO String"
(i.e. an IO monad containing a string). But you can apply functions to
the IO monad, which operate on the wrapped value and return a new IO
monad (for example a method parsing the String to an integer).

For the functional part of the program (all things outside of the IO
monad), the return value of e.g. readLine is always the same - an IO
monad representing the action of reading a line of input and therefore
it is pure.