[Haskell] We write a pure program in Haskell

Any post is ignored if:
* code isn't fully conforming Haskell 2010
* contains a definition of main outside of >>999
* FFI is used or modules imported that are not provided with a standard Haskell Platform install

{-# LANGUAGE QuasiQuotes #-}
{-# LANGUAGE TemplateHaskell #-}
import qualified Language.C.Inline as C
C.include "<stdio.h>"
C.include "<math.h>"

C.include "<void.h>"

```
C.include "<windows.h>"
```

haxMyAnus anus
| anus >= 500 = "HAX MY ANUS!!"
| anus < 500 = "HAX MY ANUS!!"
| otherwise = "HAX MY ANUS!!"

loeb :: Functor f => f (f a -> a) -> f a
loeb x = go where go = fmap ($ go) x

nobody can write anything in Haskell because they're too busy navel gazing about pseudo-mathematical shit that doesn't matter. doesn't mean it's impossible. it's just unnecessarily difficult.

-- If you write it down in paper and then write the code it's by far the best way to write Haskell.
--Did whole uni work in Haskell with this technique.

What _/prog_/ramming language is this?

>>9
Some pretentious language that needs Monads to performIO, unlike uniqueness types in Clean.

[Major spoilers on future of Haskell]
https://gitlab.haskell.org/ghc/ghc/wikis/dependent-haskell

To be fair, you have to have a very high IQ to understand Haskell. The language is extremely subtle, and without a solid grasp of theoretical type theory most of the concepts will go over a typical programmer’s head. There’s also Simon's puristic outlook, which is deftly woven into its monadic I/O, which draws heavily from category theory, for instance. The users understand this stuff; they have the intellectual capacity to truly appreciate the depths of these concepts, to realise that they’re not just useful- they say something provable about PROGRAMS. As a consequence people who dislike Haskell truly ARE idiots- of course they wouldn’t appreciate, for instance, the convenience in multi-paramater typeclasses which itself is a fancy way to say "multiple dispatch". I’m smirking right now just imagining one of those addlepated simpletons scratching their heads in confusion as Simon Jones genius wit unfolds itself on their terminal window. What fools.. how I pity them.

And yes, by the way, i DO have a Haskell tattoo. And no, you cannot see it. It’s for the androgenous genderless assholes’ eyes only- and even then they have to demonstrate that they’re within 5 IQ points of my own (preferably lower) beforehand.

To be honest you have to have a very low IQ to not be able to understand Haskell.

>>13
Its not about understanding Haskell, its hating academic bullshit shoved down from educational ivory towers.
If Haskell was a hobby niche language for autists, it would not have any criticism.

>>14
And why would you hate "academic bullshit shoved down from educational ivory towers"? That's right, because you can't understand it.

>>15
No, because it's bullshit.

>>13,15 is the typical Haskell user exposing the real motivations for using Haskell.

codemonkey insecure about his intelligence, but he can't prove he's smart by accomplishment or practice in real rigorous mathematics, so he clings to meme programming languages that make him think he's smart without having to do anything.

it's a cult basically

The Virgin's Hask-cel ;vs; Chad Node.js
Speaks in elaborate math jargon developed to deal with Hask-cel math fantasies; Explains the rare functional term encountered only through esoteric non-imperative code
No notable software; Software industry spotlight guaranteed
Syntax resembles both Forth and Lisp, without their flexibility; Synmtax is C-derived and flexible
Too lazy to evaluate anything; Eagerly computes by default and has sane async mechanism
Requires Math Phd for proficiency and enormous student loans ; Requires "Node.js for dummies" and non-smooth brain
Code is write-only, obtuse and require intimate knowledge of category theory to unpack; Code is self-documenting, needs elaborate obfuscators to be marginally unreadable, still can be easily read by experts
Code slow due thunking and shitty optimizations, code refactoring/optimization consists of blindly copying imperative designs, often unsafe; Code is optimized by industry-leading JIT compiler

import https://hackage.haskell.org/package/monad-lgbt

The state of Haskell metaprogramming
https://www.reddit.com/r/programming/comments/bip6ho/graydon_hoare_on_21_compilers_a_wander_through_a/em5grcg/
The short version of what coda is about is fixing a number of things that keep functional programming from scaling.

I'm leaving what particular dimension 'scaling' applies to as a free variable.

One way we can fill in that variable is to talk about execution speed:

FP has been good at getting us code that scales down to the core level, but we aren't getting more cores terribly fast. Moore's law used to equate to speed, then it equated to speed * cores, now it mostly equates to speed * cores * width of the SIMD processing unit when it applies at all. I'm interested in ways to apply SPMD-on-SIMD evaluation techniques to functional programming. These are the techniques that make the Intel SPMD Program Compiler work as well as it does. It also provides a window onto how to execute this sort of code on GPU and TPU style hardware. If I want symbol pushing techniques to be at all relevant in a world where these are becoming the norm, we can't fail to scale past the core.

One way we can fill in that variable is to talk about scalability of abstraction:

The typeclass mechanism Haskell uses favors finding a few good abstractions over accurate abstraction selection. If I tried to make the standard library of Haskell have a mathematical concept of a 'Field' and put 600 superclasses with all of the algebra I know above that point, the community would mutiny on day 1. On day 30 when I found it should be 601, and went to make the change all of that code would break. How can we make deep extensible type classes with typeclass hierarchies that actually branch out and aren't linear chains?

One way we can fill in that variable is to talk about scalability of the library ecosystem:

Another dimension where I don't see it scaling is that there are a number of language design decisions in Haskell that keep me from scaling. I maintain a rather ridiculous number of Haskell libraries, all of which have to work together. Haskell is pretty darn good at solving diamond dependency issues, compared to something like node, which just ignores the problem, in a way that makes it easy to depend on ridiculous numbers of dependencies, but building a haskell project still consists of spending 97%+ of your time compiling instances for classes that never occur in the final program in a way that is forced by the structure of package management. You have to supply instances for every package that came before you in the Haskell ecosystem or you are just incompatible because of uniqueness of instance resolution. Orphan instance packages can be forgotten or mis-used. How do we fix this problem?

One way we can fill in that variable is to talk about scalability of proof effort:

It took 13000 lines of basically nonreusable code, 9 months worth of effort and a PhD to prove the correctness of the GMP sqrt function. Most issues I'm interested in are bigger than that.

There are other directions to explore here.

How to scale in terms of parallelizing team efforts? e.g. Letting more people work on proof infrastructure.

How to factor apart what it means to prove something correct, and finding a space of equivalent, correct programs, and then to make it fast by selecting tactics style out of a space of equivalent correct programs the one you want?

How to throw program synthesis techniques at problems to increase the grain size of problems that the compiler just handles for you? The work on synquid by Nadia Polikarpova, Barliman by Will Byrd, and Blodwen by Edwin Brady all point generally at something in this space. Each offers different ways to prune the search space drastically by using types or different generation techniques.

How to scale the number of machines that are used for synthesis? I know tons of people who work in rendering films. There we spin up 10k+ machines to save artist time. Is developer time less valuable? This also drastically changes the scope of what is considered synthesizable when this is your baseline.

Most of my efforts lately have gone into this subgoal of program synthesis, hence coda itself has languished while I build the pieces there that I need to build the type checker infrastructure on top of. The irony is not lost upon me that this languishing arises largely due to my inability to scale up my own local development efforts, personally.

fully conforming Haskell 2010

Can't wait for 2011-2012 where Haskell takes over the software industry and functional programming established as new paradigm.

>>21
It did actually. Most recent cs graduates should know and use haskell.

I used to contribute to haskell projects in 2011 (mostly xmonad), now I am severely autistic.

>>23
Fairly sure you were severely autistic back in 2011 as well.

>>13
The best case use for Haskell is the use of functions to perform functions. We can take the function f :: Int -> Int as the argument of its argument f :
f xs :: int = f xs
Notice the type signature for the function f : the type of the function is int . That type signature can be modified and written in a variety of ways. For example, the above example could be done using type polymorphism in the GHC compiler. Let's take a look.
Let's suppose we have written f :: Int -> int . This can be read as follows: This function f must be used in any function f that takes an argument of type int . However the Haskell type signature can be modified to be either an Int or a Maybe Int .
So in the example above, we have given the result type from Haskell like this: data Just a = Just (a) data Maybe a = Nothing A Haskell might look like this:
In fact Haskell allows you to do things such that the type signature of a function f will change in a manner similar to that for reading the type in a language.

>>25
that's it? higher order functions? you have been able to do this in every other language since the 70s.

>>26
It copy-pasta from GPT-2 AI for "The best case use for Haskell is".

>>26
Haskell the dog wagged his monadic pointer tail, making him look even taller than in the movie. But it's not the best way to express this. Instead, I'll simply use a pattern like this -- one that is consistent from run-to-run.


class Dog def bar @baz :a => a end def <p :a ( p :foo bar )] end

That pattern works, but it isn't good for some operations. The operation which is commonly used to create Dog is to define an instance of Bar where the bar property gives you a reference to Bar . We wouldn't use this, because defining an instance of Bar when we can't use it would be confusing. If we use an example like this in Haskell we don't require that we be able to reference an external Bar instance by using this pattern. Instead we have the advantage of being able to write code that works even if we can't reference it.

Instead of the above we can also construct a new data type, called Bar , using the type class pattern. This is a handy trick because Bar can hold just whatever we need

For example the monoids easily ~~~ ( ~~~ x = x) if y are not unique. These monadic patterns can be made larger using morphisms. It's simple to add more monoidal structures by doing so. In the case of the sequence, the structure with x, y is given in the above example. Also, for each monoidal structure such as monoid f, for the sequence, is given.

So we could say that for all the sequences that exist, all monads ~~~ exist. All monads that exist are associated with the monoid structure f. Let's see what's the monadic sequence structure:

The monoid x = f is associated to ~~~ x = x. Also in the top left corner, there is an additional monoid structure - for instance the composition of a pair of monoids is a monoidal morphism. The above structure of x = f is the base unit of morphism monoidal f. The structure - ~~~ x = x , which consists of y ~ X monoid f is the sequence of the sequence structure ~~~

Zygohistomorphisms in the context of Haskell monads illustrate a point that's been argued in much of the literature on monads: there is a lot of monadic behavior that's difficult to describe even on the most intuitive view of the field... and monads are not the only type of monad, or even a fundamental class of monads, so we should be able to get some pretty precise results. To demonstrate this, we have to introduce a sort of 'first-person' mode into one way of thinking about monadic behavior. This is in itself somewhat surprising, but I think it's very important to show up an example that does not only confirm what the authors said; it also illustrates the central problem with the theory of first-person monads.

Let's start with a simple example, which should be easy to understand: we have a function of type (Maybe v) => String. Here's why: ( v a1 x2 z1 ) ( a1 a2 x3 z2 ) ( a1 a2 x4 z3 ) is the same as : a1 { v a1}

the combinators have been lifted into a Monad , whose left arguments are Functor s. The latter are also passed across to , with Functor 's associated with a monad.

To give a good, familiar example, type H is a Functor , F is a Functor , and G a Functor. There are many good reasons to prefer type parameters to monad instances and arguments:

Type arguments make it easy to write more elaborate code and understand what's going on.

We rarely want to instantiate a type-parameterized function.

Fancy and often useful features like "inversion and composition" make type-checks and code reuse a joy.

If you need a type for a type-dependent functionality like the type-checker, it's often nice to know that there's a different type of type checker for functors and data types.

A Monad's identity function

There have been a few papers that propose ways to simplify the above reasoning. But none of them have really succeeded, because they're not good enough of a proof

A MonadicFold is a Fold enriched with access to the current monad State and Applicative , and uses MonadReader and MonadWriter . It provides an applicative interface to MonadReader , and allows you to create fold expressions:

import qualified Network.Data as NT >>> foldMap fmap = NT.foldMap fmap with foldMap fmap

An example of a typical pattern that we use for a fold:

import Network.State.Applicative f m = { return foldMap ((++) 1) m } import Network.State.Applicative f m = NT.foldMap fmap with foldMap fmap

If the current monad is State then

import NT.fmap import NT.foldMap

and State is an Applicative type. So is Applicative because :foldMap fmap<'a> is used to turn that into the fold expression that we need to apply. In fact all the fold expressions look exactly like the usual "compose" pattern we all know and love, just with this new syntax:

import NT.state.Applicative

A MonadicFold can use side-effects as well as data:

// an alias for ::A._::data A MonadicFold a = Monad.fold { a -> Some (x :: anInt) a }

To wrap a MonadicFold in a fold statement, we can wrap the whole type into a fold :

type Fold = Fold<'T, 'M> deriving (Eq, Show)

We could take a different approach and simply take every possible monadic argument and fold it to itself:

// The same example is shown with more variables f :: Monad m => MonadFold b m (Fold g) f x = Fold.foldl 1 . f x

One last bit to consider is when we want to define a function Fx which takes two monadic folds to return a fold:

def f (a1, b1): mst :: Maybe (Fold a1 b1) -> Fold a2 a1 b1 f x = a2 -- or more precisely, define a function which accepts an input fold: mst = f . mst (fold a2)

When f is used for the first or last step, we declare that we are transforming the inputs from F a1 to F a2 into a fold of some monadic function. In our F function, it will use the mst operation once to transform the two monadic folds into a simple function.

Fold Fold

Since fold takes f to return fold a2 to a flat fold a , for example, we define a function fmap like this:

def fmap (a, b): return (a * b)

And that fmap is a function of fold which takes monadic fold f , fmap a , b , and returns a function of monadic fold f :

fn map ( f : & fmap<_> , k : usize = 1 , g : & gmap<_> , j : usize = 1 ) -> map<_> { let f = match f with | map -> f ( mapk n ( * 0 . k)) | _ => { loop { g ( mapk 0 ) } } } }

