Newest at the top
| 2024-04-25 15:02:03 +0200 | destituion | (~destituio@2a02:2121:340:2456:fffe:d0f:7737:dd1) |
| 2024-04-25 15:00:53 +0200 | xff0x | (~xff0x@2405:6580:b080:900:78b5:44c3:11b7:3511) |
| 2024-04-25 15:00:11 +0200 | danza | (~francesco@151.19.233.234) |
| 2024-04-25 15:00:04 +0200 | destituion | (~destituio@85.221.111.174) (Ping timeout: 268 seconds) |
| 2024-04-25 14:47:13 +0200 | <tomsmeding> | when I figured out the model of how this works, I was delighted by how structured it really is |
| 2024-04-25 14:46:44 +0200 | <tomsmeding> | unboxed types can never be lifted (because they are not represented by a pointer, they are just the value itself), hence the liftedness distinction applies to boxed types only |
| 2024-04-25 14:46:11 +0200 | <tomsmeding> | with -XUnliftedDatatypes you can define your own unlifted data types https://downloads.haskell.org/ghc/latest/docs/users_guide/exts/primitives.html#extension-UnliftedD… |
| 2024-04-25 14:46:02 +0200 | tromp | (~textual@92-110-219-57.cable.dynamic.v4.ziggo.nl) |
| 2024-04-25 14:45:06 +0200 | <tomsmeding> | boxed types can be unlifted; this means that _|_ is not an element of that type |
| 2024-04-25 14:44:24 +0200 | <tomsmeding> | lifted values are those that can be bottom (i.e. that are "lazy") |
| 2024-04-25 14:44:14 +0200 | <tomsmeding> | boxed values are those that are represented by a pointer to a heap location |
| 2024-04-25 14:43:34 +0200 | <tomsmeding> | (which is something different from "unlifted", which is what I said before) |
| 2024-04-25 14:43:21 +0200 | <tomsmeding> | Int# is unboxed |
| 2024-04-25 14:43:15 +0200 | <yahb2> | type Int# :: TYPE 'IntRep ; data Int# ; -- Defined in ‘GHC.Prim’ |
| 2024-04-25 14:43:15 +0200 | <tomsmeding> | % :i Int# |
| 2024-04-25 14:42:47 +0200 | <tomsmeding> | https://hackage.haskell.org/package/base-4.19.1.0/docs/GHC-Exts.html#t:RuntimeRep |
| 2024-04-25 14:42:18 +0200 | sp1ff | (~user@c-24-21-45-157.hsd1.wa.comcast.net) |
| 2024-04-25 14:40:17 +0200 | totalghost | (~ghost@172-105-178-131.ip.linodeusercontent.com) (Ping timeout: 256 seconds) |
| 2024-04-25 14:34:56 +0200 | zetef | (~quassel@93.122.248.176) |
| 2024-04-25 14:32:50 +0200 | danza | (~francesco@151.37.242.9) (Ping timeout: 256 seconds) |
| 2024-04-25 14:31:47 +0200 | yin | (~yin@user/zero) (Ping timeout: 256 seconds) |
| 2024-04-25 14:31:04 +0200 | jco | (~jco@90-230-146-75-no600.tbcn.telia.com) () |
| 2024-04-25 14:30:55 +0200 | jco | (~jco@90-230-146-75-no600.tbcn.telia.com) |
| 2024-04-25 14:28:15 +0200 | <lyxia> | it's different |
| 2024-04-25 14:19:59 +0200 | bitdex | (~bitdex@gateway/tor-sasl/bitdex) (Quit: = "") |
| 2024-04-25 14:18:16 +0200 | <Inst> | so it's sort of the reverse of newtype? |
| 2024-04-25 14:11:08 +0200 | danza | (~francesco@151.37.242.9) |
| 2024-04-25 14:07:43 +0200 | pastly | (~pastly@gateway/tor-sasl/pastly) |
| 2024-04-25 14:06:11 +0200 | kshube | (~kshube@49.207.195.24) (Client Quit) |
| 2024-04-25 14:06:06 +0200 | pastly | (~pastly@gateway/tor-sasl/pastly) (Ping timeout: 260 seconds) |
| 2024-04-25 14:06:03 +0200 | kshube | (~kshube@49.207.195.24) |
| 2024-04-25 14:05:29 +0200 | xff0x | (~xff0x@125x103x176x34.ap125.ftth.ucom.ne.jp) (Ping timeout: 268 seconds) |
| 2024-04-25 14:00:55 +0200 | billchenchina | (~billchenc@103.152.35.21) (Remote host closed the connection) |
| 2024-04-25 13:59:52 +0200 | billchenchina | (~billchenc@103.152.35.21) |
| 2024-04-25 13:59:36 +0200 | yin | (~yin@user/zero) |
| 2024-04-25 13:59:21 +0200 | yin | (~yin@user/zero) (Quit: Reconnecting) |
| 2024-04-25 13:58:28 +0200 | totalghost | (~ghost@172-105-178-131.ip.linodeusercontent.com) |
| 2024-04-25 13:47:12 +0200 | hgolden | (~hgolden@2603:8000:9d00:3ed1:f849:272c:fda5:33c9) |
| 2024-04-25 13:41:36 +0200 | yin | (~yin@user/zero) |
| 2024-04-25 13:34:06 +0200 | <tomsmeding> | so if you evaluate until you have an I#, you automatically also have the Int# inside |
| 2024-04-25 13:33:52 +0200 | <tomsmeding> | Int# is an unlifted data type, so it has no bottom value |
| 2024-04-25 13:33:28 +0200 | <tomsmeding> | I think seq'ing an Int constructor will evaluate the Int# |
| 2024-04-25 13:33:17 +0200 | <Inst> | not until i pattern match, run an eq, or do something like print |
| 2024-04-25 13:32:48 +0200 | <Inst> | addition, basic arithmetic operations, is also lazy |
| 2024-04-25 13:32:34 +0200 | <Inst> | the implication is also that addition in Haskell... well, i wasn't actualyl that surprised by that! |
| 2024-04-25 13:31:30 +0200 | <Inst> | is that called boxing? |
| 2024-04-25 13:31:06 +0200 | <Inst> | and iirc even if i seq an Int constructor (but not deepseq), it won't evaluate the underlying number |
| 2024-04-25 13:27:26 +0200 | <tomsmeding> | so yes, it is lazy |
| 2024-04-25 13:27:22 +0200 | <tomsmeding> | Int is just `data Int = I# Int#` |
| 2024-04-25 13:13:43 +0200 | ocra8 | (ocra8@user/ocra8) |