NewsBot
1
http://clean.cs.ru.nl/About_Clean/Clean_Language_Features/clean_language_features.htmlBack from Christmas party. A late-night thread before Machine.Idle...
Some thoughts...
Let's discuss functional programming language features. Which features are you liking the most. I've just finished speed-reading Expert F# (will have to go through a second and perhaps third pass for some sections, such as computation expressions, or workflows (F# monads)).
I'll not be making a clear distinction between library features and language features.
A pretty simple first and second feature I'm betting I'll like is the composition and pipe operators.
let*z = [1;2;3] |> List.map (fun x -> x+4)
let*f = List.map (fun x -> x+4) >> List.filter (fun x -> x>5)
The first line pipes a list through to a partial application of the list mapping function. The second line creates a new function that pipes the output of a list mapping application through to a list filter. So these operators are closely related, but pose a quite intuitive syntax and apparently also help type-inference.
The third and fourth feature that looks very promising is the computation expressions and the asynchronous computation expressions (workflows and asynchronous workflows).
The canonical example Don Syme gives for asynchronous workflows is an asynchronous workflow that fetches a set of webpages.
The next step is to switch to using the Task Parallel Library (TPL, or PFX?) instead of the thread pool as the underpinning of the asynchronous workflow implementation. That*sounds reasonable.
One might distinguish between embarassingly parallel tasks and embarassingly parallelizable code. I wonder what the future brings in terms of auto-parallelization where there doesn't need to be any explicit concurrency and the compiler and virtual machine finds opportunities to optimize hotspots on the fly, just as the hotspot VM finds opportunities on the fly for optimizing hotspots now (I don't know about the CLR).
The question then - how intelligent can auto-parallization become - with potentially side-effecting*I/O functions interleaved in the code.
F# is not a complete "port" of OCaml for .Net in that it misses some features, but also has some other features, so it's not a strict feature subset either.
Having spent a little time with SML, I've come to somewhat admire the functors - from a distance at least. The way things like powesets are represented look quite beautiful to me.
The mathematical purity of functional programming is also attractive, although it can be mind-bending (category theory and a thousand morphisms.)
But what do you think? What features are some of the most powerful in the realm of functional programming and where do you see mainstream functional programming go and how might the CLR better cater for functional code?
Another aspect is that, for example in Expert F#, there's lots of examples on the use of Windows Forms and other .Net libraries, although I believe Foundations of F# is the book on .Net library use from F#, it seems to me that these frameworks are developed from the POV of a C# or VB developer. I wonder what frameworks we'll get from the POV of a functional programmer who thinks functional first. I'm betting there'll be some differences there. Not to mention that Windows Forms is sort of deprecated of course (not, but in a more or less immutable state.) There might also be some tension between functional and imperative .Net programmers if new platforms emerge with a functional bias - and vice versa of course.
Then there's the temporal nature of imperative programs with the freedom to destructively update compared to the side-effect free functional programs (free from side-effects or bound to side effect-free'ness?). It is possible to have partially side-effecting functional structures of course, but to remain pure those effects should probably remain hidden and be tied to the way the structures remain efficient, under the hood - not as a means to have immutable structures of mutable objects, so to speak. A parallel to this is (I believe) the*CLEAN language which has some semantics for safe destructive updates within a pure functional language (CLEAN destructive updates, so to speak). That's a pretty cool feature.
OK, this looks more like a blog post now, but I hope you'll share your thoughts...
A good source of functional programming research (check out the last two posts - one on higher-kinded generics, the other on the nature of infinity... okay, so strike the last one, but check it anyway):
http://lambda-the-ultimate.org/
More...
View All Our Microsft Related Feeds
Some thoughts...
Let's discuss functional programming language features. Which features are you liking the most. I've just finished speed-reading Expert F# (will have to go through a second and perhaps third pass for some sections, such as computation expressions, or workflows (F# monads)).
I'll not be making a clear distinction between library features and language features.
A pretty simple first and second feature I'm betting I'll like is the composition and pipe operators.
let*z = [1;2;3] |> List.map (fun x -> x+4)
let*f = List.map (fun x -> x+4) >> List.filter (fun x -> x>5)
The first line pipes a list through to a partial application of the list mapping function. The second line creates a new function that pipes the output of a list mapping application through to a list filter. So these operators are closely related, but pose a quite intuitive syntax and apparently also help type-inference.
The third and fourth feature that looks very promising is the computation expressions and the asynchronous computation expressions (workflows and asynchronous workflows).
The canonical example Don Syme gives for asynchronous workflows is an asynchronous workflow that fetches a set of webpages.
The next step is to switch to using the Task Parallel Library (TPL, or PFX?) instead of the thread pool as the underpinning of the asynchronous workflow implementation. That*sounds reasonable.
One might distinguish between embarassingly parallel tasks and embarassingly parallelizable code. I wonder what the future brings in terms of auto-parallelization where there doesn't need to be any explicit concurrency and the compiler and virtual machine finds opportunities to optimize hotspots on the fly, just as the hotspot VM finds opportunities on the fly for optimizing hotspots now (I don't know about the CLR).
The question then - how intelligent can auto-parallization become - with potentially side-effecting*I/O functions interleaved in the code.
F# is not a complete "port" of OCaml for .Net in that it misses some features, but also has some other features, so it's not a strict feature subset either.
Having spent a little time with SML, I've come to somewhat admire the functors - from a distance at least. The way things like powesets are represented look quite beautiful to me.
The mathematical purity of functional programming is also attractive, although it can be mind-bending (category theory and a thousand morphisms.)
But what do you think? What features are some of the most powerful in the realm of functional programming and where do you see mainstream functional programming go and how might the CLR better cater for functional code?
Another aspect is that, for example in Expert F#, there's lots of examples on the use of Windows Forms and other .Net libraries, although I believe Foundations of F# is the book on .Net library use from F#, it seems to me that these frameworks are developed from the POV of a C# or VB developer. I wonder what frameworks we'll get from the POV of a functional programmer who thinks functional first. I'm betting there'll be some differences there. Not to mention that Windows Forms is sort of deprecated of course (not, but in a more or less immutable state.) There might also be some tension between functional and imperative .Net programmers if new platforms emerge with a functional bias - and vice versa of course.
Then there's the temporal nature of imperative programs with the freedom to destructively update compared to the side-effect free functional programs (free from side-effects or bound to side effect-free'ness?). It is possible to have partially side-effecting functional structures of course, but to remain pure those effects should probably remain hidden and be tied to the way the structures remain efficient, under the hood - not as a means to have immutable structures of mutable objects, so to speak. A parallel to this is (I believe) the*CLEAN language which has some semantics for safe destructive updates within a pure functional language (CLEAN destructive updates, so to speak). That's a pretty cool feature.
OK, this looks more like a blog post now, but I hope you'll share your thoughts...
A good source of functional programming research (check out the last two posts - one on higher-kinded generics, the other on the nature of infinity... okay, so strike the last one, but check it anyway):
http://lambda-the-ultimate.org/
More...
View All Our Microsft Related Feeds