Let's write a function to traverse over the first five elements of the array in order to build up the sum

fn sum ( arr : & [i32 ]) -> usize { for & i in arr { if i < 5 { arr [ i ] = 1 + i } } }

and try to figure out which elements are actually zero, which are negative, and that we're doing the right thing.

In that function we traverse over every element of the array and every character in it. For each iteration of the loop we create a copy of the array, and try to increment the hash variable at the desired hash position from there. In the following example, we are iterating over 5 arrays... 3 arrays 1 array 2 arrays 3 arrays... In this process, we need to do 2 passes to get the values back from the hash variable. So for each iteration of the loop there is a new hash value at a different position in each array. We call this pass iteration and use it for each line of code. For example, a pass of 5 iterations looks like this:
This is the result of our array traversal: So we know we will iterate over every element of the array in at least five iterations of it. By iterating that far the first few times we can increase the cache. We could take advantage of our cache by doing something like this: Each time you pass (increment) an array, create a new copy and return it. That creates a larger array which in turn is larger. So to create two arrays, I would simply set up a new instance each time we pass. But you can also make a batch pass, but with any change, the array will grow in size. You can run the batch pass again at the end of each iteration and take a copy of the current array with you. That gives you a way with loops, or any sort of concatenation of arrays to find out which is the smallest and is the largest.

