freenode/#lisp - IRC Chatlog
Search
23:26:08
phoe
"but all of the databases we use nowadays will be passé in 10 or 20 years, we'll need to rewrite anyway to make use of the newest MassiveDB and ImmutableJS or whatever current fad is the shit"
23:40:39
verisimilitude
I'm fortunate to have written only a single line of JavaScript in my life and not for something I personally cared about.
23:41:38
verisimilitude
What I think, ebrasca, is that a language many decades old still being at least near the top of things is a sign of stagnation.
23:42:01
verisimilitude
It's not necessarily that Lisp is great, but more that most other things are just pathetic.
23:51:17
_death
verisimilitude: not bad, all things considered. I think Lisp has something intrinsic in it that draws me to it, so I don't care if everything else is at stasis
0:15:04
stylewarning
Still a ways to go, but strongly typed parametric polymorphism in otherwise bog standard Lisp code is a dream
0:27:30
makomo
does the issue appear when you have all three of those constraints: constant time, constant memory, respects the lexical environment?
0:29:57
stylewarning
I don’t think you can feasibly do the first and last because it’s O(n) time to build the memory
0:46:15
jasom
ACTION has always thought it would be fun to make a thin wrapper for algebraic data types on lisp, but it's a significant project
0:48:06
jasom
something that would actually be smart about inserting type declarations that are revealed (e.g. emit something like (let ((x (cadr y)) (declare (type foo x)) ...) when y is known to be of type (list foo))
0:49:17
aeth
Interesting. I just found out about another historic Lisp that's pretty obscure and with comparatively very little information (not even a Wikipedia article). "Cambridge Lisp" for the Amiga. This 1987 review complains about how different from CL it is. https://www.atarimagazines.com/startv1n4/cambridgelisp.html
0:53:19
jasom
googling tells me that there was a "combridge lisp" implemented in bcpl shortly after lisp/370
0:53:22
aeth
The manual for the Acorn version (if it's even the same Lisp dialect, this one is apparently published by Acorn, not Metacomco) is online. http://chrisacorns.computinghistory.org.uk/docs/Acorn/Sci/AcornScientific_CambridgeLISPRM.pdf
0:55:13
aeth
Incompatible 16-bit Lisp that wasn't used by many and probably didn't have interesting features compared to the big lispms, so I'm not surprised that it's very obscure.
0:57:36
aeth
jasom: I think you can get pattern matching in vanilla Lisp through a sufficiently advanced macro (perhaps requiring CLtL2, idk... I think you could just expand it into nested typecases)
1:00:14
jasom
aeth: optima does pattern matching, including type based matching and destructuring, but see also the lack of an algebraic type-system in lisp
1:01:12
jasom
also I think there is no portable way to get information about enclosing lexical bindings in a macro, so you can't enforce completeness of pattern matches in a meaningful way.
1:10:56
aeth
jasom: Something a lot of pattern matching languages would have, translated into Common Lisp, is afaik something along the lines of: if you define a member type, then you can ensure that every branch (i.e. every member of the member type) is handled in the cases... so if you redefine (deftype colors () `(member :red :green :blue)) to now be (member :red :green :blue :yellow) you should get compilation errors
1:11:44
aeth
jasom: But I think you can still get that in CL if you just replace directly using the DEFTYPE to define member types like that to using some custom macro.
1:12:55
jasom
aeth: right, but ML will infer the type you are matching on, and that's just not possible in CL, even if one line above your match macro you declared the type of the variable you are matching on!
1:15:21
aeth
stylewarning: I'm not sure I agree. There's MEMBER, there's OR, and there's DEFSTRUCT/DEFCLASS.
1:20:16
aeth
stylewarning: The way you'd do that is defstruct with slots with :type. I've done that for typed linked lists. Trees would be just a bit trickier. Of course, you're looking at a 30% performance loss on SBCL, and not every implementation will respect :type in defstruct slots. (defclass will be even worse here)
1:20:45
aeth
(Actually using conses and type checking there would have to walk through the whole list afaik)
1:24:59
aeth
You'd also probably want a true way to say (maybe foo) because (or null foo) won't work on symbols, lists, or booleans.
1:39:19
stylewarning
Yes what you said about “maybe” gets to the root of the problem, algebraic parametric polymorphism
2:57:24
loli
it seems this library gives pattern matching exhaustion which is neat https://github.com/stylewarning/cl-algebraic-data-type
3:08:08
verisimilitude
It's been a time since I've taken a look, but are you perhaps thinking of (VECTOR *), hellcode?
3:13:15
hellcode
mmm idk, isn't t a supertype of everything? so that (vector t) ought to include (vector char) and so on?
3:55:36
aeth
since T will be (mostly) pointers but some specialized vectors can remove pointers for e.g. ub64 or double-float
5:08:34
pjb
And then, if you really need ot know, you should refer to the documentation of sbcl and of clisp, and it probably won't be the same thing.
5:10:48
pjb
LdBeth: otherwise, you can always try (documentation 'system::*driver* 'variable) or (describe 'system::*driver*)
5:11:01
pjb
LdBeth: Third, it's not documented in clisp, so DUH! https://clisp.sourceforge.io/impnotes/idx.html
9:41:20
akater
What is the best way to disable initargs validity checking for a particular #'change-class call?
9:43:15
no-defun-allowed
also, dunno if you can, validity checking is usually handled by however lambda lists are handled
9:44:23
no-defun-allowed
"initargs validity checking" sounds like something silly like putting an odd number of values in the &key section, but i'm not sure
9:45:49
specbot
Declaring the Validity of Initialization Arguments: http://www.lispworks.com/reference/HyperSpec/Body/07_ab.htm
9:47:21
akater
I'm not even sure how to do it globally withot total redefinition of primary method with &allow-other-keys