freenode/#lisp - IRC Chatlog
Search
6:42:51
kristof
Does anyone know of any discussion on why MAKE-PACKAGE takes a string designator and not a symbol-designator? I thought I read something by kent pitman once but I can't remember...
6:44:12
White_Flame
what would the package of the naming symbol do? if it's ignored, then a string is appropriate
6:45:04
kristof
it would intern the symbol and set it's PACKAGE-VALUE (does not exist, I know) to # <PACKAGE ...>
6:45:05
White_Flame
different symbols can have the same name. different packages cannot. package names are not namespaced
6:45:27
kristof
right, there would be a clear advantage to using symbols instead of strings so that packages could be namespaced
6:45:28
beach
kristof: If a package were named by a symbol, what would be the package of that symbol?
6:45:43
White_Flame
(well, and for holdling values, etc. but a symbol as a name is because it can be namespaced and locally interned)
6:46:53
kristof
oh, I think I remember what it is that I read. kent said he (often) writes his own machinery on top of defpackage that "does what he wants", and he detailed some specifics in a usenet post somewhere
7:11:05
phoe
Is there a format control that will automatically print ordinals? As in, 1 -> "1st", 2 -> "2nd", ...
7:48:10
elderK
Are they just like, the same as most Lisp stuff: Information that an implementation can use but may not.
7:48:54
elderK
Like, experimentally, it seems that SBCL does care about about the :type specified for a structural slot.
7:49:16
elderK
And of course, just because SBCL uses them, doesn't necessarily mean other implementations do.
7:53:02
flip214
but why are you asking about :type specifiers then, if you already see that SBCL uses them?
8:22:30
shka__
sbcl's type errors are rather neat devolping helper, allowing you to realize quicker that you messed up types
8:31:11
flip214
shka__: elderK: for another nice sbcl feature, try (setf sb-ext:*derive-function-types* t)
9:54:13
elderK
Xof: Still, this is horrible enough without adding more. So the question is, how to do this in a cleaner way?
9:55:16
elderK
shka__: Validation was done by those functions. Same with slot-count-valid-p and such
9:55:47
shka__
elderK: that seems to be better, also when type mismatches, you signal type-error specificly
9:56:16
elderK
shka__: The problem with using check-type here, is that they will have to look at the backtrace to know "Oh, right, COUNT is meant to be an integer..."
9:56:29
Xof
you could try (destructuring-bind (&rest sdlist &key (accessor (error ":accessor not supplied")) ...) (assert (= (length sdlist) 6)) (check-type accessor symbol) ...)
9:57:14
elderK
Like, if the slot description was blatantly foobar, then you'd get a destructuring error, rather than something meaningful.
9:57:47
elderK
flip214: A function like this would be used during macro expansion. It would be one of many helpers.
9:58:25
elderK
In general though, I guess... like, I'm unsure of how aggressively to test such... stuff. Like, I could just do what many other systems appear to do: Just assume the client uses the macro as documented.
9:58:25
shka__
elderK: what i like to do in situations like this is to pack relevant arguments into some sort of object and perform check in initialization-instance
9:59:32
elderK
shka__: Well, you would still need to destructure the input list, so to construct an instance of whatever "parameter pack" Object you had.
10:00:15
elderK
I tried actually just say, funcalling a function and using the slot-description as raw arguments. But then, a malformed slot-desc would generate an error when that function was called.
10:00:19
flip214
elderK: well, I guess I'd just check whether the slot description has the same length after REMOVE-DUPLICATES, and then do a DESTRUCTURING-BIND with (ERROR) defaults.
10:00:24
shka__
elderK: yes, but i am always trying to play around that so i can just apply #'make-instance arguments
10:01:06
elderK
flip214: You mean handler-case around the destructuring-bind? But then, you'd be signalling an error while validating the stuff that was successfully destructured.
10:01:12
flip214
elderK: or you just go the default lisp way and allow overriding of such slot definitions with key/value pairs in earlier positions...
10:01:18
elderK
Unless you say, broke it apart: destructure-slot-description and validate-slot-description
10:01:52
flip214
then there's no need to check for duplicates at all, just GETF the required arguments from the spec.
10:02:33
flip214
elderK: no, I meant (DESTRUCTURING-BIND (&key (accessor (ERROR "no accessor")) (count (ERROR "..."))) spec ... )
10:02:44
elderK
As long as the final "value" was sane, it would be happy. And you wouldn't be checking for invalid keywords.
10:03:19
elderK
flip214: Right. The thing is, if you wrapped that in handler-case, you'd have to tease out the difference between a destructuring error, and a validation error.
10:03:48
elderK
And you'd still need to validate that say, count was a non-zero unsigned integer and the like.
10:04:16
elderK
Out of curiosity, what is the convention for functions that validate something, but are not expected to return if the validation fails?
10:04:57
elderK
I was thinkign of simply: validate-slot-name. It would return the name if it was valid, and signal an error otherwise.
10:04:57
flip214
well, so there's no real need to handle the errors - the developer will see the backtrace and can act accordingly?
10:05:33
flip214
elderK: just as additional data point, CLOS allows to specify multiple :accessors....
10:06:14
flip214
elderK: well, in my experience having a good (ERROR "I expect :accessor to be a SYMBOL!") message and the backtrace
10:06:27
elderK
Take for instance, defclass itself. If you say, provide it random keywords or say, something foobar like (name :accessor)
10:08:02
flip214
elderK: well, how about defining a struct type instead of the 4 variables, setting them as the arguments come in, and then just check SLOT-BOUNDP?
10:08:47
flip214
that would at least move the "no ... specified" into one loop, and the "already given" can be checked the same way
10:09:13
flip214
well, allocating that structure isn't much different from having the 4 variables - both can be done on the stack.
10:10:01
elderK
It's like, should parse-slot-description return a slot-description object? Or should it simply return the stuff it parsed?
10:14:10
_death
when the end user is a programmer, there's no need to obfuscate your code with so many checks.. and then, you're bound to miss some, for example (:accessor foo :type bar :count 1 42 "hi") .. for common errors or something particularly nasty it's ok
10:22:32
elderK
I mean, if say, the error signalled by destructuring-bind is good enough, then fine.
10:32:34
elderK
_death: My problem isn't like, that I am unaware of assert and check-type and stuff. But rather, I'm not sure how I /should/ signal errors regarding to the use of say, whatever macro I create.
10:32:56
elderK
From the code I've studied, it doesn't seem to be all that common that people really verify their macros are being used correctly.
10:39:36
_death
defclass and stuff is used by everyone and pretty stable and documented, so the balance lies in a different place
10:40:48
_death
and still, it wouldn't be hard to find something that's not checked in a given implementation
10:46:45
pjb
minion: memo for kristof: note that symbols are named by strings too. concatenating a package name, one or two colons and a symbol name gives you a qualified symbol: (concatenate 'string "CL-USER" "::" "STRING") #| --> "CL-USER::STRING" |# (read-from-string (concatenate 'string "CL-USER" "::" "STRING")) #| --> string ; 15 |#
10:49:11
_death
(check-type name symbol "a slot accessor name") .. validation functions would be useful if more complex or used in multiple places or exposed.. you could also (deftype slot-accessor-name () 'symbol) and check for that type, for the same purposes
10:52:01
_death
and yes, it's likely you want to parse something like this to a slot-description object..
10:53:06
flip214
elderK: with explicite validate-calls, why not make these methods? (validate-slot :count arg)
10:53:14
jmercouris
hi everyone, I've shared a technical article about Next: https://www.reddit.com/r/lisp/comments/a3b8m0/browsing_with_lisp_next_browser_new_architecture/
10:53:43
jmercouris
basically beach suggested almost a year ago now I think, a lisp core, with a separate GUI process controlled via some remote protocol to keep the core safe and free from foreign code
10:54:19
jmercouris
anyways, we've done it, and we're at alpha, interested to hear feedback on the design, even the codebase itself, I'm of course a Lisp noob, and there are many mistakes throughout
10:56:05
elderK
I figure :count is the name of whatever you're validating. It would be eql-specialized?
10:56:17
jmercouris
also, we managed to finally produce a binary that works for Linux, it's like flatpak, but its called a guix pack
10:57:40
jmercouris
beach: since you inspired the design, I would be most interested in your feedback on the technical article
10:58:32
beach
You need to remind me. Today my favorite coauthor is coming over for lunch, so I'll be busy. And then I will (of course) forget.
10:58:57
_death
elderK: the deftype tradeoff is similar to the validation functions.. if it's a one-off a simple check-type with a type string (or not) is great. characters like "%" in names.. I stopped using such decorations a few years ago and they've become a pet peeve.. the class name should likely be "slot-description"; after all it's not a slot, but a description of it
11:00:53
elderK
_death: Other than the prefixes and naming, is that style of validation good enough?
11:03:03
elderK
I may wind up using the CLOS MOP, maybe. Not sure yet. I'd need to alter standard defclass semantics so that inheritance follows defstruct semantics.
11:03:46
elderK
And even if I did like, create a new metaclass and all that stuff, the user would not be intended to use defclass :metaclass raw. They'd still be meant to use a wrapper macro.
11:06:48
_death
elderK: right.. using a macro like define-binary-class is a good idea, even if it's just a matter of adding a metaclass or inheriting from some superclass.. it's more future-proof
11:09:09
jmercouris
_death: so you approve of my macro then: https://github.com/atlas-engineer/next/blob/master/source/mode.lisp#L6 ?
11:13:34
_death
you can always get more fancy.. providing describe-object method, pprinter functions, etc.
11:17:44
jmercouris
would it be necessary within c to make it explicitly inherit from a and b or, just from b?
11:21:24
jmercouris
why does order matter from a practical point of view when inheriting from multiple superclasses?
11:22:57
beach
jmercouris: Since I am fairly busy with SICL and paper writing, it looks like you can improve a bit before I look at it by following the advice of _death and others.
11:35:00
jmercouris
please bear in mind, it is still alpha since this is now like the 5th rewrite... it feels like we can finally focus on polishing it and adding new features now that the architecture is finally stabilized
11:56:43
shka__
when calling map 'vector, presence or absence of the fill pointer, or vector being adjustable is undefined by the standard
12:20:13
loke`
shka__: I can't see anything in the spec that clarifies that, so I'd assume it's unspecified.
12:33:21
pfdietz
"Whenever a sequence function must construct and return a new vector, it always returns a simple vector."
12:37:00
pfdietz
An implementation is allowed to make any array adjustable; the spec has a distinction between "expressly adjustable" and "actually adjustable".
12:40:56
pfdietz
"It is implementation-dependent whether displaced arrays, vectors with fill pointers, or arrays that are actually adjustable are simple arrays. "
12:42:18
pfdietz
So it's possible to have an implementation in which all arrays have the frills. Lisp machines, perhaps?
14:45:58
dim
_death: not so much no, https://github.com/dimitri/AdventOfCode/blob/master/2018/d05.lisp
14:46:19
dim
just saying the main parameter is a string, but then nothing else, neither in the flets nor in the loops
14:49:57
jmercouris
I think CCL is a monumental task for RME to go at it alone, I look at the commit history, and he seems to be far and above the most active
14:52:19
_death
dim: I think when ccl is helped with declarations it can generate OK code.. anyway, for day 5 I created a screencast https://adeht.org/casts/aoc2018.html
14:54:26
dim
I found day5 quite difficult, I think I attacked it the wrong way and then my mental model was kind of stuck
14:56:25
_death
interesting.. to me it immediately screamed "string rewriting", even before reading the problem, so I found it a bit boring
14:57:25
dim
my first approach didn't resist to the string beginning with a reaction (e.g. Aa), and then it was busted and I needed something else, from scratch
15:02:35
_death
here's a gist with minor cosmetic changes https://gist.github.com/death/e0e216ca41eee99da609f01c64d2725a
15:10:01
_death
I am not talking about tail call optimization, but about the process described by the code
15:11:21
_death
https://mitpress.mit.edu/sites/default/files/sicp/full-text/book/book-Z-H-11.html#%_sec_1.2.1
15:14:15
Odin-
Fair enough, but in practice you can only make that distinction if you have tail call optimisation.
15:16:21
_death
the process is iterative, and what the compiler decides to do with its description is an implementation detail, which in practice matters of course
15:16:28
dim
_death: https://github.com/dimitri/AdventOfCode/commit/99cb79a5414f3f249d3b22ec83e0d172dd5c6b4e
15:17:07
dim
with char-equal and a very small code clean-up now CCL and SBCL are about on-par, 1414.644ms became 100.259ms; thanks!
15:18:47
dim
_death: I see what you mean yeah, but I refrained myself for doing it that way and I don't know why really, I like recursive definition for their simplicity usually, not today though…
15:20:00
alandipert
_death I'll check out your screencast! I haven't done it 2 yet, have this so far https://github.com/alandipert/advent-of-code-2018/blob/master/day05.lisp
15:24:03
Odin-
_death: If we get right down to it, the only reason you ever need to use iterative processes is an implementation detail. :)
15:24:46
Odin-
(That is, the fact that any actual implementation is going to have a finite limit on call stack depth.)
15:26:10
_death
Odin: what is meant is that the process, by its "nature", is iterative.. i.e. without any relation to computers or compilers, just logic
15:27:56
_death
Odin: and Guy Steele in one of his lambda papers, flipped the situation with regards to implementation techniques and showed that the "stack" can be artificial
15:36:00
heisig
Damn, you guys lured me into this advent of code thing. Well, here is my take on it: https://github.com/marcoheisig/adventofcode
15:37:21
Odin-
_death: Algorithmic analysis is one way of looking at it. Looking at it from the implementation is another.
15:38:38
Odin-
_death: I'll concede that saying "no, it's not" wasn't justified, but at the same time it's not _wrong_. :p
15:40:56
Odin-
Because the implementation is recursive and leaves it to the compiler to recognise that the underlying process is iterative.
15:42:14
Odin-
If it doesn't, the process that actually gets run _is_ recursive, with significant practical consequences.
15:53:04
jkordani_
_death: its funny this topic came up. I'm going through sicp right now and last night I finally understood what they were saying about iterative v recursive
15:54:48
jkordani_
I was confused because the iterative examples look recursive to me, if I go by my old definition which was "the function calls itself" but I see now that that's an incomplete model to describe the behavior
15:57:54
Odin-
And tail call optimisation makes the code behave different from what it looks like it should. :p
15:58:36
_death
if you understand this, then the semantic arguments about appropriate terms etc. are unimportant..
16:44:58
_death
doesn't look too bad.. as for the margin, maybe it's best to ignore that rule for now, so that you indent things in a way that makes the code shape familiar
16:47:19
elderK
_death: Thanks for taking a look. I appreciate it. Aye, I'm aware of the "familiar" shape. But... the margin.
16:47:40
elderK
What I want to do, is break this out into multiple files. One that deals with the slot stuff, one that deals with the structure stuff.
16:47:52
elderK
But of course, some of the slot stuff needs to access the structure, and vice versa.
16:48:39
elderK
I have learned, however, that storing the offset for the slots doesn't really buy me much.
16:49:38
elderK
:( I've been at this for about twelve hours. I should take a break, ponder more. But at the same time, I'm determined to get something decent. At least /some/ progress.
16:50:44
_death
elderK: in make-array-initform you should likely use `(vector ,@(loop repeat count collect initform)) for initial contents.. which also does away with double backquotes
16:53:30
_death
elderK: indeed, so putting the function call form in a vector literal is wrong.. and also, you need to decide whether to evaluate it multiple times (as it is right now) or once (say, using once-only)
16:53:55
elderK
_death: Good point about the literal. But it's intended to evaluate the initform multiple times.
16:56:15
elderK
_death: Is it bad form for a file to use a function that's defined in another file, if that other file is compiled / loaded after the first?
16:56:26
elderK
Or is it best to declaim something in that case, to let the compiler know that ahead of time?
16:57:01
elderK
It's crazy. I can deal with much larger files in other languages. But, Lisp... it is so much more dense, if that makes any sense.
17:00:14
Odin-
Lisp and assembly sometimes seem to have similar requirements for exactly the opposite reasons.
17:01:15
Odin-
Assembly because it's doing things at such a low level that you need to see a lot of it to understand what the hell is going on, and Lisp because it's doing things at such a high level ... that you need to see a lot of it to understand what the hell is going on.
17:09:35
_death
elderK: well, it's not too big yet.. with practice you'll find it easier deal with chunks like that
17:33:51
elderK
_death: Another problem is that, atm, I haven't really developed an intuition for what *is* horrible.
17:37:25
_death
but did you read the Tutorial on Good Lisp Programming Style ( http://norvig.com/luv-slides.ps ) ?
17:39:00
pfdietz
elderK: the use-before-def of functions is interesting if it's a generic function. There, the idea is to put the defgeneric forms early, sort of like the declaration of function signatures in C go in .h files. The actual methods can be all over the place.