3 ms·

So??? This is how things work in Clojure. And that's just fine. I guess I just don't understand where you are coming from. It's been pointed out to you that Cl

So??? This is how things work in Clojure. And that's just fine. I guess I just don't understand where you are coming from. It's been pointed out to you that Clojure hackers don't mind importing the generic functions. You replied that then your worry is that it would be hard to preserve type information in a statically typed language that works like Clojure. I mentioned that Cecil is statically typed and preserves type information, with a multi-method system that is somewhat similar to Clojure's. At least as I understand it. If your entire worry is that you have to import every generic function you want to use, then I guess you and I just don't worry about the same things at all. To me, importing the functions that you use is a feature, not a bug! In fact, when I program in Python, I generally program a lot more with functions than with classes, and yes, in every module I explicitly import every single externally defined function that that module needs. Again, I consider this a feature, not a bug. What I would object to is having to explicitly import all the method definitions that implement the generic functions used in a multi-method system. That would be insanity, but that's a moot point, as that is never required, as far as I am aware. Also, common generic functions, however, such as map(), could clearly be automatically imported by the language. E.g., in Predef in Scala, or in built-ins in Python. In fact, in Python, map() is in built-ins, and you don't have to import it. Though, in Python's case, map() doesn't preserve the original container type

eli_gottlieb 15y ago
I'm not talking about importing the generic functions themselves at all. I'm talking about importing the modules that export those generic functions, so that I'll have the modules in my namespace to be able to name the generic functions. Again: dot-notation lets me write: import scala.collection.immutable.List def addn(n: Int) = (list: List[Int]) => list.map(_ + n) Instead of: import scala.collection.immutable.List def addn(n: Int) = (list: List[Int]) => List.map(list,_ + n) See the difference? And then, remember that map() is not a multimethod. It doesn't actually do dynamic dispatch on its first argument, or on any other argument. It's a type-class method; it does static dispatch on the functor type List[]. You cannot define map() as a generic function, at least not in the sense that Common Lisp and Clojure use the term "generic function". It can be conveniently expressed as a type-class method of a class 'Functor f :: * -> * ' or a trait method for a Functor[A]. Not a generic function.
- nessus42 15y ago
  > I'm not talking about importing the generic functions themselves at all. > I'm talking about importing the modules that export those generic functions, > so that I'll have the modules in my namespace to be able to name > the generic functions. I don't see how this is either here or there. I can import modules and then qualify functions within the modules, or I can import functions directly from the modules, renaming then if I want to. There's no difference, between these options, other than a minor difference in what name I use to refer to the function once its been imported. > Again: dot-notation lets me write: > import scala.collection.immutable.List > def addn(n: Int) = (list: List[Int]) => list.map(_ + n) > Instead of: > import scala.collection.immutable.List > def addn(n: Int) = (list: List[Int]) => List.map(list,_ + n) It isn't dot notation that lets you do that; it's the semantics of how functions are located that lets you do that. Many languages support statically overloaded functions using functional notation. It's also quite easy to imagine a language which uses the syntax f(a) to mean what a.f() means in Scala. Also, why is this to be considered so desirable? For the performance gain that comes from eliminating dynamic dispatch? In that case, it is certainly possible for a language that supports multiple dispatch to dispatch statically when it can infer that it is safe to do. > See the difference? Yes, I quite understand the concept, but it has nothing intrinsically to do with dot notation. > And then, remember that map() is not a multimethod. > It doesn't actually do dynamic dispatch on its first argument, > or on any other argument. It's a type-class method; it does static dispatch > on the functor type List[]. In Scala? I don't believe that this is correct. As far as I understand, there's a single implementation of map for the entire collection library in TraversableLike, which uses virtual functions provided by the concrete class (and a builder object which gets passed in implicitly) to construct the new container, loop over the old container, and add elements to the new container. This is similar to how map() works in Python and Clojure, where there is a single implementation of map() which uses dynamic dispatch to loop over the elements of the container. The downside to the way that Python and Clojure doing things is that you get iterators or streams back, not the original container type. But they could return the original container type if containers in Python and Clojure were to have virtual constructors. Then map() could call these virtual constructors to return a container of the same type. > You cannot define map() as a generic function, at least not in the sense that > Common Lisp and Clojure use the term "generic function". Clearly in a statically typed language, you also need some form of parametric polymorphism in addition to what Common Lisp and Clojure provide in order to preserve types. I see no reason why this should be insurmountable. I've often done things in C++ that wrapped dynamic lookup in a generic function or class, to achieve the types of things that you say require type classes. Another thing you can easily do in C++ is to write template adapter classes to provide something similar to Scala's structural types. Also, type classes surely don't require dot notation. Haskell is from where type classes originate, and Haskell doesn't have dot notation.

