www.digitalmars.com         C & C++   DMDScript  

digitalmars.D - Grafting Functional Support on Top of an Imperative Language

reply Walter Bright <newshound1 digitalmars.com> writes:
Andrei Alexandrescu's talk just given at ACCU:

http://www.digitalmars.com/d/2.0/accu-functional.pdf
Apr 04 2008
next sibling parent Brian Palmer <d brian.codekitchen.net> writes:
This is a great set of slides and I think it explains really clearly the "why"
of D 2.0's const/invariant system. I wish there was a video of Andrei giving
the presentation available.

I'm a systems/web programmer but I have a heavy background in FP, and I *love*
where D 2.0 is going. To me the automatic multiprogramming, while awesome, is
really just another side benefit. Even single-threaded code will see a huge
benefit from the guarantees of purity that the compiler can give with this
pure/invariant/const system in place. Reading through these slides has just
make me even more excited.
Apr 04 2008
prev sibling next sibling parent reply bearophile <bearophileHUGS lycos.com> writes:
Walter Bright:
 Andrei Alexandrescu's talk just given at ACCU:
 http://www.digitalmars.com/d/2.0/accu-functional.pdf

The pages of this talk are interesting, and simple enough. Page 2: >As convenient as a scripting language< This is a myth/lie. D seems more 'convenient' than C++ and C in some applications, but dynamic languages like Python are probably more 'productive' than D still. P.6: >Ideal language—allow:< I'm sure lot of people (like functional programming lovers) don't think that mix as the ideal situation :-) P.14 >Defining a transitive const< That's one possible D 2.x, the current one, but it may change. This talk presents such things like they are already finished and set in stone (FP programming in D 2.x too). P. 31: >writeln(i);< Can you put (temporary) debugging writeln/putr inside a pure function? P. 35: >It all rests on an efficient machine model!< I don't understand :-) Bye, bearophile
Apr 04 2008
parent reply Jason House <jason.james.house gmail.com> writes:
bearophile wrote:
 P. 31: >writeln(i);<
 
 Can you put (temporary) debugging writeln/putr inside a pure function?

That's always bothered me about this stuff. I don't want to lose debugging/logging ability!
Apr 04 2008
next sibling parent reply "Simen Kjaeraas" <simen.kjaras gmail.com> writes:
On Sat, 05 Apr 2008 01:09:14 +0200, Jason House  
<jason.james.house gmail.com> wrote:

 bearophile wrote:
 P. 31: >writeln(i);<

 Can you put (temporary) debugging writeln/putr inside a pure function?

That's always bothered me about this stuff. I don't want to lose debugging/logging ability!

Just use multiple return types, and have the caller do the printing. --Simen
Apr 04 2008
parent reply Bill Baxter <dnewsgroup billbaxter.com> writes:
Simen Kjaeraas wrote:
 On Sat, 05 Apr 2008 01:09:14 +0200, Jason House 
 <jason.james.house gmail.com> wrote:
 
 bearophile wrote:
 P. 31: >writeln(i);<

 Can you put (temporary) debugging writeln/putr inside a pure function?

That's always bothered me about this stuff. I don't want to lose debugging/logging ability!

Just use multiple return types, and have the caller do the printing. --Simen

Monads! Or at least I think that's what I read somewhere. I can't understand the buggers for the life of me. I think maybe it's just a fancy word for "loophole". If someone here has a good explanation for what a monad is and how it allows mutable state in FP without making thing non-FP, I'd love to hear it. Because I just don't get it. --bb
Apr 04 2008
next sibling parent reply "Simen Kjaeraas" <simen.kjaras gmail.com> writes:
On Sat, 05 Apr 2008 02:03:29 +0200, Bill Baxter  =

<dnewsgroup billbaxter.com> wrote:

 Simen Kjaeraas wrote:
 On Sat, 05 Apr 2008 01:09:14 +0200, Jason House  =


 <jason.james.house gmail.com> wrote:

 bearophile wrote:
 P. 31: >writeln(i);<

 Can you put (temporary) debugging writeln/putr inside a pure functi=




 That's always bothered me about this stuff.  I don't want to lose
 debugging/logging ability!



  --Simen

Monads! Or at least I think that's what I read somewhere. I can't understand =

 the buggers for the life of me.  I think maybe it's just a fancy word =

 for "loophole".  If someone here has a good explanation for what a mon=

 is and how it allows mutable state in FP without making thing non-FP, =

 I'd love to hear it.  Because I just don't get it.

 --bb

