Tag Info

Hot answers tagged

48

which seems to be the more mathematical way functional languages are inspired by lambda calculus. In this field, parentheses are not used for function application. I also think that the latter style is much more clear and readable than without the parens. Readability is in the eye of the beholder. You are not used to reading it. It is a bit like ...


18

The basic idea is to make the most important operation (function application) easiest to read and easiest to write. A space is very unintrusive to read and very easy to type. Note that this is not specific to functional languages, e.g. in Smalltalk, one of the first OO languages and languages inspired by it (Self, Newspeak, Objective-C), but also in Io and ...


14

Parenthesis for function application is just one of the many saddles Euler left us with. Like anything else mathematics needs conventions when there are several ways to do something. If your mathematical education only extends as far as a non-maths subject at university then you probably aren't too familiar with the many fields where function application ...


5

It's hard to tell exactly what you're asking, so this answer is aimed at providing more context about monads. Some preliminaries about monads: Crockford's monad talk is a poor source for learning about monads (I hate to say this because he's so much smarter than me, and therefore probably understand monads better than I do, but IMHO it gives an inaccurate ...


5

Although there's a lot of truth in Simon's answer, I think there's also a much more practical reason. The nature of functional programming tends to generate a lot more parentheses than imperative programming, due to function chaining and composition. Those patterns of chaining and composition also usually happen to be able to be unambiguously represented ...


5

No, there isn't any objective rule. If there were objective rules, someone could automate them and you'd be out of a job. Such decisions are always trade-offs between pressures that are pretty obvious in themselves, but have different relative strengths in different situations. So far, only (some) humans can properly judge such multidimensional optimization ...


3

Both premises are wrong. These functional languages don't use space for function application. What they do is simply parse any expression that comes after a function as an argument. GHCi> f 3 4 GHCi> f(3) 4 GHCi> (f)3 4 course if you use neither a space nor parens then it normally won't work, simply because the expression isn't properly ...


2

The simple answer is that the machinery for rows already existed in the typechecker, from the very first release of the PureScript compiler, so it made sense to reuse it to define the Eff monad. The only change was to allow rows to be parameterized by the kind of the types indexed by their labels. It certainly seems like labels are unnecessary, and they ...


2

I have never used PureScript, but the short answer is yes, effect labels are useful for modeling effects in a principled way. I'm not sure what your background is, so I don't know at what level to answer the question. Are you familiar with side effects, the downsides of their unrestricted use, functional programming, and why we try to avoid side effects in ...


1

Yesod is for Haskell and provides direct compilation to machine code with all the strong, static typing you'd expect from Haskell. It does not compile to JS though there are certainly Haskell to JS compilers at varying stages of completion and competency. Ocsigen is a family of tools for OCaml which is not Haskell but in the ML family to which Haskell is ...


1

In most programming languages and frameworks, overly-segregated interfaces make it difficult to aggregate, compose, or wrap objects which share various combinations of abilities. If many types implement an interface which defines many methods, but also includes a means of asking how well particular instances can promise to implement them, then a single ...


1

There is someone who has developed this principle to the extreme, and further: the german software Engineer Ralf Westphal made a complete programming model from it and called it "Event Based Components", together with a design method, called Flow Design. Actually, he does not use the "interface form", only Func or Action contracts, and he has got a lot of ...


1

Prefer pure functions and immutable variables/objects. Apart from that, keep in mind the limits and the conventions of the language you are using. Don't forget: Readability. Your colleagues will find your non-idiomatic code harder to understand Lack of tail call optimization Lack of laziness Lack of useful optimizations (ex. stream fusion) Lack of ...



Only top voted, non community-wiki answers of a minimum length are eligible