libera/commonlisp - IRC Chatlog
Search
18:51:05
lisp123
Fortunately I only code for myself, so I will just stick to standard primary methods :)
19:03:10
pjb
lisp123: notice the cm and mc example (m is a "mixin", and depending on the order it's in the superclasses list, the order of the methods called.
19:04:21
pjb
lisp123: notice also with the cm example, the importance of (when (next-method-p) (call-next-method)) even in the inner primary method (in the superclass).
19:42:07
xaltsc
Hey, is there a "Common Lisp for the Schemer" somewhere ? All the guides/tutorials I've found are either too basic or too advanced...
19:43:56
lisp123
I would think Practical Common Lisp would be perfect for a Schemer because they already understand the basics of Lisp, but not sure if you think its too advanced. If so, ANSI Common Lisp, which is a bit easier to read, might be sutiable
19:45:54
xaltsc
I guess what I want is how to translate scheme idoms to clisp ones, like (define fun (lambda [arg] (...))) is just (defun fun [arg] (...))
19:47:25
lisp123
You can try this cheat sheet if you want something to the point: https://github.com/ashok-khanna/lisp-notes
19:47:43
Alfr
xaltsc, you can't, e.g. tail call optimization isn't mandated and some implementations might exhaust the stack; also no call/cc.
19:48:52
lisp123
xaltsc: Unfortunately (I can get your perspective now), I can't think of anything that would be perfect for you. You might need to just bite the bullet and read through PCL
19:48:54
xaltsc
Alfr: my entry in the clisp world would only be nyxt configuration right now, so I don't have to worry about this kind of stuff
20:22:19
jcowan
I found PCL very readable, but I'm an odd case because I wrote CL (in anger) about the same time I learned Scheme (from reading the Rabbit compiler, which is written in Scheme and Maclisp). I never returned to CL after that except to update myself, but got involved in Scheme much more so.
20:28:11
jcowan
beach: Of course you can define away "unlispy CL features" by saying "Everything in CL is lispy". But if you look at how people actually use the term, they seem to focus on `format` as the most unlispy feature, followed by `loop` and CLOS in that order.
20:28:57
jcowan
I agree about `format`, think `loop` could have been designed better but the idea was a good one.
20:29:51
lisp123
White_Flame: Seems like there is two eras of Lisp - The ones before format / loop / CLOS and the ones after it
20:30:24
White_Flame
well, the old ones really sucked because they used symbol plists as an application database, and did spaghetti mutation everywhere
20:30:30
lisp123
The one before was DIY, you got the primitives, go have fun. The ones after is like, why reinvent the wheel, use these useful tools. That's my two cents
20:32:04
jcowan
There should be a bottom-up MOP+CLOS book that explains how a CLOS is done, analogous to phoe's condition book.
20:33:01
Bike
amop is kind of written like that... though it skips some of the efficiency details and isn't quite in line with the MOP "standard"
20:36:04
lisp123
jcowan: You can also check out Sonja Keene's book and then the standards. Then look at Portable Common Loops
20:38:17
lisp123
https://www.cs.cmu.edu/afs/cs/project/ai-repository/ai/lang/lisp/oop/clos/pcl/0.html
22:28:23
_death
while debugging something, I wanted to TRACE a function, evaluate a form that calls it, and then UNTRACE it..
22:42:44
_death
jcowan: sure.. but that's too much typing while debugging.. and I knew no error would be signaled
22:49:46
jcowan
What is "dead"? The last release was in 2014, but it is still being maintained. Java weevils will tell you CL is dead, but there are plenty of other weevils who will tell you Java is dead.
23:45:03
yitzi
greyrat: Keep in mind that bordeaux-threads does not support GCL and that several platforms that used GCL to support Maxima now use SBCL or something else.
0:06:35
kagevf
xaltsc: "clisp" is an implementation of Common Lisp - similar to SBCL, ABCL, ECL, and so on ; use "CL" to abbreviate "Common Lisp"
0:17:55
lad
is there a way to hook into the eval function such that I can define my own special symbols?
0:20:51
lad
I want these symbols to be able to self-evaluate: http://pastie.org/p/2HHTbH3yyf4oIqmamUs5rB
0:23:55
lad
I need to figure out how to get around Lthis ock on package COMMON-LISP violated when DO as a constant while in package COMMON-LISP-USER.
0:25:19
Bike
DO is a part of the standard CL package, so you can't define it as a constant. You can define your own package that uses the CL package but shadows DO, and then SOLFEGE:DO can be defined however
0:35:40
pjb
(defpackage "LAD" (:use "CL") (:shadow "DO")) (in-package "LAD") (defconstant do 'do) (defmacro do (&rest stuff) `(cl:do ,@stuff))
0:41:10
lad
http://pastie.org/p/5OfiqsD6UDmqoxakurCNy0 <- line 12 has an issue, what is a good way around this?
0:41:33
lad
say i don't want to define constants, just bindings that I can use within a macro, for example
0:46:04
pjb
Note: with let, they're not constant, so you can shadow them or rebind them: (with-solfege (setf do 42) (list do re mi)) #| --> (42 re mi) |#
0:47:22
lad
pjb, i think those symbols should be able to be rebound since they are relative to a scale
0:50:19
yitzi
lad: Why do you not want to do keywords? The deftype will just have `(member :do :di :re ...)`
0:51:28
pjb
The advantage of symbol-macros is that they're lexical bindings, and you can shadow them in a let (let ((si 42)) (list la si do)) #| --> (la 42 do) |#
0:52:34
lad
yitzi, i don't want to use ":" everywhere. the solfege language doesn't use colons at all so I don't want them
0:56:19
lad
pjb, symbol-macros seems to be exactly what i need in this case. otherwise i'd have to do it via a macro-expanding-to-let form. very interesting, thank you
4:05:51
jeosol
beach: btw, I noticed you extracted some statistics about # of :before, :after modifiers for one of you codebase. I was going to ask how you extracted those numbers
4:39:04
jeosol
I remember the days of using C++, one of the microsoft VC++ editor has some introspection
5:22:03
beach
So binding a special variable using something like LET, as in (let ((*x* <form>)) ...) must be the same as (progv '(*x*) (list <form>) ...) right?
5:22:33
beach
If so, binding special variables using LET or similar is just some kind of syntactic sugar for PROGV.
5:23:40
White_Flame
hmm, as LET binds in parallel, and PROGV binds in order, not sure that's exactly possible
5:24:09
White_Flame
as far as the visibility goes when mixing lexicals & specials in a singular LET form
5:27:42
White_Flame
I guess the init values are evaluated first, then the bindings are made, then forms are executed, though it's a bit hard to glean