selwyn has quit [Read error: Connection reset by peer]
waleee has quit [Quit: WeeChat 3.2]
waleee has joined #commonlisp
derelict has joined #commonlisp
taiju has quit [Ping timeout: 258 seconds]
akoana has left #commonlisp [#commonlisp]
waleee has quit [Ping timeout: 255 seconds]
beach` has joined #commonlisp
beach has quit [Ping timeout: 255 seconds]
derelict has quit [Quit: WeeChat 3.2]
taiju has joined #commonlisp
pjb has joined #commonlisp
hafat has quit [Ping timeout: 255 seconds]
mcfrdy- has joined #commonlisp
mcfrdy has quit [Ping timeout: 255 seconds]
lottaquestions_ has joined #commonlisp
lottaquestions has quit [Ping timeout: 255 seconds]
Bike has joined #commonlisp
lottaquestions_ has quit [Client Quit]
lottaquestions_ has joined #commonlisp
lottaquestions_ has quit [Client Quit]
<Bike>
helloooo. i am working on my threads extension again. can someone give me a name to use for a declaration that means "the compiler can/should insert points where asynchronous signals can be handled"? i'm blanking. i was going to use "interruptible", but then the opposite would be "uninterruptible", but code not having safe points doesn't mean it
<Bike>
cannot be interrupted
dsk has quit [Ping timeout: 240 seconds]
<aeth>
Bike: asyncable?
<aeth>
(compare with: ignorable)
<moon-child>
I don't think that's a problem per se. That you've marked some function as interruptible doesn't mean other functions are uninterruptible, only that you haven't explicitly said they're interruptible
<Bike>
well what i mean is there'd be another declaration meaning "do NOT insert these points"
<Bike>
and i don't want to call that "uninterruptible"
<Bike>
because that's different (e.g. the programmer could insert explicit safe points)
White_Flame has quit [Ping timeout: 272 seconds]
<moon-child>
ah, fair enough
<moon-child>
so there are three different states a function can have?
<moon-child>
oh, no, I misread
<Bike>
two. either points are inserted or they're not, and by default they're not. i could also add a finer grain to it i guess, like some points are inserted, but i don't know how valuable that would be
<moon-child>
how about 'hooked' and 'unhooked'? (Because the function contains 'hooks' for async signals)
<Bike>
not bad, but "hook" might have too many other meanings
<Bike>
maybe for now i'll just write something like "insert-safepoints" "noinsert-safepoints" and solve the hardest problem in computer science later
tyson2 has quit [Remote host closed the connection]
zacts has joined #commonlisp
CrashTestDummy3 has joined #commonlisp
CrashTestDummy2 has quit [Ping timeout: 255 seconds]
peterhil has joined #commonlisp
prxq_ has quit [Ping timeout: 268 seconds]
prxq has joined #commonlisp
zacts has quit [Ping timeout: 246 seconds]
beach` is now known as beach
<beach>
Good morning everyone!
lotuseater has quit [Ping timeout: 246 seconds]
pjb has quit [Ping timeout: 246 seconds]
mcfrdy has joined #commonlisp
mcfrdy has quit [Changing host]
mcfrdy has joined #commonlisp
mcfrdy- has quit [Ping timeout: 265 seconds]
<PinealGlandOptic>
beach: !
<PinealGlandOptic>
beach: you migrated as well
<beach>
To Libera?
<PinealGlandOptic>
beach: yep
<beach>
Sure. Didn't everyone?
<PinealGlandOptic>
beach: some users are still at Freenode. Dunno why
<beach>
Hmm.
<remexre>
how are &key args efficiently implemented in the absence of inlining?
<beach>
The function basically has to loop over all the remaining arguments and compare the keys.
<remexre>
okay, the looping is what I was thinking of; desugaring &key a to something like &key a (error "missing a"), and iterating through
<beach>
Another common "trick" is to define a compiler macro where it matters.
paulapatience has joined #commonlisp
<beach>
Why the error?
<remexre>
the language I'm implementing isn't actually CL-compatible, just CL-like
<remexre>
"things don't generally implicitly default to nil" is one of the changes I'm making
<moon-child>
remexre: that's how s7 does it as well
<beach>
remexre: That's not going to make it more efficient though.
<remexre>
right, that's the inefficient one
<remexre>
after reading the one you sent
<remexre>
Is the trampoline he same idea as adding an "inline-arg-parsing" declaration, and making defun generate a wrapper for arg parsing; inline-arg-parsing sets the inline flag only on the outer function, inline sets it on both
<beach>
No. Anything done at compile time in the caller must be re-done when the callee is redefined. The technique in the paper does not require the caller to be recompiled when the callee changes.
paulapatience has quit [Remote host closed the connection]
<beach>
Recompiling callers is iffy in Common Lisp, because of the requirement of "minimal compilation". You would need to keep around a fully macroexpanded version of the caller.
<remexre>
how does the snippet get replaced?
<beach>
It's all in the paper. It gets replaced when the callee is redefined.
Bike has quit [Quit: Connection closed]
<remexre>
er, how, not when
<remexre>
like shouldn't that require updating the caller?
<beach>
No.
<beach>
The arguments that the caller supplies remain the same.
<beach>
So there is no reason to update the caller.
<remexre>
oh, right, (f 1 2 3) is already indirecting through f, so the pointer that looks up can just change since it wouldn't be a direct jmp anyway?
<remexre>
or
<remexre>
hm
<beach>
Right. The jump target is altered when the callee is redefined, so that it goes to a new trampoline snippet.
<beach>
But if you are designing a new language, you can do what you want. No need to respect Common Lisp semantics. You can remove the "minimal compilation" restriction and just recompile the callers.
<remexre>
yeah, the real problem with that is I don't have weak refs yet, lol
<moon-child>
'just' that could be a nontrivial enterprise, for an optimizing compiler
<moon-child>
(in terms of compile time, I mean)
<beach>
I wouldn't expect there to be a lot of redefinitions of callees with a lot of callers.
<beach>
And it's all compile-time stuff anyway.
<beach>
remexre: If you are designing a new language, introducing weak references is trivial. I would amount to a maximum of a paragraph in the language definition.
<beach>
But maybe you are implementing it as well.
<moon-child>
most people who design languages are obligated by necessity to implement them themselves, or to go without an implementation
<remexre>
yeah, implementation is the problem
<remexre>
I definitely need weak maps at least, and at that point weak pointers are trivial
<remexre>
but I'm doing my own GC, and they're NYI (and the bootstrapper's GC doesn't support them)
mcfrdy has quit [Ping timeout: 255 seconds]
Bike has joined #commonlisp
<beach>
remexre: I am curious. Why are you designing a new language?
<remexre>
mad @ unix
Mandus has quit [Ping timeout: 268 seconds]
lottaquestions has joined #commonlisp
Mandus has joined #commonlisp
Volt has joined #commonlisp
<beach>
remexre: Designing a new language is a lot harder than implementing an existing specification, so there must be something you can not tolerate about Common Lisp in your context, no?
<beach>
Apparently, your new language has automatic memory management and keyword arguments, so you are not skimping there.
<remexre>
trying to make something that's like, CL-like but with better support for implementing other languages in it and doing interop in the same process, and making the VM a lot more erlang-like (lots of immutability, message-passing, probably the same supervisor/link/etc design)
<beach>
I see.
<remexre>
probably going to implement an attribute grammar language and a dependent static lang on top of it, maybe a logic language too
<moon-child>
what is it about cl that makes it unamenable to such designs? You can certainly implement vms and other languages atop it; and frameworks for making such things easier. There's a fairly complete ml somebody's done, for instance
<remexre>
can I do the erlang-stuff without a code-walker?
<beach>
remexre: Good luck. Such an undertaking is no doubt an order of magnitude harder than something like SICL.
<moon-child>
since you're not going full-out on the immutability (I assume, since you refer to weak pointers), they don't let you simplify any other aspects of the implementation
<remexre>
I have some types that have mutability, but most don't
<remexre>
e.g. conses are immutable, but I have mutable hashtables, mutable cells, etc
<moon-child>
what erlang stuff? Context switching? I think you might be best served by making an implementation with extensions specialized for the purpose, but piggybacking atop cl lets you take advantage of a lot of existing ocde and, as beach mentions, means you don't have to design a language from scratch. Of course, I dont' have very much right to say such a thing, but ¯\_(ツ)_/¯
<remexre>
like being able to run 10k processes on one machine, being able to structure applications with links+monitors (and supervisors etc on top of them), message-passing of immutable values (with that being checked), etc
<remexre>
idk, not my first lang design or implementation
<moon-child>
remexre: I have full immutability, except for buffers (fixnums/floats/bytes/whatever); this simplifies the gc because you can collect concurrently without barriers. If you have mutable objects that contain references, then you still have to deal with all the consequences of mutability
<remexre>
I tihnk doing erlang means you don't actually want concurrent GC, because you want to "charge" GC against the process in the scheduler
Mandus has quit [Ping timeout: 265 seconds]
Mandus has joined #commonlisp
<moon-child>
my understanding is that in erlang every process has its own heap
<remexre>
yeah
<moon-child>
which means that if two erlang processes are running on two different physical cpu cores, one can be gc'd while the other is running
<moon-child>
which looks a lot like concurrent gc
<remexre>
sure, yeah
<moon-child>
however this only works because messages are always copied when sent. If I try to send a mutable cons cell from one thread to another under this model, all behaviours are wrong
<remexre>
yep, that's why I'm separating immutable vs mutable types
<moon-child>
so mutable data cannot be sent in messages?
<remexre>
yeah
lisp123 has joined #commonlisp
<moon-child>
hmm. I prefer actually shared-immutable, but eh you do you :)
<remexre>
considered it, but it'
<remexre>
d be really nice if I could do the multi-machine stuff too
<moon-child>
when you do that you have referential transparency. So you _can_ do a copy if you want
<remexre>
I guess
<remexre>
idk, if it's expensive enough that it's often showing up in profiles, I'll maybe add a special mechanism for it
<remexre>
but I hypothesize that most data is small or strings/byte-vectors, both of which should be quick to copy
taiju has quit [Ping timeout: 268 seconds]
<remexre>
er, most data being sent via message*
jmes has quit [Remote host closed the connection]
lisp123 has quit [Remote host closed the connection]
lisp123 has joined #commonlisp
Bike has quit [Quit: Connection closed]
taiju has joined #commonlisp
gaqwas has joined #commonlisp
taiju has quit [Ping timeout: 268 seconds]
lisp123_ has joined #commonlisp
taiju has joined #commonlisp
lisp123__ has joined #commonlisp
lisp123 has quit [Ping timeout: 252 seconds]
lisp123_ has quit [Ping timeout: 255 seconds]
lisp123 has joined #commonlisp
lisp123__ has quit [Read error: Connection reset by peer]
taiju has quit [Ping timeout: 255 seconds]
mcfrdy_ has joined #commonlisp
gaqwas has quit [Ping timeout: 268 seconds]
taiju has joined #commonlisp
Volt has quit [Quit: ]
trufas has quit [Ping timeout: 276 seconds]
trufas has joined #commonlisp
amb007 has quit [Ping timeout: 255 seconds]
amb007 has joined #commonlisp
CrashTestDummy2 has joined #commonlisp
CrashTestDummy3 has quit [Ping timeout: 268 seconds]
pve has joined #commonlisp
hendursa1 has joined #commonlisp
hendursaga has quit [Ping timeout: 244 seconds]
<lisp123>
Is there a way to test only for 't'?
<moon-child>
(eq t whatever)?
ems has joined #commonlisp
ems has quit [Client Quit]
<lisp123>
moon-child: thanks that works. I have then tried (setf test t) and did (eq t test) and it worked - from my understanding eq tests if objects are identical and not their values
<lisp123>
i.e. eq compares pointers - is there a chance that two symbols, both with t value will have pointers to different "t"?
<moon-child>
no
<moon-child>
symbols are interned
<moon-child>
so--it's not the case that (eq t '#:t), but I expect you don't want that to be the case
<moon-child>
(obviously two symbols named 't' from different packages will also not be eq, but again that's probably what you want)
<pve>
lisp123: if you are asking whether (eq 'cl:t 'cl:t) is always true, then yes
treflip has joined #commonlisp
<lisp123>
I am storing values in symbol - which can be either nil, t, or a value
<lisp123>
So I want to be able to distinguish between t & value
<lisp123>
(not knowing what value is)
<moon-child>
in that case, eq does what you want
<pve>
lisp123: then (eq t ... ) is what you need
<lisp123>
thanks, (this is just out of curiousity) does that mean a symbol with value t points to only instance of the value t?
<pve>
lisp123: yes, but like moon-child said, you need to know about packages to have the complete picture
<moon-child>
an interned symbol named "T" (or anything else) is unique within its package. It is possible to create uninterned symbols, and symbols from different packages are distinct
<lisp123>
oh oaky, thanks pve & moon-child. I think I get it. So I need to be careful if comparing symbols from different packages?
<lisp123>
but within one package, its okay
<pve>
lisp123: and when you say "t", you implicitly mean cl:t
<moon-child>
most packages do not export symbols named NIL or T, so you are probably safe on that count. In a general sense, you need to be aware of packages when comparing symbols, but the default behaviour is almost certainly what you want
<pve>
lisp123: try (symbol-package t) in your package
<lisp123>
thanks! that all makes sense now
Lord_of_Life_ has joined #commonlisp
Lord_of_Life has quit [Ping timeout: 265 seconds]
Lord_of_Life_ is now known as Lord_of_Life
<conjunctive>
Hello, when defining a binary class (using the binary-types package) is it possible to express a sequence of another binary class as a single binary type? For example with class Y I'd like a slot describing 20 of class X in sequence.
cage has joined #commonlisp
amb007 has quit [Ping timeout: 268 seconds]
pjb has joined #commonlisp
amb007 has joined #commonlisp
lisp123_ has joined #commonlisp
lisp123 has quit [Ping timeout: 268 seconds]
lisp123 has joined #commonlisp
lisp123_ has quit [Ping timeout: 258 seconds]
<pve>
Is there a function similar to "(setf macro-function)", but for symbol macros? I.e. something that can be used to install a symbol macro.
Guest77 has joined #commonlisp
<pjb>
pve: there is not. You have to use the macro define-symbol-macro. You could do: (defun (setf symbol-macro) (new-expansion symbol) (eval `(define-symbol-macro ,symbol ,new-expansion))) and (defun symbol-macro (symbol) (macroexpand-1 symbol)) (symbol-macro 'foo) #| --> foo ; nil |# (setf (symbol-macro 'foo) '(car koo)) #| --> foo |# (symbol-macro 'foo) #| --> (car koo) ; t |# (let ((koo '(a . d))) foo) #| --> a |#
<pjb>
pve: but only for global symbol macros. For lexical symbol macros, you have to use symbol-macrolet.
<pve>
pjb: thanks, I kinda guessed this called for eval
<pjb>
Since macros are compilation-time objects, local symbol macros still have to be known at compilation-time, so you cannot use setf to mutate them.
ems has joined #commonlisp
mcfrdy_ has quit [Quit: Connection closed for inactivity]
hafat has joined #commonlisp
hafat_ has joined #commonlisp
hafat has quit [Client Quit]
hafat_ has left #commonlisp [#commonlisp]
hafat has joined #commonlisp
frgo has quit [Remote host closed the connection]
frgo has joined #commonlisp
kakuhen has quit [Quit: Leaving...]
dsk has joined #commonlisp
random-nick has joined #commonlisp
learning-cl has joined #commonlisp
tyson2 has joined #commonlisp
dsk has quit [Ping timeout: 246 seconds]
lisp123_ has joined #commonlisp
lisp123 has quit [Ping timeout: 265 seconds]
lisp123 has joined #commonlisp
CrashTestDummy3 has joined #commonlisp
rgherdt has quit [Remote host closed the connection]
CrashTestDummy2 has quit [Ping timeout: 252 seconds]
lisp123_ has quit [Ping timeout: 255 seconds]
lucerne has quit [Quit: Bye]
greyrat_ has joined #commonlisp
lucerne has joined #commonlisp
greyrat has quit [Ping timeout: 240 seconds]
Alfr has joined #commonlisp
treflip has quit [Quit: bb]
aleamb has joined #commonlisp
learning-cl has quit [Ping timeout: 246 seconds]
pjb has quit [Remote host closed the connection]
silasfox has quit [Ping timeout: 268 seconds]
silasfox has joined #commonlisp
learning-cl has joined #commonlisp
amb007 has quit [Ping timeout: 268 seconds]
amb007 has joined #commonlisp
aleamb has quit [Ping timeout: 265 seconds]
pjb has joined #commonlisp
tyson2 has quit [Quit: ERC (IRC client for Emacs 27.2)]
CrashTestDummy2 has joined #commonlisp
CrashTestDummy3 has quit [Ping timeout: 255 seconds]
Th30n has joined #commonlisp
amb007 has quit [Ping timeout: 268 seconds]
amb007 has joined #commonlisp
azimut_ has quit [Ping timeout: 244 seconds]
azimut has joined #commonlisp
<lisp123>
I was thinking
<lisp123>
Would it have been smarter for CL to define all of its functions as defgenerics / defmethods instead?
<lisp123>
that way one could re-use these function names for one's own classes
<pve>
lisp123: efficiency was probably a concern
<_death>
no, that wouldn't be particularly smart.. a generic function serves a dual role, one for callers and one for extenders.. simply taking an ordinary, nonextensible function (with a contract for callers) and making it generic would get you the worst of both sides
<lisp123>
pve: thanks, makes sense - I guess there is a cost of "looking up" the correct method to apply each time
<lisp123>
_death: could you expand? is it the loss of clarity from having different versions of a given function?
<pve>
though I don't *know* if actually was a concern, much less the main one
dsk has joined #commonlisp
<_death>
consider a function like EQUAL.. for each pair of objects you can pass to it, there is a rule saying whether it returns true or false.. callers of EQUAL can rely on these fixed semantics.. if you just make it generic, suddenly EQUAL becomes some amorphous function that isn't very useful to callers.. consider function +.. making it a generic function would not be useful for extension, because it accepts any number of terms (including
Inline has quit [Quit: Leaving]
<_death>
zero) and you wouldn't want to specialize on every term
<_death>
(wrt EQUAL, note that methods can be added or removed at any time)
<_death>
often you need to create one function that is meant to be called, and another function or set of functions that are meant to be extended
<_death>
could CL be more extensible? yes, but that work would involve much more than making all functions generic
<_death>
for example look at Eclector which has protocols for extending the Lisp reader
Inline has joined #commonlisp
<_death>
for an example of parroting caller interface with "shadow" GFs, look at Gray Streams.. the interface for extension is pretty similar to what the callers have, with some tweaks like different behavior on EOF or such.. some of the bad consequences are described in Franz's simple-streams section in their manual
<lisp123>
_death: "and you wouldn't want to specialise on every term" >>> Perhaps my understanding of generic functions is incorrect (likely), but from what I understand (and I was trying to google it now), if there is no method defined for the class in question, the method for a class it inherits from is used? i.e. the most specialised method is used
<_death>
lisp123: what I mean is, suppose you wanted to extend to vectors.. how would you define a + method for doing that..
<beach>
This discussion is a great example of why language design is hard, and why we need to be very careful before thinking that suggested changes are automatically good.
<beach>
<_death>
lisp123: the solution in case might be to define two generic functions, UNARY-+ and BINARY-+ and have + call them as needed.. so one interface for callers and another for extenders
<lisp123>
_death: so to summarise, functions are meant to be called and we don't want to change their meaning, while generic functions are meant to be "user-defined" and when one sees it, they work with them in mind. Hence, its not good to make standard functions customizable, especially when multiple people work on the same codebase?
<_death>
lisp123: the point is that you don't always need or want to make things extensible, and when you do, you need to think it through
<lisp123>
beach: yes :-) I find one of the great beauties of Lisp is its clarity of concepts, that even mere mortal users start thinking at a higher level (and that helps improve their abilities - even though 90% of the time they are wrong ;)
<lisp123>
_death: gotcha
<_death>
lisp123: also, sometimes making things extensible doesn't mean using CLOS
<lisp123>
_death: noted
<beach>
lisp123: What I find most impressive about Common Lisp is that, the more I study it (in order to implement it), the more I am impressed by how smart and knowledgeable the people were who created the standard.
zacts has joined #commonlisp
<lisp123>
(my example came from writing my own 'remove-duplicates' for a certain list of objects and trying to avoid having to use a custom name such as remove-object-duplicates)
<lisp123>
beach: :-) Indeed, it seems like an amazing language
<beach>
lisp123: It has taken me decades to understand the language well enough to hope to implement it. It will take me another couple of decades to acquire enough knowledge to improve it.
<beach>
... aside from tiny little things like we do in WSCL.
<lisp123>
beach: at least you will know that what you are doing is on the frontier of Computer Science, whilst other languages keep re-applying the old concepts that CL already worked through
<lisp123>
beach: have you had a chance to talk to some of the CL committee members?
IPmonger has joined #commonlisp
IPmonger has quit [Remote host closed the connection]
<beach>
lisp123: I am sure I have. I would have to look at the names again.
<_death>
more reasons that CL isn't very extensible in some parts is that it's an evolutionary step and had to take backwards compatibility into account.. also, CLOS was a new design and not everyone had lots of experience with it, and the idea of a CLOS-less subset of CL was in the air as well
<beach>
Kent Pitman was at ELS once, or perhaps ILC, I don't remember.
<lisp123>
_death: Thanks, that is good background knowledge to have
<beach>
pve has a point as well, given that PCL was the best they could do at the time in terms of generic dispatch, generic functions would have had a significant cost associated with them.
<beach>
And then we would have had to take opinions like "Lisp is slow" more seriously.
<lisp123>
beach: nice, his article(s) on exceptional situations in lisp were A+, although I must admit I can't be bothered using conditions when I code lol (although I might for one use-case soon: when I use somebody else's packages and am not guaranteed of the behaviour of that package)
<beach>
That's part of what impresses me with the language. They didn't include features that they weren't absolutely sure could be implemented efficiently. Unlike people who create other languages like Python.
<beach>
lisp123: So what do you do when you detect a violation of some precondition?
<lisp123>
Indeed, I think especially given the circumstances of processing power in the 70s and 80s
<_death>
if you have a language like Go, which didn't need to care for any previous codebases, you can see that some parts of its standard library are designed with extensibility in mind that makes things very convenient after adoption.. in CL you can create de-facto standards of extensibility, and it has more powerful tools to adapt the language, but it's more evolutionary and less "intelligent design".. of course, as time goes by, Go has to
<_death>
evolve and cannot be "re-designed" without terrible impact
peterhil has quit [Ping timeout: 268 seconds]
<lisp123>
beach: I write 95% of my code, so I keep it all in my head and make sure it all works - as long as I don't open it up to the outside world, it hasn't been too much of an
<beach>
lisp123: Oh, dear. You must have debugging nightmares, with incorrect results propagating way too far along the way.
<beach>
lisp123: That's not a very efficient way to work.
<lisp123>
beach: lol ;) I'm learning by struggling :-) I'm doing a lot of very conceptual work, so there are less moving pieces and rote code, so for now I'm spending all of my limited energy on the problem at hand. I think as my program evolves, I will switch over to a more robust phase
<lisp123>
I think its about 3k lines of code atm to give you context
<beach>
I recommend the work of Bertrand Meyer about modularity. He made a lot of concepts clear, like preconditions, invariants, exceptional situations.
<beach>
lisp123: So you are a newbie programmer in general? Not only in Common Lisp?
<lisp123>
I would say a little bit above newbie, but not professional. I dropped out of IT in University (switched to business), but I do all front-end web dev work without probolem and created my own (somewhat popular :) ) apps in Swift for IOS
<lisp123>
but no formal training, so a lot of stuff I do very badly (error handling and writing proper commit messages seem to be common ones), and wouldn't be able to work in a team for sure
<lisp123>
beach: thanks for the link, will definitely read
<beach>
Sure.
learning-cl has quit [Ping timeout: 246 seconds]
aleamb has joined #commonlisp
amb007 has quit [Ping timeout: 258 seconds]
amb007 has joined #commonlisp
dsk has quit [Ping timeout: 255 seconds]
amb007 has quit [Ping timeout: 252 seconds]
amb007 has joined #commonlisp
silasfox has quit [Ping timeout: 258 seconds]
Th30n has quit [Quit: WeeChat 3.2]
learning-cl has joined #commonlisp
learning-cl has left #commonlisp [#commonlisp]
lisp123 has quit [Remote host closed the connection]
lisp123 has joined #commonlisp
<jcowan>
If you think you want weak pointers, you really want ephemerons.
OlCe has joined #commonlisp
Bike has joined #commonlisp
lisp123 has quit [Ping timeout: 252 seconds]
OlCe has quit [Ping timeout: 268 seconds]
paulapatience has joined #commonlisp
isekaijin has joined #commonlisp
amb007 has quit [Ping timeout: 252 seconds]
amb007 has joined #commonlisp
lisp123 has joined #commonlisp
peterhil has joined #commonlisp
Alfr has quit [Quit: Leaving]
recordgroovy has quit [Ping timeout: 258 seconds]
pve_ has joined #commonlisp
pve has quit [Ping timeout: 255 seconds]
recordgroovy has joined #commonlisp
pve_ is now known as pve
recordgroovy has quit [Remote host closed the connection]
waleee has joined #commonlisp
zacts has quit [Ping timeout: 246 seconds]
lisp123 has quit [Remote host closed the connection]
zacts has joined #commonlisp
shka has joined #commonlisp
lisp123 has joined #commonlisp
Bike has quit [Quit: Connection closed]
lisp123 has quit [Ping timeout: 258 seconds]
lotuseater has joined #commonlisp
zacts has quit [Ping timeout: 246 seconds]
lisp123 has joined #commonlisp
<lotuseater>
beach: Why did you choose the BSD license for SICL? (I don't know much about licensing yet.)
gaqwas has joined #commonlisp
<shka>
bsd and MIT are interchangeable honestly
<shka>
gpl is different, but it is hard to even interpret in the context of lisp program
silasfox has joined #commonlisp
<shka>
would running lisp code in GPL implementation made code also gpl?
<lotuseater>
sounds to be a complex topic
<shka>
i don't know, i am not a lawyer
<lotuseater>
I'm not too (obviously) :D
<lisp123>
shka: what is your feeling? would it make the code GPL?
<shka>
uh, i think so, yeah, but no idea really
<lisp123>
wow thats tough
<lisp123>
(sorry to continue this topic among us non-lawyers, buts its an interesting one), but that would imply all emac packages are GPL?
<lisp123>
whereas people do release their packages under other licenses, so perhaps their view is different
<jackdaniel>
it would not, program is input to the implementation
<jackdaniel>
like document printed with gpl document reader is not gpl
<lisp123>
jackdaniel: that was what my understandign was too
azimut has quit [Ping timeout: 244 seconds]
azimut_ has joined #commonlisp
Alfr has joined #commonlisp
<jackdaniel>
gpl seems to be often disregarded with passion based on fueled fud (me ceases offtopic ;)
<shka>
at any rate
<shka>
i case of sicl
<shka>
if sicl components are supposed to be used
paulapatience has quit [Read error: Connection reset by peer]
<shka>
then bsd license is good fit
<shka>
as majority of existing cl implementations are not written in gpl
<shka>
*licensed under the gpl
Oladon has joined #commonlisp
hendursa1 has quit [Quit: hendursa1]
hendursaga has joined #commonlisp
<lotuseater>
sorry I'm away now for some time. have a nice day :)
hafat has quit [Ping timeout: 255 seconds]
lisp123 has quit [Remote host closed the connection]
lisp123 has joined #commonlisp
modula has joined #commonlisp
defaultxr has quit [Ping timeout: 265 seconds]
modula is now known as defaultxr
lisp123 has quit [Ping timeout: 250 seconds]
Guest77 has quit [Quit: Client closed]
Lycurgus has joined #commonlisp
lisp123mobile has joined #commonlisp
Xach has quit [Quit: leaving]
lisp123mobile has quit [Ping timeout: 265 seconds]
lisp123 has joined #commonlisp
Bike has joined #commonlisp
dsk has joined #commonlisp
lisp123 has quit [Ping timeout: 258 seconds]
pve_ has joined #commonlisp
lisp123mobile has joined #commonlisp
lisp123mobile has quit [Remote host closed the connection]
pve has quit [Ping timeout: 255 seconds]
peterhil has quit [Ping timeout: 258 seconds]
lisp123 has joined #commonlisp
ems has quit [Quit: Konversation terminated!]
cage has quit [Quit: rcirc on GNU Emacs 27.1]
lisp123mobile has joined #commonlisp
lisp123 has quit [Ping timeout: 265 seconds]
lisp123mobile has quit [Remote host closed the connection]
peterhil has joined #commonlisp
Oladon has quit [Quit: Leaving.]
shka has quit [Ping timeout: 268 seconds]
hafat has joined #commonlisp
peterhil has quit [Ping timeout: 255 seconds]
Lycurgus has quit [Quit: Exeunt]
hafat has quit [Quit: Leaving]
hafat has joined #commonlisp
pranavats has left #commonlisp [Error from remote client]
lisp123mobile has joined #commonlisp
peterhil has joined #commonlisp
lisp123mobile has quit [Remote host closed the connection]
Bike has quit [Quit: Connection closed]
White_Flame has joined #commonlisp
<aeth>
Personally, I use permissive licenses for CL stuff where I'd consider the GPL in other languages because I want to encourage people to use CL. YMMV.
<jfb4>
aeth: that's a slippery slope
<aeth>
and MIT license mainly because most CL code is MIT...
<aeth>
jfb4: I mean, if someone has to load up ECL to interface with some big, proprietary C/C++ program because they really, REALLY want to use my code, I consider that a win for CL.
lisp123mobile has joined #commonlisp
lisp123mobile has quit [Remote host closed the connection]
lisp123mobile has joined #commonlisp
lisp123mobile has quit [Remote host closed the connection]
<lotuseater>
good point aeth
<lotuseater>
so how was that, if it were GPL it couldn't be used with the proprietary thing?
<aeth>
You could use LGPL but idk how it would interact with being embedded as part of ECL, rather than as a separate C/C++ library
<edgar-rft>
it *can* be used with proptietary code but only when the proprietary code is laid open, too, what in practice is very unlikely to happen :-)
<aeth>
But always make sure that your code runs in ECL even if you never use it, at least imo
<aeth>
Because if a C programmer really, really wants your code, they're going to have to use ECL
<jackdaniel>
I have it fixed, but here comes an interesting (to me) fail: (loop for key in keys for pos = (position key head) collect (lambda (elt pos body)))
<jackdaniel>
(lambda () (elt pos body))
<jackdaniel>
because pos is modified destructively by loop, all collected lambdas will see the same pos value
<jackdaniel>
a fix is to replace lambda with (let ((pos pos)) (lambda () …))
<jackdaniel>
good night \o
taiju has quit [Quit: Quit]
taiju has joined #commonlisp
tyson2 has joined #commonlisp
dsk has quit [Ping timeout: 255 seconds]
lisp123 has joined #commonlisp
gaqwas has quit [Ping timeout: 258 seconds]
lisp123 has quit [Ping timeout: 252 seconds]
Bike has joined #commonlisp
paulapatience has joined #commonlisp
OlCe has joined #commonlisp
edgar-rft has quit [Quit: Leaving]
PuercoPop has joined #commonlisp
lisp123 has joined #commonlisp
lisp123 has quit [Ping timeout: 255 seconds]
frgo has quit [Remote host closed the connection]
<lotuseater>
How can I correctly define a readermacro in lexical-scope of a DEFMACRO? is clear what I mean?
frgo has joined #commonlisp
<lotuseater>
for defining special readtime at compiletime
waleee has quit [Ping timeout: 246 seconds]
waleee has joined #commonlisp
selwyn has joined #commonlisp
<lotuseater>
eg I want such construct like (vec! [1,2,3]) expanded as (make-array 3 :initial-contents '(1 2 3)). but ok, VEC! would be enough as a function there. the point is I thought about when one wants the readmacro for #\[ just being activated as the macro/function starts
<lotuseater>
yes I know (set-macro-character #\[ (get-macro-character #\)) you mean that?
<Bike>
you can't define a reader macro limited to a particular lexical context.
<Bike>
unless you override the entire reader, which is probably where a macro on ( is leading
<Bike>
the reader doesn't know anything about macros.
<pjb>
lotuseater: no, I mean #\(
<lotuseater>
because I understand it by now that the reader looks at everything before compiling, so if #\[ is not in the toplevel defined an error occurs
<pjb>
lotuseater: go read the reference!!!
<lotuseater>
I'll do!
<lotuseater>
Bike: that's also good advice :)
<pjb>
I mean the Ambitious url above.
<pjb>
vec! cannot be a function since it will interpret the text until the closing parenthesis differently.
<pjb>
vec! need to be something that works at read-time.
<pjb>
For that, you need to write a reader macro for #\( that will see that the operator is vec! and dispatch to some read-time parser.
<lotuseater>
pjb: thx didn't know this site yet
<lotuseater>
hehe yes ok now I get what you intend to tell me
<lotuseater>
yesterday in the late evening I played with defining one for lambdas with #\\ so eg \x y . (+ x y) => (lambda (x y) (+ x y))
<pjb>
or use λ
<pjb>
configure xmodmap to get it easy, or emacs.
<lotuseater>
yes I wanted but must configure my keyboard :D
<lotuseater>
or having it as in Haskell (the left side): \x y -> (+ x y)
<pjb>
Haskell is inferior..
<lotuseater>
haha yes :D but much superior to other stuff
<pjb>
Yes, there are worse languages.
<lotuseater>
or those Clojurists which are still enslaved to the JVM. but that's much opiniated and so offtopic :)
<lotuseater>
the tip with emacs is helpful, I still know not much about that all to configure right (but use is most times)
<lotuseater>
the "A" in "A-l" is what key?
<pjb>
Alt
<lotuseater>
hm here that's "M" for the meta key
<pjb>
You can use xmodmap to map M and A to different keys.
<pjb>
On a 105-key PC keyboard, you have 3 modifiers on the left and 4 on the right of the space bar.
<pjb>
So: Hyper- Alt- Meta- SPC Meta- Alt- Super- Hyper-
<lotuseater>
my Windows key is at the moment configured to type the APL symbol set :D
selwyn has quit [Read error: Connection reset by peer]
silasfox has quit [Ping timeout: 258 seconds]
<jcowan>
In any case, there is no existing CL implementation under the full GPL except CLISP, and that does not impose the GPL on your code (per the FSF's GPL FAQ)
raeda__ has quit [Quit: Leaving]
taiju has quit [Ping timeout: 255 seconds]
taiju has joined #commonlisp
<aeth>
also, by the FSF's writings on the LGPL and Java, the LGPL (no need for the LLGPL) should be compatible with CL as long as the LGPLed files are user-replaceable (like Java's JAR files), e.g. as separate loaded FASLs
Inline has quit [Remote host closed the connection]
<aeth>
and the implementation files certainly should fall under that, so the LGPL also would work
<lotuseater>
my head bums from that :D
Inline has joined #commonlisp
<aeth>
s/the implementation/the Lisp implementation (compiler or interpreter)/
<moon-child>
aeth: java doesn't have macros, though
CrashTestDummy3 has joined #commonlisp
easye has quit [Remote host closed the connection]
<aeth>
moon-child: right, it does make packaging awkward because you'd have to load FASLs via something like ASDF, rather than building an all-in-one binary
<aeth>
otherwise you'd have issues with macros or inline functions in dependencies
<moon-child>
if my code is closed-source, and I use an LGPL'd macro, the result of that macro is output in my code. Changing the content of the macro won't change my code
<aeth>
You would have to recompile the dependent files if the dependencies' FASLs are replaced, like QL:QUICKLOAD does, but unlike what packaged Lisp binaries tend to do
<aeth>
So LGPL does restrict how to deploy your Lisp code
CrashTestDummy2 has quit [Ping timeout: 255 seconds]
lotuseater has quit [Quit: ERC (IRC client for Emacs 27.2)]
<etimmons>
Doesn't the LGPL say that small enough macros (<10 lines, IIRC) don't make the object file that uses them a derivative work?
<etimmons>
It's annoying that the language is so specific to C
<etimmons>
But that does suggest that trivial macros don't really limit how you distribute your closed source executable
akoana has joined #commonlisp
<etimmons>
(other than the aforementioned requirement to allow people to swap out the LGPL'ed fasls)
kakuhen has joined #commonlisp
tyson2 has quit [Quit: ERC (IRC client for Emacs 27.2)]
Guest4290 has quit [Killed (molybdenum.libera.chat (Nickname regained by services))]
Alfr has joined #commonlisp
<aeth>
"FSF's position has remained constant throughout: the LGPL works as intended with all known programming languages, including Java. Applications which link to LGPL libraries need not be released under the LGPL. Applications need only follow the requirements in section 6 of the LGPL: allow new versions of the library to be linked with the application; and allow reverse engineering to debug this."
<aeth>
Considering that they have 2 Common Lisps (CLISP, GCL), 3 Schemes (Guile, Kawa, MIT), and at least 1 other (elisp), "all known programming languages" has to apply to Lisps
<aeth>
(well, GNU has them, not the FSF)
<aeth>
of course, a license is how courts interpret it, not how the FSF interprets it
cjb has joined #commonlisp
<etimmons>
aeth: yeah, I've seen that. I was mostly bemoaning the language with respect to macros
<etimmons>
Because if memory serves, that save section also mentions header files