I read a bit on Wikipedia about monads, and they seem to me to be a fanc= y = way to do multiple return values. I'm not sure if they're usable = (hackable) in D at the moment, or if we need to wait for AST macros befo= re = we can use them as they should. But one example, the 'maybe' monad, seem= s = to me a bit like this: struct Maybe(T) { bool Nothing; T data; static Maybe!(U) opCall(U)(lazy U u) { typeof(return) tmp; try { data =3D u(); tmp.Nothing =3D false; } catch (object o) { tmp.Nothing =3D true; // something went wrong, data is invalid } } T opAdd(T rhs) { if (Nothing) return rhs; // act as if data is nonexistant else return data + rhs; } // other operators overloaded in similar ways } Disclaimer: This might or might not work. It might contain some value of= = truth, and it might not. It is merely my understanding after a half-hour= = of reading at 2:30 in the morning, and so should be sanity-checked befor= e = use. -- Simen
Apr 04 2008
parent reply "Koroskin Denis" <2korden+dmd gmail.com> writes:
This reminds me 'The Power of None' presentation by Andrei Alexandrescu:=


http://www.nwcpp.org/Meetings/2006/05.html
http://www.nwcpp.org/Downloads/2006/The_Power_of_None.ppt

On Sat, 05 Apr 2008 04:54:26 +0400, Simen Kjaeraas  =

<simen.kjaras gmail.com> wrote:

 On Sat, 05 Apr 2008 02:03:29 +0200, Bill Baxter  =

 <dnewsgroup billbaxter.com> wrote:

 Simen Kjaeraas wrote:
 On Sat, 05 Apr 2008 01:09:14 +0200, Jason House  =



 <jason.james.house gmail.com> wrote:

 bearophile wrote:
 P. 31: >writeln(i);<

 Can you put (temporary) debugging writeln/putr inside a pure  =





 function?

That's always bothered me about this stuff. I don't want to lose debugging/logging ability!




  --Simen

Monads! Or at least I think that's what I read somewhere. I can't understand=


 the buggers for the life of me.  I think maybe it's just a fancy word=


 for "loophole".  If someone here has a good explanation for what a  =


 monad is and how it allows mutable state in FP without making thing  =


 non-FP, I'd love to hear it.  Because I just don't get it.

 --bb

I read a bit on Wikipedia about monads, and they seem to me to be a =

 fancy way to do multiple return values. I'm not sure if they're usable=

 (hackable) in D at the moment, or if we need to wait for AST macros  =

 before we can use them as they should. But one example, the 'maybe'  =

 monad, seems to me a bit like this:

 struct Maybe(T)
 {
    bool Nothing;
    T data;

    static Maybe!(U) opCall(U)(lazy U u)
    {
      typeof(return) tmp;

      try
      {
        data =3D u();
        tmp.Nothing =3D false;
      }
      catch (object o)
      {
        tmp.Nothing =3D true; // something went wrong, data is invalid
      }
    }

    T opAdd(T rhs)
    {
      if (Nothing)
        return rhs; // act as if data is nonexistant
      else
        return data + rhs;
    }

    // other operators overloaded in similar ways
 }


 Disclaimer: This might or might not work. It might contain some value =

 truth, and it might not. It is merely my understanding after a half-ho=

 of reading at 2:30 in the morning, and so should be sanity-checked  =

 before use.

 -- Simen

Apr 08 2008
parent "Simen Kjaeraas" <simen.kjaras gmail.com> writes:
On Tue, 08 Apr 2008 14:16:06 +0200, Koroskin Denis <2korden+dmd gmail.com>  
wrote:

 This reminds me 'The Power of None' presentation by Andrei Alexandrescu:

 http://www.nwcpp.org/Meetings/2006/05.html
 http://www.nwcpp.org/Downloads/2006/The_Power_of_None.ppt

Thanks, I hadn't read that. -- Simen
Apr 08 2008
prev sibling parent reply "Jarrett Billingsley" <kb3ctd2 yahoo.com> writes:
"Bill Baxter" <dnewsgroup billbaxter.com> wrote in message 
news:ft6fkf$1m9v$1 digitalmars.com...
 Simen Kjaeraas wrote:
 On Sat, 05 Apr 2008 01:09:14 +0200, Jason House 
 <jason.james.house gmail.com> wrote:

 bearophile wrote:
 P. 31: >writeln(i);<

 Can you put (temporary) debugging writeln/putr inside a pure function?

That's always bothered me about this stuff. I don't want to lose debugging/logging ability!

Just use multiple return types, and have the caller do the printing. --Simen

Monads! Or at least I think that's what I read somewhere. I can't understand the buggers for the life of me. I think maybe it's just a fancy word for "loophole". If someone here has a good explanation for what a monad is and how it allows mutable state in FP without making thing non-FP, I'd love to hear it. Because I just don't get it. --bb

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: print("Enter your name: ") name = readLine() print("Hi, ", name) Each of those function calls is impure, as they change the state of the computer. A "pure" way of doing it is: // we start with state defined at the beginning of the program state = print(state, "Enter your name: ") (state, name) = readLine(state) state = print(state, "Hi, ", name) (readLine returns two values.) This creates an ordering of the execution of statements, which is one part of the "imperative" problem that monads solve (since functional code does not have any set ordering of execution). I think a monad basically wraps up the ugliness of getting and passing the state into a nicer-looking syntax, i.e. do putStr "Enter your name: " name <- readLine -- this isn't named this, I don't think.. putStr "Hi, " putStrLn name which, in Haskell, is really just syntactic sugar which hides all the horrible IO Monad manipulation. But again, I'm not one to be listened to ;)
Apr 04 2008
parent reply Lars Noschinski <lars-2008-1 usenet.noschinski.de> writes:
* 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.
Apr 05 2008
parent reply Bill Baxter <dnewsgroup billbaxter.com> writes:
Lars Noschinski wrote:
 * 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.

Hmm, so would it be correct to say that monad is just another way to say 'impure function'? It sounds like that's all you're saying. So just like we're going to have 'pure' to isolate the functional code in D, functional languages have 'impure' functions that isolate the procedural/stateful stuff. They just happen to give those impure functions a ridiculous name. Seriously why on earth are they called 'monads'? Sounds like it derives from "mono" meaning "one", like "triad" is a group of three things. So 'monad' should mean a group of one thing I would thing. Yet it means "impure function". Really odd. I hate it when people give things terrible non-descriptive names. But maybe there's a rational explanantion? --bb
Apr 05 2008
next sibling parent Lars Ivar Igesund <larsivar igesund.net> writes:
Bill Baxter wrote:

 Lars Noschinski wrote:
 * 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.

Hmm, so would it be correct to say that monad is just another way to say 'impure function'? It sounds like that's all you're saying. So just like we're going to have 'pure' to isolate the functional code in D, functional languages have 'impure' functions that isolate the procedural/stateful stuff. They just happen to give those impure functions a ridiculous name. Seriously why on earth are they called 'monads'? Sounds like it derives from "mono" meaning "one", like "triad" is a group of three things. So 'monad' should mean a group of one thing I would thing. Yet it means "impure function". Really odd. I hate it when people give things terrible non-descriptive names. But maybe there's a rational explanantion?

I always thought it had to do with money, but then I'm not a native English speaker ... -- Lars Ivar Igesund blog at http://larsivi.net DSource, #d.tango & #D: larsivi Dancing the Tango
Apr 05 2008
prev sibling parent reply Jeff Nowakowski <jeff dilacero.org> writes:
Bill Baxter wrote:
 
 Seriously why on earth are they called 'monads'?

http://en.wikipedia.org/wiki/Monads_in_functional_programming "The name monad derives from category theory, a branch of mathematics that describes patterns applicable to many mathematical fields. (As a minor terminological mismatch, the term "monad" in functional programming contexts is usually used with a meaning corresponding to that of the term "strong monad" in category theory, a specific kind of category theoretical monad.[citation needed])" -Jeff
Apr 05 2008
parent Bill Baxter <dnewsgroup billbaxter.com> writes:
Jeff Nowakowski wrote:
 Bill Baxter wrote:
 Seriously why on earth are they called 'monads'?

http://en.wikipedia.org/wiki/Monads_in_functional_programming "The name monad derives from category theory, a branch of mathematics that describes patterns applicable to many mathematical fields. (As a minor terminological mismatch, the term "monad" in functional programming contexts is usually used with a meaning corresponding to that of the term "strong monad" in category theory, a specific kind of category theoretical monad.[citation needed])"

Hmm, comes close, but doesn't really explain it. So the reason they are called monads is because they are like "strong monads" from category theory. So why are they called "strong monads" in category theory? Anyway, thanks for trying to help despite my laziness. :-) --bb
Apr 05 2008
prev sibling next sibling parent "Unknown W. Brackets" <unknown simplemachines.org> writes:
Surely there would be some sort of (detectable) cast or some such to 
"escape" a pure function for debugging?  Or maybe this just plain ol' 
relies on running a debugger (not so much fun.)

-[Unknown]


Jason House wrote:
 bearophile wrote:
 P. 31: >writeln(i);<

 Can you put (temporary) debugging writeln/putr inside a pure function?

That's always bothered me about this stuff. I don't want to lose debugging/logging ability!

Apr 04 2008
prev sibling next sibling parent Leandro Lucarella <llucax gmail.com> writes:
Jason House, el  4 de abril a las 19:09 me escribiste:
 bearophile wrote:
 P. 31: >writeln(i);<
 
 Can you put (temporary) debugging writeln/putr inside a pure function?

That's always bothered me about this stuff. I don't want to lose debugging/logging ability!

You can't have all. If you functions have side effects, you can't do a lot of things (like a rollback & retry with STM). -- Leandro Lucarella (luca) | Blog colectivo: http://www.mazziblog.com.ar/blog/ ---------------------------------------------------------------------------- GPG Key: 5F5A8D05 (F8CD F9A7 BF00 5431 4145 104C 949E BFB6 5F5A 8D05) ---------------------------------------------------------------------------- RENUNCIO PARA IR A REZARLE A SAN CAYETANO -- Crónica TV
Apr 04 2008
prev sibling parent Brian Palmer <d brian.codekitchen.net> writes:
Jason House Wrote:

 bearophile wrote:
 P. 31: >writeln(i);<
 
 Can you put (temporary) debugging writeln/putr inside a pure function?

That's always bothered me about this stuff. I don't want to lose debugging/logging ability!

This seems like a non-issue to me. Even Haskell, one of the "purest of the pure", so to speak, has the unsafePerformIO "back door" to allow just these kind of idempotent side effects. I'm sure D will have the same. The trade-off, of course, is that once you decide to sneak in the back door, it's up to you to verify that your debug statements or whatever truly don't have any affect on the rest of the application, because at that point you've given up all compiler promises. D would probably implement it as a simple "cast" on functions from non-pure to pure, much of the issues that arise in Haskell's back door don't apply to D because of lazy vs. eager evaluation, etc.
Apr 04 2008
prev sibling next sibling parent reply Sean Kelly <sean invisibleduck.org> writes:
== Quote from Walter Bright (newshound1 digitalmars.com)'s article
 Andrei Alexandrescu's talk just given at ACCU:
 http://www.digitalmars.com/d/2.0/accu-functional.pdf

It's unfortunate that he won't talk to any of us about this. Sean
Apr 04 2008
parent reply bearophile <bearophileHUGS lycos.com> writes:
Sean Kelly:
 It's unfortunate that he won't talk to any of us about this.

Through that document he is talking to you. There are just less ways to push information the opposite direction :-) Bye, bearophile
Apr 04 2008
parent reply Georg Wrede <georg nospam.org> writes:
bearophile wrote:
 Sean Kelly:
 
 It's unfortunate that he won't talk to any of us about this.


Yes. But the way he got treated here, who can blame him.
 Through that document he is talking to you. There are just less ways
 to push information the opposite direction :-)

What I really wish, is for him to write down the main points in the slide show, maybe along the lines I recently wrote here in "What is pure and what is not pure". Walter might post a copy of it here? That would help a lot, especially since I can't say I really understood too much of the slide show.
Apr 04 2008
next sibling parent Jason House <jason.james.house gmail.com> writes:
Georg Wrede Wrote:

 bearophile wrote:
 Sean Kelly:
 
 It's unfortunate that he won't talk to any of us about this.


Yes. But the way he got treated here, who can blame him.

Huh? What happened?
 
 Through that document he is talking to you. There are just less ways
 to push information the opposite direction :-)

