www.digitalmars.com         C & C++   DMDScript  

digitalmars.D.learn - Functional Programming in D

reply NonNull <non-null use.startmail.com> writes:
Hello,
I want to become fluent in the use of functional programming 
techniques in D (as well as the use of ranges) using 
std.functional (and std.algorithm and whatever else is relevant). 
Is there anything out there that isn't just module documentation 
that covers the full scope of this?
Oct 09 2019
next sibling parent reply Jonathan Gerlach <jonathan thegerlach.net> writes:
On Wednesday, 9 October 2019 at 14:26:53 UTC, NonNull wrote:

 Hello,
 I want to become fluent in the use of functional programming 
 techniques in D (as well as the use of ranges) using 
 std.functional (and std.algorithm and whatever else is 
 relevant). Is there anything out there that isn't just module 
 documentation that covers the full scope of this?


I had this same feeling about wanting to learn `std.functional` a 
bit more, so I decided to do https://adventofcode.com/ with 
additional constraints that the code would be functional D with 
as many unit tests as I could manage.  I learned a bunch and had 
a lot of fun with it.
Oct 09 2019
next sibling parent "H. S. Teoh" <hsteoh quickfur.ath.cx> writes:
On Wed, Oct 09, 2019 at 05:41:02PM +0000, Jonathan Gerlach via
Digitalmars-d-learn wrote:

 On Wednesday, 9 October 2019 at 14:26:53 UTC, NonNull wrote:

 Hello,
 I want to become fluent in the use of functional programming
 techniques in D (as well as the use of ranges) using std.functional
 (and std.algorithm and whatever else is relevant). Is there anything
 out there that isn't just module documentation that covers the full
 scope of this?


 
 I had this same feeling about wanting to learn `std.functional` a bit
 more, so I decided to do https://adventofcode.com/ with additional
 constraints that the code would be functional D with as many unit
 tests as I could manage.  I learned a bunch and had a lot of fun with
 it.


Actually, std.functional is somewhat of a misnomer. It mostly deals with
higher-order functions, i.e., functions that return functions, currying,
that sort of thing.  These are part of functional programming, but
there's more to functional programming than that.  I'd say std.range and
std.algorithm are another major part of functional-style programming
support in D, along with the purity system.

Here are some resources that might help get you started:

	https://klickverbot.at/blog/2012/05/purity-in-d/
	https://tour.dlang.org/tour/en/basics/ranges
	http://ddili.org/ders/d.en/ranges.html
	http://dconf.org/2015/talks/davis.html
	http://www.informit.com/articles/printerfriendly.aspx?p=1407357&rll=1
	http://wiki.dlang.org/Component_programming_with_ranges


T

-- 
What did the alien say to Schubert? "Take me to your lieder."
Oct 09 2019
prev sibling next sibling parent reply Russel Winder <russel winder.org.uk> writes:
On Wed, 2019-10-09 at 11:12 -0700, H. S. Teoh via Digitalmars-d-learn wrote=
:
[=E2=80=A6]

 Actually, std.functional is somewhat of a misnomer. It mostly deals with
 higher-order functions, i.e., functions that return functions, currying,
 that sort of thing.  These are part of functional programming, but
 there's more to functional programming than that.  I'd say std.range and
 std.algorithm are another major part of functional-style programming
 support in D, along with the purity system.


[=E2=80=A6]

I feel that it is best to leave functional programming to functional
programming language, e.g. Haskell, Scheme, etc. rather than try to do
functional programming in imperative languages, e.g. Java, C++, Rust, D. Th=
e
reason is things like lazy evaluation and the consistency of everything bei=
ng
a function, etc. The underlying computational models of functional programm=
ing
languages and imperative programming languages need different mindsets to u=
se
well. Witness the issues in using Scala.

Having said this, declarative programming can be pursued in functional
languages, logic languages (e.g. Prolog), and imperative languages. Tools s=
uch
as higher order functions are crucial to this, but currying is not, unless =
it
is core to partial evaluation as it is in Haskell.

Modern C++, D, Rust =E2=80=93 but not Go =E2=80=93 all admit programming us=
ing a declarative
way of working just as Haskell and Scheme do. My experience of emphasising
declarative programming in imperative languages is that people build smalle=
r,
more comprehensible, and maintainable code that achives the goal compared w=
ith
using tradition imperative programming.

