lets talk Functional Programming. Is haskell based? What are some use cases?

I more so mean that “String = [Char]” was a terrible decision, those 32-biye chars are boxed by the way.
A linked list of 32-byte chars, all of them on the heap, to encode a string.

There's a good reason other functional languages such as Scheme and OCaml never did that but if you ask me String should be a typeclass, not a type which they did do for numbers so it's weird. Then again, I'm not sure why Haskell doesn't have a general Sequence typeclass either. It's obviously easy to define but there are many standard library functions that demand a list in particular that could work fine with any abstract sequence.

Strings as linked list is a terrible decision, but as said, make it a type class and give them both as lists or as constant time vectors.

to be fair, some "looser" versions of polymorphic sequences can already be approximated through existing typeclasses. Traversable and MonadPlus should let you do a lot of the things you want to do with sequences.

Have you met the monadic-bang gang?

monadic bang is neat for small examples but is also counterintuitive. for example:
setRef x "40" >> print !(readRef x)
doesn't do what you might think

>between Haskell, OCaml, Elixir which would you pick?
Clojure

clojure is cool but frankly it's stupid in a lot of ways

The "right" order isn't a consequence of the simple rule: do !(!mma) !mb = do ma <- mma; b <- mb; !ma b
We could transform the `>>` into `;` first.
With Ghc-8.4 LSP understood monadic bang until I split my project into multiple files. The newest GHC/LSP has no problems.

Yes, there you go, random “where” clause has to be made temporary binding, for what reason?

Now imagine breaking from a nested loop. It becomes unnecessarily messy very quickly for no good reason.

Did you try Control.Monad.Cont? I don't use it because mapMaybe or other functions from base and lens don't leave me reaching for deeply nested loops with break.

>But Idris is strict and still uses this IO Monad thing for effects. That's simply weird.
It's not weird. Monads are the most elegant way to handle side effects if you want a language that's lazy and/or referentially transparent. The Monad typeclass can be defined in just a few lines of code, and if you add a bit of syntactic sugar, you get a very general abstraction for things that can be sequenced together: I/O operations, parsers, async operations in coroutines, probabilistic computations, etc. Monads are so simple that anyone smart can understand them in 15 minutes, and so useful that people who come from Haskell often miss them in C# or Scala, and want to reinvent them. I find your insistence that they're complicated, difficult, and overengineered is ridiculous. You should go read a beginner Haskell book instead of inventing imaginary problems to justify things you don't understand.

>people who come from Haskell often miss them in C# or Scala
how are they missing in Scala?
Idk the exact definition and I don't care, but Option and Try work for all the use cases your cited. Using for comprehensions instead of do notation. Not that I use them cause you get 90% of the benefits of FP using map/filter/reduce and pattern matching...

>Option and Try
>for comprehensions instead of do notation
Congratulations, you just reinvented them with slightly different syntax
>Idk the exact definition and I don't care
Why argue about things you don't understand? You could just google the definition. I swear, the people on this website are getting more moronic by the year.

Anon, no, all of that can be done in a far simpler way by simply letting the type of the function dictate whether it can have effects or not.

Everyone understands monads, everyone understands GOTOs as well. Code written with monads quickly becomes completely unreadable without do-notation so that needed to be added at well and at that point what you're left with is simply the same syntax as in an imperative language, but less expressive.

Okay, so add do notation. What's the problem again? It seems that you really dislike monads but can't formulate any sensible argument against them, you just parrot that they're "overcomplicated" and other methods are "far simpler", which is obviously not true - monads are simultaneously simple and general, and I already pointed out that you can't have impure functions if you want your language to be lazy and/or referentially transparent.

monads also generalize to things like choice (lists as a monad), failure (maybe / either as a monad), and so on.
btw your example is moronic. you could just write
main = forever $ <CODE GOES HERE>

with forever being either imported or written as a one-liner such as
forever m = m' where m' = m *> m'
you can also import or define lots of other constructs as convenient.

Scala is the only relevant FP language and since Scala 3 it's based af.

If you want to do pure FP use ZIO and if you simply want to get shit done use Haoyis libraries which are now part of Scala Toolkit.

scala is irrelevant doe. it's also the troony of programming languages, as it's basically java pretending to be something like haskell. any decent haskeller can sense that there's something wrong with scala, and you can find several write-ups (for example, one from edward kmett) articulating this.

import System.IO

main = askName
where
askName = do
putStr "Please enter your name: "
hFlush stdout
name <- getLine
if name == "John" then
return name
else do
putStrLn "Your name is wrong, let's try again."
askName

Replace putStr for putStrLn if you don't want to flush buffer.

main = do
name <- let loop1 = do
putStrLn "Name?"
n <- getLine
if n == "John" then
let loop2 = do
putStrLn "Surname?"
s <- getLine
if s == "Doe" then
return (n ++ " " ++ s)
else do
putStrLn "Wrong (nested)."
loop2
in loop2
else do
putStrLn "Wrong"
loop1
in loop1
putStrLn ("Hello " ++ name)