What I really wish, is for him to write down the main points in the slide show, maybe along the lines I recently wrote here in "What is pure and what is not pure". Walter might post a copy of it here? That would help a lot, especially since I can't say I really understood too much of the slide show.

Apr 04 2008
prev sibling parent "Craig Black" <craigblack2 cox.net> writes:
"Georg Wrede" <georg nospam.org> wrote in message 
news:47F6D1A2.70300 nospam.org...
 bearophile wrote:
 Sean Kelly:

 It's unfortunate that he won't talk to any of us about this.


Yes. But the way he got treated here, who can blame him.

He shouldn't ignore all of us just because of one hot head with a chip on his shoulder. -Craig
Apr 04 2008
prev sibling next sibling parent reply Jarrod <qwerty ytre.wq> writes:
On Fri, 04 Apr 2008 14:46:26 -0700, Walter Bright wrote:

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

I'm going to get grilled for this post. D is a great imperative language. D is a terrible functional language. This might sound harsh, but it's true. Functional languages need a lot of special features to be what they are. They need to have statements that work as expressions, unique data structures like chained lists, the ability to heavily compress statements so as to prevent using temporary values that us imperative programmers do enjoy so very much. Some functional languages (in fact, arguably the 'cleanest' functional languages like forth and joy) require the use of a special 'stack' to manage data. D does not have these features, and unless you want to completely change what D is, D cannot have these features. Now, I'm all for the non-breaking things that functional languages have graced us: map, filter and range, tail recursion optimization, even simple forms of 'pure' functions are nice as well. But this whole const and pure thing is looking pretty ugly. Imperative programmers use const/invariant datasets as a contract; a way to set out guidelines for how their data should be used. Functional languages take it a step further and force all data to be immutable, making it a rule, not a guideline to use immutable data. The meaning of const changes between these two paradigms, and I think it's going to cause a lot of problems within D when they mix, especially when functional languages keep all this immutable stuff conveniently hidden away inside lists and stacks that the programmer doesn't have to worry about. 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.
Apr 04 2008
next sibling parent Bill Baxter <dnewsgroup billbaxter.com> writes:
Jarrod wrote:
 On Fri, 04 Apr 2008 14:46:26 -0700, Walter Bright wrote:

 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.