--=20
Russel.
=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=
=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D
Dr Russel Winder      t: +44 20 7585 2200
41 Buckmaster Road    m: +44 7770 465 077
London SW11 1EN, UK   w: www.russel.org.uk
Oct 10 2019
parent reply bachmeier <no spam.net> writes:
On Thursday, 10 October 2019 at 08:59:49 UTC, Russel Winder wrote:


 I feel that it is best to leave functional programming to 
 functional programming language, e.g. Haskell, Scheme, etc. 
 rather than try to do functional programming in imperative 
 languages, e.g. Java, C++, Rust, D. The reason is things like 
 lazy evaluation and the consistency of everything being a 
 function, etc. The underlying computational models of 
 functional programming languages and imperative programming 
 languages need different mindsets to use well. Witness the 
 issues in using Scala.


My impressions is that the complaints about Scala are similar to 
C++: too many features that clash with one another and make the 
language complicated, plus extremely slow compilation times. I 
haven't seen a lot of complaints about mixing imperative and 
functional.
Oct 10 2019
parent Bienlein <ffm2002 web.de> writes:
On Thursday, 10 October 2019 at 16:05:13 UTC, bachmeier wrote:

 On Thursday, 10 October 2019 at 08:59:49 UTC, Russel Winder 
 wrote:

 My impressions is that the complaints about Scala are similar 
 to C++: too many features that clash with one another and make 
 the language complicated, plus extremely slow compilation 
 times. I haven't seen a lot of complaints about mixing 
 imperative and functional.


Scala compile times are slow, because Scala has more compilation 
phases than C++. I guess that is because of feature bloat in the 
language as such, IMHO not necessarily because FP and OOP are 
mixed into the same language. Scala is just packed with too many 
language constructs that are also in many cases quite extensive. 
Then there is a problem with implicit conversions in Scala not 
being scalable in compilation times, see 
https://dzone.com/articles/implicits-scala-conversion

In Scala3 (due to be released in spring 2020) implicits were 
replaced by what they call delegates (and extension methods were 
introduced). Whether that reduces compilation times I don't know. 
But the compiler in Scala3 is based on a complete new approach to 
further reduce compilation times. However, Scala3 is a new 
language. Whether people will make the move from Scala to Scala3 
remains to be seen.
Oct 11 2019
prev sibling next sibling parent reply "H. S. Teoh" <hsteoh quickfur.ath.cx> writes:
On Thu, Oct 10, 2019 at 09:59:49AM +0100, Russel Winder via Digitalmars-d-learn
wrote:

 On Wed, 2019-10-09 at 11:12 -0700, H. S. Teoh via Digitalmars-d-learn wrote:
 […]

 Actually, std.functional is somewhat of a misnomer. It mostly deals
 with higher-order functions, i.e., functions that return functions,
 currying, that sort of thing.  These are part of functional
 programming, but there's more to functional programming than that.
 I'd say std.range and std.algorithm are another major part of
 functional-style programming support in D, along with the purity
 system.


 […]
 
 I feel that it is best to leave functional programming to functional
 programming language, e.g. Haskell, Scheme, etc. rather than try to do
 functional programming in imperative languages, e.g. Java, C++, Rust,
 D.


[...]

Note this is why I wrote "functional-style programming" w.r.t. D, rather
than "functional programming". Clearly, what D has isn't "real"
functional programming in the strict sense, but it does share similar
characteristics when written in that style.


T

-- 
It is of the new things that men tire --- of fashions and proposals and
improvements and change. It is the old things that startle and
intoxicate. It is the old things that are young. -- G.K. Chesterton
Oct 10 2019
next sibling parent Bienlein <ffm2002 web.de> writes:
On Thursday, 10 October 2019 at 10:08:14 UTC, H. S. Teoh wrote:

 On Thu, Oct 10, 2019 at 09:59:49AM +0100, Russel Winder via 
 Digitalmars-d-learn wrote:

 On Wed, 2019-10-09 at 11:12 -0700, H. S. Teoh via 
 Digitalmars-d-learn wrote: […]

 Actually, std.functional is somewhat of a misnomer. It 
 mostly deals with higher-order functions, i.e., functions 
 that return functions, currying, that sort of thing.  These 
 are part of functional programming, but there's more to 
 functional programming than that. I'd say std.range and 
 std.algorithm are another major part of functional-style 
 programming support in D, along with the purity system.


 […]
 
 I feel that it is best to leave functional programming to 
 functional programming language, e.g. Haskell, Scheme, etc. 
 rather than try to do functional programming in imperative 
 languages, e.g. Java, C++, Rust, D.


 [...]

 Note this is why I wrote "functional-style programming" w.r.t. 
 D, rather than "functional programming". Clearly, what D has 
 isn't "real" functional programming in the strict sense, but it 
 does share similar characteristics when written in that style.


