Logs: freenode/#haskell
| 2021-03-18 19:56:51 | <bbhoss> | haha alright, it seemed a little clunky, but I am a n00b obviously. I guess alternatively I could export a function that does this? |
| 2021-03-18 19:56:51 | <geekosaur> | there is of course simply exporting everything by not specifying an export list |
| 2021-03-18 19:57:19 | → | teardown joins (~user@gateway/tor-sasl/mrush) |
| 2021-03-18 19:58:07 | <monochrom> | There are times you export just the type name, but hide constructors and field selectors, to present your type as an abstract type. |
| 2021-03-18 19:58:45 | <monochrom> | Therefore one way or another, there needs one syntax for type-only, and one other syntax for type-and-its-guts. |
| 2021-03-18 19:58:53 | hackage | tasty-bench 0.2.3 - Featherlight benchmark framework https://hackage.haskell.org/package/tasty-bench-0.2.3 (Bodigrim) |
| 2021-03-18 19:59:03 | <monochrom> | That is the minimum requirement for any syntax design at all. |
| 2021-03-18 19:59:11 | → | idhugo joins (~idhugo@87-49-147-45-mobile.dk.customer.tdc.net) |
| 2021-03-18 19:59:12 | <bbhoss> | got it, just want to make sure I was being idiomatic |
| 2021-03-18 20:00:23 | <bbhoss> | I don't need to export the type AND the MyType(..) do I? It seems to work without exporting the type |
| 2021-03-18 20:01:03 | <edmundnoble> | You cannot export a type's constructors without exporting the type |
| 2021-03-18 20:01:14 | <geekosaur> | because it'd be meaningless |
| 2021-03-18 20:01:18 | <edmundnoble> | Well |
| 2021-03-18 20:01:32 | <edmundnoble> | Hm can you export functions without exporting their return type |
| 2021-03-18 20:01:42 | <edmundnoble> | Or I suppose more generally, names without exporting their types |
| 2021-03-18 20:01:50 | <Uniaika> | hmm |
| 2021-03-18 20:01:57 | <Uniaika> | I have a naïve question |
| 2021-03-18 20:02:03 | <edmundnoble> | Best kind |
| 2021-03-18 20:02:11 | <bbhoss> | right, so exporting MyType(..) implies that the type is exported |
| 2021-03-18 20:02:16 | <edmundnoble> | Does yes |
| 2021-03-18 20:02:16 | <Uniaika> | if unboxed integers (for instance) are so great for performance, why aren't they the default kind of integer? |
| 2021-03-18 20:02:29 | <edmundnoble> | Unboxed integers are not necessarily great for performance |
| 2021-03-18 20:02:33 | <edmundnoble> | Because they are not lazy |
| 2021-03-18 20:02:40 | <edmundnoble> | But even assuming they were, in all cases, better for performance |
| 2021-03-18 20:02:43 | <mniip> | Uniaika, historical reasons |
| 2021-03-18 20:02:56 | <edmundnoble> | Type parameters cannot be instantiated by unboxed types in most cases |
| 2021-03-18 20:03:03 | <Uniaika> | oh my, mniip and edmund in the chan. I feel like on Discord |
| 2021-03-18 20:03:09 | <Uniaika> | edmundnoble: I see! |
| 2021-03-18 20:03:09 | <mniip> | we've only very recently figured out the story with runtime representations in kinds |
| 2021-03-18 20:03:09 | <edmundnoble> | Lmao I haven't seen you on discord |
| 2021-03-18 20:03:14 | <mniip> | hecate |
| 2021-03-18 20:03:20 | <Uniaika> | edmundnoble: yes you did :3 |
| 2021-03-18 20:03:21 | <edmundnoble> | Oh hai |
| 2021-03-18 20:03:32 | <mniip> | furthermore you lose polymorphism |
| 2021-03-18 20:03:40 | <Uniaika> | mniip: Int vs Int# ? |
| 2021-03-18 20:03:43 | <mniip> | yes |
| 2021-03-18 20:03:46 | <mniip> | sometime edwardk is trying to win back |
| 2021-03-18 20:03:50 | <Uniaika> | but aren't they both concrete types? |
| 2021-03-18 20:03:52 | × | idhugo quits (~idhugo@87-49-147-45-mobile.dk.customer.tdc.net) (Remote host closed the connection) |
| 2021-03-18 20:03:52 | <edmundnoble> | Oh right so if you mean "why aren't they the default" like why isn't that the default `Num` instance |
| 2021-03-18 20:03:57 | <edmundnoble> | There is no `Num` instance for `Int#` |
| 2021-03-18 20:03:57 | <mniip> | ask him about compiling a package 1700 times with backpack |
| 2021-03-18 20:03:57 | <edmundnoble> | At all |
| 2021-03-18 20:04:05 | <dolio> | You can't put an Int# in a list. |
| 2021-03-18 20:04:08 | <edmundnoble> | Because `Int#` is an unboxed type, so it doesn't have kind `*` |
| 2021-03-18 20:04:09 | <koz_> | There is no anything instance for Int#. |
| 2021-03-18 20:04:13 | <edmundnoble> | Well |
| 2021-03-18 20:04:16 | <mniip> | % [0#] |
| 2021-03-18 20:04:16 | <yahb> | mniip: ; <interactive>:31:2: error:; * Couldn't match a lifted type with an unlifted type; When matching types; a :: *; Int# :: TYPE 'GHC.Exts.IntRep; * In the expression: 0#; In the expression: [0#]; In an equation for `it': it = [0#]; * Relevant bindings include it :: [a] (bound at <interactive>:31:1) |
| 2021-03-18 20:04:24 | <mniip> | it really doesn't work |
| 2021-03-18 20:04:27 | <edmundnoble> | I think you can have type class instances for unlifted types |
| 2021-03-18 20:04:38 | <mniip> | you can write things for unlifted types yes |
| 2021-03-18 20:04:38 | <Uniaika> | I see I see |
| 2021-03-18 20:04:42 | <edmundnoble> | But they will be able to do very little, subject to levity polymorphism's restrictions |
| 2021-03-18 20:04:45 | <dolio> | Everything that deals with Int# has to specifically deal with it, and not be polymorphic. |
| 2021-03-18 20:04:48 | <mniip> | but you can never accept a runtimerep-polymorphic argument |
| 2021-03-18 20:04:52 | <edmundnoble> | Right |
| 2021-03-18 20:04:54 | <koz_> | edmundnoble: Really? I thought that type variables for type classes default to Type? |
| 2021-03-18 20:04:58 | <mniip> | this includes data constructors and class methods |
| 2021-03-18 20:05:00 | <edmundnoble> | The big issue is that unlifted shit doesn't have the kind `*` |
| 2021-03-18 20:05:09 | <edmundnoble> | And almost all terms have types with kind `*` |
| 2021-03-18 20:05:14 | <Uniaika> | % :k 0# |
| 2021-03-18 20:05:14 | <yahb> | Uniaika: ; <interactive>:1:1: error: parse error on input `0#' |
| 2021-03-18 20:05:19 | <Uniaika> | dangit |
| 2021-03-18 20:05:21 | <myShoggoth> | Streaming GHC GC code reading and analysis: https://www.twitch.tv/myshoggoth |
| 2021-03-18 20:05:23 | <mniip> | % :k Int# |
| 2021-03-18 20:05:23 | <yahb> | mniip: TYPE 'GHC.Exts.IntRep |
| 2021-03-18 20:05:27 | → | pk37 joins (7aa1ce54@122.161.206.84) |
| 2021-03-18 20:05:28 | <koz_> | Uniaika: I recommend reading Kinds Are Calling Conventions. |
| 2021-03-18 20:05:30 | × | petersen quits (~petersen@redhat/juhp) (Ping timeout: 256 seconds) |
| 2021-03-18 20:05:31 | <edmundnoble> | % :k Int |
| 2021-03-18 20:05:31 | <yahb> | edmundnoble: * |
| 2021-03-18 20:05:37 | <mniip> | * = TYPE LiftedRep |
| 2021-03-18 20:05:40 | <edmundnoble> | And `*` is what again, |
| 2021-03-18 20:05:41 | <edmundnoble> | Gotcha |
| 2021-03-18 20:05:46 | <koz_> | It's a very readable paper and goes into some detail explaining why the restrictions around unlifted types exist. |
| 2021-03-18 20:05:48 | <Uniaika> | koz_: great, thanks |
| 2021-03-18 20:06:02 | <edmundnoble> | koz_: that's not what you said, you said there are no instances of anything |
| 2021-03-18 20:06:05 | <koz_> | (yes, there was a 'Types are Calling Conventions' before it) |
| 2021-03-18 20:06:09 | → | mikoto-c1 joins (~anass@gateway/tor-sasl/mikoto-chan) |
| 2021-03-18 20:06:27 | <edmundnoble> | It is true however that if you have a type class with kind for example `* -> Constraint`, you will not be able to have instances for unlifted types |
| 2021-03-18 20:06:42 | <Uniaika> | edmundnoble: okay so there is a fundamental conflict between "TYPE LiftedRep" and "TYPE IntRep" |
| 2021-03-18 20:06:48 | <mniip> | you can have a polykinded class |
| 2021-03-18 20:06:48 | <edmundnoble> | They just don't unify, yes |
| 2021-03-18 20:06:51 | <koz_> | edmundnoble: I don't think I said there are no instances fro anything. I said there are no instances of anything for Int#. |
| 2021-03-18 20:07:01 | <dolio> | Yes, those are not the same calling convention. |
| 2021-03-18 20:07:03 | <edmundnoble> | Right, which is incorrect |
| 2021-03-18 20:07:10 | edmundnoble | There can be instances of things for `Int#` |
| 2021-03-18 20:07:16 | <edmundnoble> | There are just far fewer |
| 2021-03-18 20:07:26 | <koz_> | Wait, so what instances exist for Int#? |
| 2021-03-18 20:07:31 | <koz_> | Because I'm not aware of any. |
| 2021-03-18 20:07:34 | × | ukari quits (~ukari@unaffiliated/ukari) (Remote host closed the connection) |
| 2021-03-18 20:07:38 | <mniip> | % class Show# (a :: TYPE r) where show# :: a -> String; instance Show a => Show# a where show# = show; instance Show# Int# where show# x = show (I# x) ++ "#" |
| 2021-03-18 20:07:38 | <yahb> | mniip: ; <interactive>:35:55: error: parse error on input `instance' |
| 2021-03-18 20:07:39 | → | gues62271 joins (~username@185.234.208.208.r.toneticgroup.pl) |
| 2021-03-18 20:07:51 | → | petersen joins (~petersen@redhat/juhp) |
| 2021-03-18 20:07:51 | → | icebreaker joins (michalc@freeshell.de) |
| 2021-03-18 20:07:51 | × | icebreaker quits (michalc@freeshell.de) (Changing host) |
| 2021-03-18 20:07:51 | → | icebreaker joins (michalc@unaffiliated/icebreaker) |
| 2021-03-18 20:07:56 | <mniip> | % class Show# (a :: TYPE r) where { show# :: a -> String }; instance Show a => Show# a where { show# = show }; instance Show# Int# where { show# x = show (I# x) ++ "#" } |
All times are in UTC.