libera/#commonlisp - IRC Chatlog
Search
21:21:28
Kingsy
beach: kakuhen: I have this set -> (proclaim '(optimize (safety 3) (debug 3) (space 0) (speed 0) (compilation-speed 3)))
21:22:55
Kingsy
pjb: I was going to do that but I didnt want to change my main lisp file. does it matter at all?
21:23:02
kakuhen
try (declaim (optimize (debug 3) (safety 3) (speed 0) (space 0) (compilation-speed 0)))
21:23:49
kakuhen
according to the SBCL manual, you need the debug level to be greater than speed, space, and compilation-speed
21:34:12
Kingsy
kakuhen: so should I decrease the compilation speed? does it matter what I set it to?
21:35:15
kakuhen
Well, the SBCL manual suggests it should be lower than the debug level so functions become steppable
21:35:54
kakuhen
I don't know what exact policy SBCL uses for compilation-speed. All of these quantities are implementation-dependent. I do know that SBCL's backend tends to have different VOPs targetting policies like "safe", "fast", and "fast-safe" (these will correspond to different quantities of safety and speed)
21:36:06
kakuhen
But I just don't know how SBCL (or any other Common Lisp implementation) handles compilation-speed
21:36:20
kakuhen
This would be a good question for #sbcl, or for anyone lurking here that knows more about SBCL internals than I do
21:39:15
Bike
sbcl's policies are in src/compiler/policies.lisp. the only one there that compilation-speed affects is insert-step-conditions, which is done when (> debug (max speed space compilation-speed))
21:40:25
Bike
yeah, looks like it can affect a bunch of other things, like what kind of register allocation is done
21:46:30
kagevf
what's the difference between (proclaim '(optimize (safety 3) (debug 3) (space 0) (speed 0) (compilation-speed 3))) and (declaim (optimize (debug 3) (safety 3) (speed 0) (space 0) (compilation-speed 0))) ...?
21:47:42
kagevf
oops ... I just copied from the screen ... I meant all the sub-components to be the same
21:49:22
kagevf
ok ... and follow-up: I would need to re-compile any functions I want to step through after running either of those, right?
21:50:40
kakuhen
Yes. You should recompile any forms you want to be affected by the new optimize policy
22:04:17
Kingsy
can someone help me understand execution order here. I have stepped into this function --> https://hastebin.com/okeyugiyug.rust <- but according to the stepper the first thingthat is evaluated is (db:ensure-id paste-ish) .. why?! doesnt it need to eval the typecase to see which form is T ?
22:08:48
kakuhen
anyway, STEP is probably one of the most useless macros I've ever seen in the Common Lisp specification
22:08:59
kakuhen
For instance, CLHS says "It is technically permissible for a conforming implementation to take no action at all other than normal execution of the form."
22:09:27
kakuhen
I would personally use SLY stickers to record the history of values in a function (and how they change) rather than a stepper
22:10:18
Kingsy
I just wanted something that allowed me to interactively follow exeution flow so I could see how th language works
22:12:27
Kingsy
let me ask this, am I correct in thinking that a (typecase ..) is a conditional set of forms depending on an argument?
22:18:49
Bike
Kingsy: as to the stepping question, your implementation probably compiled the form down, so there's not much to be stepped as to the typecase
22:19:37
Kingsy
Bike: quickly on this topic before I swap channels, how is (dm:data-model paste-ish) <- that a condition that a typecase can evaluate? its just a function call right? i don't get it.
22:20:15
Bike
i'm just saying the stepper blew through the typecase so that the first thing you see actually stepped is the function call. that doesn't mean it didn't DO the type test, just that it wasn't steppable
22:21:01
Kingsy
oh yeah I kinda assumed that was happening. but I don't understand what the typecase evaluated on the two forms it skipped.
22:22:11
Bike
in (typecase (dm:data-model paste-ish) ...), (dm:data-model paste-ish) is not a function call
22:22:46
Bike
what the type case does is test whether paste-ish is of type dm:data-model, and if it is, it evaluates and returns the form (here, paste-ish)
22:24:06
Kingsy
hmm sorry I don't understand that.. haha man I am slow. its evaluatingif paste-ish is a dm:data-model? if it is it returns paste-ish?
22:32:41
Kingsy
Bike: last question on this function, the second eval, db:id, how is that (or ..) every going to return the error? an (error) isnt ever going to be of type db:id right?
22:42:04
Bike
in "nothing is of type NIL" you are referring to the type NIL, while in "NIL is of type NULL" you are referring to the value NIL
22:42:30
Bike
"the type NIL is of type NULL" would not be a coherent statement, because types do not have types
22:43:01
Kingsy
wow.. I think I'll just focus on reading and understanding the syntax first. that hurts my brain
22:43:35
aeth
it doesn't make sense if you try to assign some kind of underlying meaning to "nil" and "null" imo
22:44:52
aeth
It's made worse when you realize that NIL isn't even a null, it's false, so it can't be null in the sense of nulls that you think about in e.g. SQL.
22:46:29
aeth
My point is, it's not null in the sense of a truth table consisting of true, false, and null because it's... false, the only false in the language in fact.
22:47:13
aeth
So if you have any experience with logic, mathematics, or programming outside of Common Lisp, this sort of thing is very counterintuitive.
22:47:41
Kingsy
yeah its not making alot of sense to me rightnow. so I might just ignore it..... for now
22:48:10
aeth
you just have to accept that the name's bad and don't try to bring outside experience into understanding it
22:51:13
aeth
If you don't want to Python 3 your programming language, you just have to live with bad names from time to time
0:06:21
aeth
took me a second to parse that because I thought you were talking about a (SQL-using relational) database migration
0:08:18
aeth
Fortunately, Common Lisp could avoid most issues with renaming by simply versioning the COMMON-LISP (nickname CL) package (as long as it doesn't touch the reader or a few other things). Although I guess library interop with other libraries could suffer.
0:08:55
aeth
The only problem is that that becomes a user-effort rather than a core-language-effort and users tend to... make radical changes just to make radical changes. Thus, not really getting anyone to use it.
0:09:06
kakuhen
eh... coming from a mathematics background, I don't generalized booleans to be all that confusing in Common Lisp. The only object of type NULL is NIL, and NIL can represent an empty list too, so it's pretty intuitive to me that *type* NIL is "empty" and hence a subtype of everything else.
0:09:33
masinter
use URLs for package full-names on a per-file basis, and at least you'll hve more resilience
0:10:39
aeth
kakuhen: NIL is either false or an empty list (or both, I guess) depending on the context. NIL the type is the type of nothing. NULL the type is the type of NIL, which isn't a null in things like JSON, SQL, etc., that you might interact with (unless you choose to represent it as null instead of as false when converting it, which is probably a mistake).
0:11:29
aeth
masinter: the only reason I don't do that is because nobody puts hyphens in domain names but everybody puts hyphens in project names... So if I did that everywhere, it would double my domain costs.
0:12:14
aeth
"com.example" will actually show up as just "example" afaik, but it gets ugly when you use two words without a hyphen in the domain.
0:13:11
kakuhen
aeth: sure, that's exactly my point: the confusion seems to come from nil representing both the (generalized) boolean false and the empty list. But otherwise, the design is not very counterintuitive to me
0:13:17
aeth
masinter: well, no, because now the owner of example-regular-expression.com (which might actually be a site, don't go there, I'm making it up, poorly) will be mad at you if you express example.com/regular-expression as com.example-regular-expression
0:13:26
aeth
masinter: the point is to be unambiguous after all and now you just introduced ambiguity again
0:13:50
kakuhen
as for interchange of data between Common Lisp and languages that distinguish a false value and a null value, I agree it's annoying deciding how to designate this kind of data
0:16:11
aeth
it gets even trickier if you want to represent {"foo" : 42} as (:foo 42) because now you have nil that could be {}, [], false, or null (but please don't let it be null)
0:24:29
masinter
and one has first and last name, and the other has family and given name, you have to work hard to disambiguate