I did programming in Smalltalk for about 10 years. Smalltalk has 
all those things that are now called "functional-style 
programming" or even IMHO incorrectly "functional programming" 
that are about applying operations on collections. In Smalltalk 
these functions (like collect, map, reject, detect, inject, etc.) 
are simply called "collection iterators". They already exist in 
Smalltalk-80, which is called that way, because it was published 
in 1980. To verify this you can download the Smalltalk-80 "blue 
book" from here and do a text search on these function names: 
http://stephane.ducasse.free.fr/FreeBooks/BlueBook/Bluebook.pdf

In those 10 years where I did Smalltalk development I met no one 
who called making use of those collection iterators functional 
programming. There are several books about Smalltalk who have 
some importance in CS, because Smalltalk was the first truly 
useable OO language afer Simula. I don't think the term 
functional programming is ever used there.

Calling collection iterators functional programming opened 
Pandoras box of mixing up things. I fear it is too late to 
explain to people that functional progeramming is what is done in 
Haskel and Lisp and related languages and nothing else.

Collection iterators carry some aspects of functional programming 
such as non-destructive programming as the result of applying a 
function on a call returns a new collection leaving the original 
collection unchanged, but that alone is not enogh for things to 
be called functional programming. It is merely simply making use 
of closures.
Oct 10 2019
prev sibling parent bachmeier <no spam.net> writes:
On Thursday, 10 October 2019 at 10:08:14 UTC, H. S. Teoh wrote:

 On Thu, Oct 10, 2019 at 09:59:49AM +0100, Russel Winder via 
 Digitalmars-d-learn wrote:

 On Wed, 2019-10-09 at 11:12 -0700, H. S. Teoh via 
 Digitalmars-d-learn wrote: […]

 Actually, std.functional is somewhat of a misnomer. It 
 mostly deals with higher-order functions, i.e., functions 
 that return functions, currying, that sort of thing.  These 
 are part of functional programming, but there's more to 
 functional programming than that. I'd say std.range and 
 std.algorithm are another major part of functional-style 
 programming support in D, along with the purity system.


 […]
 
 I feel that it is best to leave functional programming to 
 functional programming language, e.g. Haskell, Scheme, etc. 
 rather than try to do functional programming in imperative 
 languages, e.g. Java, C++, Rust, D.


 [...]

 Note this is why I wrote "functional-style programming" w.r.t. 
 D, rather than "functional programming". Clearly, what D has 
 isn't "real" functional programming in the strict sense, but it 
 does share similar characteristics when written in that style.


 T


An even better phrase is simply "good programming practice". 
Avoiding global mutable state, writing pure functions, passing 
around functions as arguments, and letting the language handle 
iteration rather than using for loops and related outdated 
constructs is good practice. You might need to make exceptions 
for performance reasons, but then you're in the realm of hacks 
rather than practices.
Oct 10 2019
prev sibling parent Russel Winder <russel winder.org.uk> writes:
On Thu, 2019-10-10 at 03:08 -0700, H. S. Teoh via Digitalmars-d-learn wrote=
:
[=E2=80=A6]

 Note this is why I wrote "functional-style programming" w.r.t. D, rather
 than "functional programming". Clearly, what D has isn't "real"
 functional programming in the strict sense, but it does share similar
 characteristics when written in that style.


Indeed, I was trying to support that view. I think declarative rather than
functional-style is a better label for this since it avoids the functional =
vs
imperative paradigm conflict left over from the late 1980s and 1990s.
=20
--=20
Russel.
=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=
=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D
Dr Russel Winder      t: +44 20 7585 2200
41 Buckmaster Road    m: +44 7770 465 077
London SW11 1EN, UK   w: www.russel.org.uk
Oct 10 2019
prev sibling parent reply SrMordred <patric.dexheimer gmail.com> writes:
https://garden.dlang.io/
Oct 09 2019
parent Tobias Pankrath <tobias+dlang pankrath.net> writes:
On Wednesday, 9 October 2019 at 18:57:01 UTC, SrMordred wrote:

 https://garden.dlang.io/


This should be more prominent. Very nice.
Oct 10 2019