Stop pretending studying arrow theory improves your apping

Given two functors S,T:C→B, a natural transformation τ:S→T is a function which assigns to each object c of C an arrow τ_c=τc:Sc→TC of B in such a way that every arrow f:c→c' in C yields a diagram
ﾠﾠﾠﾠﾠﾠﾠﾠﾠﾠﾠτc
c ﾠﾠ Sc---→Tc
|ﾠﾠﾠﾠﾠﾠﾠﾠ|ﾠﾠﾠﾠﾠﾠﾠ|
|fﾠﾠﾠﾠﾠSf↓ﾠﾠﾠﾠﾠ↓Tf
↓ﾠﾠﾠﾠﾠﾠﾠ|ﾠﾠτc'ﾠﾠ|
c', ﾠﾠﾠ Sc'--→Tc'

which is commutative. When this holds, we also say that τ_c=τc:Sc→Tc is natural in c. If we think of the functor S as giving a picture in B of (all the objects and arrows of) C, then a natural transformation τ is the set of arrows mapping (or, translating) the picture S to the picture T, with all squares (and parallelograms!) like that above commutative:
ﾠaﾠﾠﾠﾠﾠﾠﾠﾠﾠﾠSa----------→Ta
ﾠ|ﾠ╲fﾠﾠﾠﾠﾠﾠﾠ ﾠ|ﾠ╲Sfﾠﾠﾠﾠﾠﾠﾠﾠﾠ|ﾠ╲Tf
ﾠ|ﾠﾠﾠ↘ﾠﾠﾠﾠﾠﾠﾠ|ﾠﾠﾠ↘ﾠﾠﾠτbﾠﾠﾠ|ﾠﾠﾠ↘
ﾠ|ﾠﾠﾠﾠﾠbﾠﾠﾠﾠ ﾠ|ﾠﾠﾠﾠSb----------→Tb
ﾠ|ﾠﾠﾠ╱ﾠﾠﾠﾠﾠﾠﾠ|ﾠﾠﾠ╱ﾠﾠﾠﾠﾠﾠﾠﾠﾠ|ﾠﾠﾠ╱
↓ﾠ↙ﾠﾠﾠﾠﾠﾠ ﾠ↓↙Sgﾠﾠﾠﾠﾠﾠﾠﾠ↓ﾠ↙Tg
ﾠcﾠﾠﾠﾠﾠﾠﾠﾠﾠﾠSc----------→Tc

>>1
But how will programmers justify the money and effort spent for
a CS degree?

Nice commutative diagram, nigger.

Only retards major in CS to find out "math is useless and too hard" and start apping epic webcodes in Javashit. Are you one of them, >>2-san?

but its ~MATH~

you're just too stupid to understand the value of it.

Fucking philistine. I have downloaded about 300 category theory PDFs that were recommended to me on IRC so I know what I'm talking about.

EPIC CATEGORY THEORY INJOKE:

When Mac Lane and Eilenberg shuffled off this mortal coil it rendered them both initial and terminal in the category of category theorists.

Natural transformations are kindergarten category theory. There's nothing difficult about them.

apping

I like it. I like it a lot.

It doesn't improve apping, but it does improve programming.

>>8

baseless claims

get the functor out of here

>>9
Who are you quoting?

>>9
Or else what, you'll overfill the thread with the pain of a dumbass who cannot into category theory?

Smug Haskell Weenies ITT

>>4
If you hate math so much, please implement a physics engine or a 3D software renderer that doesn't use any math and uses these epic Javashit promises of yours, kind broapper.

Your ``ironic'' statement is not funny and you're a massive retard.

IHBT

>>13
You don't seem to be getting it.. there's math that is relevant and useful to a given problem and math that isn't.

There is mathematics generalized enough that the very basic definitions from it can be applied to anything: because it's "math" most people are too scared to question it but it's basically snake oil - it is completely useless for programming.

People have been writing physics engines for years using linear algebra and numerics. Trying to shoehorn yonedas lemma, topos theory and comonadics in doesn't improve the software. It's pointless they just do it to sound smart.

>>14
In that case, I agree with you. Sorry for making wrong assumptions.

Though there's nothing wrong with Haskell or category theory, I do believe some academics have too much fun wanking over this. That said, gonads are not a bad idea.

>>15
There is a lot wrong with haskell as a community and the language is being destroyed but the new crowd. Their watered down version of category theory is also quite sad.

monads are important in programming but I'm always surprised how bad haskell programmers are with them and transformers. It's pretty distressing.

