3 ms·

> The proper CS name is "parametric polymorphism". No, it isn't. You would know this if you actually bothered to understand the terms you used rather than ban

> The proper CS name is "parametric polymorphism". No, it isn't. You would know this if you actually bothered to understand the terms you used rather than bandying them about in an attempt to win Internet points. Generic programming is a far broader topic than parametric polymorphism: that's why languages which already have parametric polymorphism, like Haskell, have variants which support true generic programming, like Generic Haskell and Scrap Your Boilerplate. > (What is special, is the abysmal C++ implementation of parametric polymorphism.) Given that you obviously don't understand the difference between run-of-the-mill parametric polymorphism and the generic programming enabled by C++ templates (and no other typed implementation except perhaps GADTs, and I remain unconvinced even of that) Id say you're fairly unqualified to be assessing the quality of C++'s implementation of parametric polymorphism. > The transformation required to go from a higher order program to a first order one is called "lambda lifting". This goes way beyond syntactic sugar. Wow, you really seem to enjoy using terms you clearly don't understand. No, lambda lifting doesn't "go way beyond syntactic sugar." It's actually a fairly simple syntactical transformation: the free variables in the function body are converted to arguments to a static function, and closures, when generated, are a simple data structure consisting of a pointer to this static function and the arguments to "fill in" when called. > So, a language which lack lambdas don't fully implement functions… It's hard to believe that you'd even say that, let alone get modded up for doing so. I find it hard to argue against, much like I would have difficulty arguing against someone who said that a country which lacked cars couldn't fully implement wheels. You see, what lambda lifting does is convert closures (which seem synonymous, at least in your writing, with lambdas) into ordinary functions with no free variables. Functions without free variables are more basic than functions with free variables.

