Home freenode/#haskell: Logs Calendar

Logs: freenode/#haskell

←Prev  Next→
Page 1 .. 1236 1237 1238 1239 1240 1241 1242 1243 1244 1245 1246 .. 5022
— 502,152 events total
2020-11-11 23:06:48 <dminuoso> So you might be interested into looking how module nix code is often structured
2020-11-11 23:06:55 <dminuoso> as a counter example
2020-11-11 23:07:06 <monochrom> Yes, objects can be multiple-instance modules. Especially when your module has an internal mutable state.
2020-11-11 23:07:50 <dminuoso> sm[m]: Oh and regarding libraries, this all depends on how you define things. But generally Id say a library is a bunch of modules. So it's a collection of exported things. :p
2020-11-11 23:08:01 <monochrom> DNS functions on unixes used to be a module. Now they have to make them an object for re-entrancy and concurrency.
2020-11-11 23:08:15 <dminuoso> But, it could be conceivable to turn libraries into first class values too
2020-11-11 23:08:27 <dminuoso> And then have libraries parametrized by modules, libraries parametrized by other libraries..
2020-11-11 23:09:09 → brettgilio joins (~brettgili@brettgilio.com)
2020-11-11 23:09:30 <dminuoso> (strictly speaking, libraries *are* often parametrized by build flags or similar things)
2020-11-11 23:10:40 <sm[m]> we seem to have a number of different things for making software modular, and they're not all called module. And the meaning of "module" seems to drift a bit
2020-11-11 23:11:09 → visage_ joins (~visage_@unaffiliated/visage/x-6658724)
2020-11-11 23:12:11 <sm[m]> in ocaml, "module" is a well-defined and important concept. In ghc haskell, it's well-defined but simpler and in practice a synonym for "file". In other languages I think it has some other meanings
2020-11-11 23:13:00 <dminuoso> modules in Haskell are more than files though
2020-11-11 23:13:38 <dminuoso> "A module defines a collection of values, datatypes, type synonyms, classes, etc. (see Chapter 4), in an environment created by a set of imports (resources brought into scope from other modules). It exports some of these resources, making them available to other modules. We use the term entity to refer to a value, type, or class defined in, imported into, or perhaps exported from a module. "
2020-11-11 23:13:43 <sm[m]> I believe you but is that visible in practice ?
2020-11-11 23:14:06 <dminuoso> Of course it is. Do you not export/import things across modules?
2020-11-11 23:14:32 <bqv> Ghc limits modules to 1 per file
2020-11-11 23:14:37 <bqv> Its not in the spec
2020-11-11 23:14:50 <sm[m]> yes, and conceptually it's as if exporting/importing files. Same thing in practice
2020-11-11 23:14:51 <sm[m]> ie in ghc haskell, module and files are one to one
2020-11-11 23:14:52 <dminuoso> Indeed, in fact the Haskell2010 report doesn't even have a notion of "files" anywhere
2020-11-11 23:14:57 <dminuoso> That's an implementation detail
2020-11-11 23:15:12 <sm[m]> I thought so, that's why I'm saying ghc haskell
2020-11-11 23:15:17 <sm[m]> I remember seeing multiple, perhaps nested modules defined in a single file somewhere
2020-11-11 23:15:50 <sm[m]> perhaps that was ocaml
2020-11-11 23:15:51 <dminuoso> There are some GHC proposals in that area
2020-11-11 23:16:06 → gtk joins (~user@roc37-h01-176-170-197-243.dsl.sta.abo.bbox.fr)
2020-11-11 23:16:06 <bqv> Interesting how ghci just ignores an IO (IO a)
2020-11-11 23:16:11 <dminuoso> And we had a talk during Munihac a while ago with some of the GHC developers about it
2020-11-11 23:17:24 <sm[m]> I think my working definition is: a module is an importable/exportable chunk of software
2020-11-11 23:17:30 <gtk> All primitive types are unlifted – can’t contain bottom. what does it mean bottom? why is it important or meaningful to contain a bottom?
2020-11-11 23:17:31 <dminuoso> sm[m]: https://github.com/goldfirere/ghc-proposals/blob/local-modules/proposals/0000-local-modules.rst
2020-11-11 23:17:54 <dminuoso> gtk: bottom is a name for "can contain error or infinite computation"
2020-11-11 23:18:13 <sm[m]> ie, a chunk of software whose visibility can be controlled
2020-11-11 23:18:31 <dminuoso> gtk: phrased differently, if its unlifted then it *definitely* is defined and has a value
2020-11-11 23:18:41 <sm[m]> thanks dminuoso
2020-11-11 23:18:53 <dminuoso> (in the implementation it means we dont need to represent it in a way that allows for bottom)
2020-11-11 23:19:42 <dminuoso> gtk: Roughly, you could pretend unboxed and unlifted to mean the same thing. We have both because there's things that happen to be boxed but unlifted
2020-11-11 23:19:46 <dminuoso> ByteArray# comes to mind
2020-11-11 23:20:07 <dminuoso> (So ByteArray# uses a boxed representation, but it cannot ever contain bottom)
2020-11-11 23:20:57 × merijn quits (~merijn@83-160-49-249.ip.xs4all.nl) (Ping timeout: 260 seconds)
2020-11-11 23:21:02 <gtk> So ByteArray# can not contain error?
2020-11-11 23:21:02 <gtk>
2020-11-11 23:21:22 <bqv> • No instance for (Show (IO b0)) arising from a use of ‘print’
2020-11-11 23:21:26 <bqv> Uh, what
2020-11-11 23:22:27 <Rembane> bla >>= print
2020-11-11 23:22:30 <Rembane> Should work better
2020-11-11 23:22:45 <dminuoso> gtk: right
2020-11-11 23:22:49 <gtk> dminuoso: bottom means can contain error; so if ByteArray# don't contain bottom, it means the opposite of can contain error?
2020-11-11 23:22:53 <monochrom> bqv, if you have "foo :: IO (IO Int)", perhaps you have better luck telling ghci to "x <- foo", so as to sidestep the thorny question "how to print x :: IO Int"
2020-11-11 23:22:58 <dminuoso> gtk: Id rather say "bottom means not defined"
2020-11-11 23:23:10 <dminuoso> the reason I chose this phrasing is, becaue it could also be an infinite computation
2020-11-11 23:23:38 <bqv> Rembane: mm, seems it was hiding an error
2020-11-11 23:23:49 <gtk> is this infinite computation? [1..] dminuoso
2020-11-11 23:23:59 <dminuoso> `length [1..]` is
2020-11-11 23:24:18 <bqv> monochrom: I just didn't realise... I did <&> instead of >>= but couldn't tell cause it was just silent
2020-11-11 23:24:21 <dminuoso> It will not ever return a value, from a semantics position that however is indistinguishable from `error "foo"`
2020-11-11 23:24:21 → xerox_ joins (~xerox@unaffiliated/xerox)
2020-11-11 23:24:32 <dminuoso> In both cases you don't get a value back
2020-11-11 23:24:39 → dansho joins (~dansho@ip68-108-167-185.lv.lv.cox.net)
2020-11-11 23:24:41 × conal quits (~conal@66.115.157.100) (Quit: Computer has gone to sleep.)
2020-11-11 23:24:58 × alp quits (~alp@2a01:e0a:58b:4920:1845:95d6:9c3f:6683) (Ping timeout: 244 seconds)
2020-11-11 23:26:06 <dminuoso> gtk: So in short: If its unboxed, its also necessarily unlifted
2020-11-11 23:26:09 <gtk> dminuoso: i still dont see the point of distinguishing lifted or primitive
2020-11-11 23:26:14 <dminuoso> (because it requires boxing in order to have bottom)
2020-11-11 23:26:46 <dminuoso> gtk: So boxing just means you have an additional level of indirection in memory
2020-11-11 23:26:59 <dminuoso> we need that boxing in order to represent say thunks
2020-11-11 23:27:15 <dminuoso> without that box, at best you could just have a value right there.
2020-11-11 23:27:27 <gtk> dminuoso: i sort of get boxed vs. unboxed; it seems boxed are in the land of haskell. but lifted is more baffling to understand
2020-11-11 23:27:41 <dminuoso> gtk: the term "lifted" is not interetsing
2020-11-11 23:27:46 <dminuoso> it's "unlifted" that is interesting
2020-11-11 23:27:49 × Iceland_jack quits (~user@95.149.219.123) (Ping timeout: 264 seconds)
2020-11-11 23:28:15 <dminuoso> Like I said, the only reason to talk about lifted/unlifted is because of things like ByteArray#
2020-11-11 23:28:25 × carlomagno quits (~cararell@148.87.23.10) (Ping timeout: 264 seconds)
2020-11-11 23:28:39 <gtk> when would you use Int# instead of just Int?
2020-11-11 23:28:44 <dminuoso> In GHC, ByteArray# exists on the heap, so that requires an indirection (thus boxing!)
2020-11-11 23:29:10 <dminuoso> But that's just an implementation issue, in principle we dont need to represent a thunk that could, possibly evalutae to error or infinite computation
2020-11-11 23:29:37 <monochrom> You have to consider how to implement laziness, and how to still have non-lazy, actual integers, in order to see you need both lifted and unlifted.
2020-11-11 23:30:08 <monochrom> If you have time, any of those lengthy STG papers/tutorials has it.
2020-11-11 23:30:09 <gtk> so unboxed are not lazy?
2020-11-11 23:30:13 → justsomeguy joins (~justsomeg@unaffiliated/--/x-3805311)
2020-11-11 23:30:15 <dminuoso> indeed.
2020-11-11 23:30:23 <dminuoso> they're just there, directly in memory
2020-11-11 23:30:37 <gtk> I'm begging to see through the cloud
2020-11-11 23:30:38 <dminuoso> if you had a pointer to an unboxed value, you could just read from that pointer
2020-11-11 23:30:45 <gtk> beginning
2020-11-11 23:30:49 → conal joins (~conal@66.115.157.100)
2020-11-11 23:30:51 <monochrom> If you have less time, https://github.com/takenobu-hs/haskell-ghc-illustrated is of reasonable length.
2020-11-11 23:31:45 → jmcarthur joins (~jmcarthur@c-73-29-224-10.hsd1.nj.comcast.net)
2020-11-11 23:31:58 <dminuoso> If it wasnt for things like ByteArray#, we wouldnt even have lifted/unlifted, we'd just have boxed/unboxed
2020-11-11 23:32:14 <dminuoso> (and implicitly know that boxed meant lifted, and unboxed meant unlifted)
2020-11-11 23:33:14 <monochrom> Yeah the 2nd axis is just because some non-lazy primitive things are too big so they must still sit on the heap.
2020-11-11 23:34:07 <dminuoso> So if you want the really short answer, replace "lifted" with "boxed", and "unlifted" with "unboxed", and then move on.
2020-11-11 23:34:08 <gtk> Is there any good tutorials on how GHC works?
2020-11-11 23:34:13 <dminuoso> That's an approximation that's perfectly fine
2020-11-11 23:34:19 <monochrom> "box" means exactly what Rust means by Box<T>.
2020-11-11 23:34:22 <dminuoso> gtk: monochrom linked a pretty good book above
2020-11-11 23:34:25 <monochrom> (How convenient!)
2020-11-11 23:34:35 <gtk> I've tried to read the wiki. But it's a bit daunting.
2020-11-11 23:34:47 <gtk> dminuoso: ok i'll chck it
←Prev  Next→
Page 1 .. 1236 1237 1238 1239 1240 1241 1242 1243 1244 1245 1246 .. 5022

All times are in UTC.