< 1541980820 327378 :danieljabailey!~danieljab@cpc75709-york6-2-0-cust725.7-1.cable.virginm.net JOIN :#esoteric < 1541981210 797053 :ais523!~ais523@unaffiliated/ais523 JOIN :#esoteric < 1541981224 988228 :ais523!~ais523@unaffiliated/ais523 PRIVMSG #esoteric :@messages? < 1541981225 291096 :lambdabot!~lambdabot@haskell/bot/lambdabot PRIVMSG #esoteric :Sorry, no messages today. < 1541981237 477701 :shachaf!~shachaf@unaffiliated/shachaf PRIVMSG #esoteric :his523 < 1541981257 146711 :ais523!~ais523@unaffiliated/ais523 PRIVMSG #esoteric :hi < 1541981278 896317 :ais523!~ais523@unaffiliated/ais523 PRIVMSG #esoteric :any progress on the fixed point of Codensity? < 1541981293 869976 :shachaf!~shachaf@unaffiliated/shachaf PRIVMSG #esoteric :I was going to ask you the same thing. < 1541981303 844949 :shachaf!~shachaf@unaffiliated/shachaf PRIVMSG #esoteric :No, I didn't think about that type much since last time. < 1541981349 492047 :shachaf!~shachaf@unaffiliated/shachaf PRIVMSG #esoteric :I think not satisfying the monad associativity law might not be so bad. < 1541981356 225077 :shachaf!~shachaf@unaffiliated/shachaf PRIVMSG #esoteric :You just don't call your thing a monad. < 1541981461 88386 :shachaf!~shachaf@unaffiliated/shachaf PRIVMSG #esoteric :The alternative is to explicitly make your code into a tree with "bracket $ do { ... }" calls. I think bracket is quite similar to reset from delimited continuations. < 1541981580 546954 :shachaf!~shachaf@unaffiliated/shachaf PRIVMSG #esoteric :By the way, I said earlier that C mutable types were similar to e.g. refs in SML, but there's an important difference: If you have a ref containing a pair, you can't in general get a ref to each of its components. < 1541981591 424481 :shachaf!~shachaf@unaffiliated/shachaf PRIVMSG #esoteric :Is there a language with explicit refs that does allow that? < 1541981654 881486 :ais523!~ais523@unaffiliated/ais523 PRIVMSG #esoteric :shachaf: the "how do you contrast elements of the pair with the pair itself" question is really, really complex < 1541981670 888785 :ais523!~ais523@unaffiliated/ais523 PRIVMSG #esoteric :and conflating them is one of the most common mistakes made in theoretical computer science < 1541981676 70103 :ais523!~ais523@unaffiliated/ais523 PRIVMSG #esoteric :I had to write quite a bit in my thesis about it < 1541981692 182823 :shachaf!~shachaf@unaffiliated/shachaf PRIVMSG #esoteric :The situation in C is more complicated than I would've thought. < 1541981696 155808 :ais523!~ais523@unaffiliated/ais523 PRIVMSG #esoteric :unfortunately, this /specific/ question isn't one of the ones I have a ready-made answer to, and I don't want to throw out an answer quickly because experience shows that any simple answer here will probably be wrong < 1541981710 13751 :shachaf!~shachaf@unaffiliated/shachaf PRIVMSG #esoteric :C has two "." operators for field access, one for lvalues and one for rvalues. < 1541981774 688776 :shachaf!~shachaf@unaffiliated/shachaf PRIVMSG #esoteric :If read : LValue a -> RValue a, then read(lval.x) = read(lval).x, so it's easy to confuse them. < 1541981809 656860 :ais523!~ais523@unaffiliated/ais523 PRIVMSG #esoteric :the basic issue wrt pairs can be seen by trying to access both halves of the pair; is that a) a single operation that decomposes a pair into its two halves, or b) two operations, each of which reads one half of a pair? < 1541981841 835346 :shachaf!~shachaf@unaffiliated/shachaf PRIVMSG #esoteric :I wish I knew a good language that doesn't have lvalues. < 1541981847 530343 :ais523!~ais523@unaffiliated/ais523 PRIVMSG #esoteric :if you're counting how many accesses are made to something (in my thesis, this came up wrt affine typing, but `volatile` is a more familiar example), the distinction is really important < 1541981855 4440 :ais523!~ais523@unaffiliated/ais523 PRIVMSG #esoteric :shachaf: but does have mutable variables? < 1541981866 924171 :zzo38!~zzo38@24-207-47-161.eastlink.ca PRIVMSG #esoteric :Do you know BLISS? < 1541981868 158095 :shachaf!~shachaf@unaffiliated/shachaf PRIVMSG #esoteric :No, just pointers/references. < 1541981879 483307 :shachaf!~shachaf@unaffiliated/shachaf PRIVMSG #esoteric :zzo38: BLISS and ALGOL 68 are the two answers I know to this question. < 1541981894 863342 :zzo38!~zzo38@24-207-47-161.eastlink.ca PRIVMSG #esoteric :OK < 1541981901 429161 :ais523!~ais523@unaffiliated/ais523 PRIVMSG #esoteric :shachaf: well, a reference to an immutable value is normally very hard to distinguish from the value itself < 1541981936 996862 :shachaf!~shachaf@unaffiliated/shachaf PRIVMSG #esoteric :"volatile" seems like a weird thing to have as a property of a variable. < 1541981938 220364 :ais523!~ais523@unaffiliated/ais523 PRIVMSG #esoteric :the only difference is that if the value is deallocated, the reference becomes invalid, but deallocation is effectively a form of mutation < 1541981949 716791 :shachaf!~shachaf@unaffiliated/shachaf PRIVMSG #esoteric :It seems much more like it should be a property of the read/write operation on the variable. < 1541981967 156771 :ais523!~ais523@unaffiliated/ais523 PRIVMSG #esoteric :shachaf: well, from a mathematical point of view, it's simplest to initially treat everything as volatile and then potentially allow for optimisations that change the number of reads on something < 1541981988 878970 :ais523!~ais523@unaffiliated/ais523 PRIVMSG #esoteric :I can see an argument to have a volatile version of lvalue and of rvalue dereferencing, though < 1541982002 281186 :ais523!~ais523@unaffiliated/ais523 PRIVMSG #esoteric :hmm… half the complexity of lvalues would be simplified if they /couldn't/ be read < 1541982012 756191 :ais523!~ais523@unaffiliated/ais523 PRIVMSG #esoteric :that'd be a pretty weird language, though < 1541982017 969242 :shachaf!~shachaf@unaffiliated/shachaf PRIVMSG #esoteric :read, read_volatile : Ptr a -> a < 1541982037 944187 :ais523!~ais523@unaffiliated/ais523 PRIVMSG #esoteric :int X {get; set}; setX(4); setX(getX()+1); < 1541982087 318200 :ais523!~ais523@unaffiliated/ais523 PRIVMSG #esoteric :I don't see any particular reason why this style of programming wouldn't work, and it's a lot clearer than many others (and it's more or less how object-oriented program treats exposed variables, although probably for a different reason) < 1541982115 792517 :ais523!~ais523@unaffiliated/ais523 PRIVMSG #esoteric :now pass-by-reference is accomplished via passing the setX or getX /function/ by value < 1541982116 957218 :shachaf!~shachaf@unaffiliated/shachaf PRIVMSG #esoteric :I think maybe C++ was making a change like that? < 1541982129 493656 :ais523!~ais523@unaffiliated/ais523 PRIVMSG #esoteric :that's most likely for class fields < 1541982133 986568 :ais523!~ais523@unaffiliated/ais523 PRIVMSG #esoteric :I don't think anyone treats /local/ variables like this < 1541982140 595275 :ais523!~ais523@unaffiliated/ais523 PRIVMSG #esoteric :(I stole the syntax from C#) < 1541982165 839610 :shachaf!~shachaf@unaffiliated/shachaf PRIVMSG #esoteric :Oh, no, it's Rust: https://doc.rust-lang.org/std/ptr/fn.read_volatile.html < 1541982195 661323 :shachaf!~shachaf@unaffiliated/shachaf PRIVMSG #esoteric :I was talking about the thing I said. I'm not sure what you mean by passing the function by value. < 1541982214 250756 :ais523!~ais523@unaffiliated/ais523 PRIVMSG #esoteric :I was going to ask "why is that unsafe" and then saw it works on `*` pointers, which would be a good reason < 1541982251 966893 :ais523!~ais523@unaffiliated/ais523 PRIVMSG #esoteric :re: passing the function by value, I mean you could pass the return value of getX() (i.e. pass by value), or you could pass the getX function itself so that the callee could then call it itself (i.e. pass by reference) < 1541982271 762325 :ais523!~ais523@unaffiliated/ais523 PRIVMSG #esoteric :like the difference between passing x and passing (int const *)&x in C < 1541982272 21195 :shachaf!~shachaf@unaffiliated/shachaf PRIVMSG #esoteric :Where getX is a closure or something? < 1541982281 903735 :ais523!~ais523@unaffiliated/ais523 PRIVMSG #esoteric :getX is something like a closure, I think < 1541982294 62333 :ais523!~ais523@unaffiliated/ais523 PRIVMSG #esoteric :but the point is that the variable X can't be directly referenced at all < 1541982311 429227 :ais523!~ais523@unaffiliated/ais523 PRIVMSG #esoteric :all you have is its lvalue part setX and rvalue part getX, which correspond to the operations of assigning to it and reading it < 1541982362 291720 :shachaf!~shachaf@unaffiliated/shachaf PRIVMSG #esoteric :It's nice to separate it into the covariant part and contravariant part, I guess. < 1541982406 97215 :ais523!~ais523@unaffiliated/ais523 PRIVMSG #esoteric :yes < 1541982456 745674 :ais523!~ais523@unaffiliated/ais523 PRIVMSG #esoteric :anyway, most languages treat variables like products of their lvalue and rvalue; a product's a type of pair where the pair itself acts as a unit, any operation on the pair can say "do this on the LHS" or "do this on the RHS" but the two parts aren't separable (unless you copy out of half of the pair individually) < 1541982496 345586 :ais523!~ais523@unaffiliated/ais523 PRIVMSG #esoteric :whereas this version of things treats variables like tensors of their lvalue and rvalue; a tensor's a type of pair which is basically just a wrapper for two halves, with the wrapper having no properties of its own, rather each half has its own independent behaviour < 1541982542 387325 :ais523!~ais523@unaffiliated/ais523 PRIVMSG #esoteric :typically speaking you have to copy a product to act on both halves of it (e.g. in a stack-based language, you'd do dup, then get hold of one half, operate on it, then get hold of the other half using the copy of the pair you made earlier) < 1541982556 721981 :shachaf!~shachaf@unaffiliated/shachaf PRIVMSG #esoteric :I'm not sure I follow. < 1541982568 770332 :ais523!~ais523@unaffiliated/ais523 PRIVMSG #esoteric :whereas with a tensor, the operation you use to act on the tensor drops it into two halves of its own accord, so if you only act on one you need to explicitly pop the other one < 1541982596 593595 :ais523!~ais523@unaffiliated/ais523 PRIVMSG #esoteric :shachaf: this is a really confusing subject in general and I'm not all that great at understanding it < 1541982600 281021 :ais523!~ais523@unaffiliated/ais523 PRIVMSG #esoteric :*at explaining it < 1541982634 310992 :ais523!~ais523@unaffiliated/ais523 PRIVMSG #esoteric :it almost feels like the tensor/product distinction is the same sort of thing as monads, i.e. people use it all the time when writing in more mathematical languages but often only poorly understand it, except that it isn't well-known that it even is a problem < 1541982663 273509 :shachaf!~shachaf@unaffiliated/shachaf PRIVMSG #esoteric :ski wrote about this a little while ago at http://slbkbs.org/ski-mercury.txt < 1541982667 89856 :ais523!~ais523@unaffiliated/ais523 PRIVMSG #esoteric :but it basically comes down to what happens when a language has some sort of metadata you can attach to a value (which is very common) < 1541982736 520905 :shachaf!~shachaf@unaffiliated/shachaf PRIVMSG #esoteric :I'd like a language that makes all this very clear, most languages muddle it up or don't support talking about it at all. < 1541982760 650488 :ais523!~ais523@unaffiliated/ais523 PRIVMSG #esoteric :re: lvalue versus rvalue, OCaml is 100% explicit on the matter < 1541982799 326719 :ais523!~ais523@unaffiliated/ais523 PRIVMSG #esoteric :using := as lvalue dereference (producing a setter) and ! as rvalue dereference (which should produce a getter, although it actually executes the getter immediately; that's something of a mathematical flaw, I guess) < 1541982801 161559 :shachaf!~shachaf@unaffiliated/shachaf PRIVMSG #esoteric :But can you get a ref to a part of a product inside another ref? < 1541982827 258406 :ais523!~ais523@unaffiliated/ais523 PRIVMSG #esoteric :no, you can't; that's because OCaml products are products < 1541982834 525467 :ais523!~ais523@unaffiliated/ais523 PRIVMSG #esoteric :rather than tensors < 1541982845 517808 :ais523!~ais523@unaffiliated/ais523 PRIVMSG #esoteric :or rather, there's a distinction < 1541982848 570754 :ais523!~ais523@unaffiliated/ais523 PRIVMSG #esoteric :do we have OCaml in hackego? < 1541982853 525193 :ais523!~ais523@unaffiliated/ais523 PRIVMSG #esoteric :`` which ocaml < 1541982853 705802 :shachaf!~shachaf@unaffiliated/shachaf PRIVMSG #esoteric :I don't think so. < 1541982854 776237 :HackEso!~h@techne.zem.fi PRIVMSG #esoteric :No output. < 1541982858 119430 :ais523!~ais523@unaffiliated/ais523 PRIVMSG #esoteric :nope < 1541982871 933575 :ais523!~ais523@unaffiliated/ais523 PRIVMSG #esoteric :anyway, in OCaml you can't get a ref to anything unless it was declared via the ref keyword < 1541982885 637929 :ais523!~ais523@unaffiliated/ais523 PRIVMSG #esoteric :so ref (1, 1) has a different type from (ref 1, ref 1) < 1541982891 485625 :shachaf!~shachaf@unaffiliated/shachaf PRIVMSG #esoteric :Right. < 1541982907 977802 :shachaf!~shachaf@unaffiliated/shachaf PRIVMSG #esoteric :This is what most of the explicit-about-refs languages do. < 1541982926 479567 :shachaf!~shachaf@unaffiliated/shachaf PRIVMSG #esoteric :I'm interested in languages that help you talk about memory layout and so on. < 1541982940 29786 :shachaf!~shachaf@unaffiliated/shachaf PRIVMSG #esoteric :When you declare a struct or union in C, what information exactly are you declaring? < 1541982962 305588 :shachaf!~shachaf@unaffiliated/shachaf PRIVMSG #esoteric :I've asked that question before but I'm still not sure I have an answer. < 1541982965 895052 :ais523!~ais523@unaffiliated/ais523 PRIVMSG #esoteric :well, in the very early days of C, declaring a struct just gave you a list of constants representing memory offsets < 1541982980 102371 :shachaf!~shachaf@unaffiliated/shachaf PRIVMSG #esoteric :In lvalue-land, you're declaring things like: A sizeof, an alignment, an offset for each field. < 1541982984 887108 :ais523!~ais523@unaffiliated/ais523 PRIVMSG #esoteric :like, if you wrote struct a {int b; int c}, that was more or less equivalent to "const int b = 0; const int c = 4;" < 1541983012 967542 :ais523!~ais523@unaffiliated/ais523 PRIVMSG #esoteric :(with the exception that struct a would be reported as having size 8 for the rest of the program, affecting things like sizeof, allocation of auto variables, and the like) < 1541983015 345996 :shachaf!~shachaf@unaffiliated/shachaf PRIVMSG #esoteric :In rvalue-land, you're declaring something like, "this is the information that this struct consists of" < 1541983035 336874 :shachaf!~shachaf@unaffiliated/shachaf PRIVMSG #esoteric :The thing in lvalue-land is effectively a memory encoding of the thing in rvalue-land. < 1541983042 792262 :ais523!~ais523@unaffiliated/ais523 PRIVMSG #esoteric :it feels like it's within the spirit of C for struct fields to not be rvalues at all < 1541983054 916507 :shachaf!~shachaf@unaffiliated/shachaf PRIVMSG #esoteric :When you pass something by value to a function, the calling convention doesn't use the lvalue-land memory layout, it uses something more efficient. < 1541983057 357129 :ais523!~ais523@unaffiliated/ais523 PRIVMSG #esoteric :that said, I think they actually are in practice < 1541983076 503452 :shachaf!~shachaf@unaffiliated/shachaf PRIVMSG #esoteric :"f().c" is an rvalue < 1541983081 829647 :ais523!~ais523@unaffiliated/ais523 PRIVMSG #esoteric :yes, as is 2+2 < 1541983098 947258 :arseniiv!~arseniiv@95.105.76.158 QUIT :Ping timeout: 252 seconds < 1541983109 588809 :ais523!~ais523@unaffiliated/ais523 PRIVMSG #esoteric :functions returning structs is something of a weird case in C; it doesn't feel like it "should" be possible, and in fact many compilers need special cases for it < 1541983125 772351 :shachaf!~shachaf@unaffiliated/shachaf PRIVMSG #esoteric :It seems pretty reasonable to me. < 1541983150 633572 :ais523!~ais523@unaffiliated/ais523 PRIVMSG #esoteric :`` gcc -x c /dev/stdin <<< 'int main(void) {puts("Hello, world!"); return 0;}'; ./a.out < 1541983153 763358 :HackEso!~h@techne.zem.fi PRIVMSG #esoteric :​/dev/stdin: In function ‘main’: \ /dev/stdin:1:17: warning: implicit declaration of function ‘puts’ [-Wimplicit-function-declaration] \ int main(void) {puts("Hello, world!"); return 0;} \ ^~~~ \ Hello, world! < 1541983174 214212 :ais523!~ais523@unaffiliated/ais523 PRIVMSG #esoteric :`` gcc -x c /dev/stdin <<< 'int main(void) {puts("Hello, world!"); return 0;}' | cat; ./a.out < 1541983175 158989 :HackEso!~h@techne.zem.fi PRIVMSG #esoteric :​/dev/stdin: In function ‘main’: \ /dev/stdin:1:17: warning: implicit declaration of function ‘puts’ [-Wimplicit-function-declaration] \ int main(void) {puts("Hello, world!"); return 0;} \ ^~~~ \ Hello, world! < 1541983185 104776 :ais523!~ais523@unaffiliated/ais523 PRIVMSG #esoteric :hmm, what's up with all the terminal control codes < 1541983190 61540 :shachaf!~shachaf@unaffiliated/shachaf PRIVMSG #esoteric :The reason I gave f().c as an example is that it shows that a.b doesn't always mean a thing like *(&a + b_offset). < 1541983209 839670 :ais523!~ais523@unaffiliated/ais523 PRIVMSG #esoteric :`` gcc -fdiagnostics-color=never -x c /dev/stdin <<< 'int main(void) {puts("Hello, world!"); return 0;}'; ./a.out < 1541983210 722873 :HackEso!~h@techne.zem.fi PRIVMSG #esoteric :​/dev/stdin: In function ‘main’: \ /dev/stdin:1:17: warning: implicit declaration of function ‘puts’ [-Wimplicit-function-declaration] \ int main(void) {puts("Hello, world!"); return 0;} \ ^~~~ \ Hello, world! < 1541983238 113690 :ais523!~ais523@unaffiliated/ais523 PRIVMSG #esoteric :`` gcc -fnodiagnostics-show-caret -fdiagnostics-color=never -x c /dev/stdin <<< 'int main(void) {puts("Hello, world!"); return 0;}'; ./a.out < 1541983238 811729 :HackEso!~h@techne.zem.fi PRIVMSG #esoteric :gcc: error: unrecognized command line option ‘-fnodiagnostics-show-caret’; did you mean ‘-fno-diagnostics-show-caret’? \ Hello, world! < 1541983243 532966 :ais523!~ais523@unaffiliated/ais523 PRIVMSG #esoteric :`` gcc -fno-diagnostics-show-caret -fdiagnostics-color=never -x c /dev/stdin <<< 'int main(void) {puts("Hello, world!"); return 0;}'; ./a.out < 1541983244 497530 :HackEso!~h@techne.zem.fi PRIVMSG #esoteric :​/dev/stdin: In function ‘main’: \ /dev/stdin:1:17: warning: implicit declaration of function ‘puts’ [-Wimplicit-function-declaration] \ Hello, world! < 1541983269 419020 :shachaf!~shachaf@unaffiliated/shachaf PRIVMSG #esoteric :`runc int main() { puts("hi"); return 0; } < 1541983270 338152 :HackEso!~h@techne.zem.fi PRIVMSG #esoteric :hi < 1541983277 386974 :ais523!~ais523@unaffiliated/ais523 PRIVMSG #esoteric :shachaf: I agree that C currently works like this; however, I believe that all the cases that force structs to be treated as rvalues are weird special cases that /shouldn't/ have been in C < 1541983285 300909 :zzo38!~zzo38@24-207-47-161.eastlink.ca PRIVMSG #esoteric :There is also LLVM, but does not have macros though < 1541983303 870897 :shachaf!~shachaf@unaffiliated/shachaf PRIVMSG #esoteric :ais523: Do you also think struct assignments shouldn't be allowed? < 1541983310 38991 :ais523!~ais523@unaffiliated/ais523 PRIVMSG #esoteric :yes < 1541983324 765072 :shachaf!~shachaf@unaffiliated/shachaf PRIVMSG #esoteric :Hm. They seem pretty reasonable to me. < 1541983340 725660 :ais523!~ais523@unaffiliated/ais523 PRIVMSG #esoteric :actually, there's a related question which is something that I've been really interested in over the past few months in general, and past few days more earnestly < 1541983341 99527 :shachaf!~shachaf@unaffiliated/shachaf PRIVMSG #esoteric :What about passing structs as arguments by value? < 1541983362 885533 :ais523!~ais523@unaffiliated/ais523 PRIVMSG #esoteric :which is that languages seem to often use the same sort of language feature for a) large, complex values, and b) stateful objects < 1541983371 961989 :ais523!~ais523@unaffiliated/ais523 PRIVMSG #esoteric :I think they should be treated entirely differently < 1541983382 909094 :ais523!~ais523@unaffiliated/ais523 PRIVMSG #esoteric :things in class a) shouldn't be mutable, things in class b) shouldn't be passable by value < 1541983414 835582 :ais523!~ais523@unaffiliated/ais523 PRIVMSG #esoteric :quite a few languages are skirting round the edges of this idea but I don't think any has gone the whole way < 1541983539 90857 :shachaf!~shachaf@unaffiliated/shachaf PRIVMSG #esoteric :How would languages be different if they made that distinction? < 1541983798 596012 :zzo38!~zzo38@24-207-47-161.eastlink.ca PRIVMSG #esoteric :I did think of a way to make "user primitives" for JavaScript that can implement (a) < 1541983891 57597 :ais523!~ais523@unaffiliated/ais523 PRIVMSG #esoteric :shachaf: well for example, you'd never need a value/reference distinction < 1541983895 355415 :ais523!~ais523@unaffiliated/ais523 PRIVMSG #esoteric :in the actual syntax < 1541983920 134980 :ais523!~ais523@unaffiliated/ais523 PRIVMSG #esoteric :if something is a value, it's always a value; if something's an object, it isn't a value at all, it can only be manipulated via references to it (and those references are values) < 1541983937 705795 :ais523!~ais523@unaffiliated/ais523 PRIVMSG #esoteric :so the code itself sees only values < 1541983944 250875 :ais523!~ais523@unaffiliated/ais523 PRIVMSG #esoteric :(objects are manipulated via methods/accessor functions) < 1541983970 475706 :ais523!~ais523@unaffiliated/ais523 PRIVMSG #esoteric :more controversially, I /also/ think it would be beneficial if objects just persisted forever if they weren't explicitly deallocated, /but/ you could search for objects with particular properties < 1541983995 454986 :ais523!~ais523@unaffiliated/ais523 PRIVMSG #esoteric :my only argument in favour of this is that for something like the last 10 programs I've tried to seriously write, they'd be more easily written in that style than in a style that tries to maintain indexes manually < 1541984031 31421 :shachaf!~shachaf@unaffiliated/shachaf PRIVMSG #esoteric :Search for? < 1541984097 962450 :zzo38!~zzo38@24-207-47-161.eastlink.ca PRIVMSG #esoteric :Garbage collection works for unsearchable objects < 1541984135 432435 :ais523!~ais523@unaffiliated/ais523 PRIVMSG #esoteric :shachaf: like, there's a function that returns a reference to "the object whose x property is y" < 1541984184 954029 :ais523!~ais523@unaffiliated/ais523 PRIVMSG #esoteric :zzo38: I know that garbage collection works, however I think that garbage collection of reference-like objects is normally a bad idea, because if a programmer knows what they're doing they typically know the points at which they're supposed to become no longer useful anyway < 1541984226 373823 :zzo38!~zzo38@24-207-47-161.eastlink.ca PRIVMSG #esoteric :I am not so sure that is true < 1541984234 483569 :ais523!~ais523@unaffiliated/ais523 PRIVMSG #esoteric :it's only objects that act like values that really benefit from garbage collection; this is because reference+garabage collect is a more efficient way of implementing the semantics you normally want (which is to replace referencing by copying, and freeing copies that go out of scope) > 1541987111 486484 PRIVMSG #esoteric :14[[07WHY14]]4 M10 02https://esolangs.org/w/index.php?diff=58340&oldid=58103 5* 03Camto 5* (+54) 10Add them categories. < 1541990118 969157 :oerjan!oerjan@hagbart.nvg.ntnu.no JOIN :#esoteric < 1541990516 646167 :shachaf!~shachaf@unaffiliated/shachaf PRIVMSG #esoteric :boker toevjan < 1541990611 22828 :zzo38!~zzo38@24-207-47-161.eastlink.ca PRIVMSG #esoteric :What does that mean? < 1541990792 736429 :oerjan!oerjan@hagbart.nvg.ntnu.no PRIVMSG #esoteric :ACTION suspects hebrew < 1541990817 596219 :oerjan!oerjan@hagbart.nvg.ntnu.no PRIVMSG #esoteric :ACTION was right < 1541990828 587069 :oerjan!oerjan@hagbart.nvg.ntnu.no PRIVMSG #esoteric :heichaf < 1541990869 289710 :shachaf!~shachaf@unaffiliated/shachaf PRIVMSG #esoteric :erev toevjan < 1541990891 432127 :shachaf!~shachaf@unaffiliated/shachaf PRIVMSG #esoteric :hm, it's slightly irritating that "morning" and "evenign" are singular in hebrew, but e.g. "noon" is plural < 1541991041 313809 :oerjan!oerjan@hagbart.nvg.ntnu.no PRIVMSG #esoteric : Maybe oerjan remembers. <-- AAAAAAAAAAA < 1541991897 627547 :shachaf!~shachaf@unaffiliated/shachaf PRIVMSG #esoteric :what is it that oerjan remembers? i've forgotten hth < 1541992451 566502 :oerjan!oerjan@hagbart.nvg.ntnu.no PRIVMSG #esoteric :yay < 1541992458 60258 :oerjan!oerjan@hagbart.nvg.ntnu.no PRIVMSG #esoteric :tdh thx < 1541992517 950345 :shachaf!~shachaf@unaffiliated/shachaf PRIVMSG #esoteric :Oh, the thing with differentials. < 1541993014 529555 :zzo38!~zzo38@24-207-47-161.eastlink.ca PRIVMSG #esoteric :Now I wrote a document for a internet protocol called Netsubscribe, which I invented, you can read and please to question, complaint, or other comments about it. < 1541993826 283849 :zzo38!~zzo38@24-207-47-161.eastlink.ca PRIVMSG #esoteric :It is: http://zzo38computer.org/textfile/miscellaneous/netsubscribe Do you like this? > 1541994122 395434 PRIVMSG #esoteric :14[[07MIX (Knuth)14]]4 10 02https://esolangs.org/w/index.php?diff=58341&oldid=58339 5* 03Zzo38 5* (+399) 10Include the bootstrap card for MIXPC assembler < 1541994174 225224 :ais523!~ais523@unaffiliated/ais523 QUIT :Remote host closed the connection < 1541994186 899890 :ais523!~ais523@unaffiliated/ais523 JOIN :#esoteric < 1541994238 884289 :ais523!~ais523@unaffiliated/ais523 PRIVMSG #esoteric :zzo38: I think the specification could be organised a bit more clearly; for example, I would separate the normative description of the protocol itself from suggestions about how to implement it, and I would move any detailed description of competing protocols and protocols that you plan to replace to a separate section near the end < 1541994286 772957 :ais523!~ais523@unaffiliated/ais523 PRIVMSG #esoteric :it might also be helpful to separate the description of what data the protocol operates on from the way that those data are represented within the protocol, but I might be wrong about that < 1541994404 247741 :zzo38!~zzo38@24-207-47-161.eastlink.ca PRIVMSG #esoteric :ais523: OK, I deleted some of the stuff from the introduction, such as the stuff about other protocols (which was there in order to try to make it more clearly), although one reason I put that there was to clarify it, although ideally it should be clear without. < 1541994425 940099 :ais523!~ais523@unaffiliated/ais523 PRIVMSG #esoteric :the set of error codes you have is much smaller than in most protocols; I think most protocols eventually discovered that they needed to use a system of error numbers, in which the number encoded some information about the error (so that clients knew how to handle unknown errors) but also just a code describing the cause of the error < 1541994443 649939 :ais523!~ais523@unaffiliated/ais523 PRIVMSG #esoteric :zzo38: I think that sort of information isn't necessarily useless, but people want to know the information in importance order < 1541994458 112176 :ais523!~ais523@unaffiliated/ais523 PRIVMSG #esoteric :if you have to read less important information to get to more important information it's easy to get confused < 1541994505 596488 :zzo38!~zzo38@24-207-47-161.eastlink.ca PRIVMSG #esoteric :Yes, maybe there should be an error code for a permission error, and for a temporary error. < 1541994527 89801 :zzo38!~zzo38@24-207-47-161.eastlink.ca PRIVMSG #esoteric :You can make other kind of suggestions about what kind of error you think needs to be mentioned. < 1541994555 676533 :hexfive!~hexfive@50-46-223-124.evrt.wa.frontiernet.net JOIN :#esoteric < 1541994562 340495 :zzo38!~zzo38@24-207-47-161.eastlink.ca PRIVMSG #esoteric :Yes, I could add stuff about relation to other protocols in a section at the end, I will try to do that. < 1541994671 474217 :zzo38!~zzo38@24-207-47-161.eastlink.ca PRIVMSG #esoteric :I am not sure how I should organize the suggestions how to implement it as you describe though, and I am not sure about separating the description of what data the protocol operates on from the way that those data are represented within the protocol (you say yourself you may be wrong about that, though) < 1541994739 546731 :ais523!~ais523@unaffiliated/ais523 PRIVMSG #esoteric :zzo38: well, in RFCs, advice like "don't use gets()" and similar advice about how to implement the protocol securely is often placed in a section called "security implications" at the end < 1541994920 821827 :zzo38!~zzo38@24-207-47-161.eastlink.ca PRIVMSG #esoteric :I deleted the part about gets() and fgets(). And you could use fgets() anyways, as long as you check for the presence of the line break so I was wrong about that anyways. < 1541995082 258764 :zzo38!~zzo38@24-207-47-161.eastlink.ca PRIVMSG #esoteric :But I will add a section of security implications. < 1541995200 690402 :Taneb!~Taneb@2001:41c8:51:10d:aaaa:0:aaaa:0 QUIT :Quit: I seem to have stopped. < 1541995289 624006 :Taneb!~Taneb@2001:41c8:51:10d:aaaa:0:aaaa:0 JOIN :#esoteric < 1541995297 255524 :zzo38!~zzo38@24-207-47-161.eastlink.ca PRIVMSG #esoteric :Also, do you think there are any security implications that I may have missed? < 1541995513 51331 :ais523!~ais523@unaffiliated/ais523 PRIVMSG #esoteric :it's hard to get all the security implications first time with a new protocol; so I'd expect anyone to miss some the first time < 1541995524 77568 :zzo38!~zzo38@24-207-47-161.eastlink.ca PRIVMSG #esoteric :Ah, OK. < 1541995527 21268 :ais523!~ais523@unaffiliated/ais523 PRIVMSG #esoteric :but I'm not really used to this protocol so I'd be even more likely to miss them < 1541995605 78082 :zzo38!~zzo38@24-207-47-161.eastlink.ca PRIVMSG #esoteric :(But that is also why I ask; even if I might miss some that someone else doesn't, even if it is likely to miss them, there is also the possibility that there is one you don't miss, I suppose.) < 1542000056 966162 :ais523!~ais523@unaffiliated/ais523 QUIT :Quit: quit < 1542000742 18712 :xkapastel!uid17782@gateway/web/irccloud.com/x-hwjuqnmrklgpqzpe QUIT :Quit: Connection closed for inactivity < 1542004302 806097 :nfd!~nfd9001@2601:602:8500:d0d1:7575:fc76:2c9f:4afa JOIN :#esoteric < 1542004516 205003 :nfd9001!~nfd9001@2601:602:8500:d0d1:7575:fc76:2c9f:4afa QUIT :Ping timeout: 260 seconds < 1542004735 754388 :oerjan!oerjan@hagbart.nvg.ntnu.no QUIT :Quit: Nite < 1542004933 2494 :shachaf!~shachaf@unaffiliated/shachaf PRIVMSG #esoteric :@ask ais523 I've forgotten your idea involving generalizing Rust's ?, is it written somewhere? < 1542004933 157429 :lambdabot!~lambdabot@haskell/bot/lambdabot PRIVMSG #esoteric :Consider it noted. < 1542011547 197764 :shachaf!~shachaf@unaffiliated/shachaf PRIVMSG #esoteric :@ask ais523 I vaguely remember seeing a Haskell proposal that would translate something like do { f (<- a) (<- b) } into do { x <- a; y <- b; f x y } and so on. Do you remember something like that? < 1542011547 345453 :lambdabot!~lambdabot@haskell/bot/lambdabot PRIVMSG #esoteric :Consider it noted. < 1542011555 483472 :shachaf!~shachaf@unaffiliated/shachaf PRIVMSG #esoteric :Or oerjan or Taneb or whoever < 1542012035 667631 :xkapastel!uid17782@gateway/web/irccloud.com/x-gvrezdvfumnqwalh JOIN :#esoteric < 1542014146 846189 :nfd!~nfd9001@2601:602:8500:d0d1:7575:fc76:2c9f:4afa QUIT :Ping timeout: 250 seconds < 1542016272 285856 :AnotherTest!~turingcom@d51A46C74.access.telenet.be JOIN :#esoteric > 1542017396 163752 PRIVMSG #esoteric :14[[07Talk:Brainfoctal14]]4 10 02https://esolangs.org/w/index.php?diff=58342&oldid=58331 5* 03Salpynx 5* (+1401) 10/* Numbering system */ great suggestion, thank you!! < 1542017437 563827 :nfd!~nfd9001@2601:602:8500:d0d1:7575:fc76:2c9f:4afa JOIN :#esoteric < 1542017923 237475 :imode!~imode@unaffiliated/imode QUIT :Ping timeout: 246 seconds < 1542021016 475718 :xkapastel!uid17782@gateway/web/irccloud.com/x-gvrezdvfumnqwalh QUIT :Quit: Connection closed for inactivity < 1542021642 452979 :shachaf!~shachaf@unaffiliated/shachaf PRIVMSG #esoteric :@tell ais523 Ah, it's https://github.com/ghc-proposals/ghc-proposals/pull/64 < 1542021642 635364 :lambdabot!~lambdabot@haskell/bot/lambdabot PRIVMSG #esoteric :Consider it noted. < 1542021707 303371 :shachaf!~shachaf@unaffiliated/shachaf PRIVMSG #esoteric :@tell ais523 Oh, and http://docs.idris-lang.org/en/latest/tutorial/interfaces.html#notation is even closer < 1542021707 451931 :lambdabot!~lambdabot@haskell/bot/lambdabot PRIVMSG #esoteric :Consider it noted. < 1542023635 245701 :Lord_of_Life!~Lord@unaffiliated/lord-of-life/x-0885362 QUIT :Ping timeout: 246 seconds < 1542023780 703146 :Lord_of_Life!~Lord@46.217.127.217 JOIN :#esoteric < 1542023780 794257 :Lord_of_Life!~Lord@46.217.127.217 QUIT :Changing host < 1542023780 794302 :Lord_of_Life!~Lord@unaffiliated/lord-of-life/x-0885362 JOIN :#esoteric < 1542024210 871468 :wob_jonas!25bf3cd1@gateway/web/cgi-irc/kiwiirc.com/ip.37.191.60.209 JOIN :#esoteric < 1542024733 816152 :wob_jonas!25bf3cd1@gateway/web/cgi-irc/kiwiirc.com/ip.37.191.60.209 PRIVMSG #esoteric :hmm < 1542024757 550152 :wob_jonas!25bf3cd1@gateway/web/cgi-irc/kiwiirc.com/ip.37.191.60.209 PRIVMSG #esoteric :`dateu < 1542024758 929673 :HackEso!~h@techne.zem.fi PRIVMSG #esoteric :2018-11-12 12:12:38.052784510+00:00 < 1542025554 537499 :nfd!~nfd9001@2601:602:8500:d0d1:7575:fc76:2c9f:4afa QUIT :Ping timeout: 252 seconds > 1542026408 735791 PRIVMSG #esoteric :14[[07Falsebrain9Q+Fishload14]]4 10 02https://esolangs.org/w/index.php?diff=58343&oldid=57914 5* 03Joshop 5* (+6) 10 < 1542029014 268130 :moei!~moei@softbank221078042071.bbtec.net JOIN :#esoteric < 1542031765 242836 :wob_jonas!25bf3cd1@gateway/web/cgi-irc/kiwiirc.com/ip.37.191.60.209 QUIT :Quit: http://www.kiwiirc.com/ - A hand crafted IRC client < 1542032232 636445 :john_metcalf!~digital_w@host81-136-80-199.range81-136.btcentralplus.com JOIN :#esoteric < 1542033838 236669 :arseniiv!~arseniiv@95.105.76.158 JOIN :#esoteric < 1542034361 731302 :Essadon!~Essadon@81-225-32-185-no249.tbcn.telia.com JOIN :#esoteric < 1542034991 467431 :ski!~ski@remote11.chalmers.se PRIVMSG #esoteric :shachaf : "The reason I gave f().c as an example is that it shows that a.b doesn't always mean a thing like *(&a + b_offset)." -- hm, i suppose that goes into the difference between "persistent" vs. "transient" values (objects ?). cf. the C++ kerfuffle with "rvalue references" in relation to "move semantics" (and "perfect forwarding") < 1542034996 466682 :ski!~ski@remote11.chalmers.se PRIVMSG #esoteric :shachaf : "ais523 : I've forgotten your idea involving generalizing Rust's ?, is it written somewhere?" -- hm, i vaguely remember thinking and talking about something like that, on another channel < 1542035016 524580 :ski!~ski@remote11.chalmers.se PRIVMSG #esoteric :(partly in relation to my "reflective syntax" idea) < 1542035110 129737 :ski!~ski@remote11.chalmers.se PRIVMSG #esoteric :shachaf : fwiw, did you add some follow-up comments or questions after that (paste) snippet ? i think i intended to look and continue that conversation, but i got busy and then forgot, and now it's out of my scrollback < 1542035895 680505 :Sgeo__!~Sgeo@ool-18b98dd9.dyn.optonline.net JOIN :#esoteric < 1542036007 526750 :MDead!~MDude@c-73-187-225-46.hsd1.pa.comcast.net JOIN :#esoteric < 1542036051 198926 :Sgeo_!~Sgeo@ool-18b98dd9.dyn.optonline.net QUIT :Ping timeout: 260 seconds < 1542036072 714545 :MDead_!~MDude@c-73-187-225-46.hsd1.pa.comcast.net JOIN :#esoteric < 1542036155 403053 :MDude!~MDude@c-73-187-225-46.hsd1.pa.comcast.net QUIT :Ping timeout: 244 seconds < 1542036315 990814 :MDead!~MDude@c-73-187-225-46.hsd1.pa.comcast.net QUIT :Ping timeout: 264 seconds < 1542038343 999588 :sleepnap!~thomas@2603:3015:260e:1900::13ed JOIN :#esoteric < 1542039319 201197 :xkapastel!uid17782@gateway/web/irccloud.com/x-bplzoeqjinejszwh JOIN :#esoteric < 1542041592 792352 :Phantom_Hoover!~phantomho@unaffiliated/phantom-hoover JOIN :#esoteric < 1542042720 256073 :imode!~imode@unaffiliated/imode JOIN :#esoteric < 1542045839 595984 :ais523!~ais523@unaffiliated/ais523 JOIN :#esoteric < 1542045847 408698 :ais523!~ais523@unaffiliated/ais523 PRIVMSG #esoteric :@messages- < 1542045847 545215 :lambdabot!~lambdabot@haskell/bot/lambdabot PRIVMSG #esoteric :shachaf asked 11h 21m 54s ago: I've forgotten your idea involving generalizing Rust's ?, is it written somewhere? < 1542045847 545256 :lambdabot!~lambdabot@haskell/bot/lambdabot PRIVMSG #esoteric :shachaf asked 9h 31m 40s ago: I vaguely remember seeing a Haskell proposal that would translate something like do { f (<- a) (<- b) } into do { x <- a; y <- b; f x y } and so on. Do you remember < 1542045847 545265 :lambdabot!~lambdabot@haskell/bot/lambdabot PRIVMSG #esoteric :something like that? < 1542045847 545273 :lambdabot!~lambdabot@haskell/bot/lambdabot PRIVMSG #esoteric :shachaf said 6h 43m 24s ago: Ah, it's https://github.com/ghc-proposals/ghc-proposals/pull/64 < 1542045847 545280 :lambdabot!~lambdabot@haskell/bot/lambdabot PRIVMSG #esoteric :shachaf said 6h 42m 19s ago: Oh, and http://docs.idris-lang.org/en/latest/tutorial/interfaces.html#notation is even closer < 1542045888 2167 :ais523!~ais523@unaffiliated/ais523 PRIVMSG #esoteric :shachaf: I don't think I posted my generalized-? idea anywhere but IRC, and it isn't fleshed out into a formal specification or anything like that < 1542046017 875669 :ais523!~ais523@unaffiliated/ais523 PRIVMSG #esoteric :perhaps we should try to express it in Haskell notation or something like that < 1542046048 57560 :ais523!~ais523@unaffiliated/ais523 PRIVMSG #esoteric :the basic idea is that x? converts the rest of the block into a function and gives it as an argument to x < 1542046056 186157 :ais523!~ais523@unaffiliated/ais523 PRIVMSG #esoteric :which can run it once, or not run it, or run it repeatedly < 1542046085 910936 :ais523!~ais523@unaffiliated/ais523 PRIVMSG #esoteric :and the f (<- a) (<- b) idea that you mention would be necessary so that code like f(a?)(b?) would be sensible < 1542046162 275800 :ais523!~ais523@unaffiliated/ais523 PRIVMSG #esoteric :Idris ! may be equivalent, although it's weird seeing it around presumably nullary terms like "print" < 1542046177 228942 :ais523!~ais523@unaffiliated/ais523 PRIVMSG #esoteric :err, not nullary, but returning a monad that contains unit < 1542046236 988783 :ais523!~ais523@unaffiliated/ais523 PRIVMSG #esoteric :I guess that works even in Rust < 1542046293 768519 :ais523!~ais523@unaffiliated/ais523 PRIVMSG #esoteric :there's no reason why you couldn't have a Result where the "non-error" case contained no data < 1542046294 356893 :ais523!~ais523@unaffiliated/ais523 PRIVMSG #esoteric :so (print x)? would mean "print x, and return on failure, otherwise continue" < 1542046300 933261 :ais523!~ais523@unaffiliated/ais523 PRIVMSG #esoteric :that's probably a common idiom in Rust already, come to think of it < 1542046316 412043 :ais523!~ais523@unaffiliated/ais523 QUIT :Quit: sorry for my connection < 1542046328 824425 :ais523!~ais523@unaffiliated/ais523 JOIN :#esoteric < 1542046746 487413 :ski!~ski@remote11.chalmers.se PRIVMSG #esoteric :(s/returning a monad that contains unit/returning a monadic action whose result is unit/) < 1542046817 943912 :ski!~ski@remote11.chalmers.se PRIVMSG #esoteric : shachaf : "ais523 : I've forgotten your idea involving generalizing Rust's ?, is it written somewhere?" -- hm, i vaguely remember thinking and talking about something like that, on another channel (partly in relation to my "reflective syntax" idea) < 1542046949 673686 :ais523!~ais523@unaffiliated/ais523 PRIVMSG #esoteric :I guess I'm mostly thinking about this ? proposal for less heavily functional languages < 1542046983 559329 :ais523!~ais523@unaffiliated/ais523 PRIVMSG #esoteric :does Haskell have anything resembling a promise library? or does it not need one, because the language is lazy anyway? < 1542047025 368835 :ais523!~ais523@unaffiliated/ais523 PRIVMSG #esoteric :…actually, the problem with Haskell wouldn't be blocking until the result arrives, but starting to ask for the result before you need it < 1542047036 885868 :ais523!~ais523@unaffiliated/ais523 PRIVMSG #esoteric :so that it's there when you do < 1542047059 519511 :ais523!~ais523@unaffiliated/ais523 PRIVMSG #esoteric :something that was discussed on a previous work project of mine, but not implemented, was "parallel call by need evaulation" < 1542047063 958462 :ais523!~ais523@unaffiliated/ais523 PRIVMSG #esoteric :*evaluation < 1542047068 312162 :xkapastel!uid17782@gateway/web/irccloud.com/x-bplzoeqjinejszwh QUIT :Quit: Connection closed for inactivity < 1542047102 112204 :ais523!~ais523@unaffiliated/ais523 PRIVMSG #esoteric :the idea is that when you see code "f x", you start evaluating x in the background while calling f; if f turns out to return without actually needing the value of x, you halt/discard the background evaluation < 1542047110 903694 :ais523!~ais523@unaffiliated/ais523 PRIVMSG #esoteric :(obviously, this only really works in a pure language) < 1542047130 76059 :ais523!~ais523@unaffiliated/ais523 PRIVMSG #esoteric :that style would make promises entirely irrelevant < 1542047284 524860 :ski!~ski@remote11.chalmers.se PRIVMSG #esoteric :iirc, the Rust `?' thing was (originally ?) about operations returning a result of option type ? < 1542047293 108502 :ais523!~ais523@unaffiliated/ais523 PRIVMSG #esoteric :anyway, re the "monad that contains" thing, I apologise for the sloppy language (but think "monadic action whose result is" is misleading; it's not really like a result at all, more like an argument) < 1542047335 127502 :ais523!~ais523@unaffiliated/ais523 PRIVMSG #esoteric :Rust's ? was probably first used with Result (the equivalent of Haskell's Either) as that's the type which most commonly needs it in practice < 1542047348 133625 :ski!~ski@remote11.chalmers.se PRIVMSG #esoteric :yea, i just like to emphasize that a monad is not a run-time value, really. a value of monadic type is something else < 1542047382 627855 :ski!~ski@remote11.chalmers.se PRIVMSG #esoteric :your description of `x?' above seemed related to CPS ? < 1542047407 898937 :zzo38!~zzo38@24-207-47-161.eastlink.ca PRIVMSG #esoteric :I don't really like "monad that contains" or "monadic action whose result is". Some monads neither contain such a value nor perform an action having a result < 1542047424 706265 :ski!~ski@remote11.chalmers.se PRIVMSG #esoteric :example ? < 1542047435 578517 :ais523!~ais523@unaffiliated/ais523 PRIVMSG #esoteric :sk; < 1542047443 346278 :ais523!~ais523@unaffiliated/ais523 PRIVMSG #esoteric :*simplest example is probably the void monad < 1542047446 614285 :ski!~ski@remote11.chalmers.se PRIVMSG #esoteric :(i agree about not "containing" a value) < 1542047455 477900 :ais523!~ais523@unaffiliated/ais523 PRIVMSG #esoteric :although, actually, no, that doesn't support return < 1542047468 554155 :zzo38!~zzo38@24-207-47-161.eastlink.ca PRIVMSG #esoteric :And then there is stuff that can contain a value of that type but might not, such as Maybe and [] < 1542047472 293638 :ski!~ski@remote11.chalmers.se PRIVMSG #esoteric :i'm not sure what you have in mind by that term < 1542047475 664675 :ais523!~ais523@unaffiliated/ais523 PRIVMSG #esoteric :I guess I don't intuitively see why a monad should < 1542047494 316395 :ais523!~ais523@unaffiliated/ais523 PRIVMSG #esoteric :ski: "Maybe except it always contains Nothing", for example < 1542047502 887498 :ski!~ski@remote11.chalmers.se PRIVMSG #esoteric :`Maybe' expresses the possibility of not ending up with a result < 1542047503 359708 :HackEso!~h@techne.zem.fi PRIVMSG #esoteric :​/srv/hackeso-code/multibot_cmds/lib/limits: line 5: exec: Maybe': not found < 1542047513 100437 :ski!~ski@remote11.chalmers.se PRIVMSG #esoteric :that's the effect that the `Maybe' monad expresses < 1542047543 607993 :ais523!~ais523@unaffiliated/ais523 PRIVMSG #esoteric :I guess the difference in thought between me and everyone else is that I see monad actions as not necessarily belonging to any particular monad type < 1542047551 692510 :ski!~ski@remote11.chalmers.se PRIVMSG #esoteric :generally, one could say that all behaviour of an action of some monad, apart from simply "yielding" a single result, is an effect < 1542047566 324048 :ais523!~ais523@unaffiliated/ais523 PRIVMSG #esoteric :Haskellers think in terms of "Maybe Integer", whereas I think more in terms of "Nothing" or "Just 6" < 1542047580 617409 :ais523!~ais523@unaffiliated/ais523 PRIVMSG #esoteric :as being of type (Monad x) => x Integer < 1542047580 718112 :ski!~ski@remote11.chalmers.se PRIVMSG #esoteric :so, for `Maybe' an effect is not giving a result value. for list, an effect is not giving a result value, or giving multiple result values < 1542047602 161118 :ski!~ski@remote11.chalmers.se PRIVMSG #esoteric :for state, an effect is depending on, and possibly changing, the implicit state < 1542047617 406468 :ais523!~ais523@unaffiliated/ais523 PRIVMSG #esoteric :ski: why are you treating the case where one result value is available as a special case? < 1542047637 699541 :oren!~oren@ec2-18-212-11-99.compute-1.amazonaws.com PRIVMSG #esoteric :hmmm, can you compose types like "SuchThat f Integer"? < 1542047641 679408 :ais523!~ais523@unaffiliated/ais523 PRIVMSG #esoteric :because that's what "pure"/"return" does, and thus it isn't an effect by definition? < 1542047654 84989 :ski!~ski@remote11.chalmers.se PRIVMSG #esoteric :ais523 : well, `Nothing' is of type `Maybe Integer', not of type `Monad x => x Integer', afaiac -- i'm not following your line of thought here, elaborate ? < 1542047656 100657 :oren!~oren@ec2-18-212-11-99.compute-1.amazonaws.com PRIVMSG #esoteric :e.g. an integer such that f returns true on it? < 1542047705 948314 :ski!~ski@remote11.chalmers.se PRIVMSG #esoteric :ais523 : "why are you treating the case where one result value is available as a special case?" because that's the non-effectful ("pure") case, which is what the `return'/"unit" monadic operation (not that greatly named in Haskell) gives you < 1542047736 779928 :ais523!~ais523@unaffiliated/ais523 PRIVMSG #esoteric :ski: I know, it isn't of type Monad x => x Integer; it's more that for me, the important thing about Nothing and Just 6 is that (Nothing (>>=)) and ((Just 6) (>>=)) are funcitons that take (Integer -> a) arguments < 1542047748 665223 :ski!~ski@remote11.chalmers.se PRIVMSG #esoteric :oren : in dependent typing, you can < 1542047768 251927 :ais523!~ais523@unaffiliated/ais523 PRIVMSG #esoteric :…actually, I think I've realised what's up with my understanding; I think of monads as being /just/ the >>= < 1542047774 841047 :ais523!~ais523@unaffiliated/ais523 PRIVMSG #esoteric :without caring about the "return"/"pure" part of the mat all < 1542047789 126695 :ski!~ski@remote11.chalmers.se PRIVMSG #esoteric :well, both are important < 1542047798 424695 :ski!~ski@remote11.chalmers.se PRIVMSG #esoteric :while admittedly, one is more interesting than the other < 1542047820 149941 :ski!~ski@remote11.chalmers.se PRIVMSG #esoteric :but when branching, you want the ability/choice to not do anything interesting in one branch < 1542047904 422598 :ski!~ski@remote11.chalmers.se PRIVMSG #esoteric :hm, thinking of `(Nothing >>=)' and `(Just 6 >>=)' again to me suggests thinking about continuations (CPS, or in this case, the Codensity monad, which is a kind of optimization that you sometimes want to apply) < 1542047914 984764 :ais523!~ais523@unaffiliated/ais523 PRIVMSG #esoteric :…and thinking about this even more: the behaviour of ">>=" is effectively part of the monad /action/, whereas the behaviour of "return"/"pure" isn't, it's only part of the monad /type/ < 1542047921 273011 :wob_jonas!b03f190e@gateway/web/cgi-irc/kiwiirc.com/ip.176.63.25.14 JOIN :#esoteric < 1542047939 624920 :ski!~ski@remote11.chalmers.se PRIVMSG #esoteric :well, in a sense, both are trivial < 1542047949 408674 :ski!~ski@remote11.chalmers.se PRIVMSG #esoteric :both are about *sequencing* some kind of interesting *effects* < 1542047952 715865 :wob_jonas!b03f190e@gateway/web/cgi-irc/kiwiirc.com/ip.176.63.25.14 PRIVMSG #esoteric :ohai < 1542047958 312397 :ski!~ski@remote11.chalmers.se PRIVMSG #esoteric :but neither of them actually expresses an interesting effect < 1542047965 528725 :oren!~oren@ec2-18-212-11-99.compute-1.amazonaws.com PRIVMSG #esoteric :because if you can have a SuchThat f Integer then you can instead of hacing a function return a Maybe Integer it can *take* a SuchThat f Integer < 1542047990 278228 :ski!~ski@remote11.chalmers.se PRIVMSG #esoteric :if you *only* have `return' and `(>>=)' operations of a monad to work with, that's (close to) useless, you can't do much useful stuff < 1542047995 963590 :ais523!~ais523@unaffiliated/ais523 PRIVMSG #esoteric :so suppose we have code like (Haskell) do {a1 <- a; b1 <- b; return (a+b)} < 1542048011 824986 :ais523!~ais523@unaffiliated/ais523 PRIVMSG #esoteric :is it possible to make something like that work when a and b belong to /different/ monads? my guess is no < 1542048022 705833 :ais523!~ais523@unaffiliated/ais523 PRIVMSG #esoteric :err < 1542048025 94717 :ski!~ski@remote11.chalmers.se PRIVMSG #esoteric :(actually, with higher-order operations, you can do some useful things. but only as library operations that eventually will have to be applied in a particular situation, with a particular monad with more operations available) < 1542048027 813272 :ais523!~ais523@unaffiliated/ais523 PRIVMSG #esoteric :do {a1 <- a; b1 <- b; return (a1+b1)} < 1542048045 310826 :ski!~ski@remote11.chalmers.se PRIVMSG #esoteric :"monad" is like an abstract data type interface, like "priority queue" < 1542048057 350633 :ais523!~ais523@unaffiliated/ais523 PRIVMSG #esoteric :yes < 1542048079 292429 :ski!~ski@remote11.chalmers.se PRIVMSG #esoteric :but, knowing that you have a priority queue, but not being given any additional, implementation-specific operations, for it, you can still do useful things < 1542048084 503361 :ais523!~ais523@unaffiliated/ais523 PRIVMSG #esoteric :I mean, and b have two different types, and each such class belongs to the typeclass Monad < 1542048085 148664 :ski!~ski@remote11.chalmers.se PRIVMSG #esoteric :with a monad, not so much < 1542048121 33479 :ski!~ski@remote11.chalmers.se PRIVMSG #esoteric :typically, you want to have some extra operations, like state operations, non-deterministic operations, exception operations, parsing, concurrency-related, continuation stuff, &c. < 1542048151 591460 :ski!~ski@remote11.chalmers.se PRIVMSG #esoteric :"is it possible to make something like that work when a and b belong to /different/ monads? my guess is no" -- in general, no -- in some particular cases, it may be possible < 1542048159 318864 :ais523!~ais523@unaffiliated/ais523 PRIVMSG #esoteric :OK, I think I know what goes wrong in Haskell; you'd need /two/ returns, the inner one creating a value that's pure with respect to b's effects, the outer one creating a value that's pure with respect to a's effects < 1542048189 298829 :ski!~ski@remote11.chalmers.se PRIVMSG #esoteric :well, that can also be useful, in certain situations < 1542048193 777810 :ski!~ski@remote11.chalmers.se PRIVMSG #esoteric :(but that's a different thing) < 1542048194 67398 :ais523!~ais523@unaffiliated/ais523 PRIVMSG #esoteric :yes < 1542048220 384601 :ais523!~ais523@unaffiliated/ais523 PRIVMSG #esoteric :the closest you can get to what I want in Haskell is do {a1 <- a; return do {b1 <- b; return (a1+b1)}} < 1542048220 773233 :ski!~ski@remote11.chalmers.se PRIVMSG #esoteric :oren : yep < 1542048274 596895 :ski!~ski@remote11.chalmers.se PRIVMSG #esoteric :let's say `a' in the state monad (`State t', say, `t' being the type of the state which the computation depends on, and may change) < 1542048287 419470 :ski!~ski@remote11.chalmers.se PRIVMSG #esoteric :and `b' in the environment/input/reader monad (`Reader t') < 1542048324 414093 :ski!~ski@remote11.chalmers.se PRIVMSG #esoteric :so, you're not interested in the final value of the state, and so you want to avoid bothering getting back the final state result from the "rightmost-leaning branch" in your computation tree < 1542048374 980167 :ski!~ski@remote11.chalmers.se PRIVMSG #esoteric :so, here we'd have a variant of `(>>=)', of type `m a -> (a -> n b) -> n b', where `m' here would be `State t', and `n' would be `Reader t' < 1542048516 772409 :ski!~ski@remote11.chalmers.se PRIVMSG #esoteric :(we also have a conversion of type `m a -> n a', which here just discards the final state, and `n a -> m a', which copies over the input state. the former operation is a post-inverse to the latter, but not the other way around. then there's some laws of interaction between these two conversions, and the `(>>=)' above, and the usual monadic operations) < 1542048543 127088 :shachaf!~shachaf@unaffiliated/shachaf PRIVMSG #esoteric :ski: I don't remember what I wrote after that conversation, I didn't log it or anything. < 1542048564 335010 :ski!~ski@remote11.chalmers.se PRIVMSG #esoteric :(another example would be a version of lists, where we only care about the final number of solutions. so then `m = []' and `n = Const Integer' or somesuch) < 1542048570 925162 :ski!~ski@remote11.chalmers.se PRIVMSG #esoteric :shachaf : fair enough < 1542048662 826492 :ski!~ski@remote11.chalmers.se PRIVMSG #esoteric :ais523 : hm, so perhaps you could elaborate on "…and thinking about this even more: the behaviour of \">>=\" is effectively part of the monad /action/, whereas the behaviour of \"return\"/\"pure\" isn't, it's only part of the monad /type/" ? < 1542048724 440286 :shachaf!~shachaf@unaffiliated/shachaf PRIVMSG #esoteric :ais523: Maybe you mean (Monad x *> x Integer) instead of (Monad x => x Integer)? < 1542048827 874056 :ski!~ski@remote11.chalmers.se PRIVMSG #esoteric :ACTION sighs about presuppositions < 1542048881 924134 :ais523!~ais523@unaffiliated/ais523 QUIT :Remote host closed the connection < 1542048899 922492 :ais523!~ais523@unaffiliated/ais523 JOIN :#esoteric < 1542048908 3035 :ais523!~ais523@unaffiliated/ais523 PRIVMSG #esoteric :ski: well, the only "general-purpose" thing you can do with a monad action is to use its >>= (producing another monad action of the same type) < 1542048983 255399 :ais523!~ais523@unaffiliated/ais523 PRIVMSG #esoteric :so, in a sense, the monad action "is" its >>=, because anything else you could do with it is a special case < 1542048983 344049 :ais523!~ais523@unaffiliated/ais523 QUIT :Remote host closed the connection < 1542048995 497389 :ais523!~ais523@unaffiliated/ais523 JOIN :#esoteric < 1542049007 679577 :ais523!~ais523@unaffiliated/ais523 PRIVMSG #esoteric : meanwhile, "return"/"pure" doesn't take a monad action as argument at all, it's a constructor for monad actions < 1542049018 614855 :ais523!~ais523@unaffiliated/ais523 PRIVMSG #esoteric :and the monad action you construct doesn't actually have anything to do with the monad it belongs to < 1542049030 996276 :ais523!~ais523@unaffiliated/ais523 PRIVMSG #esoteric :because all return values from "return"/"pure" have the /same/ >>= < 1542049069 70954 :ais523!~ais523@unaffiliated/ais523 PRIVMSG #esoteric :(specifically, "(>>=) (return x)" = "(\f -> return (f x))") < 1542049090 41835 :ski!~ski@remote11.chalmers.se PRIVMSG #esoteric :if you don't have access to other monadic operations, for some monad `m', than `return' and `(>>=)', then you can only build actions like e.g. `return x >>= \y -> return (f y)' which (by monad law) is equal to `return (f x)' < 1542049110 411389 :ski!~ski@remote11.chalmers.se PRIVMSG #esoteric :so, every action of type `m a' you can build will then be equal to `return x', for some `x' < 1542049115 811914 :ski!~ski@remote11.chalmers.se PRIVMSG #esoteric :that's not terribly exciting < 1542049135 469920 :ais523!~ais523@unaffiliated/ais523 PRIVMSG #esoteric :ski: I guess I'm assuming I have access to some constructors that return impure monad actions < 1542049159 194265 :ski!~ski@remote11.chalmers.se PRIVMSG #esoteric :(you can do a little more interesting stuff if you take monadic callback arguments, and express patterns of compsing them in particular ways, possibly while simutaneously traversing a data structure, or somesuch) < 1542049197 914837 :ais523!~ais523@unaffiliated/ais523 PRIVMSG #esoteric :…actually, I guess that what I'm doing is not wanting to draw a distinction between any instance of "return 4" < 1542049199 628747 :wob_jonas!b03f190e@gateway/web/cgi-irc/kiwiirc.com/ip.176.63.25.14 PRIVMSG #esoteric :ski: I don't think you can. there's the monad associativity law that says that can't be more interesting. < 1542049217 431238 :shachaf!~shachaf@unaffiliated/shachaf PRIVMSG #esoteric :I like the thing Oleg mentioned about how you can write dne :: (forall m. Monad m => (a -> m Void) -> m Void) -> a < 1542049230 536253 :ais523!~ais523@unaffiliated/ais523 PRIVMSG #esoteric :I don't see any reason why "Just 4" and "[4]" should be considered different values < 1542049239 890687 :ski!~ski@remote11.chalmers.se PRIVMSG #esoteric :wob_jonas : (simple) examples of such "slightly more interesting" operations i have in mind is `sequence' and `mapM' < 1542049271 18496 :ski!~ski@remote11.chalmers.se PRIVMSG #esoteric :(the associativity law says that the "bracketing/grouping" doesn't matter, only the order (may) matter) < 1542049271 236103 :shachaf!~shachaf@unaffiliated/shachaf PRIVMSG #esoteric :It was on http://okmij.org/ftp/Computation/lem.html which is now a 404? Oh no < 1542049317 75982 :ski!~ski@remote11.chalmers.se PRIVMSG #esoteric :ais523 : the reason i was "singling out" `Just 4' and `[4]' above was that they can be expressed as `return x', for some `x' < 1542049332 665906 :ski!~ski@remote11.chalmers.se PRIVMSG #esoteric :and `return' is *the* way to express an "efectfully trivial" action < 1542049332 941542 :shachaf!~shachaf@unaffiliated/shachaf PRIVMSG #esoteric :ski: Did I talk mention my weird "rest of block" programming language idea to you? < 1542049340 131976 :ski!~ski@remote11.chalmers.se PRIVMSG #esoteric :shachaf : i don't think so < 1542049376 994777 :ski!~ski@remote11.chalmers.se PRIVMSG #esoteric :ais523 : i agree this is a bit like singling out the integer zero from all the other integers ("because adding it to something doesn't change the result", so to speak) < 1542049389 842454 :ais523!~ais523@unaffiliated/ais523 PRIVMSG #esoteric :ski: right < 1542049424 580730 :ais523!~ais523@unaffiliated/ais523 PRIVMSG #esoteric :I guess from my point of view, I don't consider "Just 4" and "[4]" to be special in a different sense: the two values are indistinguishable using monad operations, even in an impure language < 1542049450 79787 :ski!~ski@remote11.chalmers.se PRIVMSG #esoteric :from my POV, monads are for capturing/expressing "effects". `return' is used when the interface (the type) allows the possibility of an effect, but in this particular case, we don't want one < 1542049468 684016 :ski!~ski@remote11.chalmers.se PRIVMSG #esoteric :(but if we never want one, then we don't need to use a monad there) < 1542049474 563790 :ais523!~ais523@unaffiliated/ais523 PRIVMSG #esoteric :if you imagine an impure language that has monads, you can do things like "x >>= \y.(unsafePerformIO (putStrLN (show y)))" < 1542049492 859434 :ais523!~ais523@unaffiliated/ais523 PRIVMSG #esoteric :and that lets you distinguish between different monadic actions in x, but you can't distinguish between the various sorts of return 4 < 1542049509 239857 :ski!~ski@remote11.chalmers.se PRIVMSG #esoteric :hm, not sure what you have in mind by "the two values are indistinguishable using monad operations, even in an impure language" < 1542049545 900099 :ski!~ski@remote11.chalmers.se PRIVMSG #esoteric :ais523 : hm, what is the monad used for `(>>=)', there ? < 1542049574 984653 :ais523!~ais523@unaffiliated/ais523 PRIVMSG #esoteric :well, «(return 4) >>= (\y.(unsafePerformIO (putStrLn (show y)))» is, by monad laws, equivalent to «unsafePerformIO (putStrLn "4")»; and it doesn't matter what the monad you use is < 1542049594 628264 :wob_jonas!b03f190e@gateway/web/cgi-irc/kiwiirc.com/ip.176.63.25.14 PRIVMSG #esoteric :but surely [4] and (Just 4) can't be completely interchangable if show can distinguish them < 1542049599 73408 :ais523!~ais523@unaffiliated/ais523 PRIVMSG #esoteric :likewise, in the original example, I'm assuming we don't know what type x has, just that it has type (Monad m) => m Integer < 1542049610 631470 :ski!~ski@remote11.chalmers.se PRIVMSG #esoteric :it looks to me like the type of the latter would be `()'/`unit'/`void', or however you spell it < 1542049626 177176 :ski!~ski@remote11.chalmers.se PRIVMSG #esoteric :which doesn't seem to fit the pattern `m a', of a monad `m' applied to a "monadic result type" `a' < 1542049641 791053 :ais523!~ais523@unaffiliated/ais523 PRIVMSG #esoteric :ski: sorry, I forgot a "return" < 1542049645 611305 :ski!~ski@remote11.chalmers.se PRIVMSG #esoteric :ah, ok < 1542049669 368571 :ais523!~ais523@unaffiliated/ais523 PRIVMSG #esoteric :«x >>= \y.(return (unsafePerformIO (putStrLn (show y))))» < 1542049681 910781 :ski!~ski@remote11.chalmers.se PRIVMSG #esoteric :ACTION assumes ais523 means : just that is has type `m Integer', for some monad `m' (iow for some `m' satisfying `Monad m') < 1542049689 96467 :wob_jonas!b03f190e@gateway/web/cgi-irc/kiwiirc.com/ip.176.63.25.14 PRIVMSG #esoteric :it's not like show is magical or breaks monad laws or purity or anything there < 1542049694 195325 :ais523!~ais523@unaffiliated/ais523 PRIVMSG #esoteric :ski: yes < 1542049716 456885 :ski!~ski@remote11.chalmers.se PRIVMSG #esoteric :(that's why i sighed about presuppositions before. i see this sort of confusion in #haskell all the time) < 1542049717 887991 :shachaf!~shachaf@unaffiliated/shachaf PRIVMSG #esoteric :I think maybe you're thinking in terms of continuations, and how "return x" always calls its continuation exactly once, or something? < 1542049735 950973 :ais523!~ais523@unaffiliated/ais523 PRIVMSG #esoteric :wob_jonas: oh, I'm assuming that our monad action x has an unknown type other than being a monad action which takes functions that take integers in its >>=, so we can't give it directly as an argument to show because we don't know it implements Show < 1542049737 39609 :ski!~ski@remote11.chalmers.se PRIVMSG #esoteric :ais523 : anyway, i'm still now sure where you're going with this "indistinguishable" business < 1542049791 952757 :ais523!~ais523@unaffiliated/ais523 PRIVMSG #esoteric :ski: I guess I'm imagining a language with a weaker type regime than Haskell (possibly even untyped), in which case all possible return values from "return 4" are the same value, given that you have no way to distinguish between them < 1542049816 179901 :ski!~ski@remote11.chalmers.se PRIVMSG #esoteric :hm, it seems to me that's already the case in Haskell < 1542049819 804165 :ais523!~ais523@unaffiliated/ais523 PRIVMSG #esoteric :so if we want a value that's "Maybe Integer" we have two possibilities: a) "return n" for any Integer n; or b) "Nothing" < 1542049836 148930 :ski!~ski@remote11.chalmers.se PRIVMSG #esoteric :ACTION nods < 1542049941 652776 :shachaf!~shachaf@unaffiliated/shachaf PRIVMSG #esoteric :I think Maybe and [] are maybe misleading, especially since Maybe is just an affine special case of []. < 1542049947 981341 :wob_jonas!b03f190e@gateway/web/cgi-irc/kiwiirc.com/ip.176.63.25.14 PRIVMSG #esoteric :ah, so like a... language with a different type system, and Monad defined such that return isn't a method, but a function that doesn't depend on the monad tycon? < 1542049949 302626 :shachaf!~shachaf@unaffiliated/shachaf PRIVMSG #esoteric :Say "m" is (e ->) or something. < 1542049973 219395 :ais523!~ais523@unaffiliated/ais523 PRIVMSG #esoteric :shachaf: which monad is that? Reader? < 1542049984 700097 :shachaf!~shachaf@unaffiliated/shachaf PRIVMSG #esoteric :Yes. < 1542049986 560127 :ais523!~ais523@unaffiliated/ais523 PRIVMSG #esoteric :wob_jonas: right < 1542050011 943829 :shachaf!~shachaf@unaffiliated/shachaf PRIVMSG #esoteric :OK, I guess I might see what you're getting at < 1542050051 968828 :ais523!~ais523@unaffiliated/ais523 PRIVMSG #esoteric :shachaf: so with Reader, you have "return 4" being "\x.4", and you can likewise perform operations on that without knowing what x is < 1542050055 916997 :wob_jonas!b03f190e@gateway/web/cgi-irc/kiwiirc.com/ip.176.63.25.14 PRIVMSG #esoteric :ais523: but then what would the signature of whatever becomes of the (>>=) method in that different Monad be like? < 1542050083 712151 :ski!~ski@remote11.chalmers.se PRIVMSG #esoteric :ACTION isn't even sure what we're currently discussing, anymore < 1542050087 609335 :shachaf!~shachaf@unaffiliated/shachaf PRIVMSG #esoteric :ais523: I don't think the >>=(\y.unsafePerformIO (putStrLn (show y))) thing makes sense, though < 1542050090 978884 :ais523!~ais523@unaffiliated/ais523 PRIVMSG #esoteric :wob_jonas: same as for any monad < 1542050099 804973 :ais523!~ais523@unaffiliated/ais523 PRIVMSG #esoteric ::t (>>=) < 1542050101 345013 :lambdabot!~lambdabot@haskell/bot/lambdabot PRIVMSG #esoteric :Monad m => m a -> (a -> m b) -> m b < 1542050113 641622 :ais523!~ais523@unaffiliated/ais523 PRIVMSG #esoteric :shachaf: why not? < 1542050152 789422 :wob_jonas!b03f190e@gateway/web/cgi-irc/kiwiirc.com/ip.176.63.25.14 PRIVMSG #esoteric :ais523: but then how could that work on both monads created by return and monads created in other ways? < 1542050164 379279 :wob_jonas!b03f190e@gateway/web/cgi-irc/kiwiirc.com/ip.176.63.25.14 PRIVMSG #esoteric :I dunno < 1542050202 296491 :ski!~ski@remote11.chalmers.se PRIVMSG #esoteric :(s/monads/monadic actions/, sorry to bother) < 1542050231 223946 :shachaf!~shachaf@unaffiliated/shachaf PRIVMSG #esoteric :ais523: Which value would that call the continuation with? < 1542050246 546355 :ais523!~ais523@unaffiliated/ais523 PRIVMSG #esoteric :OK, let's look at it this way: suppose we have an operator, let's call it (>>='), which has type (Monad m1, Monad m2) => m1 a -> (a -> m2 b) -> ? b, where ? is some monad < 1542050260 245443 :ski!~ski@remote11.chalmers.se PRIVMSG #esoteric :(well, have fun. i have to leave presently. will perhaps check in later) < 1542050262 985168 :ais523!~ais523@unaffiliated/ais523 PRIVMSG #esoteric :the question is, what type should ? have? < 1542050282 970870 :ais523!~ais523@unaffiliated/ais523 PRIVMSG #esoteric :and I think the answer is "in general you can't answer this, but for many specific cases there's a reasonable answer" < 1542050297 525269 :ais523!~ais523@unaffiliated/ais523 PRIVMSG #esoteric :for example, if either m1 or m2 is Identity, then you can make ? work as the other of the two monads < 1542050313 56537 :wob_jonas!b03f190e@gateway/web/cgi-irc/kiwiirc.com/ip.176.63.25.14 PRIVMSG #esoteric :how did we even get here from places in structure fields? < 1542050317 266211 :ais523!~ais523@unaffiliated/ais523 PRIVMSG #esoteric :and if m1 = m2, then the unknown monad at the end is the same thing < 1542050323 255988 :wob_jonas!b03f190e@gateway/web/cgi-irc/kiwiirc.com/ip.176.63.25.14 PRIVMSG #esoteric :or, um, how did you get here while I was not looking? < 1542050339 648723 :ais523!~ais523@unaffiliated/ais523 PRIVMSG #esoteric :wob_jonas: well, this sort of topic is something that shachaf and I have been discussing on and off for weeks < 1542050393 189576 :shachaf!~shachaf@unaffiliated/shachaf PRIVMSG #esoteric :wob_jonas: This is an orthogonal discussion to the one about structs and lvalues, I think. < 1542050405 136537 :wob_jonas!b03f190e@gateway/web/cgi-irc/kiwiirc.com/ip.176.63.25.14 PRIVMSG #esoteric :ok < 1542050414 128025 :ais523!~ais523@unaffiliated/ais523 PRIVMSG #esoteric :now, if we consistently use >>=' rather than >>=, then a) all existing Haskell code works because m1 and m2 will always have the same type, b) we can consistently define (return a) using the return from Identity, rather than using the original monad, and things will still work < 1542050543 244905 :ais523!~ais523@unaffiliated/ais523 PRIVMSG #esoteric :…so I guess what I want is a world in which all monads are associative in the sense that Monad1 (Monad2 x) and Monad2 (Monad1 x) are the same type < 1542050568 966230 :wob_jonas!b03f190e@gateway/web/cgi-irc/kiwiirc.com/ip.176.63.25.14 PRIVMSG #esoteric :ais523: but isn't that impossible? < 1542050575 235468 :ais523!~ais523@unaffiliated/ais523 PRIVMSG #esoteric :maybe I should try to write a concrete language like this and see where it goes wrong < 1542050582 10222 :ais523!~ais523@unaffiliated/ais523 PRIVMSG #esoteric :wob_jonas: it depends on how many monads you support < 1542050592 53186 :ais523!~ais523@unaffiliated/ais523 PRIVMSG #esoteric :it's certianly possible if you have only a small whitelist of monads < 1542050594 781345 :wob_jonas!b03f190e@gateway/web/cgi-irc/kiwiirc.com/ip.176.63.25.14 PRIVMSG #esoteric :well sure, if you only have Identity and nothing else that it could work < 1542050622 43161 :ais523!~ais523@unaffiliated/ais523 PRIVMSG #esoteric :for example, we could combine Maybe and List by deleting Nothiing-valued list elements < 1542050677 496807 :shachaf!~shachaf@unaffiliated/shachaf PRIVMSG #esoteric :Something like https://en.wikipedia.org/wiki/Distributive_law_between_monads < 1542050689 424939 :shachaf!~shachaf@unaffiliated/shachaf PRIVMSG #esoteric :I think I remember something about a system that used this? But I don't remember the details < 1542050864 21700 :ais523!~ais523@unaffiliated/ais523 PRIVMSG #esoteric :actually, an even better way to think about this is to think about the mathematical definition of monads (which uses two operations, one of type (x → m x), one of type (m m x → m x)); the ideal would be for the (m m x → m x) to work with two /different/ ms on the LHS < 1542050898 551748 :ais523!~ais523@unaffiliated/ais523 PRIVMSG #esoteric :in Haskell, at the moment, it's common to use monad transformers for that sort of thing < 1542050924 209196 :ais523!~ais523@unaffiliated/ais523 PRIVMSG #esoteric :e.g. it's easy enough to write a function (Reader (IO x)) → ((ReaderT IO) x) < 1542050941 781442 :nfd!~nfd9001@c-73-157-90-101.hsd1.wa.comcast.net JOIN :#esoteric < 1542050967 846789 :ais523!~ais523@unaffiliated/ais523 PRIVMSG #esoteric :…do monad /transformers/ always commute with each other? my guess is "not always, but they often do" < 1542050990 284467 :shachaf!~shachaf@unaffiliated/shachaf PRIVMSG #esoteric :No < 1542051000 329230 :shachaf!~shachaf@unaffiliated/shachaf PRIVMSG #esoteric :Monad transformers are kind of ad-hoc < 1542051014 52167 :wob_jonas!b03f190e@gateway/web/cgi-irc/kiwiirc.com/ip.176.63.25.14 PRIVMSG #esoteric :they don't commute < 1542051022 681101 :xkapastel!uid17782@gateway/web/irccloud.com/x-ndtowjjxdbhvhvvl JOIN :#esoteric < 1542051536 109456 :shachaf!~shachaf@unaffiliated/shachaf PRIVMSG #esoteric :ski: So the idea is that you have a bunch of control flow things that affect "the rest of the block" < 1542051553 817431 :shachaf!~shachaf@unaffiliated/shachaf PRIVMSG #esoteric :ski: Like { if(p); ... } for what's normally written as if (p) { ... } < 1542051567 295020 :john_metcalf!~digital_w@host81-136-80-199.range81-136.btcentralplus.com QUIT :Ping timeout: 240 seconds < 1542051571 606902 :shachaf!~shachaf@unaffiliated/shachaf PRIVMSG #esoteric :And { x := for(xs); ... } for what's normally for (x : xs) { ... } or something < 1542051619 299488 :shachaf!~shachaf@unaffiliated/shachaf PRIVMSG #esoteric :I now think that maybe this should be marked more explicitly, something like { if(p)`; ... }, where ` on a value means "pass the rest of the block as a continuation" < 1542051674 539623 :shachaf!~shachaf@unaffiliated/shachaf PRIVMSG #esoteric :I think this is maybe similar to delimited continuations in a restricted form, with {} having a role similar to reset? < 1542051683 944723 :shachaf!~shachaf@unaffiliated/shachaf PRIVMSG #esoteric :And { A; B; C; } meaning { A; { B; C; } } < 1542051829 884638 :shachaf!~shachaf@unaffiliated/shachaf PRIVMSG #esoteric :Do you know of something like that? < 1542051859 798034 :wob_jonas!b03f190e@gateway/web/cgi-irc/kiwiirc.com/ip.176.63.25.14 PRIVMSG #esoteric :yeah, you've asked about that earlier here, I think < 1542051879 862306 :zzo38!~zzo38@24-207-47-161.eastlink.ca PRIVMSG #esoteric :I did think some time I wanted to have the possibility to have a macro in JavaScript that allows passing the rest of the function as a continuation. < 1542051893 134145 :wob_jonas!b03f190e@gateway/web/cgi-irc/kiwiirc.com/ip.176.63.25.14 PRIVMSG #esoteric :there's prolog's nondeterminism which you could think of as a special case of that < 1542052548 624021 :wob_jonas!b03f190e@gateway/web/cgi-irc/kiwiirc.com/ip.176.63.25.14 PRIVMSG #esoteric :but it's not delimited, it takes the whole rest of the run of the program, not just the rest of the "block" < 1542052708 372195 :ais523!~ais523@unaffiliated/ais523 PRIVMSG #esoteric :well, unless you have an alternative (based on ; or on a second definition of the same predicate) < 1542055067 983738 :zzo38!~zzo38@24-207-47-161.eastlink.ca PRIVMSG #esoteric :I have now added two new responses to the Netsubscribe protocol, which are & (deferred processing) and T (timeout). > 1542055325 681020 PRIVMSG #esoteric :14[[07Esolang:Featured languages/Candidates14]]4 10 02https://esolangs.org/w/index.php?diff=58344&oldid=57018 5* 03Camto 5* (+69) 10Burlesque < 1542055481 430231 :wob_jonas!b03f190e@gateway/web/cgi-irc/kiwiirc.com/ip.176.63.25.14 QUIT :Quit: http://www.kiwiirc.com/ - A hand crafted IRC client < 1542055500 237570 :wob_jonas!b03f190e@gateway/web/cgi-irc/kiwiirc.com/ip.176.63.25.14 JOIN :#esoteric < 1542055504 481818 :wob_jonas!b03f190e@gateway/web/cgi-irc/kiwiirc.com/ip.176.63.25.14 QUIT :Client Quit > 1542056716 453865 PRIVMSG #esoteric :14[[07A14]]4 10 02https://esolangs.org/w/index.php?diff=58345&oldid=58336 5* 03Cortex 5* (+23) 10 > 1542056780 814034 PRIVMSG #esoteric :14[[07A14]]4 10 02https://esolangs.org/w/index.php?diff=58346&oldid=58345 5* 03Cortex 5* (+0) 10/* Numbers from 1 to 10 */ > 1542057094 322930 PRIVMSG #esoteric :14[[07A14]]4 10 02https://esolangs.org/w/index.php?diff=58347&oldid=58346 5* 03Cortex 5* (+168) 10 > 1542057118 637717 PRIVMSG #esoteric :14[[07A14]]4 10 02https://esolangs.org/w/index.php?diff=58348&oldid=58347 5* 03Cortex 5* (+4) 10 > 1542058336 677822 PRIVMSG #esoteric :14[[07Web framework list14]]4 M10 02https://esolangs.org/w/index.php?diff=58349&oldid=50039 5* 03Camto 5* (+21) 10Retrieved from Wayback Machine. < 1542059572 518919 :moei!~moei@softbank221078042071.bbtec.net QUIT :Quit: Leaving... > 1542062258 187513 PRIVMSG #esoteric :14[[07User:JonoCode937414]]4 10 02https://esolangs.org/w/index.php?diff=58350&oldid=57956 5* 03JonoCode9374 5* (+76) 10 < 1542064497 123898 :sleepnap!~thomas@2603:3015:260e:1900::13ed QUIT :Quit: Leaving. < 1542065607 388998 :AnotherTest!~turingcom@d51A46C74.access.telenet.be QUIT :Ping timeout: 240 seconds < 1542065858 462915 :tromp!~tromp@ip-217-103-3-94.ip.prioritytelecom.net QUIT :Remote host closed the connection < 1542065874 313409 :tromp!~tromp@ip-217-103-3-94.ip.prioritytelecom.net JOIN :#esoteric < 1542066034 90405 :Essadon!~Essadon@81-225-32-185-no249.tbcn.telia.com QUIT :Quit: Qutting < 1542066803 749217 :Lord_of_Life_!~Lord@46.217.20.124 JOIN :#esoteric < 1542066996 774145 :Lord_of_Life!~Lord@unaffiliated/lord-of-life/x-0885362 QUIT :Ping timeout: 268 seconds < 1542066997 269050 :Lord_of_Life_!~Lord@46.217.20.124 NICK :Lord_of_Life < 1542066997 902615 :Lord_of_Life!~Lord@46.217.20.124 QUIT :Changing host < 1542066997 902682 :Lord_of_Life!~Lord@unaffiliated/lord-of-life/x-0885362 JOIN :#esoteric