Notorious b.s.d. posted:

iostreams has a lot of problems but the builder pattern isn't the root of them

pseudorandom name posted:

I too like text output systems that cannot be localized.

Notorious b.s.d. posted:

let me turn this around for you.

leaving the loop implementation exactly the same, do you consider this an improvement?

code:

(#%%~ ^@!? 5 ^. x = 0 <<.= y ^. y = 1 <<.= (+ x y) %@~ y)

each of these is a real operator from that haskell library.

did moving to arbitrary non-words improve or hurt the readability of a perverse mis-use of a macro that neither of us likes?

Notorious b.s.d. posted:

there are plenty of ways to build a printf replacement that doesn't involve a second little macro language, unchecked by your compiler, inside string literals

but yeah a builder with inline strings has the notable downside of not easily changing the location of substitutions

Suspicious Dish posted:

Since I've never really written a line of Haskell here, is that how those operators are usually used?

I thought this was more of a domain-specific thing where you have:

x = (y #%%~ z)

AlsoD posted:

let's look at some real code, some of the worst examples from my game (well i call it that, it's barely at the stage where it's interactive)

code:

actions :: Float -> [(Key, State -> State)]
actions dt =
    [ (Char 'w', viewPort.vpTranslate._2 -~ 5  *dt)
    , (Char 's', viewPort.vpTranslate._2 +~ 5  *dt)
    , (Char 'a', viewPort.vpTranslate._1 +~ 5  *dt)
    , (Char 'd', viewPort.vpTranslate._1 -~ 5  *dt)
    , (Char '-', viewPort.vpScale        *~ 1-1*dt)
    , (Char '=', viewPort.vpScale        *~ 1+1*dt)
    , (Char 'r', const initialState)
    , (MouseButton LeftButton , setSelection      )
    , (MouseButton RightButton, moveSelectedPlayer)
    ]

"viewPort.vpTranslate._2" delves into a structure and then i modify its value using +,- or *. simple.

code:

handleInput :: Event -> State -> State
handleInput (EventKey k keyState _ _) s = s &
     keysDown . contains k .~ (keyState == Down)

in the field keysDown which is a set that contains the element k if the keyState is down

code:

handleInput (EventMotion xy) s = s &
    mouseOver ?~ invertViewPort (_viewPort s) xy

?~ is like .~ for a Maybe field i.e. (l ?~ x) is (l .~ (Just x))

Suspicious Dish posted:

Just curious, do you have any ideas for a localizable printf replacement?

funroll loops posted:

i mean idk since i dont use haskell at all, but maybe that's not so bad? at least the goofy operators are compositions of regular haskell operators, right? it seems like if you were comfortable with the regular syntax of haskell then you could piece together what the operators meant. this is actually why long names are good, you piece together the meanings of the whole from each individual word. often times you are trading inscrutable operators with jargon. the same with the loop macro or whatever. you derive the meaning from experience and context just like with anything else.

Notorious b.s.d. posted:

so because the rest of haskell is loving terrible, the abortions in the lens library are supposed to get a free pass?

coffeetable posted:

mathematical ideas are best communicated with prose. the notation's just there to a) provide rigour where plain english can't and b) so the reader doesn't have to invent their own notation when they themselves want to manipulate the ideas at hand.

Notorious b.s.d. posted:

there are plenty of ways to build a printf replacement that doesn't involve a second little macro language, unchecked by your compiler, inside string literals

but yeah a builder with inline strings has the notable downside of not easily changing the location of substitutions

Notorious b.s.d. posted:

double sulk posted:

haskell is useless

double sulk posted:

haskell is useless

double sulk posted:

haskell is useless

Notorious b.s.d. posted:

Notorious b.s.d. posted:

a second little macro language, unchecked by your compiler

vOv posted:

why are so many people unable to distinguish 'operator overloading' from 'defining your own infix operators'

vOv posted:

why are so many people unable to distinguish 'operator overloading' from 'defining your own infix operators'

funroll loops posted:

the intent is nearly the same, you just carry less baggage when you don't use the regular math ones

coffeetable posted:

the baggage is good though. if i overload (+) on my vector type, it is patently obvious to anyone reading what (u + v) is computing. conversely, the first seventeen times they encounter (u #!% v) they're going to have to toddle off to the documentation

Deus Rex posted:

Oh, and what does the overloaded (*) do on your vector type?

Deus Rex posted:

Oh, and what does the overloaded (*) do on your vector type?

coffeetable posted:

the baggage is good though. if i overload (+) on my vector type, it is patently obvious to anyone reading what (u + v) is computing. conversely, the first seventeen times they encounter (u #!% v) they're going to have to toddle off to the documentation

quote:

ofc, if you can labour under the assumption that anyone reading your code is already familiar with (#!%) and its effect on vectors, then it's absolutely fine to use (#!%). if lenses became ubiquitous throughout the programming world, it'd be fine to use them because as alsod says, there is a method in their madness and it doesn't take long to learn how to deduce what they do.

but very few people are familiar with lenses and that's not changing any time soon so~

motedek posted:

the lens operators ain't great but they're pretty much required knowledge to get a job in software these days

AlsoD posted:

and on the topic of punctuation let's talk about list comprehensions

haskell: [(x+y)^2 | x <- [0..10], y <- [0..10], even x, odd y]
python: [(x+y)^2 for x in range(11) for y in range (11) if x&2 if not (y&2)]

how does LINQ do it?

Deus Rex posted:

Oh, and what does the overloaded (*) do on your vector type?

pseudorandom name posted:

nothing, because you've overloaded ⨯ and ∙ instead

AlsoD posted:

oh god I wish I had (∘) instead of (.) in haskell. we've had the unicode sytax discussion before though

AlsoD posted:

we've had the unicode sytax discussion before though