ski 2017-02-03 22:45:15
@type (`replicate` Nothing) :: Int -> (forall a. [Maybe a])
lambdabot 2017-02-03 22:45:17
Int -> [Maybe a]
ski 2017-02-03 22:45:25
(in Haskell the movement of the `forall' is implicit)
ski 2017-02-03 22:45:41
perhaps
ski 2017-02-03 22:45:50
@type (`replicate` id)
lambdabot 2017-02-03 22:45:52
Int -> [a -> a]
ski 2017-02-03 22:46:06
would be more apropos here, since `[a -> a]' mentions `a' both contravariantly and covariantly
ski 2017-02-03 22:47:30
athan : it's not uniqueness, then ?
mniip 2017-02-03 22:48:13
athan, can you destroy / not use a term
athan 2017-02-03 22:49:22
mniip: ! ahh, thank you
athan 2017-02-03 22:49:31
I'm mistaken :x
ski 2017-02-03 22:49:40
mistaken about what ?
athan 2017-02-03 22:50:00
linearity in regards to term _usage_, not necessarilly it's ability to be used
athan 2017-02-03 22:50:11
(I think)
ski 2017-02-03 22:51:30
with linearity, you basically can express that you're not allowed to reuse a thing, in the *future*. with uniqueness, you're ensuring that you haven't reused it, in the *past*
ski 2017-02-03 22:51:38
the latter allows update-in-place
ski 2017-02-03 22:51:57
(since you know you're given the unique reference to the object)
athan 2017-02-03 22:52:19
:O woah, okay thank you ski
athan 2017-02-03 22:52:39
I still don't have a practical outlet to use these features, but do you happen to know of a reference to where I can learn more?
ski 2017-02-03 22:52:49
(also allows "compile-time-GC", iow putting an explicit call to `free' at this point, if you're rather throw the memory block of the object away, rather than reusing it)
athan 2017-02-03 22:52:56
I remember advanced topics in TaPL breifly mentions substructural type systems
athan 2017-02-03 22:53:12
oh wow that sounds awesome
ski 2017-02-03 22:55:31
i suppose you could try looking at Clean (the "other" lazy programming language, whose makers' goals couldn't be reconciled with the general goals agreed upon by the (rest of the) Haskell committe), ..
ski 2017-02-03 22:56:22
.. or Mercury (a (statically typed) logic/functional programming language, interesting in its own right for its (static) mode, inst and determinism system for keeping track of how much info is known yet about variables, and how many solutions predicates/relations and functions may have, given different patterns of known data. also has type classes, existentials, &c.)
ski 2017-02-03 22:57:41
Clean incorporates uniqueness into types. if you call e.g. `(++)' with first argument unique, it'll modify the tail of it to point to the second
ski 2017-02-03 22:58:58
the same can happen in Mercury, except that uniqueness is incorporated into insts (instantiation states) and modes (transitions between instantiation states, also descriptions of how arguments/results of predicates&functions transition, when called in some initial state, together with information on the number of solutions (determinism))
ski 2017-02-03 22:59:20
istr there's also some papers by Wadler (and probably others) ?
ski 2017-02-03 23:01:36
( has links to papers, e.g. see "Strong modes can change the world!" by Fergus Henderson in 1992-11 (Fergus also participated in with Peyton Jones,et al.))
noan 2017-02-03 23:02:08
So if I'm using http://www.yesodweb.com/book/persistent... how do I even structure the module definition O.o?
athan 2017-02-03 23:02:24
!!! Awesome, thank you ski!
ski 2017-02-03 23:04:07
for Clean, see , e.g. . paper list is at , i don't recall any particular to recommend
ski 2017-02-03 23:04:53
for Mercury, the docs on uniqueness is at
ski 2017-02-03 23:05:26
perhaps could be interesting as well
ski 2017-02-03 23:05:29
athan ^
athan 2017-02-03 23:06:23
thank you ski :)
noan 2017-02-03 23:07:03
Anyone know where I can find baby's first guide to module organisation? like, if I have src/db/SomeFile I would like to import it as DB.SomeFile not simply SomeFile
athan 2017-02-03 23:07:33
noan: They're orthogonal to filesystem paths
athan 2017-02-03 23:07:45
so DB.SomeFile would be src/DB/SomeFile.hs
noan 2017-02-03 23:08:14
athan, and the module declaration in SomeFile would just be module SomeFile where
noan 2017-02-03 23:08:15
?
athan 2017-02-03 23:08:54
noan, nope, it needs to be absolute as well - module DB.SomeFile where
athan 2017-02-03 23:09:11
and notice though that `src/` is arbitrary under the Cabal `haskell-src-dirs` clause
athan 2017-02-03 23:09:15
(I think it's that)
noan 2017-02-03 23:09:18
oh my god. the . is a valid part of the name
noan 2017-02-03 23:09:21
there's where I was getting fucky.
athan 2017-02-03 23:09:28
hs-source-dirs*
athan 2017-02-03 23:09:36
:)
noan 2017-02-03 23:09:47
So it's not "SomeFile contained in DB" it's "No bitch my name is DB.SomeFile"
athan 2017-02-03 23:10:00
same difference imho
athan 2017-02-03 23:10:25
you can re-export modules, but it's smart to do it predicatively like DB re-exports DB.SomeFile
noan 2017-02-03 23:10:39
and in my cabal file I need to explicitly list every source dir and every module to export, right?
noan 2017-02-03 23:10:44
nothing is assumed recursive?
athan 2017-02-03 23:10:58
correct
athan 2017-02-03 23:11:17
also, it's wise to list non-exported modules under `other-modules` as well, for linking concerns
noan 2017-02-03 23:11:24
for instance?
athan 2017-02-03 23:11:35
yep, that looks right to me
ski 2017-02-03 23:12:33
athan : re Wadler, i was probably thinking of
noan 2017-02-03 23:13:45
athan, fairly related to this is... I want to start setting up Persistent. Normally I try to define my modules like module Foo( Bar, Baz) where so only Bar and Baz are exported if I understand right...
noan 2017-02-03 23:14:14
But with perstient it gets a little confusing. Is it bad practice(and possible?) to simply module Foo where and then everything past the where is available upon import?
noan 2017-02-03 23:14:33
athan, thanks for the help by the way :D
athan 2017-02-03 23:15:56
noan, yep your intuition is correct, if nothing is explicitly exported then everything is. This is actually pretty tricky because persistent generates terms using metaprogramming, so it's hard to predict what exactly is available for export
athan 2017-02-03 23:16:57
ski: got it! Can't wait to read
ski 2017-02-03 23:20:28
athan : for Mercury, it helps to know a little about logic programming (e.g. Prolog) .. imho, every programmer ought to know at least a little about what logic programming (and preferable also constraint (logic) programming) is, just as they ought to know about functional programming
noan 2017-02-03 23:21:26
athan, which is why I was thinking of going "module MyDBTypeFromPerstistent where". Is this generally bad practice or anything like that?
noan 2017-02-03 23:21:33
or in this case seen as "yeah that's fine"
ski 2017-02-03 23:23:49
athan : hmm .. when using TH that generates definitions/bindings, it ought to be possible to (preferably(?), and at least abstractly) give a name to the group of bindings/names, so that you can explicitly choose to list that abstract name in the module export (and also in later imports ?)
ski 2017-02-03 23:24:08
.. hm, i suppose this issue is related to hygiene (or lack thereof) in TH
athan 2017-02-03 23:25:03
ski: I'm only familiar with GHC's Contraint system, but I think I have an intuition to logic programming. That's one field I would like to explore more, though
athan 2017-02-03 23:25:41
I have no idea ski :)
athan 2017-02-03 23:26:05
noan: I wouldn't consider that terrible practice, but I usually do something like `Schema.Foo` and throw all the persistent stuff in there
ski 2017-02-03 23:26:06
i suppose allowing submodules would be an easy way to accomplish this. your TH would give a name to the submodule (which would presumably usually be automatically opened/imported into the enclosing larger module), and then you could refer to that submodule in the export list, at least ?
noan 2017-02-03 23:26:51
athan, in my cause it's going to be DB.SessionToken in this example and only the schema parts. Business rules will go under something like Resources.Whatever
noan 2017-02-03 23:26:55
or something.
athan 2017-02-03 23:27:44
hm, it appears that GHC's RTS options under ARM doesn't recognize -N :s
athan 2017-02-03 23:28:19
noan: That sounds sane to me, I'm sure you'll develop a style that makes sense & comfort to you :)
ski 2017-02-03 23:28:56
athan : there are ##prolog,#mercury (and #cleanlang). if you happen to have access to
ski 2017-02-03 23:28:59
@where CTM
lambdabot 2017-02-03 23:28:59
"Concepts, Techniques, and Models of Computer Programming", by Peter Van Roy,Seif Haridi, at
ski 2017-02-03 23:33:00
athan : then i'd also recommend it. it is a bit comparable to SICP, but more modern, and covers more paradigms. it uses the multi-paradigm language Oz (a simple logic programming language without disjunction at the base), implementation is Mozart
athan 2017-02-03 23:33:46
oh wow!!!
ski 2017-02-03 23:33:48
athan 2017-02-03 23:34:00
thank you dearly!
athan 2017-02-03 23:34:49
I've heard of Oz before from somewhere..
ski 2017-02-03 23:36:20
but otherwise, for logic programming, most of the available material is for Prolog (or systems based on it), so i'd recommend checking out Prolog regardless (even though it's dated, has many flaws, no standard module system, higher-order programming is a kludge (works, but can be annoying), side-effects present, the (sadly necessary) "cut" abomination, var/1, &c. ..)
athan 2017-02-03 23:37:24
heh, I'll definitely check it out :) I hear it's a thorn most students like to pluck quickly
ski 2017-02-03 23:37:45
athan : "Re: Mercury in academic teaching?" by Richard A. O'Keefe in 2006-10-(09|10) at , might be interesting re learning Prolog or Mercury first ..
