16 ms·
What is so ugly about it? Swift tries to be somewhat close to the usual C-syntax (it's supposed to be the successor of Obj-C, after all). For someone used to C
by CookWithMe 11y ago
What is so ugly about it? Swift tries to be somewhat close to the usual C-syntax (it's supposed to be the successor of Obj-C, after all).
For someone used to C-syntax, I guess the main deviation is that the return type is in the back and that there's a func keyword. As for the operaters, there is the addition of generics (what is wrong about <> ?), -> to describe signature of a function (a very sensible choice IMO) and ? for Optionals (again, fine for me).
I don't really see how a statically typed language can substantially improve this, but I'd be happy if someone can proof me wrong :-)
- kittenfluff 11y agoIt's not clear to me why it's necessary to include <T, U> at the start of the function definition. In Haskell, unquantified type variables are implicitly universally quantified, i.e. you assume that the signature must be valid for any types T and U. That's the only thing I think could be substantially improved, though. Personally I find the style where you separate the type signature from the function definition easier to read, for example How about <^> : (T -> U) * T? -> U? <^> (f, a) { return a.map(f) } or even <^> : (T -> U) * T? -> U? <^> (f, a) -> a.map(f) which is already pretty close to the Haskell equivalent (<^>) :: (t -> u) -> Maybe t -> Maybe u (<^>) = fmap Arguably, Haskell syntax could be improved with more built-in syntax <^> : (t -> u) -> t? -> u? <^> = fmap though I haven't thought about what this means for parsing the language.
- lmm 11y agoExplicit is better than implicit. Does Haskell allow functions to have value parameters that aren't declared?
- TheCoelacanth 11y agoDepends what you mean by "not declared". Haskell doesn't require you to provide type signatures, so if you don't put a type signature on a function, you can have parameters that aren't explicitly declared (though they still have an inferred static type, so you could use ghci to see what all the parameters are). If you do put any type signature on the function, then all parameters would have to be included.
- lmm 11y agoIf I make a typo when using a value parameter in a function definition, can I accidentally introduce an extra value parameter? If I make a typo when using a type parameter in a function definition, can I accidentally introduce an extra type parameter?
- TheCoelacanth 11y ago> If I make a typo when using a value parameter in a function definition, can I accidentally introduce an extra value parameter? No. > If I make a typo when using a type parameter in a function definition, can I accidentally introduce an extra type parameter? You couldn't introduce a new concrete type. You could introduce a new type variable, but the type signature would still have to typecheck, so it would difficult to come up with a non-contrived example where that would happen.
- octocoupler 11y agoHow do your examples specify that T and U are generics?
- kittenfluff 11y agoAs I said, in Haskell "unquantified type variables are implicitly universally quantified" i.e. type variables (which are always lowercase in Haskell, to distinguish them from concrete types which are uppercase) are always generic. So it's true that in the Swift examples, you would need a convention to distinguish type variables from concrete types, or else you need to explicitly mark them as generic.
- deleted 11y ago[deleted]
- efnx 11y agoThank you! This actually explained what is going on perfectly.