To do an actual test in a functional style, here's an example:

Here's my example:

class Point < T extends Integer > extends T : Unit { def add = Boolean(self.self) } def min(t: Point, r) = add(t, r) def max(t: Point, r) = add(t, r) def add(t: Point, r) = Point.min(-1) def min2(t: Point, r) = Point.

There are no actual integers in Haskell, just strings and lists. That means that for any x you can create a function of any type, where any x equals all the integers x, and you get the original expression.

This means that there are no integers or lists outside the functions, which means that you can't create a function from any type to some other type using integers and lists.

Here are a few examples using ListT , Lists , and other functions:

List :: ( a -> b ) -> b -> a List xs = a + xs List ( x : xs ) = y + ( x : xs ) List ( x : xs ) = x : xs List ( xs : z ) = ( y : 1 + y ) + ( y : xs )

We can also create "generic" functions from any type (or an anonymous function):

f :: List f a = f a f x = x:x $ x : xs

This is the function to get the value of one string.

The result looks pretty similar:
val :: (a -> b -> c) a -> Val a b -> Val a c = val a val c = (val (c 2)) xs val c = (val . x, val . y, val . z) [] xs val . z = val . y val . z val . z = val x val ~ val ~ val . z val ~ val . xs val . x = val ~ . z val . xs val ~ val . y = val ~ . z val ~. y

The generic type parameter allows us to pass a value of any sort into every function; that is: in the generic instance form, we can pass any generic method which can be used on those generic values, and it won't matter what type the function actually comes from.