import Control.Monad.Cont
import Control.Monad.IO.Class
import Control.Monad

main = do
let q prompt = liftIO $ do
putStrLn prompt
getLine
p = liftIO . putStrLn

name <- runContT `flip` return $ callCC $ exit -> forever $ do
n <- q "Name"
if n == "John"
then forever $ do
s <- q "Surname?"
if s == "Doe"
then exit (n ++ " " ++ s)
else p "Wrong (nested)."
else p "Wrong"
putStrLn ("Hello " ++ name)

And would you not agree that this is beyond unreadable compared to a simple nested break from a loop?

This is why Monads for effects are a bad idea.

What even is this code opposed to a simple labeled outer loop and a break to it. Even without labeled loops, checking a value to decide to break is much more readable than this monstrosity.

You can do my simple loop1-loop2 solution for readability like other languages or use the Cont monad which is a nuclear bomb to solve it (it solves problems beyond loops, like modeling functions that work with a ton of callbacks)

>unsafeInterleaveIO
delete this

a lot of imperative languages don't support breaking out of nested loops either :). probably for good reason, too. most nested loops are better done by having a single loop with the combined iterators from the two loops it replaces. other use cases would have to be judged separately to decide whether nested break would be readable

btw

import Control.Monad.Cont
import Control.Monad.IO.Class
import Control.Monad

main = do
let q prompt = liftIO $ do
putStrLn prompt
getLine
p = liftIO . putStrLn

name <- runContT `flip` return $ callCC $ exit -> forever $ do
n <- q "Name"
if n == "John"
then forever $ do
s <- q "Surname?"
if s == "Doe"
then exit (n ++ " " ++ s)
else p "Wrong (nested)."
else p "Wrong"
putStrLn ("Hello " ++ name)

is dunking on you for fun

by "you" in "this way you can make sense of it", I mean someone with basically zero haskell experience.

If you’re evaluating languages by jobs, stick to Python, JavaScript, and the POO languages.

Also, I never mentioned “streams” either as in what Miranda does. You're arguing against ghosts.

I said that it's far simpler to simply have the type system discriminate between pure and impure functions and enforce a constraint that:
>impure functions can call both pure and impure functions
>pure functions can only call other pure functions

That's it. Nothing else is needed. No streams, no monads, no uniqueness types.

Have you met the monadic-bang gang?

It works out nicely for mutable state that's contained within a single program, because the impurity can't escape outside the effect handler.
For example:
effect state<a> // declare color for mutable variable
fun get() : a
fun set( x : a ) : ()

fun sumdown( sum : int = 0 ) : <state<int>,div> int
val i = get()
if i <= 0 then sum else
set( i - 1 )
sumdown( sum + i )

fun state( init : a, action : () -> <state<a>,div|e> b ) : <div|e> b
var st := init
with handler
fun get() st
fun set(i) st := i
action()

fun main()
state(3){ sumdown() } // 6, state is contained in this call
state(10){ sumdown() } // 55, different state variable than before

External impurity like I/O is dangerous, yes. It's kind of like Rust's unsafe where the language holds your hand up to a point, but allows hiding impure I/O if you're naughty.
Generally, the idea is that everything requiring external impurity (e.g. I/O) is colored with the correct label and the effect handlers are near the main func.

That's so cool. Is the total/div checked by the compiler or deos it just trust the user?

>because the compiler isn't very good at recursion proofs.
It's the halting problem. The compiler literally cannot solve it. Do total functions recieve any beneftis?

See Koka for a good design of purity/impurity.
Koka also allows you to specify other function colors, such as async, total/diverging, throwing/noexcept.

>Perceus is an advanced compilation method for reference counting. Together with evidence passing, this lets Koka compile directly to C code without needing a garbage collector or runtime system. Perceus also performs reuse analysis and optimizes functional-style programs to use in-place updates when possible
I will now try your language

>A warning if your man has div
Anon... if main couldn't be div the language wouldn't be during complete.

It's the opposite that's obviously interesting, that a function is total, which can't be decided but in reverse, if the compiler can prove it then we know that function is total and that that part of the code thus doesn't contain the bug we might be searching for.

It's useful to avoid bugs to move divergent computations to as few functions as possible, it's like asking:
>What good does it do knowing for sure that 99% of the functions in the language can't lead to undefined behavior, and only 1% can which are marked as such.
You know that when you get a segfault that the problem can't be in the 99%.

just because the side effects are modelled with functions doesn't mean they are not pure. side effects only matter at execution time. this is the part you are not understanding. you still think in C unfortunately.

I bet you're the guy who was on here arguing that "monads" are just continuations (wrong). imagine thinking these things when the list monad exists. you don't want to learn anything or think differently.

>a high level language interfacing with low level stuff has to do hacks to abstract it
POSIX is a hack, not raw dogging your assembly is a hack. Everything is a hack. UGLY.

Uniqueness and monads are pure. Given the same computer state as input, and the computation continuation, the result will always be the same next state. The contents are impure, the state never repeats, the clock is always ticking, it may partially repeat and give similar results. Or maybe the PC gets hit by lightning and it gets fried and suffers the ultimate side effect and your square <total<int>> never returns.
>internally uses monads for effects
Ok.