I was just checking earlier if there was a nice persistent data structure on hackage and the first one I looked at uses unsafePerformIO.

>>16
Quite honestly, I can't think of a programming language community that's not absolute horse shit.

>>1
Your diagram doesn't even render on Firefox and it renders like crap on Chrome.

-- | "Fuse" a 'Traversal' by reassociating all of the '<*>' operations to the
-- left and fusing all of the 'fmap' calls into one. This is particularly
-- useful when constructing a 'Traversal' using operations from GHC.Generics.
--
-- Given a pair of 'Traversal's 'foo' and 'bar',
--
-- @
-- 'confusing' (foo.bar) = foo.bar
-- @
--
-- However, @foo@ and @bar@ are each going to use the 'Applicative' they are given.
--
-- 'confusing' exploits the 'Yoneda' lemma to merge their separate uses of 'fmap' into a single 'fmap'.
-- and it further exploits an interesting property of the right Kan lift (or 'Rift') to left associate
-- all of the uses of '(<*>)' to make it possible to fuse together more fmaps.
--
-- This is particularly effective when the choice of functor 'f' is unknown at compile
-- time or when the 'Traversal' @foo.bar@ in the above description is recursive or complex
-- enough to prevent inlining.
--
-- 'Control.Lens.Lens.fusing' is a version of this combinator suitable for fusing lenses.
--
-- @
-- 'confusing' :: 'Traversal' s t a b -> 'Traversal' s t a b
-- @
confusing :: Applicative f => LensLike (Rift (Yoneda f) (Yoneda f)) s t a b -> LensLike f s t a b
confusing t = \f -> lowerYoneda . lowerRift . t (liftRiftYoneda . f)
where
liftRiftYoneda :: Applicative f => f a -> Rift (Yoneda f) (Yoneda f) a
liftRiftYoneda fa = Rift (`yap` fa)
{-# INLINE liftRiftYoneda #-}

yap :: Applicative f => Yoneda f (a -> b) -> f a -> Yoneda f b
yap (Yoneda k) fa = Yoneda (\ab_r -> k (ab_r .) <*> fa)
{-# INLINE yap #-}

{-# INLINE confusing #-}

>>19

\f -> lowerYoneda . lowerRift . t (liftRiftYoneda . f)

\f -> t (f >>> liftRiftYoneda) >>> lowerRift >>> lowerYoneda

I prefer Haskell as imperative language even without lenses. I write quite a bit of networking/runtime system/concurrent code, so it's basically lots of IO all over the place and programs really nicely.

I think lots of people somehow get convinced that IO should be avoided at all cost, but very imperative and IO heavy coding in Haskell is really pleasant in my experience. You still get to have the type system, ADTs/pattern matching, and having first-class IO is also lovely.

dubs get

bump ebin thread XD toasting

>>13
It's easy. Just move the objects around. If they touch, then nudge them around and stuff. Just ++ their position until they don't touch anymore. Problem solved.

>>21

lovely

I like it when you use this word.

>>21
So why aren't you using OCaml?

>>26
OCaml's deficiencies are too numerous to list.

>>27
Compared to Haskell? You must be joking.

>>28
IO is not first-class. In Haskell, it is. OCaml -100 : 100 Haskell. Need I go on?

>>29
Yes.

>>30
OCaml does not support addition of numbers:

val a = 1.2
val b = 2
a + b (* illegal in OCaml *)

Simple single-delimiter single-line comments is another useful thing OCaml doesn't support.

-- OCaml can't do this

Read more here:
http://flyingfrogblog.blogspot.ru/2010/08/rise-and-fall-of-ocaml.html

>>31
OCaml is strongly typed, film at 11.

The blog post is too old. Everything it mentions has seen change since then.

>>32
Are you saying that OCaml finally supports multicore dubs checking routines?

>>32
Haskell is "strongly typed" too, yet it supports the addition of numbers.

No it hasn't.

Following a discussion on this thread, telling me that I was abusing tuples, I decided to post a separate question about giant tuples or an alternative to (R) data-frame. When I say giant tuples, I mean from 5-uples, to 50-uples+ ;-).

The general consensus seems to be that tuples should be avoided (especially long one) and (R) data.frame smells of bad design, therefore any related question are usually not considered as real world and as such does't come up with a "real world" asnwer . However I have a real case scenario where giant tuple/record is a necessity : generating corporate reports using Word (or equivalent).

An easy way to generate nice reports is to use Word and its mail merging feature. For people how doesn't know, you create a template document with fields and feed Word with a csv. Word instantiate the templates for each row, each field being a column in the csv.

So far so good, most of the reports are just map-reduce problems, seems an easy job for Haskell. The problem is , a simple report would have a minimum 20 fields, whereas a big one could have 50-80 fields, meaning as many column in a csv.

How do you deal with that in Haskell ? I know people will just answer : "create a big record with all you fields and the job is done" and that's probably the answer, however the workflow I'm use to (which is probably ) needs more flexibility.

I started writing those report in Excel. The workflow is basically, load a csv, and each time you need to compute something, create a new column (even intermediate results). Keeping intermediate result (as a column) is a good practice because it means than formula are shorter and if something gets wrong, you can easily find problem and/or rewrite formulat.

However, doing things manually becomes quickly a pain so I then used R. R with data.frame is great an allow to replicate this workflow. For people how doesn't R, data.frame basically a table (as in SQL or in a excel spreadsheet). They have rows, (named) columns and you can do everything you need with them (adding row, adding column, join them) etc ...

You can do things like that :

data1 <- read.csv(file1) -- read a csv
data2 <- read.csv(file2) -- read another csv
data <- merge(data1, data2) -- do a join using common columns
data$q6 = roundTo(data$quantity, 6) -- round up quantities to multiple of 6.
data$amount = data$q6*data$price -- great a new column : amount = price*q6

It's damm quick to write and you can't really beat it. However, 6 months later you have no idea how many columns data has, and worst, you don't know if quantity is coming originaly from file1 or file2.

I'm trying to do the same in Haskell. Reading a csv is easy. Merging them too (thanks to the these package. The main problem is data representation.

What's is hard to do in Haskell (but easy in R) is that each intermediate calcul (or steps) creates a new shape by extending the previous one.

For example

data1 would be (String, Int) (item code, quantity).
data2 would be (String, Double) (item code, price). the result of merge(data1,data2) , (String, Int, Double). when adding q6 : (String, Int, Double, Int). when adding amount : `(String, Int, Double, Int, Amount).

etc ...

This type extension ((String, Int, Double) => (String, Int, Double, Int) => (String, Int, Double, Int, Double) is needed for different reason and is the problem I would like to solve.

The different approach I found are, tuples, records, HList.Record and dataframe ?
tuples

Tuples are great mainly because you don't need to create a type but also because they come batteries including ie instantiate all the standard typeclass (like Monoid, csv reader etc ...). However, they don't compose well (how do you transform ((a,b), c) to (a, b,c), they are a pain to get/set value from , and worst, the common instances have a limit and each packages as it's own limit. For example, the morph package instantiate HFoldable for 13-uple whereas Monoid stops as 5-uples.
Record

I've been told that types are cheap in haskell, so I could indeed creates a new type for each steps. The main problems here are : instanciation of common typeclass (Monoid, fromCSv etc ..) and find a good name for each type variation (and their accessors).
Record with polymorphic tail

It's probably equivalent to HList.Record ...
HList.Record

HList.Record seems to tick all the boxes, they are extendable, easy to access etc ... However, I don't how well the perform with LOTS of fields. And, my main concern at the moment, is type signature. The type signature of a HList.Record with 10 fields would probabaly not fit in a page.
DataFrame

I've heard of a dataframe package but I don't know if it's ready and or is really different from the HList.Record approach.

Any thought are welcome :-)

>>35
Fix Your Formatting.

>>34
You can add numbers in OCaml. It doesn't do implicit conversions for you because that is some weakass shit right there.

No it hasn't.

If Haskell sucks so hard you need to deny reality to support your choice that's your problem.

I don't get why people even bother with Haskell when things like Idris exists. You might as well take advantage of the code inference and so on.

>>37
There's nothing implicit in the example I've posted. One number is obviously an integer, the other is obviously floating-point. It's OCaml's fault that it can't add them.

Oh and you haven't posted any proof that OCaml's multicore support has been improved.

There's nothing implicit in the example I've posted.

More lies. There's an implicit type mismatch (or domain error if you prefer.)

Oh and you haven't posted any proof that OCaml's multicore support has been improved.

I'll play Google for you once you prove a single one of your ridiculous claims.

>>39

There's an implicit type mismatch

There is no type mismatch. Addition works only on operands of the same type. It is impossible to add an int to a double using the regular (+) method - you would have to make explicit casts. And yet this works:

Prelude> let x = 1.6
Prelude> let y = 2
Prelude> x + y
3.6