I see his point about familiarity should not be a factor, but let's be real, if Haskell was your first language, and you saw examples of length on different types, then on tuple, the result would be unintuitive to most people, and for good reason. His requirement is the other extreme, even IEEE floating 0.1 + 0.2 might not be a wat then.
The von Neumann architecture is poor. Ridiculous Instruction Set Computers (RISC) are much, much, much, much worse. Direct execution stack-based architectures seem to be the best. If example, the Western Digital Pascal Engine, the Novix (Forth), The Lisp Machine, and Smalltalk on a RISC (except that it is a RISC). Designing hardware and software are the same activity. Both can be modeled with Petri Nets. Using semantic design, the hardware/software division is based on speed and cost (not a qualitative difference). The Novix chip implemented the Forth interpreter directly in hardware instead of software. Implementing the COG Smalltalk virtual machine in hardware would greatly speed up Smalltalk. Implementing the Java virtual machine in hardware is problematic because of the terrible design of the Java engine. Implementing the core Haskell interpreter in hardware would be worth investigating. Prototyping with an FPGA instead of an ASIC is a very good idea. I object to you using the term "printing" for fabricating an IC. Each diffusion and metalization step is much more complex than just "printing". The actual diffusion can take up to two weeks. You are trying to implement a Haskell program directly in hardware. A better starting point is to implement the Haskell virtual machine in hardware. That would be much easier and could then run all Haskell programs, not just one. P.S. If you switched from inherently quantum mechanically defective CMOS (a transient short between power and ground every clock cycle) to resonant tunnel diode threshold logic, your speed power product would improve 100,000 times. That is something to look into when you are through prototyping and ready to produce SOaCs.
Just an annotation. Monad Transformations are also useful in Erlang, for anyone not doing Mathematics, but still has a need to understand what a Monad Transformation is, and ends up here as a result.
The question is not why the length of a pair is 1, then, but why a pair is foldable in the first place. foldr f b t = fmap f t b for a pair `t`. Why shouldn't `Int` be Foldable, with `length 3 = 1`?
Haskell is not adopted because: memory consumption is the primary goal of Haskell, computations are converted into alternative computations that use the memory and memory bus in excess and cause swapping, memory and swap maximise the amount of computation that is done (computing a value in terms of disk state is the biggest computation possible and Haskell prefers to use that); tools to diagnose and solve that are missing, dysfunctional, or uninstallable (ghc-vis is all three); package databases make packages uninstallable except in sparse points; it's hard to find the /right/ package, there are tons of wrong ones and people talk about them as if they're right; the community preference is to mislead and trick. Haskell does not suffer from an insufficiency of Java.
@Chris Done FP Toastmaster here. You might want to look that up. Really bad speech characteristics tend to make people move on very quickly. If one actually wants to persuade one's viewers to listen to what one is saying if more than thirty seconds, those characteristics are essential.
This only has an overcompressed 480p stream as the best option and the slides aren't clear I think as a result. Is there anything you can do to get clearer text?
@@michelkannfliegen Unfortunately, the original code had bitrotted, and I needed to cut out the Twitter code to get the slides back up. Sorry about that!
IMNSHO, this is a clear Wat. In particular, you say you take the length of a tuple and get 1; but it only happens for a *pair* in particular. All other tuples fail! The key question here is, why can we traverse a pair in particular? The argument I've seen for it only addresses why it traverses the last field, not why it's different from all other tuples. The Either example is using Either as a Result type, and is quite arguable semantics; it's not clear from the type or constructor name that one is considered a shortcut and the other not, unlike Maybe. That's a minor flaw of the library. And if we look up what tuple means to the rest of the world, it *is* a list - so expecting it to behave like a list if it can be handled like a list is not surprising. Essentially, you're arguing for the Ok constructor to hold the rightmost type, and completely glossing over why you think a 2-tuple in particular needs to be foldable.
instance Foldable (,,) a b where { foldMap f (_, _, x) = f x } length (1, 2, 3) ==> 1 Just because it's not in the standard library doesn't mean you can't take the length of an n-tuple. I largely agree about Either---sometimes it's used to mean error/result, sometimes there really are two possible outcomes; that's just the downside of using structural types as as opposed to nominal types. It's not unique to Either (e.g. Maybe can be used to mean represent failure without a diagnostic, or an optional value), and its not unique to Haskell (e.g. a null likewise can indicate failure or an optional value). If we look up what the less-than operator is to the rest of the word, it's an infix, but in Lisp it's a prefix operator. I guess that makes Lisp's less-than a wat? No, it just means you don't know Lisp. If you think Haskell pairs are lists, it just means you don't know Haskell very well... but it's been a few years so I expect you've learned by now. As for why the rightmost type should be the one that holds the result, well, if you wanted the left side to hold the error, you would need to define a type synonym and turn on the TypeSynonymInstances extension; OTOH, if the right one holds the result, then in standard Haskell you can just partially apply Either and everything works out. Though if you really wanted the left side to hold the result, you could switch over to the Bifunctor interface (though I'm not sure there's a compelling reason to do so). Does a 2-tuple _need_ to be Foldable? No. Nothing needs to be Foldable. You don't need to use Haskell, you don't need to be a programmer, you don't need to use a computer. But there _is_ a sensible instance for `Foldable (,) a`, and perhaps some people get some use out of it. If it weren't in the prelude, it might end up in somebody's utilities collection. I don't personally use pairs as functors or foldables or any of that; most of the time, I'd much rather use `second f (x, y)` than `fmap f (x, y)`
Typing Mochizuki's IUTT papers in this at the moment. Turns out chapters 1 through 17 are surprisingly doable, although the Hodge Theaters are a bit harder to construct under category theory axioms. Thank god for the abstract topological group package.
Frege is an Haskell like language, but has its own compiler and doesn't use GHC, whereas eta is a backend for GHC and provides an equivalent of the GHC runtime on the JVM.
A very important research and implementation ! Thank You very much! Looking forward to (pre-)releases of GHC 8.2.1 equipped with backpack. What a pity that the audio is clipped / oversteered / has distortion. Hope You will repeat Your presentation some day :-)
Even though OverloadedStrings let you write string literals that are either String or ByteString, it doesn't solve the problem of also giving you functions that let you perform operations on these strings. But it's true that type classes solve similar problems to Backpack: Backpack is better for dealing with cases where you need to support a lot of functions in your API.
