Home freenode/#haskell: Logs Calendar

Logs: freenode/#haskell

←Prev  Next→
Page 1 .. 1432 1433 1434 1435 1436 1437 1438 1439 1440 1441 1442 .. 5022
— 502,152 events total
2020-11-21 20:50:37 <merijn> MarcelineVQ: Of course
2020-11-21 20:50:42 → Volt_ joins (~Volt_@c-73-145-164-70.hsd1.mi.comcast.net)
2020-11-21 20:50:46 <merijn> MarcelineVQ: There's no guarantees for your hardware either :p
2020-11-21 20:51:07 <merijn> At some point you need to settle for a realistic threat model
2020-11-21 20:51:21 <hpc> that's the nice thing about hardware, the fires are literal
2020-11-21 20:51:24 <merijn> I would recommend following James Mickens' threat model :p
2020-11-21 20:52:10 <monochrom> Just use a nitrogen chamber.
2020-11-21 20:52:13 <merijn> I refer to the threat model table on page 2 of https://www.usenix.org/system/files/1401_08-12_mickens.pdf (although, in all honestly I highly recommend reading the entire thing)
2020-11-21 20:52:25 <merijn> s/honestly/honesty
2020-11-21 20:53:10 <monochrom> Use the subtraction method. s/in all// is a more efficient fix. :)
2020-11-21 20:54:30 hackage zio 0.1.0.2 - App-centric Monad-transformer based on Scala ZIO (UIO + ReaderT + ExceptT). https://hackage.haskell.org/package/zio-0.1.0.2 (bebarker)
2020-11-21 20:54:32 <hpc> oh man, that pdf is great
2020-11-21 20:55:01 <merijn> hpc: Good news for you
2020-11-21 20:55:13 <merijn> hpc: He wrote like 10 more editorials and gave several equally amazing talks
2020-11-21 20:55:38 <merijn> The Night Watch is especially nice if you've ever done any systems stuff
2020-11-21 20:56:18 × zyklotomic quits (~ethan@unaffiliated/chocopuff) (Ping timeout: 256 seconds)
2020-11-21 20:58:30 × LKoen quits (~LKoen@169.244.88.92.rev.sfr.net) (Remote host closed the connection)
2020-11-21 20:58:50 → xsperry joins (~as@unaffiliated/xsperry)
2020-11-21 20:59:42 × falafel__ quits (~falafel@2601:547:1303:b30:7811:313f:d0f3:f9f4) (Ping timeout: 260 seconds)
2020-11-21 21:00:09 × tomboy64 quits (~tomboy64@gateway/tor-sasl/tomboy64) (Read error: Connection reset by peer)
2020-11-21 21:01:04 → tomboy64 joins (~tomboy64@gateway/tor-sasl/tomboy64)
2020-11-21 21:03:00 hackage pandoc-crossref 0.3.8.4 - Pandoc filter for cross-references https://hackage.haskell.org/package/pandoc-crossref-0.3.8.4 (lierdakil)
2020-11-21 21:03:11 × p-core quits (~Thunderbi@2a0e:1c80:4:1023::1004) (Ping timeout: 272 seconds)
2020-11-21 21:03:49 × AlterEgo- quits (~ladew@124-198-158-163.dynamic.caiway.nl) (Quit: Leaving)
2020-11-21 21:04:08 <triteraflops> I just learned about Clean. Looks like that's the way to go for building a real thing today using linear types.
2020-11-21 21:04:27 <merijn> Clean doesn't have linear types, I don't think?
2020-11-21 21:04:35 <merijn> Pretty sure they only have uniqueness types, no?
2020-11-21 21:04:41 <ski> correct
2020-11-21 21:04:43 <triteraflops> isn't that the same thing?
2020-11-21 21:04:43 <c_wraith> Uniqueness types are a lot more useful anyway
2020-11-21 21:04:49 <ski> triteraflops, nope
2020-11-21 21:04:53 <merijn> Although, if you wanna built CRUD applications for Windows, Clean is good ;)
2020-11-21 21:05:25 → pavonia joins (~user@unaffiliated/siracusa)
2020-11-21 21:06:19 <triteraflops> ski: so what's the difference?
2020-11-21 21:07:21 <c_wraith> a linear function says "this function uses this argument exactly once". A function with a unique constraint says "this value is passed to this function and not use anywhere else"
2020-11-21 21:07:54 <ski> (Mercury's another language with uniqueness. although, in that case, not put into the types, but rather the "insts" (instatiation states). Rust also has stuff that is of a somewhat similar ilk)
2020-11-21 21:08:48 <triteraflops> hm, kind of moves the bubble over.
2020-11-21 21:09:27 <triteraflops> uniqueness puts constraints on other functions and linearity is a constraint only on that function
2020-11-21 21:09:38 <ski> triteraflops : with uniqueness, you know that the value haven't been duplicated in the past (but you're allowed to duplicate in the future). with linearity/affinity, you're promising not to duplicate it in the future (but it might already have been duplicated in the past)
2020-11-21 21:09:47 <c_wraith> more generally, uniqueness puts the constraint on the caller. But yes.
2020-11-21 21:11:12 <triteraflops> But they're kinda solving the same problem, of compile-time duplication awareness and avoidance
2020-11-21 21:11:38 <ski> (difference between linearity and affinity is that affinity allows you to (implicitly) discard, while linearity doesn't (you could still pass explicitly to a waste disposal facility))
2020-11-21 21:12:18 <triteraflops> Then there's C++'s move semantics, which are just silly.
2020-11-21 21:12:29 <triteraflops> I still don't understand them.
2020-11-21 21:12:40 <triteraflops> too complicated
2020-11-21 21:13:34 <[exa]> there's no move
2020-11-21 21:14:52 × alx741 quits (~alx741@181.196.69.47) (Ping timeout: 260 seconds)
2020-11-21 21:15:06 <merijn> move semantics are ok, they're pretty straightforward it's the rvalue reference stuff that's a confusing mess :)
2020-11-21 21:15:12 <ski> it seems to me there's an interesting language trapped inside C++ lvalue & rvalue references, move semantics, perfect forwarding, wanting to be released
2020-11-21 21:15:35 <c_wraith> C++ is long past mere lvalues and rvalues. now it has a whole hierarchy
2020-11-21 21:15:40 <merijn> pvalues!
2020-11-21 21:15:59 <merijn> lvalue references, rvalue references!
2020-11-21 21:15:59 <ski> (wg 70
2020-11-21 21:16:04 <triteraflops> copy elision
2020-11-21 21:16:08 <merijn> I think we have like prvalues too?
2020-11-21 21:16:15 <triteraflops> yeah that too
2020-11-21 21:16:25 <merijn> triteraflops: copy elision is obsoleted by move semantics and rvalue references
2020-11-21 21:16:43 <triteraflops> well, good for C++
2020-11-21 21:16:46 <triteraflops> lol
2020-11-21 21:16:54 <triteraflops> I gave up on it a while ago
2020-11-21 21:17:04 <[exa]> there are 3 in fact, standard section 7.2.1 specifies just lvalue, xvalue and prvalue
2020-11-21 21:17:16 <merijn> move semantics are just a more formal and structured way of considering copy elision without worrying whether copy elision will trigger by the compiler, since it's now specified
2020-11-21 21:17:28 <[exa]> copy&move elision are completely orthogonal concepts related to function call semantics
2020-11-21 21:17:41 <merijn> anyhoo
2020-11-21 21:17:54 <merijn> This conversation is triggering, so time to stop coding/ircing ;)
2020-11-21 21:18:00 → knupfer joins (~Thunderbi@200116b82ce1e10028bb8f758d5216f6.dip.versatel-1u1.de)
2020-11-21 21:19:06 × conal quits (~conal@64.71.133.70) (Quit: Computer has gone to sleep.)
2020-11-21 21:21:00 → LKoen joins (~LKoen@169.244.88.92.rev.sfr.net)
2020-11-21 21:21:40 <triteraflops> wth, there's like 5 people in #cleanlang. Why isn't this language more popular?
2020-11-21 21:23:38 <merijn> Because I think the only people using it are all at the Radboud Universiteit :p
2020-11-21 21:24:16 <merijn> It's mostly a research language, I don't think there's a very big community working on libraries, packages, etc.
2020-11-21 21:24:17 <ski> Clean isn't bad
2020-11-21 21:24:37 <merijn> ski: I didn't say it was, I just said it didn't have any users ;)
2020-11-21 21:24:44 × jonatanb quits (jonatanb@gateway/vpn/protonvpn/jonatanb) (Remote host closed the connection)
2020-11-21 21:25:01 <merijn> You need critical mass for libraries and you need libraries for users
2020-11-21 21:25:15 <[exa]> Evil me: Clean isn't popular because it didn't target the web. Realistic me: Well, yeah
2020-11-21 21:25:29 ski . o O ( "Recently, researchers have experimented with new I/O combinators based on monads." -- <https://web.archive.org/web/20140303101716/http://www-fp.dcs.st-and.ac.uk/%7Ekh/papers/io-tutorial/io-tutorial.html> )
2020-11-21 21:25:56 <merijn> Every year at the NL-FP day we still have the mandatory one or two Clean talks :p
2020-11-21 21:26:28 <dsal> How many days of dirty talks?
2020-11-21 21:26:52 <ski> merijn : ah, sorry. i didn't mean that to sound like being an opposing point to what you said, just as a general sentiment response to triteraflops
2020-11-21 21:28:11 × geekosaur quits (82659a09@host154-009.vpn.uakron.edu) (Remote host closed the connection)
2020-11-21 21:28:15 × coot quits (~coot@37.30.49.253.nat.umts.dynamic.t-mobile.pl) (Quit: coot)
2020-11-21 21:28:45 × gproto23 quits (~gproto23@unaffiliated/gproto23) (Ping timeout: 256 seconds)
2020-11-21 21:28:50 → Tario joins (~Tario@201.192.165.173)
2020-11-21 21:29:57 → conal joins (~conal@64.71.133.70)
2020-11-21 21:32:09 <ski> Clean has an interesting integration of `Dynamic' with pattern-matching, allowing them to trivially implement e.g. `dynApply'; <https://clean.cs.ru.nl/download/html_report/CleanRep.2.2_10.htm#_Toc311798086>
2020-11-21 21:32:54 <monochrom> As a general heuristic, if you language doesn't use C syntax, it won't be popular.
2020-11-21 21:33:15 <merijn> monochrom: SQL? :P
2020-11-21 21:33:50 <monochrom> Hey, that's a great idea, perhaps the no-sql movement started with hating SQL syntax!
2020-11-21 21:33:52 × heatsink quits (~heatsink@107-136-5-69.lightspeed.sntcca.sbcglobal.net) (Remote host closed the connection)
2020-11-21 21:35:05 → jonatanb joins (jonatanb@gateway/vpn/protonvpn/jonatanb)
2020-11-21 21:35:09 × ClaudiusMaximus quits (~claude@unaffiliated/claudiusmaximus) (Quit: ->)
2020-11-21 21:35:13 <monochrom> Also it's just a heuristic. Python deviates partly from C syntax, and it's still popular. Although, Python probably shows you the largest extent of deviation you can afford.
2020-11-21 21:36:17 <monochrom> Namely, if you still stick to the "f(x,y,z)" syntax, if you only replace {;} by layout, you will be OK.
2020-11-21 21:36:53 <monochrom> Whereas Lisp's "(f x y z)" and SML's "f x y z" prove to be going too far.
2020-11-21 21:39:51 → invaser joins (~Thunderbi@31.148.23.125)
2020-11-21 21:41:34 <ski> perhaps we just have to draw it out more
2020-11-21 21:41:49 × Volt_ quits (~Volt_@c-73-145-164-70.hsd1.mi.comcast.net) (Quit: )
2020-11-21 21:41:54 → alx741 joins (~alx741@186.178.110.117)
2020-11-21 21:43:38 → sand_dull joins (~theuser@c-73-149-95-105.hsd1.ct.comcast.net)
←Prev  Next→
Page 1 .. 1432 1433 1434 1435 1436 1437 1438 1439 1440 1441 1442 .. 5022

All times are in UTC.