The array mutating as an optimization is an implementation detail.
RealWorld can't be compared because it's abstract and it represents all the pointers and memory and all the runtime state of everything. The unit type represents that too. They could use an Int instead to represent a returned status code like C.
Clean's unique World is not just an optimization either, it enables optimizations and ensures purity.

>pure Haskell without requiring any compiler magic whereas the IO Monad requires special magical help from the compiler to implement and that one can't write one's own IO Monad and that it requires a magical RealWorld datatype internal to the compiler to work.
well duh, this is what an abstraction is. I suggest you read some of the papers by wadler and peyton jones back in the early 90s. it's not a hack, the language itself is pure. real world things can be modelled with mathematics.

https://dl.acm.org/doi/pdf/10.1145/158511.158524

Also, come to think of it, with machine random number generation from quantum uncertainties, which does exist, the “RealWorld” actually cannot model it any more. Referential transparency is truly lost there even in a hypothetical case where the entire state of the world were somehow stored into a datum, a ridiculous thing to begin with even without such true random number generation because even pseudo random number generation literally takes ambient air in the room the machine is standing on as input through temperature censors.

And it literally says:
>But what has become of’ the world values in the final
>C code? The world value manipulated by the program
>represents the current stat e of the real world, but since the
>real world is updated ‘(in ~Jace” the world value carries no
>useful information. Hence we simply arrange that no code
>is ever generated to move values of type World. This is
>easy to do, as type information is preserved throughout
>the compiler. In particular, the world is never loaded
>into a register, stored in ZL data structure, or passed to C

They're not doing the opposite of what you described. They're not modelling side effects by having a RealWorld datum, they're modeling a restricted form of RealWorld by having side effects.

RealWorld in the full form is strictly more powerful than mere side-effects because it can express storing and restarting states, examining the real world to see if the result be satisfactory, if not, then restart from a certain place and do it again to eventually arrive at the RealWorld one wants. This can't be done with RealWorld as an artifical uniqueness type where one can never get back to a prior state without having a function that could do so, and since all functions work with side effects, not with actually manipulating a RealWorld datum and one wan't unwrite lines to a terminal or undelete a file, such a function can't be made.

It's the opposite. It's not modeling side-effects with RealWorld, it's modeling a limited version of RealWorld with side effects.

Lisp was used for artificial intelligence and robotics in space with great success until C deposed it because the runtime was too fat.

>It makes sense for the Eq impementation to exist
>It's super simple to implement
totally wrong. The only sensible equivalence relation is functional equality, which is undecidable.

Those would, but in that system one doesn't have to constantly pass a RealWorld value around.
Yes, it's abstracted by monads, which are further abstracted by do notation but that Haskell needed an abstraction on top of an abtraction to make it remotely work shows how unwieldy and silly it is.

And even with all that, some of the example code is still verbose and ridiculous exactly because in some way that RealWorld datum needs to be passed around for every loop, every branch, every call. A unit type being passed through the entire program to simply be deleted by the optimizer at the end, all to stop it from ordering things out of sequence in earlier stages of optimization.

The difference is not having to pass RealWorld around all the time, however abstracted, creating unnecessarily verbose code for no reason.

My proposal would simply work like:

main () = sequence
let name = readLine ()
putStrLn $ "Hello, " ++ name ++ "!"

These are all simply effectful functions called with (). Of course they can't be called inside of pure functions on a type level but there is no need to rely on runCont madness to escape from a nested loop any more because there is no value RealWorld value that needs to leak.

It essentially functions the same as any other pogramming language.

It's ``po'', because it is free.

>yes of course, I love FlatMappabled error handling

Well, I do. Whatcha gonna do about it?

Straight white male here, frick trannies, they'll never be women, sneed.

Rust is an excellent language. The tooling is awesome. I don't miss C/C++ clusterfrick of ideologies and styles. Still use it for some stuff because Rust tooling doesn't support some exotic shit I work in, but otherwise link to Rust libs and all UI is in rust. Unironically started learning rust to hate it on it more effectively.

Its no bad at all. Kind of the "next step" in systems languages.

I have so far survived without ever joining that discord. No one I know who writes Rust is on that discord. Maybe just forget it exists and try writing rust with existing documentation and github examples. I think all the gender shock troops are contained at this point to their own club.

I don't know am I off base here? Who makes design decisions for the language? Everything seems more or less reasonable to me. If you disagree with something usually reading the history of why the decision was made clarifies the situation and makes sense. Whatever it is, its so much better than C/C++ cacophony of boomer design patterns.

slint (like a sane person)

No.

Sounds like something a shitskin would say

>if you hate my virtue signaling eyesore you're a <bigot | transphobe | shitskin>
you're just as insufferable as they are

It gets real old seeing a bunch of morons that can't find Ukraine on a map spouting slava ukraini every chance they get so they can show off what a good goy they are.

it's just as insufferable when they can find ukraine on a map.