eli_gottlieb 15y ago

I'm not talking about importing the generic functions themselves at all. I'm talking about importing the modules that export those generic functions, so that I'll have the modules in my namespace to be able to name the generic functions. Again: dot-notation lets me write: import scala.collection.immutable.List def addn(n: Int) = (list: List[Int]) => list.map(_ + n) Instead of: import scala.collection.immutable.List def addn(n: Int) = (list: List[Int]) => List.map(list,_ + n) See the difference? And then, remember that map() is not a multimethod. It doesn't actually do dynamic dispatch on its first argument, or on any other argument. It's a type-class method; it does static dispatch on the functor type List[]. You cannot define map() as a generic function, at least not in the sense that Common Lisp and Clojure use the term "generic function". It can be conveniently expressed as a type-class method of a class 'Functor f :: * -> * ' or a trait method for a Functor[A]. Not a generic function.

nessus42 15y ago
> I'm not talking about importing the generic functions themselves at all. > I'm talking about importing the modules that export those generic functions, > so that I'll have the modules in my namespace to be able to name > the generic functions. I don't see how this is either here or there. I can import modules and then qualify functions within the modules, or I can import functions directly from the modules, renaming then if I want to. There's no difference, between these options, other than a minor difference in what name I use to refer to the function once its been imported. > Again: dot-notation lets me write: > import scala.collection.immutable.List > def addn(n: Int) = (list: List[Int]) => list.map(_ + n) > Instead of: > import scala.collection.immutable.List > def addn(n: Int) = (list: List[Int]) => List.map(list,_ + n) It isn't dot notation that lets you do that; it's the semantics of how functions are located that lets you do that. Many languages support statically overloaded functions using functional notation. It's also quite easy to imagine a language which uses the syntax f(a) to mean what a.f() means in Scala. Also, why is this to be considered so desirable? For the performance gain that comes from eliminating dynamic dispatch? In that case, it is certainly possible for a language that supports multiple dispatch to dispatch statically when it can infer that it is safe to do. > See the difference? Yes, I quite understand the concept, but it has nothing intrinsically to do with dot notation. > And then, remember that map() is not a multimethod. > It doesn't actually do dynamic dispatch on its first argument, > or on any other argument. It's a type-class method; it does static dispatch > on the functor type List[]. In Scala? I don't believe that this is correct. As far as I understand, there's a single implementation of map for the entire collection library in TraversableLike, which uses virtual functions provided by the concrete class (and a builder object which gets passed in implicitly) to construct the new container, loop over the old container, and add elements to the new container. This is similar to how map() works in Python and Clojure, where there is a single implementation of map() which uses dynamic dispatch to loop over the elements of the container. The downside to the way that Python and Clojure doing things is that you get iterators or streams back, not the original container type. But they could return the original container type if containers in Python and Clojure were to have virtual constructors. Then map() could call these virtual constructors to return a container of the same type. > You cannot define map() as a generic function, at least not in the sense that > Common Lisp and Clojure use the term "generic function". Clearly in a statically typed language, you also need some form of parametric polymorphism in addition to what Common Lisp and Clojure provide in order to preserve types. I see no reason why this should be insurmountable. I've often done things in C++ that wrapped dynamic lookup in a generic function or class, to achieve the types of things that you say require type classes. Another thing you can easily do in C++ is to write template adapter classes to provide something similar to Scala's structural types. Also, type classes surely don't require dot notation. Haskell is from where type classes originate, and Haskell doesn't have dot notation.