In F# we have Computation Expressions, which can reduce boiler-plate and nesting when working in various computational contexts (async, optionals and so on).
Does ReasonML have an equivalent of this?
If so, what is the syntax?
By default, nope; no computation expressions. Reason is just another syntax still sharing all of the OCaml semantics, so a similar behavior is commonly achieved using modules, functors and composition.
However, Reason and OCaml have ppx rewriters, that allow extending the syntax to achieve this sort of things. There is already an open issue about a special syntax for asynchronous and awaitable computations.
Some useful ppx rewriters that are similar to computation expressions:
ppx_let: Monadic let-bindings
ppx_lwt: LWT programming, async/await
ppx_deriving: Haskell like type deriving, like for Show, Eqand Ord
Related
There is RxJava-Computation-Expressions extension for RxJava. It provides operators like ifThen and others. However, the advantages of using it are not obvious. Because standard if-else block can be used or ternary operator, which are way readable and usual. I checked different functional languages and didn't find similar construction. All of them are using standard if-else operator.
Moreover, such extension is available not for all Rx languages and available only for RxJava 1.x.
The question is: what is the purpose of using ifThen operator from RxJava? Which advantages could it give comparing to standard if-else or ternary operator?
They allow taking a branch at subscription time and not when the sequence is assembled. It can mean that different subscribers will get different branches.
Further reading.
In C++, expression templates is a technique that relies on the compiler's knowledge about expressions in C++ code to simplify them and optimize them beyond what would be possible in a procedural program. It's a powerful technique used by e.g. the Eigen and Armadillo matrix libraries to speed up certain compound operations on matrices. An incomplete wiki page on the Eigen web page almost starts explaining it.
I wonder if a similar technique exists in Rust, i.e. is there a way to make the Rust compiler optimize certain expressions at compile time so that the least amount of temporaries is created.
If I read Expression Templates right, then you can see them in action with Rust Iterators: methods such as filter, take, etc etc return an expression template, a struct which represents the computation but doesn't perform it until requested. This gives the optimization you require right away, no temporaries are created.
Using the where clause I imagine one can write specializations to further optimize certain combinations of computations.
This might be a stupid question, but since OCaml is not pure and has side effects built-in, what is the use of monads in OCaml?
Monads have nothing to do with purity, except that a pure language without Monads would be almost entirely useless.
In layman's terms, a Monad is just a set of rules that describe how a sequence of steps can be executed. Having a Monad abstraction gives you the ability to define a DSL for executing stuff. A Monad can be built to intelligently handle things like exceptions, ATOMIC rollbacks/commits, retry logic, sleeping between each step, or whatever.
Here are some examples of Monads:
https://wiki.haskell.org/Monad#Interesting_monads
I realize that this list is for Haskell, which is a pure language, but don't let that confuse you.
You don't need to understand category theory to understand what a Monad is, contrary to popular belief. A monad basically has 2 things: (paraphrased from this wikipedia article)
A unit function, defined as (a -> M a), called "return" in Haskell, used to put a value into the context of a Monad.
A binding operation, defined as (M t -> (t -> M u) -> M u), which looks scary but if you look carefully, this is a function that gets invoked between each step of the process, this is where you inject the good stuff.
Depending on the language, there may be more things, but this is the heart of it.
Whilst OCaml supports the standard side-effects provided by most languages, this does not include all possible side-effects. There are a number of effects which OCaml does not provide native support for. Many of these effects can be encoded using Monads. For example,
Concurrency (see Lwt and Async libraries)
Non-deterministic choice
First-class continuations
Ambivalent choice and backtracking
Using more sophisticated representations of computation, such as parameterised monads, even more exotic effects can be encoded. For example,
Polymorphic state
Linear resources
While OCaml allows one to write imperative code it is still functional by its nature, it is used by functional programmers. And we prefer to use persistent data structures and algorithms whenever possible.
What concerning your question, then in particular monads are usefull, for asynchronous computations, e.g., Lwt, Async, where they're used to bind computations (instead of usual way of setting callbacks). Also, monads are used for error handling, instead of exceptions. Also, monads are very helpful in writing parsers, see mparser library. There're also other uses, I enumerated only the most popular.
In general monads just allow you to hide a complex control flow under simple sequential syntax.
This may be a lot more naive than the answer you want but a monad is just a simple abstraction that's useful for structuring computation. It's a little math thing like an equivalence relation (or for people smarter than I am, like a group). Once you learn what they are, you see them everywhere, and they help organize your thinking.
Supposing we have two grammars which define the same languge: regular one and LALR(1) one.
Both regular and LALR(1) algorithms are O(n) where n is input length.
Regexps are usually preferred for parsing regular languages. Why? Is there a formal proof (or maybe that's obvious) that they are faster?
You should prefer stackless automaton over pushdown one as there is much more developed maths for regular language automatons.
We are able to perform determinization for both types of automaton, but we are unable to perform efficient minimization of PDA. The well known fact is that for every PDA there exists equivalent one with the only state. This means that we should minimize it with respect to transitions count/max stack depth/some other criteria.
Also the problem of checking whether two different PDAs are equivalent with respect to the language they recognize is undecidable.
There is a big difference between parsing and recognizing. Although you could build a regular-language parser, it would be extremely limited, since most useful languages are not parseable with a useful unambiguous regular grammar. However, most (if not all) regular expression libraries recognize, possibly with the addition of a finite number of "captures".
In any event, parsing really isn't the performance bottleneck anymore. IMHO, it's much better to use tools which demonstrably parse the language they appear to parse.
On the other hand, if all you want to do is recognize a language -- and the language happens to be regular -- regular expressions are a lot easier and require much less infrastructure (parser generators, special-purpose DSLs, slightly more complicated Makefiles, etc.)
(As an example of a language feature which is not regular, I give you: parentheses.)
People prefer regular expressions because they're easier to write. If your language is a regular language, why bother creating a CFG grammer for it?
I've been looking at the new features in C++11 and it really looks like it will be possible to program in a very functional programming style using it. I've gotten use to using the types List, Seq, Array in F# and I see no reason why their members couldn't be ported into some sort of C++11 template. What problems or advantages do you see in using C++11 vs something like F# for a mixed functional programming style? Maybe the Boost guys will make a new functional once C++11 comes out.
The biggest problem with trying to program in a functional style in C++ is that it does not support tail recursion. In a functional language you don't have to worry about stack explosion when you tail recurse correctly, but in C++ you always have to worry about that. Therefore, many "functional" type algorithms will be clumsy or heavy.
Here are some of the problems I encountered trying to write functional code in C#, mixed with some goodies from my time when I was still using C++:
Lack of pattern matching. Once you get used to it, not having it can drive me crazy.
Lack of syntactic sugar for tuples.
Lack of syntax for copying records and setting fields in one go.
Lack of syntax for lists and arrays. That goes for constructors and pattern-matching.
Not having a GC, and unsafe memory accesses. Not being constrained by a GC is an advantage, but remembering the reports I got from my first runs of Valgrind on C++ code I thought was bug free scared me for ever.
Understanding template code isn't exactly accessible to all mortals. I don't have problem understanding mine, but whenever I looked into implementations of the STL, boost or cgal I found myself wondering what language they were using. My C++ and their C++ don't live in the same world.
The total lack of fun in dealing with a library that uses another version of boost (or any library that uses templates).
Verbosity of separate header/implementation files.
Type inference in C++ does not go as far as e.g. F#. I know it's been improved in C++11, but as I understand it's similar to var in C#, which isn't enough once you tasted F#-style inference.
Lack of computation expressions, including sequence expressions, comprehensions, async...
It would not surprise me if several of these points were actually possible in C++ using some template and preprocessor magic, but you can't really use these in a production environment unless you have very adventurous and tolerant co-workers.
I was a die-hard C++ enthusiast before. Then I started using generic programming with templates and higher-order functions using function objects. It just was too tiresome to write. After I tried a functional language I never looked back.
You might find this interesting:
http://smellegantcode.wordpress.com/2009/01/26/linq-to-c0x/
What problems of advantages do you see in using c++0x vs something like f# for a mixed functional programming style?
The upward funarg problem, which was debated in the context of Lisp 40 years ago!
I imagine that it would be… interesting… to implement certain optimizations common to functional languages in C++0x (like common subexpression elimination).