libera/#sicl - IRC Chatlog
Search
8:36:45
Duuqnd
Here's my implementation for a random number generator system for SICL: https://gist.github.com/johnlorentzson/f6c2389b9896c13ea3d9c23f95527070
8:38:20
Duuqnd
It's all in one file because it doesn't depend on other SICL modules and I just wanted to prototype it easily
8:39:08
Duuqnd
And the CL symbols used are shadowed but not exported because I don't know what the standard practice for that is in SICL and I just wanted to be able to test this in SBCL without issues.
8:40:16
Duuqnd
There's still a few things I'm not so sure about here but I'd like some feedback before I begin making a pull request
8:48:20
moon-child
Duuqnd: you do not need to ':reader random-bits' for mt19937-random; it will be inherited from random-state
8:51:56
moon-child
as a point of style, I think (let ((y ...)) (setf y) (setf y) (setf y)...) would do better to shadow than mutate. (let* so it doesn't end up deeply nested)
8:56:48
Duuqnd
I mainly did the three setf because I was more or less following the pseudo-code from Wikipedia and SBCL does the same but yeah, let* does make more sense.
8:59:25
Duuqnd
Alright, I've made the changes: https://gist.github.com/johnlorentzson/ed0ed853732b5c7a84e3df5319ecbdca
9:00:21
moon-child
ah, two more things. (loop for i... for xi-1 = (aref). Since the array in question is full of integers, xi-1 will never be NIL; but in principle if it became nil, it would halt the loop, so using for there can subvert expectations. So I would prefer _as_ xi-1 = ...
9:01:06
moon-child
and, you allow state-array to be set by the user (where it could have arbitrary length), but elsewhere assume its length is +mt19937-size+
9:01:16
moon-child
I am sure others have feedback as well. But make a PR! This is all very nitpicky stuff
9:02:54
Duuqnd
Alright, sounds good. Btw, should the CL symbols (random, make-random-state, etc) be exported by the sicl-random package?
9:08:30
beach
The intrinsic package would :USE the CL package, and export symbols that are not CL symbols but that can still be useful to client code. It can optionally export the CL symbols as well.
9:09:50
Duuqnd
What's a good example of this in use? I think you mentioned the sequence systems before?
9:11:54
beach
Yes, the sequence system was designed to work in any Common Lisp implementation as a separate package, and in SICL as the native implementation of the sequence functions.
9:14:03
Duuqnd
The only difference between packages.lisp and packages-intrinsic.lisp in Code/Sequence seems to be that one does :use #:closer-common-lisp and the other uses #:common-lisp (and imports from a few other things) so I'm not sure I'm understanding this.
9:16:06
Duuqnd
I didn't see any other differences between them though so I'm not sure what I'm supposed to do in this case. I think I'll just use one package and system when submitting the pull request and we can fix it then before it's merged.
9:42:23
Duuqnd
I noticed that RANDOM's handling of non-positive numbers wasn't correct so I had to fix that, but I've send the pull request now.
9:55:48
beach
Duuqnd: I very much like this way of organizing a system that has a single main package, like in this case a Common Lisp implementation with the CL package. There would be one package that has only the exported symbols in it. No code is written with (in-package #:cl) at the top. Instead, individual modules would each have a package the :USEs the CL package.
9:56:45
beach
I learned this technique from the CLIM specification. It is strange at first, because other programming languages would work the other way around.
10:00:14
beach
But since we never write any code with (in-package #:cl), we never pollute the host package.
10:04:58
jackdaniel
"when all lisp vendors implement x3j13 common lisp, the clim-lisp package could be eliminated" - but clim have assumptions about gray streams not being part of x3j13
10:06:57
jackdaniel
"A CLIM implementation might define a clim-internals package that uses each of the above packages" I gather that you have referred this - it is slightly different than sicl in my understanding