I too can't help but chuckle at some of the substance less commentary at HN, where chuckling is a substitute for inability to contribute anything to a discussion.
I too can't help but chuckle at some of the substance less commentary at HN, where chuckling is a substitute for inability to contribute anything to a discussion.
The last time there was someone chuckling, I was way more civil.
do
x <- a
y <- b
return (f x y)
isn't basically imperative syntax ?
hint: if you can get from it to C (or pascal or python or whatever) simply by adding a couple types, semicolons and replacing operators, it's C. let x = a
y = b
in (f x y)
? Which in turn is very much like OCaml syntax or plenty of other functional syntaxes.This could be doing any one of:
- flatmapping over lists
- doing a computation with Maybe types, producing Nothing if a or b are nothing
- doing IO
- managing futures
- pretty much anything, actually
Don't confuse 'x <- a' with assignment, or 'return' with returning a value.
Another way of looking at it, (f x y) might be invoked:
- once
- never
- more than once
- later
hint: you are wrong.
It isn't "almost C-like syntax", unless you define that to mean "if I do any amount of search and replace I can make it into valid C code that has completely different semantics". "x <- a" in haskell is not at all the same as "x = a" in C.
And that isn't the reason I said your comment is wrong. Your comment is wrong because do notation is not the result of "40 years of research in functional PL", nor is it an accomplishment. It is simple syntactic sugar that didn't come from research at all.
Your comment could be accurately summarized as "I would like to express how smug I feel for not learning something".
are you kidding me ? if a 2016 paper from Simon Peyton Jones isn't research then what is ? (https://dl.acm.org/doi/pdf/10.1145/3241625.2976007)
But your chuckle has shown me that this code is just plain old C, with links to documents you haven't even read. Thank you for enlightening me, great chuckler.
Here is some basic reading material for you. Lets see if you can follow this
https://hackage.haskell.org/package/async-2.2.2/docs/Control...
do a1 <- async (getURL url1)
a2 <- async (getURL url2)
page1 <- wait a1
page2 <- wait a2
This implements async await in Haskell via a library using Monads. Hint: you cannot do this in C via any library. You need to modify the language. If you are uneducated about Monads, you might think this is similar to some kind of C code. It is not!Here is the same do syntax being used to parse source files instead of doing async/await IO. Yes this parser will also perform backtracking etc, which will not be obvious to anyone who thinks this is some kind of transliteraton of C
https://markkarpov.com/tutorial/megaparsec.html
mySequence :: Parser (Char, Char, Char) mySequence = do
a <- char 'a'
b <- char 'b'
c <- char 'c'
return (a, b, c)
Hint: If you want to do something like this in C, you use yacc/bison, a parser generator tool - there is no library. And it is fucking ugly.Hint 2: There are monads for parsing, async IO, exceptions, nondetermenism, monte carlo .........
Hint 3: The parser libraries are 25 years old.
Hint 4: Monad libraries represent less than 1% of PL research over the last 40 years.
Hint 5: C# LINQ is basically a Monad.
Hint 6: When confronted with something you don't understand, it is better to be quiet instead of opening your mouth and advertising your ignorance.
Hint 7: If your conversational style consists of chuckling and providing "Hints", be prepared for receiving a taste of the same medicine.
> This implements async await in Haskell via a library using Monads. Hint: you cannot do this in C via any library. You need to modify the language. If you are uneducated about Monads, you might think this is similar to some kind of C code. It is not!
it's still pretty much
> almost C-like syntax once again.
at no moment, not a single time, did I say in any way that I was talking about semantics but this is apparently a hill you wish to die on... so, by all means have fun !
Maybe you'll be more convinced by the exact text of the paper that introduced do-notation though ?
http://citeseerx.ist.psu.edu/viewdoc/download?doi=10.1.1.11....
let me quote it :
> Using monads gives functional programming an imperative flavour. Gofer supports a, so called, do notation which makes this imperative flavour more apparent.
or, let me rephrase that whole thing for you in a language that you seem to speak quite fluently:
class BasicallyC m where
(>>=) :: m a -> ( a -> m b) -> m b
(>>) :: m a -> m b -> m b
return :: a -> m a
fail :: String -> m a
class BasicallyC m => ImperativeFlavour mYou also failed to show how parser combinator grammars such as yacc/bison/BNF forms are basically just imperative code.
Monads model effect systems; not imperative code.
I am impressed by your ability to argue about stuff you know nothing about, and linking to papers and documents you can't even read. Have you considered running for US president?
but async / await is semantics, not syntax, thus completely irrelevant to the conversation. you want an example of building async / await into the syntax of C as a library ? tada !
void* async(...) { return NULL; }
void await(void* ptr) { }
int main(int argc, char** argv) {
void* handle = async(printf("foobar"));
await(handle);
}
or maybe you would prefer the more "modern" version, still compatible with pure C89 syntax though ? #define async
#define await (void)
int main(int argc, char** argv) {
auto x = async printf("foobar");
/* wow, you can even compose it ! */
auto y = async 2 * x;
await x;
}
please go on, this is super entertaining !This thread is silly.