5 ms·
This is pretty cool, in my day-to-day language, Scala, we cannot do the following: [('a',1);('b',2);('c',3)] |> List.map String In F# 4.0 the compiler inf
by virtualwhys 12y ago
This is pretty cool, in my day-to-day language, Scala, we cannot do the following:
[('a',1);('b',2);('c',3)] |> List.map String
In F# 4.0 the compiler infers that String takes 2 arguments and extracts the tuple accordingly.
In Scala we're forced to manually extract the tuple when the recipient function takes more than a single argument.
def plus(a: Int, b: Int) = a + b
List((1,2),(3,4)) map plus // kaboom
List((1,2),(3,4)).map{case(a,b)=> plus(a,b)} // ok
We'll see where the Microsoft OSS movement goes. If in the not too distant future we can seamlessly take advantage of, for example, Type Providers and LINQ-to-SQL/Objects on Linux, I'll certainly give F# a deeper look.
Side note: the next 3 to 4 years will be huge in computing, IMO. Microsoft stack is coming to Linux and OSX, Oracle is finally pushing forward Java and the JVM, and FP languages in general seem to be picking up steam in terms of adoption. Good times ahead for everyone ;-)
- pjmlp 12y ago> FP languages in general seem to be picking up steam in terms of adoption I have been looking forward to this since I learned Caml Light at the university back in 1996. Same applies to LP. It was been a long way.
- masklinn 12y ago> In Scala we're forced to manually extract the tuple when the recipient function takes more than a single argument. Is there no `uncurry :: (a -> b -> c) -> (a, b) -> c` in Scala? Prelude> let ap = flip map Prelude> [(1, 2), (3, 4)] `ap` (+) <interactive>:11:3: No instance for (Num t0) arising from the literal `1' The type variable `t0' is ambiguous Possible fix: add a type signature that fixes these type variable(s) Note: there are several potential instances: instance Num Double -- Defined in `GHC.Float' instance Num Float -- Defined in `GHC.Float' instance Integral a => Num (GHC.Real.Ratio a) -- Defined in `GHC.Real' ...plus three others In the expression: 1 In the expression: (1, 2) In the first argument of `ap', namely `[(1, 2), (3, 4)]' Prelude> [(1, 2), (3, 4)] `ap` (uncurry (+)) [3,7] Or some sort of `apply` method aliasing an n-ary function to a 1-ary function taking an n-tuple? edit: there's a Function.tupled method so something like this might work: List((1,2),(3,4)) map plus.tupled
- ssmoot 12y agore: Your edit: Basically. Lift the method to a function first. def plus(a: Int, b: Int): Int = a + b List( (1,2), (3,4) ) map(plus _ tupled) > List(3, 7) ( I know there's already 4 or 5 answers... I just think mine's the prettiest. ;-) )
- ArturSoler 12y agoIt's not as concise, but you could do List((1,2),(3,4)) map (plus _).tupled
- virtualwhys 12y agoNicely done ;-) However, not so easy to grok without knowing how to lift methods to functions in Scala and then applying the swiss army method of functionN types, `tupled`, to the result. The F# equivalent one understands without needing to know special features of the language, it's pretty clear what's happening.
- frowaway001 12y ago> The F# equivalent one understands without needing to know special features of the language, it's pretty clear what's happening. The requirement to explicitly say that you want to pass a method around, not the value of the evaluated method was an explicit design decision in Scala, because very often it was not clear for developers what was happening (or more precise: they thought they knew, but something different happened).
- Rizz 12y agoAnd a another way to use tupled is: list map Function.tupled(plus) Hereby additionally proving the old saying 'if you need help with a product don't say you need help because you'll get hit with RTFM, just say too bad you can't do X in product while it's easy to do in [competing product], and everyone will try to prove you wrong.'
- virtualwhys 12y ago> and everyone will try to prove you wrong heh, how true, though more of an invitation; a strength/weakness of Scala is the fact that there's often more than one way to do the same thing (at least 3 ways have been shown with the current example). From what I've seen F# does not have this characteristic. Anyway, ideally the Scala compiler would provide the same level of concision that for comprehensions do vis-a-vis flatMap/map boilerplate, thus reducing our example down to: `list map plus`, the bare essentials ;-) Worth noting that the source for Function[0] indicates `Function.tupled` methods are slated for removal in future: "these functions are slotted for deprecation, but it is on hold pending superior type inference for tupling anonymous functions" https://github.com/scala/scala/blob/v2.11.4/src/library/scala/Function.scala#L72 https://github.com/scala/scala/blob/v2.11.4/src/library/scal...