bilegeek has quit [Remote host closed the connection]
avocadoist has quit [Ping timeout: 255 seconds]
|3b| has quit [Remote host closed the connection]
|3b| has joined #commonlisp
lucasta has quit [Quit: Leaving]
grawlinson has joined #commonlisp
bilegeek has joined #commonlisp
ym has joined #commonlisp
<Pixel_Outlaw>
Anyone have advice for a simple IRC bot with REPL?
<Pixel_Outlaw>
Essentially I want something to join that just acts like a REPL
<Pixel_Outlaw>
Like a member of the Chat not it's own server.
notzmv has joined #commonlisp
<aeth>
what if you had it evaluate with , e.g. ,(+ 1 1)
<ixelp>
(+ 1 1) => 2
<aeth>
Pixel_Outlaw: are you talking about something like that?
<Pixel_Outlaw>
Yes, exactly.
<Pixel_Outlaw>
Or maybe it has other commands I can write/add
<Pixel_Outlaw>
I tried a few from Cliki and they appear to be bitrotton
yitzi has quit [Remote host closed the connection]
mehbark has joined #commonlisp
<aeth>
idk what ixelp uses; I think gilberth wrote it
<Pixel_Outlaw>
Well there is Colleen as well but it looks complex to setup.
<aeth>
the only things I know about ixelp is that it's using CCL and it resets its environment each line, including e.g. a completely deterministic random, etc.
mehbark has quit [Remote host closed the connection]
pfdietz has quit [Quit: Client closed]
mehbark has joined #commonlisp
akoana has quit [Quit: leaving]
pfdietz has joined #commonlisp
edr has quit [Quit: Leaving]
habamax has quit [Ping timeout: 255 seconds]
Alfr has quit [Quit: Leaving]
mehbark has quit [Ping timeout: 256 seconds]
pfdietz has quit [Quit: Client closed]
szkl has quit [Quit: Connection closed for inactivity]
szkl has joined #commonlisp
Alfr has joined #commonlisp
danza has joined #commonlisp
habamax has joined #commonlisp
habamax has quit [Ping timeout: 245 seconds]
habamax has joined #commonlisp
decweb has quit [Ping timeout: 260 seconds]
Josh_2 has joined #commonlisp
glaucon has joined #commonlisp
habamax has quit [Ping timeout: 255 seconds]
Josh_2 has quit [Quit: Gotta go fast!]
eddof13 has quit [Quit: eddof13]
chomwitt has joined #commonlisp
<beach>
Like I said the other day, we created Consecution: https://github.com/s-expressionists/Consecution (we transferred it to s-expressionists). It now passes almost all the tests of the ANSI test suite. The ones that don't pass are the ones where the test suite expects a TYPE-ERROR to be signaled, and instead a NO-APPLICABLE-METHOD is signaled. Feel free to check it out.
<ixelp>
GitHub - s-expressionists/Consecution: An implementation of the Common Lisp sequence functions.
kenran has joined #commonlisp
pve has joined #commonlisp
dcb has quit [Quit: MSN Messenger 4.1.1]
igemnace has joined #commonlisp
danza has quit [Read error: Connection reset by peer]
rtypo has joined #commonlisp
prokhor has quit [Remote host closed the connection]
Pixel_Outlaw has quit [Quit: Leaving]
Pixel_Outlaw has joined #commonlisp
danza has joined #commonlisp
Pixel_Outlaw has quit [Client Quit]
ronald has quit [Ping timeout: 276 seconds]
ronald has joined #commonlisp
shka has joined #commonlisp
glaucon has quit [Read error: Connection reset by peer]
danza has quit [Ping timeout: 255 seconds]
amb007 has quit [Ping timeout: 245 seconds]
amb007 has joined #commonlisp
mzan has quit [Ping timeout: 246 seconds]
mzan has joined #commonlisp
traidare has joined #commonlisp
prokhor has joined #commonlisp
_cymew_ has joined #commonlisp
glaucon has joined #commonlisp
dnhester26 has joined #commonlisp
anticrisis has quit [Read error: Connection reset by peer]
mgl has joined #commonlisp
eddof13 has joined #commonlisp
ym has quit [Remote host closed the connection]
varjag has joined #commonlisp
eddof13 has quit [Ping timeout: 246 seconds]
danse-nr3 has joined #commonlisp
jonatack has quit [Ping timeout: 255 seconds]
Guest33 has joined #commonlisp
habamax has joined #commonlisp
dajole has quit [Quit: Connection closed for inactivity]
bilegeek has quit [Quit: Leaving]
bendersteed has joined #commonlisp
donleo has joined #commonlisp
Guest33 has quit [Ping timeout: 250 seconds]
Guest33 has joined #commonlisp
danse-nr3 has quit [Remote host closed the connection]
Posterdati has quit [Remote host closed the connection]
Posterdati has joined #commonlisp
Posterdati has quit [Remote host closed the connection]
Posterdati has joined #commonlisp
_cymew_ has quit [Quit: Konversation terminated!]
Guest63 has joined #commonlisp
makomo has joined #commonlisp
danse-nr3 has quit [Read error: Connection reset by peer]
danse-nr3 has joined #commonlisp
cimento has joined #commonlisp
dnhester26 has quit [Remote host closed the connection]
attila_lendvai has joined #commonlisp
glaucon has quit [Quit: WeeChat 3.5]
glaucon has joined #commonlisp
Guest63 has quit [Quit: Client closed]
Guest33 has joined #commonlisp
szkl has quit [Quit: Connection closed for inactivity]
kevingal has joined #commonlisp
Posterdati has quit [Ping timeout: 268 seconds]
cimento has quit [Ping timeout: 255 seconds]
yitzi has quit [Remote host closed the connection]
meritamen has quit [Remote host closed the connection]
Posterdati has joined #commonlisp
Guest33 has quit [Ping timeout: 250 seconds]
dnhester26 has joined #commonlisp
danse-nr3 has quit [Ping timeout: 256 seconds]
pfdietz has joined #commonlisp
glaucon has quit [Quit: WeeChat 3.5]
traidare has quit [Ping timeout: 255 seconds]
yitzi has joined #commonlisp
green__ has quit [Ping timeout: 252 seconds]
habamax has quit [Quit: ERC 5.5.0.29.1 (IRC client for GNU Emacs 29.1.90)]
<younder>
Has anyone written any Emacs tempel abbrev completions for Common Lisp?
cimento has joined #commonlisp
green__ has joined #commonlisp
<Devon>
younder: Slime
<beach>
younder: What is "tempel abbrev"?
<beach>
younder: I use "ip" for "cl:in-package", "df" for "defun", "dg" for "defgeneric", "dma" for "defmacro", "dme" for "defmethod", "dc" for defclass, "dv" for "defvar", and "dp" for "defparameter" if that is the kind of thing you are referring to.
<beach>
I think that's the right way to write FIND. :)
<Josh_2>
I have looked at Consecution. I have been keeping track of all the modules produced by the SICL project
<beach>
The macro FOR-EACH-RELEVANT-CONS actually does traverse the list from the end. :)
<edgar-rft>
the progn example still looks odd because a) the mixed usage of uppercase and lowecase code, and b) only the first (defparameter a 1) is right but tthe if form should be (if a (progn (setf a nil) ’here) (progn (setf a t) ’there))
<beach>
edgar-rft: I agree.
<Josh_2>
beach: looking at condition-reporters-en.lisp you may have answered the question I asked you yesterday :thinking:
<beach>
Oh, I see.
<Josh_2>
although I decided to just keep using my wrapping macro. Which is effectively what you have done for consecution but the method definition is done implicitely via a macro
<Josh_2>
method specialization*
danse-nr3 has quit [Ping timeout: 255 seconds]
<Josh_2>
I have tried my best to emulate the way you write CL
<Josh_2>
:sunglasses:
<beach>
I am flattered.
<beach>
Though Consecution was written by heisig.
<Josh_2>
Then I have tried to emulate the protocol oriented design :joy:
<beach>
That's definitely a good thing.
waleee has joined #commonlisp
zxcvz has quit [Quit: zxcvz]
<younder>
Josh_2 Your 'emojies' are showing up as :skull: not 💀
hayley has quit [Ping timeout: 245 seconds]
dtman34 has joined #commonlisp
<edgar-rft>
I prefer :skull: over hollow boxes with hex numbers
dnhester26 has joined #commonlisp
<younder>
lol
hayley has joined #commonlisp
<beach>
dnhester26: I tried to push to the repository but apparently I don't have permission to do so.
<ixelp>
Unicode, Ligatures and Color Emoji - Mastering Emacs
notzmv has quit [Ping timeout: 268 seconds]
traidare has joined #commonlisp
danse-nr3 has joined #commonlisp
tyson2 has joined #commonlisp
waleee has quit [Ping timeout: 260 seconds]
cage has joined #commonlisp
azimut has quit [Ping timeout: 240 seconds]
yitzi has quit [Remote host closed the connection]
seveno4 has quit [Quit: Leaving]
JamesF has joined #commonlisp
varjag has joined #commonlisp
eddof13 has joined #commonlisp
<Josh_2>
my emojis showing up as :skull: and :skull: huh :)
<Josh_2>
You can emojify erc so you can understand the zoomers using the emojify emacs package
<yottabyte>
I'm finding things a little tedious in cl, the standard library feels like it's missing a lot of things you just get for free in other languages. I guess it's not pitched as a "batteries included" language like Racket or Clojure, and I definitely see the advantages it has over those 2 languages
<yottabyte>
but how tedious it was to even split a string, there were so many options, I could use cl-ppre, uiop, split-sequence, trimming a string was more tedious than I would've liked, car and cdr feel very dated
<yottabyte>
idk if others feel this way
<beach>
yottabyte: Again, you can't compare "languages" without a standard to Common Lisp.
<beach>
yottabyte: Racket and Clojure don't have independent standards.
<splittist>
yottabyte: I certainly feel the anxiety of choice when trying to do things in a new language.
pranavats has left #commonlisp [Error from remote client]
<yottabyte>
beach: why not? can the argument not be made that the standard needs to be modernized?
pranavats has joined #commonlisp
<beach>
yottabyte: It could benefit from being modernized, but not by adding more to the "standard library".
<beach>
yottabyte: Those other "languages" without a standard, can just add things when they like, because there is only one implementation for each "language", so they don't have to worry about other implementations keeping up.
<beach>
It is not the same at all.
<aeth>
yottabyte: what is and isn't included is arbitrary, and if it is included, it may not be the fastest or most proper way to do it, and it doesn't seem to have an impact on popularity since the #1 language is probably either C or JavaScript, neither of which have large standard libraries
<aeth>
(and any website's attempt to track programming language popularity is an exercise in futility)
<aeth>
yottabyte: e.g. if CL included regex, there may be a better library for that, anyway... and it would depend on the implementation whether or not it's better!
jackdaniel has joined #commonlisp
<beach>
yottabyte: You just need some initial effort to choose the external library that is convenient for your application.
<jackdaniel>
any takers for testing on clisp, cmucl, allegro and lispworks would be appreciated for this small pull request on clx: https://github.com/sharplispers/clx/pull/205
bjorkintosh has quit [Quit: Leaving]
<ixelp>
Fix eof on kill by dkochmanski · Pull Request #205 · sharplispers/clx · GitHub
<jackdaniel>
if anyone has spare time please give it a try and leave a note in the pull request comment thread, thanks!
<yottabyte>
right, it feels like you have to do a lot of set up, but once you do, things become beautiful. you can write some amazing helper functions and macros to make things like working with maps and sets more convenient, but I just feel like, darn, why isn't this already in place for me? maybe I've just been spoiled
cimento has joined #commonlisp
<beach>
yottabyte: No, you have been lured into using "languages" without a standard, so they can evolve arbitrarily, making your code no longer work.
<yottabyte>
but I find myself being more inclined to use a plist instead of a hashmap/hashtable because it's less tedious. idk if anyone else feels that way. I might just very well have to write more CL
eddof13 has quit [Quit: eddof13]
jackdaniel has left #commonlisp [#commonlisp]
<beach>
yottabyte: You should design an abstract data type so that you can change the implementation at will without changing client code.
<beach>
yottabyte: That way, you can put off the decision.
cimento has quit [Client Quit]
<aeth>
if it ever happened, CL standard modernization would/should probably consist primarily of dropping implicit support for 16 bit implementations by greatly increasing various minimum sizes, except in the case of short-float, which actually needs its precision to be decreased to map to either popular half-precision floating point format (i.e. 16-bit float) because short-float seems to exist primarily to
<aeth>
provide an unboxed floating-point type for 32-bit implementations which would box the 32-bit single-float type.
pranavats has left #commonlisp [Error from remote client]
<aeth>
(a hypothetical 16-bit implementation can just stick to the older version of the standard)
<beach>
aeth: I think is should primarily consist of defining behavior that is currently undefined.
<beach>
aeth: But I guess WSCL could increase those minimum sizes. If all current implementations support it, then why not.
cimento has joined #commonlisp
cimento has quit [Client Quit]
<aeth>
beach: afaik, two of the most critical currently undefined parts are what the default expectation for char-code/code-char should be (which in a modern implementation should either be Unicode code points or ASCII, both of which are the same from 0 to 127)
eddof13 has joined #commonlisp
<aeth>
and the floating point representation for single-float and double-float (if both are provided as separate types), which should be IEEE (though there is no universal standard for short-float (where there's at least one popular alternative to IEEE 16-bit) and long-float (lots of possibilities for > double-float)
<aeth>
)
<bike>
it would be nice to actually define some more of the floating point stuff, like NaNs and exception configuration and bla bla bla, even aside from mandating particular bit lengths.
<aeth>
but some of the minimum sizes are quite low to the point where e.g. a > 1024 length string is non-portable because the minimum for array-total-size-limit is a very low 1024
<aeth>
bike: yes, basically float-features... though Unicode is a bit more critical because there isn't really a good option there. I don't think there's a portable alternative to what sb-unicode does, or at least there wasn't when I last checked.
<moon-child>
clisp doesn't use ieee floats
<moon-child>
things that desperately need specified and extended: strings, floats, concurrency
<aeth>
moon-child: CLISP doesn't have an acceptable float representation, doesn't have acceptable float performance, and is the only implementation I'm aware of where e.g. (upgraded-array-element-type 'single-float) => T
<bike>
yeah, i'm on board with those three for sure.
<aeth>
moon-child: I think it's safe to disregard CLISP in the case of floats
<moon-child>
it's sadly far too late to fix cl strings, but at least spec that they're unicode, there are no extended/nonstandard attributes, decide whether upcase/downcase and others are unicode or ascii-only (I dunno what the answer is but pick one)
Pixel_Outlaw has joined #commonlisp
<moon-child>
floats and concurrency could be actually good, though. modulo portability/hardware constraints. because unfortunately, not everything is an x86 cpu supporting avx512
<aeth>
moon-child: unfortunately, case is a bit of a mess in Unicode for characters because of e.g. I/ı İ/i with Turkish locale and I/i otherwise (which is why sb-unicode:uppercase takes in locale). Though the real mess is e.g. "ß", which capitalizes to "SS" in (sb-unicode:uppercase "ß"), which is probably one of the reasons why sb-unicode only works on strings, not characters.
<aeth>
it also doesn't round trip, e.g. final sigma is lower case only
kenran has quit [Remote host closed the connection]
<bike>
"case is a bit of a mess in human language"
<aeth>
i.e. (sb-unicode:lowercase (sb-unicode:uppercase "ς")) => "σ"
<splittist>
Collections of unicodey things are very complicated, and there are lots of knobs to twist, so a library (or libraries) solution seems the right way to go
<splittist>
s/twist/twiddle/, I guess
<aeth>
I think the standard only mandates specialized arrays for bit and character (and maybe a few others related to character?)
<beach>
aeth: I would personally like to be able to count on an error being signaled if I pass something other than an array to AREF.
<beach>
aeth: As it is, production code must contain explicit tests for that before calling AREF.
<bike>
standard-char as well, yes.
<aeth>
it would be great to have some feature that says "this is a 'normal' implementation that does normal things and isn't e.g. running on top of JS or something" so you could assume single-float, double-float, (unsigned-byte 8), etc., arrays actually exist (and actually are type checked!)
<aeth>
one queryable feature instead of having to upgraded-array-element-type 30 times or whatever
<aeth>
though I doubt anyone has a very large program that does things the right way so people just probably assume it works
<bike>
if you're separating implementations into "normal" and not you're just going to make all the other implementations practically useless since nobody bothers writing code for them.
Josh_2 has quit [Ping timeout: 268 seconds]
<bike>
it would be better to either keep the status quo or mandate whatever upgraded types for every implementation.
<aeth>
at least mandate the types be checked, yes
<aeth>
when (safety 0) isn't on or whatever if SBCL is going to fight to be less safe than C
<bike>
mandating upgraded element types is fairly harmless anyway. it means the implementation has to keep track of it for a-e-t but it doesn't actually have to implement packed storage.
<aeth>
yes
<aeth>
it would also only need to exist for the absolutely most popular ones, which may just be single-float, double-float, (unsigned-byte 8), (signed-byte 8)
<splittist>
signed-byte 8?
<aeth>
probably way less popular but you'd probably want it for symmetry?
<moon-child>
aeth: ideally, u-a-e-t of a would just be a, and you always get typechecks
bjorkintosh has joined #commonlisp
bjorkintosh has joined #commonlisp
<bike>
array type upgrading could definitely use a bit of an overhaul. trying to retrofit the type system to be about how to pack storage is awkward for several reasons.
<aeth>
moon-child: that may not be uncontroversial because of SATISFY types, change-class, etc., which means that for a lot of things, you wouldn't be able to assume (aref a 42) is of the type a says it is, and would have to check there, too
<bike>
my ideal solution would probably be to separate it, so array types can specify the type of the elements or the packing or both or neither. but that's a bit extreme.
<aeth>
bike: I suppose you could have an uaref (unchecked aref) if you're only using it for packing
<bike>
i should just write out a wishlist somewhere. concurrency, floats, array types, some other type stuff, specifying some type errors, environments, some compilation semantics...
attila_lendvai has quit [Ping timeout: 256 seconds]
<aeth>
Don't forget cons types! At the moment, I think they're O(n) to check if you bother to do so, which no one does for lists. You can make your own cons cells out of defstruct, but (1) not every implementation checks struct slot types (and on the other hand SBCL doesn't check class slot types at default optimization levels!) and (2) you now have to reimplement the entire list and sequence thing and use
<aeth>
something nonstandard like extensible-sequences
<aeth>
a typed linked list would store type A (which could be any arbitrary, complicated type unless you want to make it like u-a-e-t for some reason) in its CAR, and only the cons type itself or null in the CDR
<aeth>
Similarly, the ability to restrict either the key or the value type in a hash table.
<aeth>
Though if you really want to be elaborate you could also encode a plist that alternates, I guess
<bike>
yeah, that's stuff i would group under "some other type stuff"
<aeth>
The ideal being (for array, list, or hash table) that you check *once*, store it in the thing that is now typed, and now you don't get random mystery NILs
<aeth>
and maybe help the compiler out a bit, too
<aeth>
even arrays don't give you this because for non-bit/char stuff, it could be a T array, in which case, it could still give you the mystery NIL in your AREF
<aeth>
and if you want random mystery nils, the type system lets you do (or null <your-type-here>) although that will almost certainly not be stored optimally and only be useful for checking.
yitzi has joined #commonlisp
cimento has joined #commonlisp
<bike>
it would be kind of neat if implementations were smart enough to compile that as a typed union. but that would be tricky for several reasons
kevingal has quit [Remote host closed the connection]
<aeth>
might be possible to try to do that only for (or null <type>)
<aeth>
which as a side effect would also make boolean work since that's nil or t, although you'd really want a bit array instead
eddof13_ has joined #commonlisp
<splittist>
how many keyword args would have to be added to make-array?
<bike>
twenty seven.
<splittist>
(:
<bike>
i would actually say zero, though.
dnhester26 has quit [Remote host closed the connection]
dnhester26 has joined #commonlisp
<aeth>
There's also the need for another kind of array-like object to make the "array of structs" pattern from the C/C++/(Rust?)/etc. world expressible (by contrast, "structs-of-arrays" is trivial, if it's an array type supported by u-a-e-t), i.e. the ability to densely describe something like float float float (unsigned-byte 32) (unsigned-byte 32) float float float (unsigned-byte 32) (unsigned-byte 32) float
<aeth>
float float ... in a defstruct-like way.
<aeth>
It can't be expressed in AREF's/MAKE-ARRAY's semantics iirc.
<bike>
you would just need to change the semantics a bit, not have a new kind of object.
<bike>
allow defining structs that are (a) readonly (b) comparable by eql but not eq, like numbers. then you can stick those in packed arrays same as you stick numbers in packed arrays.
<aeth>
one thing on my wishlist would be to make FILL work on arrays that aren't sequences, though I guess that would affect the start and end keys
<aeth>
heck, FILL could in theory also work on hash tables
<bike>
what, like changing all the keys or all the values?
notzmv has joined #commonlisp
<dnhester26>
hi beach: I just sent you two invites for the two repositories. You have to accept them though by clicking on the links in the email from github. Apparently the previous invitation expired after 7 days.
<aeth>
Filling keys would be nonsensical, I think... filling all values where keys exist could have a use. Probably not worth it, though. Filling 2D arrays, though, absolutely worth it.
<beach>
dnhester26: Thanks!
<beach>
dnhester26: It worked. I edited the PROGN example again.
pranavats has joined #commonlisp
cimento has quit [Quit: WeeChat 4.1.2]
<bjorkintosh>
dnhester26, how did you manage to get all that up and running so quickly?
<bjorkintosh>
did you have a template ready to go or something? I'm impressed.
<dnhester26>
bjorkintosh I worked so hard! I can't believe how much time I've invested in this!!!!
<dnhester26>
beach: great!
dnhester26 has quit [Remote host closed the connection]
<bjorkintosh>
of course. fantastic.
danse-nr3 has quit [Ping timeout: 276 seconds]
pranavats has left #commonlisp [Error from remote client]
pranavats has joined #commonlisp
<moon-child>
sorry, had to go; anyway
<moon-child>
bike: I don't think there's any need for 'packing information'; the only thing that I think could be relevant is concurrency--e.g. an implementation might not want to provide atomic ops for arrays of unboxed complex double float, so you would want to be able to specify that
eddof13_ has quit [Quit: My MacBook Air has gone to sleep. ZZZzzz…]
<moon-child>
I also argued this (unsuccessfully) on the sbcl ml. Provide an interface as declarative as possible and let the implementation take care of itself
dcb has joined #commonlisp
<bike>
Like you let the implementation decide how to pack rather than it being specified by the programmer (beyond "this array is only going to have elements of this type")?
bendersteed has quit [Quit: bendersteed]
<moon-child>
yes
eddof13 has quit [Quit: eddof13]
varjag has quit [Ping timeout: 255 seconds]
<splittist>
(declare (pack t var)) vs (declare (pack pack-spec var)) ?
<bike>
seems like it could be kind of awkward if, for example, you declare a function as getting an (array (unsigned-byte 8)) argument, and then at runtime the implementation has to check if it's a packed ub8 array, or bit, or what.
eddof13 has joined #commonlisp
<moon-child>
you wouldn't end up in that situation
<moon-child>
array of bit isn't a subtype of array of ub8 because of mutation stuff
<moon-child>
java made that mistake--cl didn't
NotThatRPG has joined #commonlisp
eddof13 has quit [Client Quit]
<bike>
oh, so do you retain upgrading?
eddof13 has joined #commonlisp
<moon-child>
no
<moon-child>
why would you?
<moon-child>
array of bit would be one type, as would array of ub8, as would array of ub6
<moon-child>
with no subtyping relationships between them
<ixelp>
(subtypep '(array (unsigned-byte 8)) '(array t)) => NIL; T
varjag has joined #commonlisp
<bike>
so (array A) is type equivalent to (array B) iff A is type equivalent to B?
<moon-child>
yes
<moon-child>
that's how it already works
eddof13 has quit [Client Quit]
akoana has joined #commonlisp
<bike>
well how it already works includes upgrading. okay, i see.
lispmacs[work] has joined #commonlisp
varjag has quit [Ping timeout: 240 seconds]
dnhester26 has joined #commonlisp
szkl has joined #commonlisp
random-nick has joined #commonlisp
mgl has quit [Ping timeout: 256 seconds]
dnhester26 has quit [Remote host closed the connection]
dnhester26 has joined #commonlisp
dnhester26 has quit [Read error: Connection reset by peer]
<lispmacs[work]>
so, playing around with the inspector, I see that (SETF MY-ACCESSOR-NAME) is the name of a generic function. Can I give any (generic?) function a list for a name?
<Alfr>
lispmacs[work], no, only a symbol or a list (setf some-symbol) are valid. Look for "function name" in the glossary.
<lispmacs[work]>
hmm, so lisp basically added this special case, to make SETF work as desired
<lispmacs[work]>
interesting
zxcvz has joined #commonlisp
<aeth>
yes, SETF is a special case in general
<aeth>
usually designed to be a setter that parallels a getter (which has nothing to do with GETF... the getter is usually just the FOO to SETF's (SETF FOO))
<aeth>
which lets it work fairly transparently with e.g. SYMBOL-MACROLET and WITH-ACCESSORS
<lispmacs[work]>
A symbol is always equal to itself, right?
<lispmacs[work]>
let's see, there is prob some section on comparision in the spec...
<lispmacs[work]>
Data and Control Flow
<lispmacs[work]>
EQ, EQL, EQUAL, EQUALP
<lispmacs[work]>
simple enough
<NotThatRPG>
lispmacs[work]: Everything is always EQ to itself! What you probably care about is whether you are naming the same symbol or not when you use a name...
<NotThatRPG>
In some circumstances there can be two different symbols (not EQ) that have the same name.
<lispmacs[work]>
well, I'm storing either 'FG or 'BG in a slot, so I've got to be able to confirm which one I've got in the slot
<NotThatRPG>
If you type 'FG you get the symbol whose name is "FG" in the current package
<NotThatRPG>
So (eq 'FG 'FG) will always be true
<NotThatRPG>
And (eq 'FG 'BG) will never be true
<NotThatRPG>
(unless there's some corner case I'm forgetting)
<lispmacs[work]>
hmm, but if the user set that slot to 'FG, while he was in a different package, it is possible it could be a different symbol with the same name
danza has joined #commonlisp
<lispmacs[work]>
so, maybe I should be using keywords instead
<aeth>
yes, so you may want keywords
<aeth>
you could also ,(string= 'abc :abc)
<ixelp>
(string= 'abc :abc) => T
yitzi has quit [Ping timeout: 255 seconds]
<aeth>
but now that's using the slower string=
<aeth>
I think something like that is what LOOP does
yitzi has joined #commonlisp
<lispmacs[work]>
so, for understanding
<lispmacs[work]>
if I evaluate 'FG in the inspector
<lispmacs[work]>
it tells me that it is an unbound symbol
<lispmacs[work]>
but it also shows it as #<SYMBOL {100F93E89F}>
<lispmacs[work]>
what is the 100F93E89F referring to?
<lispmacs[work]>
memory location?
<aeth>
unbound means there's no function/variable/type to it. Or apparently just variable.
dajole has joined #commonlisp
<aeth>
and, yes, memory location
<aeth>
if you inspect 'list you'll see it's unbound (no variable) but it has a function, names a class, and names a primitive type
<lispmacs[work]>
so, does the symbol get created in memory the first time I do something like 'FG?
<aeth>
if you inspect 'most-negative-fixnum you'll see no "unbound" and instead it says "It is a constant of value"
pfdietz has quit [Quit: Client closed]
<aeth>
lispmacs[work]: yes, you're INTERNing it
<aeth>
into a package
<aeth>
with the exception of this syntax: '#:foo
<aeth>
where the inspector says "It is a non-interned symbol."
<aeth>
I think in that case it can be garbage collected, but this is IRC so if I'm wrong I'll be corrected
<lispmacs[work]>
I was just about to ask about symbols created in different scopes in the same package
<aeth>
afaik, 'foo is creating it at read time, while (intern "FOO") or the equivalent with no case assumption (intern (symbol-name '#:foo)) does it at runtime and the scope doesn't really matter (except perhaps to determine the *package*)
NotThatRPG has quit [Quit: My MacBook has gone to sleep. ZZZzzz…]
<aeth>
and either way it's creating it and never removing it unless you unintern it, with '#:foo as a special case that creates an uninterned symbol where ,(eq '#:foo '#:foo) should be nil
<ixelp>
(eq '#:foo '#:foo) => NIL
<aeth>
mostly used indirectly by ,(gensym) in macros
<ixelp>
(gensym) => #:G1
<aeth>
notice the trick though where ,(symbol-name '#:foo) has no case assumption
<ixelp>
(symbol-name '#:foo) => "FOO"
<aeth>
so if you must build a symbol from one or more strings, this is the safest way to do it, though quite a lot of code that hardcodes things like "FOO" or appending things like "FOO-" will break if it's not upcasing
NotThatRPG has joined #commonlisp
waleee has joined #commonlisp
<lispmacs[work]>
so, if I run (inspect :fg) in the REPL, it says that it is a SYMBOL in the package "KEYWORD"
<lispmacs[work]>
weird. so keywords are just symbols in a special package
traidare has quit [Ping timeout: 245 seconds]
eddof13 has joined #commonlisp
igemnace has quit [Remote host closed the connection]
<aeth>
yes, #:foo is one of the special symbol syntax, and :foo is the other... and unlike #:foo, you don't need to quote :foo like ':foo
<aeth>
(if you want it quoted, anyway)
<aeth>
,':foo and ,:foo and ,'keyword:foo are the same
<aeth>
Otherwise you just have package:symbol for exported symbols package::symbol for all symbols and symbol for a symbol in the current package. Where you probably want them quoted if you don't want them potentially evaluated as a variable or a function (etc.) depending on their location
<moon-child>
bike: all I'm saying is (u-a-e-t x) should always be x. a completely backwards compatible change
<aeth>
moon-child: what happens if it's a SATISFIES type or you call CHANGE-CLASS on one of the items?
<moon-child>
aeth: same thing as for a struct or class with a slot of declared type
<aeth>
unfortunately, struct and class slot types aren't enforced
<aeth>
seems more problematic with structs since that's the whole point of using them
lottaquestions has joined #commonlisp
attila_lendvai has joined #commonlisp
<bike>
moon-child: yeah, i understand. i'd have to think through the consequences.
NotThatRPG has quit [Quit: My MacBook has gone to sleep. ZZZzzz…]
<moon-child>
aeth: struct slot types are enforced by sbcl
mgl has quit [Ping timeout: 256 seconds]
<aeth>
moon-child: yes, but this discussion wasn't about SBCL's behavior, but rather about what a new standard might want to require rather than permit
<moon-child>
what's your point?
<aeth>
that the problem isn't solved for structs or classes (or DECLARE, etc.) in general at the language level because implementations can just ignore this
<aeth>
just like e.g. Scheme "solves" tail recursion in general whereas CL just permits it (and being able to force on tail recursion for a function that needs it in order to not blow up the call stack would be a nice feature)
pfdietz has joined #commonlisp
<moon-child>
I guess that sbcl should mark slots as unsafe whose types potentially intersect standard-object
<moon-child>
(though it wouldn't solve the problem due to races)
NotThatRPG has joined #commonlisp
<aeth>
it shouldn't break SBCL as long as (safety 0) isn't done... or maybe it does who knows.
NotThatRPG has quit [Client Quit]
<moon-child>
what do you mean? I just showed that it creates a contradiction
<moon-child>
if you can prove a contradiction, you can prove anything
<aeth>
does the contradiction create a runtime corruption
<aeth>
maybe it does
NotThatRPG has joined #commonlisp
tyson2 has quit [Remote host closed the connection]
zxcvz has quit [Quit: zxcvz]
danza has quit [Ping timeout: 260 seconds]
azimut has joined #commonlisp
yitzi has quit [Ping timeout: 252 seconds]
yitzi has joined #commonlisp
NotThatRPG has quit [Quit: My MacBook has gone to sleep. ZZZzzz…]
NotThatRPG has joined #commonlisp
mariari has quit [Ping timeout: 252 seconds]
akoana has quit [Quit: leaving]
eddof13 has quit [Quit: eddof13]
mariari has joined #commonlisp
pfdietz has quit [Quit: Client closed]
eddof13 has joined #commonlisp
ldb has joined #commonlisp
tmtt has joined #commonlisp
dra has joined #commonlisp
<tmtt>
Hi! I'm using Vim and SlimV for my common lisp needs. Is there a way to stop SlimV from making new tmux windows for the swank server? I tried fiddling around with g:slimv_swank_cmd to run SBCL in the background (with `let g:slimv_swank_cmd = '!sbcl --load <...>/slimv/slime/start-swank.lisp &'`) but then it won't connect to the repl (unless I run the same command outside vim). Thanks a lot in advance :)
NotThatRPG has quit [Quit: My MacBook has gone to sleep. ZZZzzz…]
bilegeek has joined #commonlisp
attila_lendvai has quit [Ping timeout: 256 seconds]
hayley has quit [Changing host]
hayley has joined #commonlisp
cage has quit [Quit: rcirc on GNU Emacs 29.1]
<tmtt>
Nevermind, I managed to make it use `screen` instead of tmux to run the swank session. Looks like it crashed when ran within vim because it couldn't get any IO.
<ldb>
tmtt: so what is the expectation when say stop it from making new tmux windows?
yitzi has quit [Remote host closed the connection]
<ldb>
it needs something to held to sbcl program alive
<tmtt>
well, whenever I started a repl inside vim it would create a new tmux window only for the swank server, showing logs and other stuff.
<ldb>
right, what's the matter? you want only launch it as a process that directs output to /dev/null?
anticrisis has joined #commonlisp
<tmtt>
no, but surely there's a way to keep SBCL alive without cluttering my tmux, right? lol
makomo has quit [Ping timeout: 256 seconds]
<tmtt>
I mean, I can start and stop the swank server from within Vim, so there's no need to keep it lying around waiting for me to close it manually when I don't need it anymore
eddof13 has quit [Quit: eddof13]
<ldb>
tmtt: the point is the connection can by crashed by the program you run in sbcl, then the only thing you can do to the sbcl process is kill it instead of able to recover some data from it