Return Styles: Pseud0ch, Terminal, Valhalla, NES, Geocities, Blue Moon.

Pages: 1-4041-

Higher-kinded endofunctors

Name: Anonymous 2015-04-02 22:10

Higher-kinded type classes is what makes Haskell stand out above other functional languages for me. Things like endofunctors just cannot exist in virtually any other language.

Name: Anonymous 2015-04-02 22:38

get higher from kind bud

Name: Anonymous 2015-04-03 1:09

U MENA ENDOTENSORS

Name: Anonymous 2015-04-03 9:08

i'm allergic to word functor. It smells of academic jargon, type theory, category theory and function composition just to write a dumb app which doesn't even need this bullshit.
Higher kinded type class is probably attempt to typesafe "var" or emulate dynamic types.

Name: Anonymous 2015-04-03 9:18

>>4
You must be writing really dumb "apps" all the time if you don't even need function composition. I feel sorry for you.

Name: Anonymous 2015-04-03 10:11

Name: Anonymous 2015-04-03 10:28

>>5
Show a single useful example with function composition(not in haskell/Lisp) and i'll rewrite it to not use any composition.

Name: Anonymous 2015-04-03 10:50

>>7
Lol idiot, of course you can rewrite it without compositions, anyone can. The problem is it will look and feel like shit.

But here's an example anyway (in Scala):

def bbCodeB(in: String): String = rBold.replaceAllIn(in, (m: Match) => "<b>" + (m group "c") + "</b>")
def bbCodeUrl(in: String): String = rLink.replaceAllIn(in, (m: Match) => "<a href=\"" + (m group "add") + "\">" + (m group "c") + "</a>")
def bbCodeC(in: String): String = rCode.replaceAllIn(in, (m: Match) => "<pre>" + (m group "c") + "</pre>")
def bbCodeS(in: String): String = rStrike.replaceAllIn(in, (m: Match) => "<span class=\"s\">" + (m group "c") + "</span>")
def bbCodeSp(color: String, in: String): String = rSpoiler.replaceAllIn(in, (m: Match) => """<span class="sp"
onmouseover="this.style.color=#000000;" onmouseout="this.style.color=""" + color + """;">""" + (m group "c") + "</span>")
def bbCodeU(in: String): String = rUnderline.replaceAllIn(in, (m: Match) => "<span class=\"un\">" + (m group "c") + "</span>")
def bbCodeI(in: String): String = rItalic.replaceAllIn(in, (m: Match) => "<i>" + (m group "c") + "</i>")
def bbCodeNl(in: String): String = rNewline.replaceAllIn(in, "<br />")

def apply_bbCodes(color: String, inp: String): String = (
bbCodeUrl _ compose
bbCodeB _ compose
bbCodeI _ compose
bbCodeC _ compose
(bbCodeSp(color, _: String)) compose
bbCodeU _ compose
bbCodeS _ compose
bbCodeNl
)(rGT.replaceAllIn(rLT.replaceAllIn(inp, "&lt;"), "&gt;"))


I know it looks like shit already, but that's because

not in haskell/Lisp

Obviously, without function composition it will look like a horrendously huge shit.

Name: Anonymous 2015-04-03 11:39

>>8
Its equivalent to array of regexps with text, applied to text
var exp=[[/\[i\]/gim,"<i>"],[/\[/i\]/gim,"</i>"]]
function r(text){for(i in exp)text=text.replace(exp[i][0],exp[i][1])}

Name: Anonymous 2015-04-03 11:44

>>9
generic version
function r(text,exp){for(i in exp)text=text.replace(exp[i][0],exp[i][1])}

Name: Anonymous 2015-04-03 11:54

>>9
Arrays are an evil imperative data structure, they should be used as rarely as possible.

Name: Anonymous 2015-04-03 12:13

>>11
That was Paul Graham tier post. Tell me more about the universality of lists.

Name: Anonymous 2015-04-03 17:47

FP is the way forward
OOP has 23 design patterns and most of them suck.
FP has two design patterns that compose very well.
● Noun: immutable data. Easy to create and inspect, won’
t change.
● Verb: referentially transparent functions. Easy to define
correctness and to reproduce results.
Even this separation’s artificial: “verbs” double as “nouns”.

https://docs.google.com/presentation/d/1a4GvI0dbL8sfAlnTUwVxhq4_j-QiDlz02_t0XZJXnzY/preview?sle=true#slide=id.g2f187353a_011

Name: Anonymous 2015-04-04 6:14

immutable data
So to replace all 'a's 'b's and 'c's you need to malloc 3 strings?
referentially transparent functions
pass-by-reference is immensely useful,pass-by-value is introducing copies and extra variables.
using globals and global state is the most efficient way.

Name: Anonymous 2015-04-04 9:32

>>14
So to replace all 'a's 'b's and 'c's you need to malloc 3 strings?
No. The three traversals may be easily fused into one.

pass-by-value is introducing copies and extra variables.
In Haskell all functions are pass-by-reference because with immutability you don't need anything else.

using globals and global state is the most efficient way.
The most efficient way to create undebuggable spaghetti with errors constantly springing up out of nowhere? Yes.

Name: Anonymous 2015-04-04 9:35

>>14
In fact, immutability is so good for what you call "pass-by-reference", that values may be safely shared. For example, here's the memory layout of a Haskell list with some equal elements:

http://code.haskell.org/~dons/images/vacuum/tuple-list.png

Name: Anonymous 2015-04-04 10:59

