We have all learned functional programming in Haskell, but there are more functional languages like Lisp, Scheme, ML, and Clean.
Why should we even bother to look further than Haskell?
- You want your programs to run faster. - Monads drive you mad (what are they anyway? warm fuzzy things?). - You need objects. - You sometimes need a more powerful module system.
lets see what want: - You want your programs to run faster. C++ - Monads drive you mad (what are they anyway? warm fuzzy things?). C++ - You need objects. C++ - You sometimes need a more powerful module system. C++ classes
Day1:Blub programmers don't see the benefit of writing less code, they're just code monkeys paid by the line. Who cares if all the programs you runs are made in Blub, thats just a conspiracy by Blub architects. They purposefully made Blub so efficient and fast so everyone chooses blub. Day2:I wish that Blub would disappear, its so inelegant and obtuse compared to my language. It doesn't even have autism-express-stack-apply-in-reverse, because this is impossible to implement in there. Of course i use autism-express-stack-apply-in-reverse everyday, thats my favorite function. Day3:What do you mean "wrote any useful program"? i'm computer scientist not a code monkey.,I develop the tools and algorithms, so I essentially contribute more. Day4:I submitted a proposal to add autism-express-stack-apply-in-reverse into Blub with minimal modifications to the Blub core , but they didn't like it. Its so kawaii and they didn't like it, monsters. How the world can be so cruel? I hope it garbage collects itself.
Name:
Anonymous2015-02-20 13:29
>>5 Blub isn't about the language, it's about the user. But I can see how a Blubber would miss the distinction.
The solution to BlubParadox is simple: writing lots of simple code only tires you physically, your mind is at rest and you're in some trance state which is enjoyable. writing smarter,more abstract code tires the mind and stops any trance/flow but minimizes effort to code. probably a middle ground is to write a code that doesn't force you to think of very complex ideas, and is compact enough to not tire you physically. Object-oriented design with information hiding allows to operate on black box interfaces, which can be arbitrary complex structures. So essentially OO-Blub is both simple to think of(intuitive interface) and fast to write(using a black box). What "non-Blub superior languages" fail at is that they provide very rich, possibly arcane tools and expect the programmers(the average programmer is not a genius) to think hard how to use a tool. To add to injury syntax which needs more mental effort slows down the programmer. The code becomes mentally hard to write and interpret, the advantage of it being compact is viewed as a black box interface. Except not a Blub black box, an unconventional hard-to-modify piece of code without a OO interface to large piece of simple code. Blub wins adherent by being simple to learn, modify and create abstractions. It doesn't have anything really "hard" and "complex" but that works to Blub advantage: it makes far easier to parse, compile and modify Blub than the "superior language". Some things can't be expressed in Blub they say. When someone actually expresses the things, they're inelegant. When made elegant they're called unsafe and ugly on the inside. Blub rarely needs to express the things, it doesn't need to emulate lambda-calculus to solve problems of its domain. The things hard to express in Blub are with rare exception heavily abstract representations of academic ideas. Blub is not fundamentally crippled because it lacks these things: when Blub will need it it can linked from a module or library outside Blub.
Haskell was made for the purpose of having a functional language. ML was made with an actual purpose.
IHBT
Name:
Anonymous2015-02-20 18:11
>>12 "Meta" is just a fancy buzzword. ML isn't any more of a metalanguage than Haskell or Clojure. Is being named after a buzzword a real purpose? I think not.
Haskell was made for the purpose of research, by the way. And ML? It serves no purpose at all, except perhaps its Camel and F# incarnations, but those are just "inturdprice OOP but with them first-class functions shit so you can brag about being a functional porgrammer" languages.
And so are ``anus'' and ``hax'' by your reasoning.
Haskell was made for the purpose of research, by the way.
Right. ML's original purpose was to implement other languages (i.e. metaprogramming). It is practical. ``Research'' as a purpose is about as vague as you can get; my point still stands.
OOP but with them first-class functions
``Look, ma! I'm spewing baseless opinions on something I know nothing about again!'' --u
>>15 OK. I'll just take that as you graciously bowing out. Try again next time!
Name:
Anonymous2015-02-20 18:43
>>14 Yes, they are. Computer PL research is a definite enough purpose. The number of GHC extensions and things you can do in Haskell that you can't in 99% of languages confirms that Haskell is successful. ML? Metaprogramming? Seriously? It's even worse than Lisp.
Computer PL research Haskell was made for the purpose of having a functional language.
Yep. Haskell's purpose is for PL researchers to play around with what they can do in Haskell. Ergo, Haskell's purpose is itself.
things you can do in Haskell
You can do many things in Javascript that you can't in most other languages. That makes it successful, yes, but the people who are doing that kind of thing are making dorodango.
Metaprogramming
Yes. ML is a fantastic family of languages to write compilers in. Metaprogramming is about programming programs; that does not necessitate targeting the host language.
You are an idiot and all your points are false.
Thank you for validating all that I live for. I'm sure your PhD thesis contains this very sentence.
Name:
Anonymous2015-02-20 19:40
>>18 You are an obvious idiot. I will not even waste time explaining you why you are wrong.
>>17 The number of GHC extensions and things you can do in Haskell that you can't in 99% of languages confirms that Haskell is successful.
Prelude> let f x = x x
<interactive>:2:13: Occurs check: cannot construct the infinite type: t1 = t1 -> t0 In the first argument of `x', namely `x' In the expression: x x In an equation for `f': f x = x x
Name:
Anonymous2015-02-21 8:27
>>28 Yes, this kind of type safety is a necessary condition for Haskell's success, but it's not really a fancy thing. Other languages can forbid type-unsafe programs as well. So what's your point?
Name:
Anonymous2015-02-21 9:06
>>29 Just because Haskell can't do it doesn't mean it's unsound.
Name:
Anonymous2015-02-21 9:10
>>30 Can't do what? Apply x to x? I've never ever needed to do that.
Name:
Anonymous2015-02-21 10:36
>>31 There is no end to the list of sound things you've never needed to do.
Yes, [b]this kind of type safety[b] is a necessary condition for Haskell's success
is bullshit. There's nothing inherently unsafe about infinite types.
But if you really want to know what x x is good for, it comes up a lot in lambda calculus. In fact, application of the X combinator to itself is good for everything, being a basis of combinatory logic: https://en.wikipedia.org/wiki/Combinatory_logic#One-point_basis
Lambda calculus is not an example of practically valuable application. Try writing a hello world in it.
In fact, application of the X combinator to itself is good for everything
And unary encoding (Peano numbers) is good for everything too, but nobody uses unary (except some proof assistant academics).
Name:
Anonymous2015-02-21 13:10
>>36 That's not a safety issue. There are a lot of things in Haskell that are incomparable.
>>37 Haskell Curry used it. Without combinatory logic the Haskell type system doesn't even work. Combinators are used all the time in Haskell, MLs, Lisp and even shit like Javascript.
A form of Peano numbers are used in miniKanren and probably core.logic.
Name:
Anonymous2015-02-21 13:24
>>38 It's a safety issue because it's a type-safety issue. How are you going to ensure type-safety if you've got some uncomparable infinite types floating around?
Name:
Anonymous2015-02-21 13:26
>>38 What the fuck does combinatory logic have to do with x x? Are there any actual practical examples of where it is useful, or not? Lisp apply is practical but not compelling. Anything else?
>>44 Please stop with this minimalist dubs bullshit. There used to be a time when dubs were eloquent works of art. Nowadays, a single "no" passes for dubs. It's deplorable, really.
>>36 They are recursive, and they can be tested for equivalence. Your unification algorithm just needs to support it, and Haskell is too lazy to do it.
Name:
Anonymous2015-02-21 21:06
>>47 1. Demonstrate a type system with such a feature. 2. Haskell is too lazy to do it precisely because it's useless in practice.
Name:
Anonymous2015-02-21 21:21
>>48 1. Ocaml with rectypes. 2. Nope. They just have a limited understanding of type theory and think what they've implemented is all there is.
On 64-bit systems, the size of OCaml arrays from the Array module is limited to 2^54 - 1 and on 32-bit systems the limit is 4,194,303. For arrays of float, the limit is 2 times smaller. In both cases the index is easily represented as an int, so there's no advantage in using int64 as an index.
Name:
Anonymous2015-02-22 10:20
I have created huge systems in C++ using a combination of Generic Programming and Functional Programming meta models. I am nowadays more of Clojure + Scala + Elixir developer, but welcome the C++14 (proposed) changes, to enable polymorphism even in the anonymous realm of functoids. C++ actually has a lot of expressivity — no, I didn’t even mention performance — that most FP languages lack, from its (admittely ad hoc) notion of templates. So, there are other reasons but performance and even ABI compatibility to use C++ before other (FP) languages.
C++ is indeed re-converging. From a hairy mishmash to a more streamlined FP+GP experience. Perhaps a bit too late? Well, I welcome the changes, and the quite quick uptake of the new standard features in the compilers (MSVC, GCC and CLang, specifically…)
Am at loss when people claim that using functional techniques — such as HOFs and functional combinators — is simply an exercise and cannot be used for “real programming.” One should not eject that style of programming in C++ merely due to one’s own shortcomings. I can assure you that functional programming in C++ is used in highly real systems. Or perhaps I have just been dreaming the two million lines of C++ code I have written since 1989, with heavy use of functional combinations and streams (such as using Boost’s iterator transformers, yielding streams or Haskell/Clojure-like lazy sequences.)
Yes, you can create crappy, procedural monsters with C++. But you can write quite succinct FP+GP programs as well. And even more so with C++11, and with C++14.
I will now go back to my Scala hacking…
Name:
Anonymous2015-02-22 10:42
:: -> Functional prog//ramming->
After considering that most languages are in fact not at all functional, some language designers decided to find out what programming in a really functional language would be like. As you would expect, programming functional languages is mostly annoying and impractical. Almost no real-world problems can be usefully expressed as static, well-defined mappings from input values to output values. That being said, functional programming is not without merit and many languages have been designed to take advantage of a functional style of programming. What that means is finding a convenient way of isolating the functional parts of a program from the (actually interesting) non-functional parts. Languages like Haskell and Ocaml use this isolation as a means of making aggressive optimisation assumptions.
But this is lisp. We're very non-functional and very proud of it. To the extent that this isolation of side-effects is useful, lisp programmers can and do implement it with macros. The real purpose behind functional programming is to separate the functional description of what should happen from the mechanics of how it actually does happen. Lisp is definitely not functional, but, because of macros, there is no better platform or material for implementing functional languages than lisp.
You know a language is good when you can't have an array with 5 million elements in it.
Name:
Anonymous2015-02-22 16:31
>>59 That would be a limitation of the runtime, not the language. If you want a big array, there's always, um, the Bigarray module.
Name:
Anonymous2015-02-22 17:27
>>60 Is there another runtime for that language? If not, then it's effectively a limitation of the language.
And having separate modules for big arrays is really retarded and ad hoc, it's like some primitive negroid tribe that has numbers "one", "two" and "many".
Name:
Anonymous2015-02-22 18:05
>>61 The BigArray module is part of OCaml's standard library, like the Array module. What more do you want? If you don't like the name, just write module Array = Bigarray at the top somewhere.
Name:
Anonymous2015-02-22 18:26
>>61 Yes. Seeing as you're being obtuse, I'll let you find them yourself.
separate modules for big arrays is really retarded
Well, it's called Bigarray, but if you took half a second to google ``ocaml bigarray'' and read the documentation, you'd find there are many differences, not limited to the size of the array. If you're serious that you need garbage collection on arrays of 5 million elements, then my condolences go out to your colleagues.
Name:
Anonymous2015-02-22 19:33
>>54 Ocaml may be shit, but that doesn't change that it is a perfectly valid example of a type system that supports recursive types. Why do you feel like you have to find a way to shoot down the example?
Note that variable str is immutable in the above; it's the string that it's bound to that's mutable! Efficient strings are so important for the efficiency of so many programs that each character of an OCaml string is actually a reference;
Why Not Haskell Haskell: lazy by default → difficult to reason about performance/execution purity does not bring much to safety people use unsafePerformIO anyways + less “hackable” type-classes in practice: used 95% of the time to make the code as unreadable as possible more unreadability: need to know every possible GHC extension (there is even dynamic typing in there!?) indentation-based grammar makes code hard to read (blocs > 7 lines) does not have (AFAIK) any good subtyping mechanism
>>73 Lazy by default means Haskell doesn't do any extraneous work which implies its work is as efficient as possible. Purity means safety as you don't have to reason about the external environment outside of the function. In fact, it is possible to mathematically prove the pure code will be correct for what it does. This is not possible for impure code Whenever we use unsafePerformIO, we know where is a source of impurity which gives us hints to focus our effort whenever we encounter bugs in our program. We will use it when it's needed, and we don't need it everywhere. That's just your opinion man. That's just your opinion man. That's just your opinion man. That's just your opinion man.
Lazy by default means Haskell doesn't do any extraneous work which implies its work is as efficient as possible.
Except for that thunks are massively inefficient compared to their eager pals
Name:
Anonymous2015-02-27 18:48
>>75 No, they aren't. They use more memory but save a lot of time (less evaluations because some stuff is memoized while some stuff is never even evaluated). Besides, no language can be purely strict or purely non-strict, it's just a question of choosing the default, and lazy evaluation is definitely not the worst default.
Name:
Anonymous2015-02-27 18:49
>>76 OK I was just stirring really. I have nothing to respond with. I might pick up Haskell in a couple of months.
Name:
Anonymous2015-02-27 18:57
>>73 lazy by default → built-in modularity. Abstractions are not only possible to a much greater extent than in the imperative shit-slums, they also combine very easily and efficiently.
Purity brings a lot for safety because it means lack of global state and guarantees (with Safe Haskell) that a large portion of code can never do anything besides returning a value. This can be extended to create secure systems, see for example https://hackage.haskell.org/package/lio
unsafePerformIO is used by dumbass newfags mostly, except in the core libraries of course, but those have pure interfaces.
Haskell's code is short and denotation-like, it's a lot more readable than the {var a; a = b; b = c; c = c - 1; b = a - b*c; return a; } diarrhea.
You do not need to know every possible GHC extension. For example, Oleg Kiselyov uses only GADTs and the *Instances extensions.
No, "dynamic typing" is a library, not an extension.
Indentation is not forced. You can use your semicolons and curly braces all you want. Simon P. Jones does, for example.
There are no good subtyping mechanisms. Subtyping is shit that wrecks type inference, type safety, and developer time. Subclassing is much better and Haskell has it (no GHC extensions needed).
Any more dumbass misinformed non-reasons to hate Haskell (which is shit, by the way, but for a whole different set of reasons)?
Name:
Anonymous2015-02-27 19:00
>>78 What are the shit things then? What's a good setup? GHC is an even bigger install than Latex.
Name:
Anonymous2015-02-27 19:30
>>79 Off the top of my head: Weak module system (compared to SML). No real packages (cannot disambiguate same-name modules). Shitty record types (a community-acknowledged thorn in the ass). String is a linked list of chars. The numeric tower in the Prelude is dumb-ass (though still better than any of your Scheme or OCaml shit). Stream fusion still not well-integrated (though most languages don't even have it).
GHC is big only because it contains 4 versions of every library (and 5 copies of the compiler itself).
Name:
Anonymous2015-02-27 21:59
>>74,76 It really fucking depends man. Wasting memory is wasting cache -> wasting time. GHC can be intelligent about when to compute vs. when to memoize, but OCaml can be intelligent about when to defer/cache computation. Neither seem to do a super great job of these things. You don't want the lazy default if you care about latency.
>>78 Lazy vs. eager doesn't divide functional and imperative programming. What are you smoking?
>>80 Can't argue with this, even the OCaml jab. Not sure why you would even tolerate a broken numeric tower, but whatever floats your boat.
Name:
Anonymous2015-02-27 22:12
>>81 I don't get it. OCaml's numbers are all clearly defined. Is this to do with (+.) : float -> float?
Name:
Anonymous2015-02-27 22:22
Also I think lazy/imperative is related to some recent-ish thread in which the topic was mentioned, in essence drawing some parallel between lazy being a lot more composable (in the spirit of FP) than strict, with the example of map factorial [1..100] |> take 3 - lazy only performs factorial 3 times while both strict and imperative have the same problem of 100 factorials.
Name:
Anonymous2015-02-28 0:26
I think Perl 6 gets lazy right. It's very easy to be strict.
Name:
Anonymous2015-02-28 3:36
>>82 maybe he thinks that's a numeric tower. but ocaml's built-in numerics are all completely orthogonal up to explicit conversions.
Name:
Anonymous2015-02-28 9:58
>>81 There are no imperative languages with lazy-by-default evaluation. What are you smoking?
Name:
Anonymous2015-02-28 11:37
>>82 Exactly. Even Haskell's gay-ass numeric classes are better than having to use different functions for floats and integers.
Name:
Anonymous2015-02-28 11:41
>>87 OCaml allows SML-style overloading, even though explicitness is always better in terms of obvious correctness.
Name:
Anonymous2015-02-28 11:45
>>88 Haskell allows redefining the Prelude, so what? The language's defaults matter.
explicitness is always better in terms of obvious correctness
So each type should always have its own distinct functions for everything and 8.0 + 4.0 is less correct than 8 + 4? Laughable, get back to your ungeneric C toilet-scrubbing.
Name:
Anonymous2015-02-28 11:53
>>86 Your mom's weed, 'cause we're tight like that. Perl 6 is lazy by default, son.
No, 8. /. 3. is different to 8 / 3. Floats and integers are intrinsically different.
Name:
Anonymous2015-02-28 13:14
>>91 No, for lots of people. Just consider the recent heated FTP discussion.
Just because they're intrinsically different doesn't mean they should be different for the programmer. Google "generics".
Name:
Anonymous2015-02-28 13:30
>>92 I didn't think people were actually taking it seriously. If you think that the defaults should matter so much, I would expect that you are outraged every time you have to use a compiler flag, or one of those stupid GHC directive comments that I see clogging up the top of many a haskell file. (SML-style overloading is achievable with a library and a compiler flag, by the way.)
I understand that OCaml does not have generics. However, "being different for the programmer" is my original point: obvious program correctness via explicitness. It may be more convenient for the programmer to write integer and float division the same way, but when it comes to reading it you'd potentially have a lot of context to absorb in order to understand what is actually going on.
Name:
Anonymous2015-02-28 14:12
>>93 Are SML functors achievable with a library and a compiler flag?
Yes, seeing things like a + b makes it really hard to understand what is actually going on. Is it... could it possibly be... addition?.. I once spent two and a half hours figuring out what + meant in a particular hard-to-absorb context, so I definitely hear your pain there.
We also need separate functions lengthList, lengthText, lengthArray, lengthMutableArray, sizeSet, sizeHashMap, sizeStack, sizeQueue etc just like in Scheme. That way we can be sure everything's correct by design!
Name:
Anonymous2015-02-28 14:34
>>92 It's a tradeoff. It's not because they want you to type the arithmetic operators, it's because they need you to do it for inference. It's going to come down to a preference. You can assert one or the other all day, but it's only a question of taste.
No. OCaml makes the curious choice of disallowing implicit type conversions and not having any operators overloaded by type, even between scalar numeric types.
The only good thing about having different operators for float and integer operations is the explicit information. But it's not better information than you get with Haskell, where function signatures are the norm. Since global inference and elided signatures are the norm in OCaml, these different operators are necessary to match the information available. OCaml also needs them to type functions because this really is the minimum information level for OCaml's type system.
Yes, seeing things like a + b makes it really hard to understand what is actually going on. Is it... could it possibly be... addition?
It depends. If it's Javascript it's more likely to coerce one or both arguments to string and perform concatenation than it is to perform arithmetic. (If it's C++ god only knows what it's going to do.)
But Javascript is a stupid language, I can't base an argument off that. So, what if we relaxed OCaml's rule in a new language and let it dispatch on type? We have such a language, it's called F#:
> 1 + 2;; val it : int = 3 // duh
> 1. + 2.;; val it : float = 3.0 // cool
> "a" + "b";; val it : string = "ab" // hang on a sec
> let f a b = a + b;; val f : a:int -> b:int -> int // hey wait I thought + was generic? at least you can't call this on strings.
> 1. + 2;; 1. + 2;; -----^ .../stdin(14,6): error FS0001: The type 'int' does not match the type 'float' // aw dang
OCaml and F# both treat integer and floating point arithmetic as distinct, as they should, since the underlying machine types behave very differently and these languages aim to address the underlying machine types. But Haskell cares about the distinction too, it just doesn't mind coercing between the types because the machine behaviour is abstracted away:
<interactive>:5:1: No instance for (Bits a0) arising from a use of `shiftL' The type variable `a0' is ambiguous Possible fix: add a type signature that fixes these type variable(s) Note: there are several potential instances: instance Bits Int -- Defined in `Data.Bits' instance Bits Integer -- Defined in `Data.Bits' instance Bits GHC.Types.Word -- Defined in `Data.Bits' In the expression: shiftL 33.3 4 In an equation for `it': it = shiftL 33.3 4
<interactive>:5:8: No instance for (Fractional a0) arising from the literal `33.3' The type variable `a0' is ambiguous Possible fix: add a type signature that fixes these type variable(s) Note: there are several potential instances: instance Fractional Double -- Defined in `GHC.Float' instance Fractional Float -- Defined in `GHC.Float' instance Integral a => Fractional (GHC.Real.Ratio a) -- Defined in `GHC.Real' In the first argument of `shiftL', namely `33.3' In the expression: shiftL 33.3 4 In an equation for `it': it = shiftL 33.3 4
Sort of.
Name:
Anonymous2015-02-28 16:15
>>94 Your google-fu is spectacular yet transparent. Functors are part of the language. OK cretin, let's do it your way. Let's totally ignore the case I've been running with (division) in favour of your straw man. Let's take length. So I have a block of code containing length foo. By your assumption I don't care bout the actual type of foo, but now I want to add something to it. Oh shit! Suddenly I need to know if it's a list so I can prepend to it, or a hash so I need a key to go with the value, or a mutable array so I should be smashing my eyes open with a hammer, or maybe I can just use + on it and hope for the best, eh?
>>95 It's hardly curious. You basically answered yourself. That, and the fact that integers are treated specially by the GC though floats are boxed, but I assumed this other guy knew that because it's so common in functional languages (a trait shared with Lisp and any other language with 31- or 63-bit numbers).
Name:
Anonymous2015-02-28 16:18
>>96 Fair point, but F# can do that because it's OCaml with its guts ripped out and replaced with .NET.
It's curious to the uninitiated and rare, so generally curious. Do you think I was trying to say it was somehow bad or wrong?
Let's take length.
I don't know what point >>94 was really trying to make here. Your bleating is really strange in the face of ( > ) which is typed 'a -> 'a -> bool. But do let us take length:
# let len x = x#length;; val len : < length : 'a; .. > -> 'a = <fun>
Hurrah structural subtyping. (It works with nominal subtyping systems too, but you don't want that with global inference.)
We can have it both ways in OCaml but one way is clearly preferred. There is no controversy. What's there to argue about?
>>98 Thanks for explaining my post to me but check 'em.
>>99 Error: This expression has type 'a list but an expression was expected of type < length : 'a; .. > Also (>) is - widely known and lamented as one of a family of builtin functions that require a hole in the type system in order to work; - inapplicable to two values of differing types.
Name:
Anonymous2015-02-28 17:46
>>97 My what? Google-fu? This coming from a person who thinks that SML functors are part of the Haskell Language? Truly retarded, I should stop reading your post now. But I'll read one more piece.
By your assumption I don't care bout the actual type of foo
No, by my assumption you don't need to call a function whose name depends on that type. Whether or not you need to care about its type depends on the concrete algorithm. For example, Oleg Kiselyov has a beautiful piece on generic zippers where he does not give a single flying fuck about the type of the thing he's zipping on - he only needs to have its traversal function. But yeah, if you want to prepend stuff to foo, you probably need to know its type - but you shouldn't have to use some shitty ungeneric function just to find the damn length of it. The programmer has been spared a bit of free time and a modicum of frustration, thank God!
I'm tired of your stupidity now and will not read any further.
>>100 Type system holes are a problem in theory and nowhere else. They're a purely academic concern. In the real world you can trust sensible programmers only to use them in idiomatic ways appropriate to what you're working on. Therefore they're an overall win for expressive power, and a litmus test for distinguishing between useful languages and academic languages.
a person who thinks that SML functors are part of the Haskell Language
No. I was talking about The OCaml Language. Apparently I should have been more explicit. No wonder you are so stressed. My apologies. Google-fu was in reference to the observation that your knowledge on SML functors appeared to derive from a 5-minute google session on the search term "SML overloading".
generic zippers
Am I missing something? Why does a zipper need to be generic, and not just parameterised?
I'm saging because we're clearlyboth getting tired of this.
Name:
Anonymous2015-02-28 17:58
>>102 Considering the theory is the basis of the implementation, it's quite a practical concern.
* that error has nothing to do with the issue * ( > ) is well-typed, but thanks for playing * and of course: if x > y then x +. y … illustrates the same non-issue complained of in >>97
Name:
Anonymous2015-02-28 18:04
>>106 * The error is the fact that if I want your ``len'' I need everything to be an object. Tastes foul. * > is well-typed, yes, but your interpretation of the issue is incorrect. The implementation of > is the problem here.
This isn't an error, but: no shit, that's why we don't do it. Which is exactly what I've been saying.
The implementation of > is the problem here
That's not a hole in the type system it's just an oracular function, and no worse than read_line. OCaml is full of this stuff... I/O, Gc, FFI. You want holes in the type system? Start looking into Obj.magic, ( > ) and friends aren't going to do it for you.
>>109 It's holes when you hit Obj.magic or use FFI. That really doesn't have anything to do with any "holes" you might imagine in comparisons or oracles.
>>110 Still no holes. Yaron Minsky is worried about its performance, and confusion stemming from failing to understand comparisons. That seems unlikely because we're all used to writing Module.operation foo in OCaml. We would more likely mistake the operands for basic types than anything else.
But he thinks it's a good idea to include a hack based on comparison behaviour regarding objects in the standard library, tipping his hand that performance is his main concern (Jane Street is HFT or whatever.)