loup-vaillant 16y ago
When people talk about "genericness", or "generic programming" in front of me, the first example they give to me is the parametric polymorphism of the STL. It seems I underestimated you (again). But even if you know what you write, many people don't know what they read. Hence my up-mod. The fact that template are Turing complete doesn't hide the restrictions they come with (like how they interact with inheritance). I know they have others goals than mere parametric polymorphism. I even admit that I don't understand these goals. I just say that one goal wasn't met: simple parametric polymorphism. About lambda lifting being a (simple) syntactical transformation, please stop. You're right, but in a trivial sense: every compilation process is a (less simple) syntactical transformation. That includes lambda lifting, ghc's crazy optimizer, and every static compiler on this planet. Now, by "syntactic sugar", I meant something that could be dealt with with local macros. You know, I have done the transformation you speak of manually in C++. More than once. I know this is fairly simple. But it is not local. I still have to write something outside the definition of the function I am writing the closure in. So, to do lambda lifting, I need a more global preprocessor. The locality of the transformation may not be important to you, but to me, it is crucial. I don't mind some noise (semicolons, curly brackets, keywords…), because when used to it, I can see the actual code beneath it. However, the code has to be there. If I have to look up elsewhere, it quickly blows up my short term memory. Also, as long as the transformation is strictly local, you could deal with it with simple macros, like this: -- I assuume "closure" is a Lisp-like macro let x = let y = ... in closure arg1 arg2 (... body ...) So, a language without lambdas doesn't treat functions as first class citizens. That's what I meant by "doesn't fully implement functions". This is a strong wording, but I don't think it is inaccurate. Put the same restrictions on integers, and see if you can still say that they are "fully implemented". Did I overlooked something?
- jemfinch 16y ago
  > When people talk about "genericness", or "generic programming" in front of me, the first example they give to me is the parametric polymorphism of the STL. The STL embodies (and accomplishes) far more than parametric polymorphism. As far as I know there is no other language with as comprehensive a collection of container-independent algorithms in the standard library. > The fact that template are Turing complete doesn't hide the restrictions they come with (like how they interact with inheritance). I know they have others goals than mere parametric polymorphism. I even admit that I don't understand these goals. I just say that one goal wasn't met: simple parametric polymorphism. And you're still wrong. Templates achieve parametric polymorphism and more. I can write a simple, templated, singly-linked list class in C++ which can do everything the same `'a list` in ML can do. > About lambda lifting being a (simple) syntactical transformation, please stop. You're right, but in a trivial sense: every compilation process is a (less simple) syntactical transformation. That includes lambda lifting, ghc's crazy optimizer, and every static compiler on this planet. I was making a greater claim that you seem to understand. Lambda lifting is a simple syntactical transformation. I can explain the entire transformation in a paragraph or less. I can offer example code of the transformation off the top of my head with ease. All lambda lifting does is make explicit what closures allow to remain implicit. Your following two paragraphs are a fairly obvious attempt to change your original, wrong statement into something defensible. > So, a language without lambdas doesn't treat functions as first class citizens. Ridiculous. A language without lambdas is just that: a language without lambdas. Remove lambda from Python, and you remove only the ability of a Python programmer to define unnamed functions. Functions remain first class; their binding rules remain exactly the same. The only difference is that now programmers must give a name to all their functions.
  - loup-vaillant 16y ago
    > As far as I know there is no other language with as comprehensive a collection of container-independent algorithms in the standard library Whoops. I forgot that, sorry. People may have meant true generic programming, after all. Now, actually using STL's <algorithm> and still end up with readable code isn't easy to me. For instance, each time `for_each` or `accumulate` would be appropriate, I end up writing a `for` loop instead, because the end result is more concise and more local. So in the end, container independent algorithms rarely matter to me. > I can write a simple, templated, singly-linked list class in C++ which can do everything the same `'a list` in ML can do. I think we don't use "simple" in the same way. Here, such an implementation of lists takes only 12 tokens and 2 lines in ML. How many do you need to do the same in C++? My first guess is more five times that, probably ten. Still simple, but much more complicated nonetheless. Though in that particular case, I'd rather blame the absence of inductive types. Templates really are simple here. The real problem shows when you combine them with inheritance: you have to jump through some hoops (like having to re-declare virtual methods in the derived classes). > Your following two paragraphs are a fairly obvious attempt to change your original, wrong statement into something defensible. It was an attempt to clarify my meaning. Yes, my statement was wrong. Lambda lifting doesn't go way beyond syntactic sugar. But, to me, it still crosses the line. To you, it doesn't. I think that's only because your definition of "syntactic sugar" is more liberal than mine. But even then, we're not done. Before you do the actual lambda lifting, you have to parse the source code. Trivial in Lisp, but quite a feat in C++. > […] The only difference is that now programmers must give a name to all their functions. To me, such a restriction is sufficient to make function second-class citizen. If you can have anonymous integers, and you can't have anonymous functions at the same time, then functions are not first class. Again, we disagree on a mere definition. Beyond that, I agree that the other "first-classiness" properties of functions are far more important.

loup-vaillant 16y ago

When people talk about "genericness", or "generic programming" in front of me, the first example they give to me is the parametric polymorphism of the STL. It seems I underestimated you (again). But even if you know what you write, many people don't know what they read. Hence my up-mod. The fact that template are Turing complete doesn't hide the restrictions they come with (like how they interact with inheritance). I know they have others goals than mere parametric polymorphism. I even admit that I don't understand these goals. I just say that one goal wasn't met: simple parametric polymorphism. About lambda lifting being a (simple) syntactical transformation, please stop. You're right, but in a trivial sense: every compilation process is a (less simple) syntactical transformation. That includes lambda lifting, ghc's crazy optimizer, and every static compiler on this planet. Now, by "syntactic sugar", I meant something that could be dealt with with local macros. You know, I have done the transformation you speak of manually in C++. More than once. I know this is fairly simple. But it is not local. I still have to write something outside the definition of the function I am writing the closure in. So, to do lambda lifting, I need a more global preprocessor. The locality of the transformation may not be important to you, but to me, it is crucial. I don't mind some noise (semicolons, curly brackets, keywords…), because when used to it, I can see the actual code beneath it. However, the code has to be there. If I have to look up elsewhere, it quickly blows up my short term memory. Also, as long as the transformation is strictly local, you could deal with it with simple macros, like this: -- I assuume "closure" is a Lisp-like macro let x = let y = ... in closure arg1 arg2 (... body ...) So, a language without lambdas doesn't treat functions as first class citizens. That's what I meant by "doesn't fully implement functions". This is a strong wording, but I don't think it is inaccurate. Put the same restrictions on integers, and see if you can still say that they are "fully implemented". Did I overlooked something?