Whatever it is in haskell, immutable structure mean you need to construct a new one EACH TIME the structure changes.
Which rules out most dynamic datastructures, thus making Haskell unusable for practical apps.

Name: Anonymous 2015-04-04 11:02

The cult of functional programming

Name: Anonymous 2015-04-04 11:51

>>17
Consider a tree. Are your mental abilities sufficient to imagine a tree? If so, consider what part of a tree needs to be reconstructed when one of its leaves changes. The answer: only the spine leading to that leaf. I.e. a change in a leaf requires reconstruction of only that leaf plus ~log n spine elements (pointers). Yes, that is right: all the (n - 1) leaves plus all the (n - log n) spine elements can be safely shared between the updated structure and the original one. Thus, "most dynamic datastructures" are far frome ruled out in Haskell; they are used widely and fruitfully.

Read Okasaki's book about purely functional datastructures if you don't want to keep being an uneducated imperative bigot.

Name: Anonymous 2015-04-04 12:34

>>19
They are either 1.Violating the "pure functional autism"(most likely, as unsafePerformIO popularity shows) 2.simulate dynamic structures with deep/local copies of data, "safely sharing" duplicate data or both(as your post implies).
I won't read academic abstract bullshit thats useless in real life. All thats useful and practical in haskell is already done better by imperative, structured and OOP languages.

Name: Anonymous 2015-04-04 13:34

>>20
Hah. Enjoy being an ignorant, outdated bigot. That's right, you're outdated - all the newer popular languages like Clojure, Scala and Rust are going more and more immutable. People who use global mutable state and mutable updates will go the way of the dinosaur.

Name: Dino dubs 2015-04-04 13:37

Dino dubs

Name: Anonymous 2015-04-04 13:44

All thats useful and practical in haskell is already done better by [...] OOP languages.
IHBT

Name: Anonymous 2015-04-04 13:47

and mutable updates will go the way of the dinosaur.
People said same things about GOTO.

Name: Anonymous 2015-04-04 14:00

>>24
And guess what? Nobody uses GOTO anymore. Coincidence? I think not.

Name: Anonymous 2015-04-04 14:11

>>25 Yeah, i agree only fortran and old basic users continue, everyone else moved to goto.

Name: Anonymous 2015-04-04 14:17

>>26
What were you even trying to say, drunkard?

Name: Anonymous 2015-04-04 14:27

>>25
Nobody uses GOTO anymore

...

you've never seen anyone elses code have you?

Name: Anonymous 2015-04-04 14:31

>>28
Alright, some bad programmers and irresponsible rednecks might still be using GOTO. But they get kicked off any team that cares about the quality of their product.

Name: Anonymous 2015-04-04 14:47

>>29 Being an enterprise code monkey must be suffering.

Name: Anonymous 2015-04-04 15:19

>>29
I always try to include at least one goto just to piss off people like you.

Name: Anonymous 2015-04-04 15:32

import Control.Monad.Cont -- mtl

data Void = Void !Void

absurd :: Void -> a
absurd (Void v) = absurd v

vacuous :: Functor f => f Void -> f a
vacuous = fmap absurd

data LabelT r m = LabelT (ContT r m Void)

label :: ContT r m (LabelT r m)
label = callCC $ \k ->
let
l = LabelT $ k l
in return l

goto :: LabelT r m -> ContT r m a
goto (LabelT l) = vacuous l

usesGoto :: (Monad m) => ContT r m r -> m r
usesGoto = flip runContT return

Name: Anonymous 2015-04-04 15:35

Name: Anonymous 2015-04-04 15:36

Name: Anonymous 2015-04-04 16:11

>>32
Yes, the Cont monad can be used to implement GOTO (after all, undelimited continuations are a glorified GOTO). So what? Nobody in their right mind uses it.

>>34
Implementing tail-call optimizations is like implementing loops in an imperative language - it requires GOTO specifically so that any programmer using TCO/loops does not need to use GOTO. That's called "structured programming", you know - use correct high-level structures guaranteed to limit spaghetti instead of raw low-level GOTO that will make you shoot yourself in the foot.

Name: Anonymous 2015-04-04 16:21

>>35
Take 2 minutes to learn some basic gun safety and you won't have to worry about your feet.

Name: Anonymous 2015-04-04 16:24

>>36
GOTO does not have any safety rules, it makes code pretty much impossible to reason about. Surprised I have to explain such basic truths on a programming forum.

Name: Anonymous 2015-04-04 16:24

>>35
great, now consider a case when you didn't have goto when "it requires GOTO specifically " because a person just like you deemed it harmful and excluded from the language.

Name: Anonymous 2015-04-04 16:26

>>38
Even if it's still in left in some languages, 99% of professional programmers do not use it.

Name: Anonymous 2015-04-04 16:31

>>39
Oh yeah? Look at the disassembly.

Name: Anonymous 2015-04-04 16:34

>>40
Do not use it directly, mister Hair-Splitter.

Name: Anonymous 2015-04-04 18:40

What a stupid discussion in a stupid thread, on a stupid board. What a stupid use of my time it is for me to read this. And to post this response.

Name: Anonymous 2015-04-04 18:49

>>42
And the most stupid post in this thread is yours because completely off-topic and useless. Fuck you.

Name: Anonymous 2015-04-04 19:08

>>43
Any off topic post in this thread could not be as stupid as the thread itself, nor the posts that are contained within its stupid topic.

Name: Anonymous 2015-04-04 19:50

>>44
Behold, these are the Dubs of Error.

Don't change these.
Name: Email:
Entire Thread Thread List