Nooooo! That's what I called my D library with Flexible Linear Algebra Types. --bb
Apr 04 2008
prev sibling next sibling parent Jarrod <qwerty ytre.wq> writes:
On Sat, 05 Apr 2008 14:52:47 +0900, Bill Baxter wrote:

 Jarrod wrote:
 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.

Nooooo! That's what I called my D library with Flexible Linear Algebra Types. --bb

Aw, I liked D flat. How about FunkyD? DFunct? D++?
Apr 04 2008
prev sibling next sibling parent "Janice Caron" <caron800 googlemail.com> writes:
On 05/04/2008, Jarrod <qwerty ytre.wq> wrote:
  Heck, why not make a functional dialect of D? Call it "D flat"

You do realise that D flat is the same thing as C sharp?* I suppose there is some ironic humor in that. J ---- *To be precise, in contemporary Western music, D flat is enharmonically equivalent to C sharp, but there are other tuning systems in which that is not so.
Apr 04 2008
prev sibling next sibling parent reply Christopher Wright <dhasenan gmail.com> writes:
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.
Apr 05 2008
parent Sean Kelly <sean invisibleduck.org> writes:
== 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.

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
Apr 05 2008
prev sibling parent Jarrod <qwerty ytre.wq> writes:
On Sat, 05 Apr 2008 15:43:16 +0000, Sean Kelly wrote:

 == Quote from Christopher Wright (dhasenan gmail.com)'s article
 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

