Hacker News Board Hacker News, browsed like a classic message board
Live data from Hacker News

Smashing Swift

nomothetis.svbtle.com

Post reply on HN
Print view View original

31–40 of 150 posts

Re: Smashing Swift

#31

Post by bjeanes »

jkrems wrote: post #27
archgrove wrote: post #18

Earlier quoted context omitted.

Very interesting, thanks. I also ran up against another annoying bug/oversight/v0.1ism : You can't inherit from a generic class without becoming generic yourself. So, even if you fully instantiate your parent's type information, you have to be generic as well! For example: class Foo { ... } class Bar : Foo { ... } You'd expect Bar to be a non-generic type, but this throws a compiler error. You have to declare: class…

Well, derived classes are meant to be drop-in replacement for the base class. In that sense it totally makes sense that you can't have a non-generic child class of a generic base class. Otherwise it encourages design where classes are treated as method dumps.

Exactly what I was going to say. This seems like a good design decision, especially because the typealias hack offers a work around if you really need to.

Re: Smashing Swift

#32

Post by drivingmenuts »

archgrove wrote: post #9

Compiler bugs really don't worry me - despite the name, this is is really an alpha release. However, I ran up against the lack of generic protocols myself today (for those with access, there's an interesting debate at https://devforums.apple.com/thread/230611?tstart=0 ). It seems like a deliberate design choice, but one I'm not really sure about. The primary vibe I'm getting from Swift is pragmatism . They had variou…

This makes sense - Apple's philosophy is "Everything Apple" and so they have a vested interest in designing a language that gets things moving on their platform, rather than being the best language it can be right now.

If, and this is a big if, Apple is actually interested in Swift in the long term, then they will open up the language to community development so that these sorts of things can be added by the community.

My suspicion is, though, that Swift will be improved by Apple alone and that it will be pragmatically discarded when the time is appropriate. Which doesn't mean it won't have a long life, just an undignified exit.

Re: Smashing Swift

#33

Post by eridius »

FWIW. map() already exists. It's a global function, rather than being a protocol method, and it uses overloading. So you can still define functions merely by defining a new overload for map() that operates on your type.

Re: Smashing Swift

#35

Post by acomar »

dscrd wrote: post #26
wting wrote: post #17

Earlier quoted context omitted.

A functor is a thing that can be mapped over. For example: map abs [-1, 2, 3] => [1, 2, 3] Arrays are the simplest example, but it looks like an iterable. However functors retain shape whereas iterables don't. For example if we had a tree (represented visually): oak = -1 / \ 2 3 If we used oak as an iterable, we would lose the structure of the tree: map abs iter(oak) => [1, 2, 3] However if tree belongs to the functo…

>However functors retain shape whereas iterables don't. Wow. Such a simple sentence yet this is the first time I have read it, and it makes the concept much more clear than hundreds of articles before did. Thank you! I wish all FP features would be explained so simply.

You can build a bit of mathematical intuition for the concept now that you get the basic idea. Try and work out from the functor laws why functors preserve shape. The laws are very straightforward:

    map id c = id c
(Mapping the identity function is the same as simply applying the identity function -- or with a little more category theory, the functor maps the identity function in the base category to the identity function in the functor's category)

    map f (map g c) = map (f . g) c
The second law is also simple -- mapping one function over the container then mapping another function is exactly the same as mapping the composition of the functions over the container. This one is the basis of stream fusion, a very important optimization, that allows you take two traversals of a container and turn them automatically into just one traversal.

The preservation of structure follows from just these two laws and parametricity (The element type of the containers is generic and therefore unknown, this greatly restricts what operations are available on the elements of the container. You can't, for example, conjure up a new value of the element type to insert.). I strongly recommend trying to figure out how.

Re: Smashing Swift

#36

Post by pohl »

After reading this, I tried to find out which versions of Haskell and Scala introduced higher kinded types. I'm sure it wasn't among the first features. Does anybody know the history of either?

AFAIK you can't do Functor in Rust yet either, and for the same reason.

Re: Smashing Swift

#37

Post by danabramov »

dirtyaura wrote: post #6

I've had very similar experience: I try to port non-trivial, but still rather simple functional code, for example containing a couple of nested closures, and the compiler crashes. And it seems that the Xcode playground, the command line compiler and REPL all behave a bit differently. In one case playground works, but REPL crashes, in another, compiler works, REPL has trouble of figuring out types. I have absolutely n…

Microsoft's work on C# compiler (Roslyn) is amazing: they offer compiler-as-a-library so the IDE, plugins and debugger use the same backend as the compiler itself. I wish at some point Apple could adopt a similar approach.

Re: Smashing Swift

#38

Post by jmah »

I successfully got the Functor example to work like this:

    protocol Functor {
        typealias T
        typealias FunctorResult
        func map
(mappingFunction: T -> P) -> FunctorResult
    }
    
    extension Dictionary : Functor {
        func map
(mappingFunction: ValueType -> P) -> Dictionary {
            var newDict:Dictionary = [:]
            for (key, value) in self {
                newDict[key] = mappingFunction(value)
            }
            return newDict
        }
    }

Re: Smashing Swift

#39

Post by pohl »

danabramov wrote: post #37
dirtyaura wrote: post #6

I've had very similar experience: I try to port non-trivial, but still rather simple functional code, for example containing a couple of nested closures, and the compiler crashes. And it seems that the Xcode playground, the command line compiler and REPL all behave a bit differently. In one case playground works, but REPL crashes, in another, compiler works, REPL has trouble of figuring out types. I have absolutely n…

Microsoft's work on C# compiler (Roslyn) is amazing: they offer compiler-as-a-library so the IDE, plugins and debugger use the same backend as the compiler itself. I wish at some point Apple could adopt a similar approach.

That's basically what drove the design of clang. No doubt the approach with swift will be similar.

Re: Smashing Swift

#40

Post by pohl »

noobermin wrote: post #2

Just to point out, the last two sound like it's due to the current implementation (compiler) being new, so it isn't so upsetting at all. Now, not supporting functors is odd, though.

Why is it odd? Is there a historical precedent for some other language exposing higher kinded types this early in the lifecycle? (Prior to 1.0, that is?)

Ωmega, maybe? Is that what we're expecting of the new "normal" already?

Post reply on HN