Tag Info

New answers tagged

0

This sounds a lot like replacing failure by a list of successes You're talking about Maybe a rather than [a], but in fact they're very similar: we can think of Maybe a as being like [a], except it can contain at most one element (ie. Nothing ~= [] and Just x ~= [x]). In the case of lists, your tryFunctions would be very simple: apply all of the functions ...


1

import Data.Monoid tryFunctions :: a -> [a -> Maybe b] -> Maybe b tryFunctions x = getFirst . mconcat . map (First . ($ x))


5

Given a closed set (fixed number of elements) S with elements {a..z} and a binary operator *: There is a single identity element i such that: forall x in S: i * x = x = x * i The operator is associative such that: forall a, b, c in S: a * (b * c) = (a * b) * c You have a monoid. Now given any monoid you can define a binary function f as: f(i, x) = x ...


1

bind() doesn't actually do currying. What it does is partial application. lodash and rambda have a method called _.partial() that does partial application without setting the context object. A function f is curried if calling f with one or more arguments is equivalent to calling f with one argument, then calling the return value with the next argument, and ...


2

I believe that your question can be rephrased as: why do languages have currying? It is mostly a question of convenience: In Ocaml, you could code let sum3 x y z = x + y + z;; let foo xx yy ll = List.map (sum3 xx yy) ll;; In Scheme you'll need to explicitly make an anonymous function (define (sum3 x y z) (+ x y z)) (define (foo xx yy ll) (map ...


4

Originally, currying was to simplify analysis, rather than a practical programming technique; in lambda calculus, all functions are unary. Currying is often used at the language level for a similar reason: simplifying the computational model. Partial application is used when a named, useful function can be implemented in terms of another, more general ...


1

At it's purest, functional programming is about defining a set of data types, devoid of behaviour, and then defining a set of "free" functions over those data types, which can be freely extended as need arises. This usually comes with some sort of namespace/module mechanism, so despite the fact that the functions are free, they're not global in the sense ...


26

When people say "X doesn't compose", what they mean by "compose" really just means "put together", and what and how you put them together can be very different, depending on what exactly "X" is. Also, when they say "doesn't compose", they can mean some slightly different things: You can't put two Xs together at all, period. You can put two Xs together, ...


17

Composability means that you can easily and reliably combine program components together to produce larger components and more complex functionality. Some things that help make components more composable: Idempotence. An idempotent function will always produce the same output or side effects, if called multiple times with the same parameter values. This ...


0

In this case you can pretend that it is, but be careful. List comprehentions create or mutate variables in the surrounding scope. (in ipython console): In [1]: x NameError: name 'x' is not defined In [2]: [x for x in range(10)] Out[2]: [0, 1, 2, 3, 4, 5, 6, 7, 8, 9] In [3]: x Out[3]: 9 So if you had something like x = "foo" [x for x ...] x will not ...


2

Yes it is, because there is no state being mutated. The line branch_counts = [count_leaves(b) for b in tree] can be interpreted as a simple binding (like a let statement in Haskell or Lisp), as there are no further reassignments or mutations. Additionally, you could reformat it like this to make it clearer: def count_leaves(tree): return 1 if ...


-3

my knowledge about functional programming is very limited In functional programing, calling a function only affect the instance calling it so you let the allow the function to be call from everywhere can't cause bug except in the module calling the function (which is the one having a buggy behaviour).


0

In your example I see no benefit, but other languages (like Ceylon) use union types in useful ways. Imagine doing something like this (C#) int Length<A> (String | List<A> obj) {...} While this example isn't very meaningful since String implements IEnumerable, the idea behind this is that you can receive a parameter which can be one various ...


0

There has been a lot of movement on Clojure on Android (https://github.com/clojure-android/neko)Neko. There are performance issues related to the Dalvik VM and the Clojure Compiler; these issues are slowly being resolved. A presentation about the current (July 2015) status: ...


-1

Data-Oriented Entity Component Systems can coexist with Object-Oriented Paradigms - firstly, Systems themselves tend to be object-based: we're likely to create custom systems based on existing built-in ones, and there is VERY likely to be a base System class, or interface, depending on your preference. And secondly, Components can be both POD (plain old ...


0

My understanding is that a lazy evaluated language actually holds everything in a wrapper like this: class LogicalValue { ActualValue *value; ActualValue operator()() { if (value == null) { value = computeValue(); } return value; } } This is like your caching example, except that it doesn't attempt to reuse ...


1

After thinking about it overnight and looking at Nebu's answer, here are the solutions I came up with: Return only the URI, and accept one a/sync Func. While I do think it's reasonable for an API to return the URI to a video (in case the user doesn't want to download it just yet), I think it's a bit technical to ask him/her to download the source of the ...


1

Why not make FromYouTubeAsync be a pure function (e.g. which takes a String representing the HTML of the youtube video page, and which returns the URL of the mp4 video file it finds within), and then have the caller worry about how exactly to download bytes over the internet, if you think they want to have as much control over the process as you're implying? ...


2

Your first argument regarding reuse of the HttpClient makes perfect sense. As for the rest of of the requests, I think you're trying to optimize prematurely. That can lead to unnecessary complexity. Also, I'd like to warn you of using the static classes. This is usually a bad idea. It makes your code harder to test and extend. Anyways, below is a design that ...



Top 50 recent answers are included