jemfinch 16y ago
> When people talk about "genericness", or "generic programming" in front of me, the first example they give to me is the parametric polymorphism of the STL. The STL embodies (and accomplishes) far more than parametric polymorphism. As far as I know there is no other language with as comprehensive a collection of container-independent algorithms in the standard library. > The fact that template are Turing complete doesn't hide the restrictions they come with (like how they interact with inheritance). I know they have others goals than mere parametric polymorphism. I even admit that I don't understand these goals. I just say that one goal wasn't met: simple parametric polymorphism. And you're still wrong. Templates achieve parametric polymorphism and more. I can write a simple, templated, singly-linked list class in C++ which can do everything the same `'a list` in ML can do. > About lambda lifting being a (simple) syntactical transformation, please stop. You're right, but in a trivial sense: every compilation process is a (less simple) syntactical transformation. That includes lambda lifting, ghc's crazy optimizer, and every static compiler on this planet. I was making a greater claim that you seem to understand. Lambda lifting is a simple syntactical transformation. I can explain the entire transformation in a paragraph or less. I can offer example code of the transformation off the top of my head with ease. All lambda lifting does is make explicit what closures allow to remain implicit. Your following two paragraphs are a fairly obvious attempt to change your original, wrong statement into something defensible. > So, a language without lambdas doesn't treat functions as first class citizens. Ridiculous. A language without lambdas is just that: a language without lambdas. Remove lambda from Python, and you remove only the ability of a Python programmer to define unnamed functions. Functions remain first class; their binding rules remain exactly the same. The only difference is that now programmers must give a name to all their functions.
- loup-vaillant 16y ago
  > As far as I know there is no other language with as comprehensive a collection of container-independent algorithms in the standard library Whoops. I forgot that, sorry. People may have meant true generic programming, after all. Now, actually using STL's <algorithm> and still end up with readable code isn't easy to me. For instance, each time `for_each` or `accumulate` would be appropriate, I end up writing a `for` loop instead, because the end result is more concise and more local. So in the end, container independent algorithms rarely matter to me. > I can write a simple, templated, singly-linked list class in C++ which can do everything the same `'a list` in ML can do. I think we don't use "simple" in the same way. Here, such an implementation of lists takes only 12 tokens and 2 lines in ML. How many do you need to do the same in C++? My first guess is more five times that, probably ten. Still simple, but much more complicated nonetheless. Though in that particular case, I'd rather blame the absence of inductive types. Templates really are simple here. The real problem shows when you combine them with inheritance: you have to jump through some hoops (like having to re-declare virtual methods in the derived classes). > Your following two paragraphs are a fairly obvious attempt to change your original, wrong statement into something defensible. It was an attempt to clarify my meaning. Yes, my statement was wrong. Lambda lifting doesn't go way beyond syntactic sugar. But, to me, it still crosses the line. To you, it doesn't. I think that's only because your definition of "syntactic sugar" is more liberal than mine. But even then, we're not done. Before you do the actual lambda lifting, you have to parse the source code. Trivial in Lisp, but quite a feat in C++. > […] The only difference is that now programmers must give a name to all their functions. To me, such a restriction is sufficient to make function second-class citizen. If you can have anonymous integers, and you can't have anonymous functions at the same time, then functions are not first class. Again, we disagree on a mere definition. Beyond that, I agree that the other "first-classiness" properties of functions are far more important.