Well, I'm surprised to be getting people agreeing, I kind of expected to be the black sheep here. I was kind of serious about the functional dialect of D though. It seems Walter is keenly interested in exploring functional techniques, so this might be a better way to get them implemented. No need to hack up D and make it too complicated.
Apr 05 2008
prev sibling next sibling parent reply Don Clugston <dac nospam.com.au> writes:
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>
Apr 05 2008
next sibling parent reply "Craig Black" <craigblack2 cox.net> writes:
 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
Apr 05 2008
next sibling parent reply Christopher Wright <dhasenan gmail.com> writes:
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.
Apr 05 2008
parent Christopher Wright <dhasenan gmail.com> writes:
Janice Caron wrote:
 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)
 

You could use return const. But I'm not entirely sure. I was explaining what I understood of someone else's proposal.
Apr 05 2008
prev sibling parent Sean Kelly <sean invisibleduck.org> writes:
== 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>

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
Apr 05 2008
prev sibling parent "Janice Caron" <caron800 googlemail.com> writes:
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)
Apr 05 2008
prev sibling next sibling parent reply torhu <no spam.invalid> writes:
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?
Apr 05 2008
parent Walter Bright <newshound1 digitalmars.com> writes:
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.
Apr 05 2008
prev sibling parent "Steven Schveighoffer" <schveiguy yahoo.com> writes:
"Walter Bright" wrote
 Andrei Alexandrescu's talk just given at ACCU:

 http://www.digitalmars.com/d/2.0/accu-functional.pdf

Thanks for posting this. I think this is the first time you have laid out the plans/rules for pure functions in D, and it confirms what I already had inferred :) -Steve
Apr 06 2008