dtman34 has quit [Quit: ZNC 1.7.2+deb3 - https://znc.in]
lotuseater has quit [Ping timeout: 252 seconds]
dtman34 has joined #commonlisp
Lord_of_Life has joined #commonlisp
<jeosol>
NotThatRPG: lol at "superhuman Fare" ...
Lord_of_Life has quit [Ping timeout: 265 seconds]
tyson2 has quit [Quit: ERC (IRC client for Emacs 27.2)]
Lord_of_Life has joined #commonlisp
<jeosol>
btw, I do agree with the superhuman part of the statement ...
pjb has quit [Ping timeout: 268 seconds]
zacts has joined #commonlisp
froggey has quit [Ping timeout: 265 seconds]
froggey has joined #commonlisp
waleee has quit [Ping timeout: 256 seconds]
Lord_of_Life has quit [Ping timeout: 268 seconds]
Lord_of_Life has joined #commonlisp
<NotThatRPG>
jeosol: I have looked at a lot of Fare's code and it is superhuman. His ability to keep track of the idiosyncrasies of all the different implementations is astounding.
<jeosol>
@NotThatRPG: I agree with you. I started asking him questions many years ago, and even now that he moved to Gerbil scheme, he is still able to give me good pointers regarding asdf and poiu. His advice and pointers have been helpful
<beach>
pegaso: Are you new here? I don't recognize your nick.
<beach>
cheers: With respect to SICL, I don't like to give estimates. You should definitely not try it yet. Most of the code is written. Register allocation is done. Code generation is next. And there are some parts of bootstrapping that still need to be designed.
green__ has joined #commonlisp
atgreen has quit [Ping timeout: 255 seconds]
jmhimara has quit [Quit: Client closed]
<jeosol>
Good morning beach. Congratulations on that news
<beach>
jeosol: Thanks.
<jeosol>
Haven't been here much, but good to know that SICL has progressed a lot further
<jeosol>
Really great news
<beach>
It is being worked on every day, but the task is not trivial.
<jeosol>
I was in the weeds a few weeks ago, looking into parallel build with poiu and google's bazelisp systems - the latter too heavy from what I told by goggle guys
<recordgroovy>
#:trivial-task
<jeosol>
beach: I started delving more deep into program internals, following some MIT courses, and one topic with Julia about auto-boxing at all. I then remember your callsite optimization paper
<beach>
That's one of my better ideas I think.
<beach>
It's a strange feeling in that I execute SICL code every day, so most of the code has been "tested" in that it goes through the bootstrapping steps that we currently have. Yet, we have no executable to show to the world yet.
<beach>
I mean, the bootstrapping code does some pretty essential stuff like all the MOP machinery of computing effective slots, class precedence lists, effective methods, and discriminating functions. And it does this for a large number of generic functions.
<beach>
And SICL uses the MOP machinery everywhere, because only a handful of classes are not standard classes. SICL classes such as SYMBOL, PACKAGE, ARRAY, are all standard classes. And functions such as EQUAL and EQUALP, and also all the slot accessors like SYMBOL-NAME etc. are generic functions.
<jcowan>
In short, the sicl bootstrap is a large CL program with a specialized purpose.
<beach>
I know _death said EQUAL and EQUALP should not be extensible, but they are written this way for reasons of modularity.
<jcowan>
I understand why not: if you are allowed to add methods to EQUALP, you break its contract.
<beach>
Not that large actually. Currently, the bootstrapping code consists of around 4kLOC, including a GUI-based backtrace inspector.
* jcowan
nods
<beach>
Yes, I might seal EQUAL etc.
derelict has joined #commonlisp
<beach>
And the bootstrapping code contains a lot of duplication that we will eventually get rid of.
<jcowan>
I think you have to seal every function from T to (generalized-)boolean
<beach>
I don't know what that means. But then, I haven't finished my morning coffee yet.
<jeosol>
@beach: Great list of things that have been implemented. This will help the language see some resurgence in some fashion given it could be a good general base for the other implementations (with time) and development efforts can be pushed in other directions
<jcowan>
As an example, NUMBERP's signature is "numberp object => generalized-boolean". You don't want to permit a method on it that maps pairs to T, or worse yet to "What, me worry?"
<jcowan>
so anything with that signature or a related signature needs to be considered for sealing.
<beach>
jeosol: Thanks. Yes, I think I need to make the bootstrapping technique applicable to other implementations.
green__ has quit [Ping timeout: 246 seconds]
<Bike>
oh, "i think you have to seal type predicates"
<Bike>
or at least i can't think of any functions that describes that aren't type predicates
<beach>
jcowan: I would just seal the generic function as a whole.
taiju has quit [Ping timeout: 265 seconds]
<jcowan>
also eq and friends
<beach>
EQ is not generic.
<beach>
Bike: What's the quotation from?
<Bike>
nothing. that's my interpretation of "you have to seal every function from T to generalized-boolean"
<beach>
Oh, I see. I still haven't understood that one.
<Bike>
like, "for every function with an argument of type T and return value of type generalized boolean, that function must be sealed"
<beach>
Since neither T nor generalized-boolean are functions.
<jcowan>
On the other hand, if you want to add classes that actually represent numbers (quaternions, Gaussian integers, etc.) you may indeed want to unseal NUMBERP to include them.
<Bike>
right but there are functions of type (function (t) generalized-boolean)
<Bike>
like numberp
<jcowan>
Exactly
<Bike>
and those have to be sealed
<Bike>
although really it would probably be easier to list what doesn't have to be sealed.
<beach>
I am starting to understand.
<Bike>
do any implementations actually allow extended numbers?
<Bike>
several have extended sequences, but i dunno if there are ones with other stuff like that
<beach>
I am not sure about the "have to". Perhaps a "don't do that then" is enough.
<beach>
I am not a strong believer in trying to cater to incompetent programmers.
<Bike>
well, you would kind of have to go out of your way to mess up numberp or whatever
<Bike>
but on the other hand if you could do that it might screw up safety, which you don't want
taiju has joined #commonlisp
<Bike>
like if a compiler definition gets out of sync with the actual runtime definition or something
<beach>
Sure, for CLOSOS, those considerations are much more important.
CrashTestDummy3 has joined #commonlisp
ad-absurdum has quit [Quit: Leaving]
CrashTestDummy2 has quit [Ping timeout: 268 seconds]
Bike has quit [Quit: Lost terminal]
reis-r has joined #commonlisp
pegaso has quit [Ping timeout: 252 seconds]
pjb has joined #commonlisp
mariari has quit [Ping timeout: 252 seconds]
raeda has quit [Remote host closed the connection]
raeda has joined #commonlisp
mariari has joined #commonlisp
mariari has quit [Ping timeout: 258 seconds]
gaqwas has joined #commonlisp
attila_lendvai has joined #commonlisp
mariari has joined #commonlisp
CrashTestDummy2 has joined #commonlisp
CrashTestDummy3 has quit [Ping timeout: 268 seconds]
asarch_ has quit [Remote host closed the connection]
shka has joined #commonlisp
asarch_ has joined #commonlisp
CrashTestDummy3 has joined #commonlisp
mariari has quit [Ping timeout: 258 seconds]
CrashTestDummy2 has quit [Ping timeout: 255 seconds]
amb007 has quit [Ping timeout: 255 seconds]
amb007 has joined #commonlisp
Duuqnd has joined #commonlisp
mariari has joined #commonlisp
svillemot has quit [Quit: WeeChat 3.0]
silasfox has joined #commonlisp
gaqwas has quit [Ping timeout: 255 seconds]
cranium has joined #commonlisp
amb007 has quit [Ping timeout: 268 seconds]
Th30n has joined #commonlisp
amb007 has joined #commonlisp
amb007 has quit [Ping timeout: 268 seconds]
dsk has quit [Ping timeout: 255 seconds]
amb007 has joined #commonlisp
amb007 has quit [Read error: Connection reset by peer]
amb007 has joined #commonlisp
amb007 has quit [Read error: Connection reset by peer]
amb007 has joined #commonlisp
pve has joined #commonlisp
recordgroovy has quit [Ping timeout: 246 seconds]
recordgroovy has joined #commonlisp
luna-is-here has joined #commonlisp
recordgroovy has quit [Ping timeout: 268 seconds]
pegaso has joined #commonlisp
amb007 has quit [Read error: Connection reset by peer]
reis-r has quit [Ping timeout: 252 seconds]
amb007 has joined #commonlisp
domovod has joined #commonlisp
azimut_ has quit [Remote host closed the connection]
azimut has joined #commonlisp
amb007 has quit [Ping timeout: 252 seconds]
amb007 has joined #commonlisp
recordgroovy has joined #commonlisp
hendursa1 has joined #commonlisp
hendursaga has quit [Ping timeout: 244 seconds]
svillemot has joined #commonlisp
lisp123 has joined #commonlisp
<flip214>
Help, please. What's the difference between these forms? (intersection r l) (remove-if-not (lambda (l) (member l r)) l)
<flip214>
r and l are lists of structures; the first form returns the expected 10 results, the second only 6 values.
<beach>
Duplicate entries might make a difference.
selwyn has joined #commonlisp
<beach>
Oh, wait.
lisp123 has quit [Ping timeout: 250 seconds]
<flip214>
beach: you seem to be right
<beach>
Yes, I think that's it.
<flip214>
thanks a lot...
<beach>
Sure.
<flip214>
didn't think of that
<beach>
It's easy to forget.
<flip214>
especially as duplicate entries are unexpected here
<pjb>
duplicate entries make a difference only if you don't consider the result as a set.
<beach>
I think INTERSECTION is underspecified in the standard.
attila_lendvai has quit [Ping timeout: 252 seconds]
<beach>
But maybe I am reading it wrong.
lisp123 has joined #commonlisp
<pjb>
What is missing is only (defun seq-equal (a b) (and (subsetp a b) (subsetp b a))) ; perhaps more efficiently.
<gin>
Need some advice with this code: https://plaster.tymoon.eu/view/2558 - I am comparing two approaches here. (1) ex-1: A single LET for all lexical variables. (2) ex-2: Multiple nested LETs for defining lexical variables only where they are needed.
<pjb>
s/seq-equal/set-equal/
<gin>
Is one approach better than the other? What is your advice on my plaster link above?
<pjb>
a set-equal function would make it more concrete that there's a set type based on list, like subst and copy-tree make it clear there's a tree type based on lists.
<beach>
gin: You should always aim to minimize the scope of each variable.
<pjb>
gin: yes. And assume the compiler can optimize things out.
<pjb>
gin: notably, for closures, it may help to have the most limited scopes.
<gin>
pjb: If I assume compiler can optimize things out, then I can stick with ex-1 where a single LET contains all lexical variables, couldn't I?
<beach>
gin: Oh, and this one looks like a case for SPLIT-SEQUENCE.
selwyn has quit [Read error: Connection reset by peer]
<beach>
gin: It is not a question of compiler optimizations. It is a matter of how much code the person reading your code has to consider for an occurrence of the variable.
<gin>
beach: thanks! I was thinking that too. But then does it bother anyone that it may lead to multiple nested-LETs making the code harder to parse with eyes? Or is that not a valid concern?
<beach>
Again, you should do what is easier to read.
<beach>
Clearly, if you have tons of nested LETs, that might be a problem too.
<gin>
beach: SPLIT-SEQUENCE from cl-ppcre?
<beach>
I think it is an independent repository.
<gin>
okay thanks
<beach>
I think EX2 is better with respect to newline-position.
<beach>
And I recommend you use LOOP and COLLECT instead of manually pushing to titles.
<beach>
gin: And the COUNT return value is silly. That should be done by the caller.
<gin>
beach: thanks! I have mentioned in comments at the top that I am making a contrived example to compare my LET-approaches. could not make a more sensible example. I understand that LOOP COLLECT is appropriate here and COUNT is not required.
<gin>
will stick with EX-2 then. I like the approach of minimizing the scope.
lisp123 has quit [Ping timeout: 258 seconds]
<_death>
gin: the nested LETs make it easier to pull the forms out into their own function, for example.. they also make it easier for the reader to know the value of the bindings, considering the alternative is a variable that changes over time
<beach>
(loop for article in articles for newline-position = (position #\Newline article) collect (subseq article 0 newline-position)) with appropriate newlines inserted.
kakuhen has quit [Quit: Leaving...]
<beach>
gin: A general rule of programming is that a function should do one single thing. The computation of the length makes the function do two things, which is not good.
<beach>
gin: You might see that more easily if you consider this function as also computing the reverse of the list, the Fibonacci number of the length, etc.
asarch_ is now known as asarch
<gin>
beach: yes. makes sense.
recordgroovy has joined #commonlisp
<beach>
gin: But, as I recall, you have already programmed before, in other languages.
<gin>
yes
<beach>
So you must already know those rules, i.e., minimize the scope to make life easier for the person reading your code, and make each function do one thing.
<beach>
There is no reason to do it differently in Common Lisp from what you already know.
<gin>
yes I do. just wanted to confirm that nested-LETs are not considered ugly.
<beach>
OK.
OlCe has joined #commonlisp
amb007 has quit [Read error: Connection reset by peer]
amb007 has joined #commonlisp
asarch has quit [Remote host closed the connection]
Lord_of_Life_ has joined #commonlisp
Lord_of_Life has quit [Read error: Connection reset by peer]
Lord_of_Life_ is now known as Lord_of_Life
asarch has joined #commonlisp
attila_lendvai_ is now known as attila_lendvai
<gin>
does (length string) take constant time to get the string length?
<shka>
gin: yes
<gin>
thanks shka. Is that true in general too? does it take constant time for any proper sequence?
<shka>
it is not actually defined, but strings are arrays, and arrays have array dimensions
<shka>
or fill pointers
<gin>
ok
<shka>
and as a result any sane implementation would give you length in constant time
<shka>
for lists, it will take O(n)
<shka>
because it has to traverse the whole of the list before returning the result
<shka>
however, list are of type sequence
<beach>
gin: If you think about how lists are represented, you can see that it has to traverse every CONS cell as shka is saying, so there is no way it can be O(1).
<beach>
gin: And if you don't know how lists are represented, it is time to learn that part. Otherwise, may things will likely confuse you in the future.
<beach>
... like why (defun push-it (element list) (push element list)) won't "work" as expected.
<beach>
s/may things/many things/
<shka>
PCL chapter i just linked should be helpful in this regard
<beach>
shka: Indeed. But a significant number of newbies here don't seem to find it useful to read about things like that.
derelict has quit [Ping timeout: 255 seconds]
amb007 has quit [Read error: Connection reset by peer]
amb007 has joined #commonlisp
frgo has quit [Remote host closed the connection]
frgo has joined #commonlisp
scymtym has quit [Ping timeout: 265 seconds]
lisp123 has joined #commonlisp
selwyn has joined #commonlisp
scymtym has joined #commonlisp
asarch has quit [Quit: Leaving]
random-nick has joined #commonlisp
lisp123_ has joined #commonlisp
OlCe has quit [Ping timeout: 255 seconds]
asarch has joined #commonlisp
lisp123 has quit [Ping timeout: 246 seconds]
tyson2 has joined #commonlisp
amb007 has quit [Ping timeout: 255 seconds]
amb007 has joined #commonlisp
green__ has joined #commonlisp
pegaso has quit [Ping timeout: 255 seconds]
amb007 has quit [Read error: Connection reset by peer]
amb007 has joined #commonlisp
engblom has quit [Read error: Connection reset by peer]
engblom has joined #commonlisp
asarch has quit [Quit: Leaving]
notzmv has quit [Remote host closed the connection]
notzmv has joined #commonlisp
cullsure has joined #commonlisp
kevingal has joined #commonlisp
lisp123_ has quit [Remote host closed the connection]
IPmonger has joined #commonlisp
IPmonger has quit [Remote host closed the connection]
amb007 has quit [Read error: Connection reset by peer]
amb007 has joined #commonlisp
luna-is-here has quit [Ping timeout: 255 seconds]
luna-is-here has joined #commonlisp
domovod has quit [Quit: WeeChat 3.2]
OlCe has joined #commonlisp
Bike has joined #commonlisp
luna-is-here has quit [Read error: Connection reset by peer]
luna-is-here has joined #commonlisp
dtman34 has quit [Ping timeout: 258 seconds]
lisp123 has joined #commonlisp
hendursa1 has quit [Quit: hendursa1]
hendursaga has joined #commonlisp
derelict has joined #commonlisp
OlCe has quit [Ping timeout: 255 seconds]
lisp123 has quit [Remote host closed the connection]
zacts has joined #commonlisp
waleee has joined #commonlisp
CrashTestDummy2 has joined #commonlisp
CrashTestDummy3 has quit [Ping timeout: 255 seconds]
attila_lendvai has quit [Ping timeout: 258 seconds]
domovod has joined #commonlisp
tyson2 has quit [Quit: ERC (IRC client for Emacs 27.2)]
domovod has quit [Ping timeout: 252 seconds]
domovod has joined #commonlisp
tyson2 has joined #commonlisp
Th30n has quit [Quit: WeeChat 3.2]
pranavats has left #commonlisp [Error from remote client]
OlCe has joined #commonlisp
domovod has quit [Quit: WeeChat 3.2]
hendursaga has quit [Remote host closed the connection]
hendursaga has joined #commonlisp
zacts18 has joined #commonlisp
zacts18 has quit [Client Quit]
zacts has quit [Quit: zacts]
silasfox has quit [Ping timeout: 256 seconds]
raeda has quit [Read error: Connection reset by peer]
davep has joined #commonlisp
lisp123 has joined #commonlisp
djuber has quit [Read error: Connection reset by peer]
silasfox has joined #commonlisp
lisp123 has quit [Remote host closed the connection]
lisp123 has joined #commonlisp
zacts has joined #commonlisp
domovod has joined #commonlisp
Inline has joined #commonlisp
silasfox has quit [Ping timeout: 252 seconds]
tyson2 has quit [Quit: ERC (IRC client for Emacs 27.2)]
selwyn has quit [Ping timeout: 265 seconds]
yitzi has joined #commonlisp
zacts has quit [Ping timeout: 246 seconds]
tyson2 has joined #commonlisp
<lisp123>
Any good resources to learn algorithms when working with trees and also searching / traversing across trees & nodes?
<beach>
Aho Hopcroft Ullman, "The Design and Analysis of Computer Algorithms" is the classic text.
dsk has joined #commonlisp
<lisp123>
beach: thank you! <3 :)
<beach>
Apparently, they also wrote "Data Structures and Algorithms" later. I haven't read that one.
<lisp123>
Google brought that one up as well, I will read TDACA first
<beach>
Be careful with any old book on data structures and algorithms. I estimate around half of published books get a simple thing like binary search wrong.
<beach>
"wrong" in that the published version takes twice the time it needs to.
<beach>
And sometimes "wrong" in that it doesn't work with duplicate elements, etc.
<lisp123>
beach: urgh. Sometimes being published doesn't mean being right I guess :-/
<beach>
These authors get it right as I recall.
<beach>
Publishing houses will print and sell anything you are willing to write, and they fired all the copy editors decades ago.
<beach>
Apress seems to be the exception. They recruit qualified editors to screen the material.
<lisp123>
Yeah, their business models are coming under fire a lot (especially for technical books)
<lisp123>
Apress has done a great job for Lisp, can't say about other languages
<jackdaniel>
there is an interesting book that touches this topic in polish "przejęzyczenie" (misspell) - it is a set of interviews with well known translators
<beach>
Interesting.
IPmonger has joined #commonlisp
IPmonger has quit [Remote host closed the connection]
<beach>
Speaking of which, the reason "Lisp in Small Pieces" is better in its English version, is that the translator is also an experienced editor. The original publishing house doesn't have staff like that as far as I know.
<jcowan>
Wasn't it also based on revisions made by Q to the original text?
OlCe has quit [Remote host closed the connection]
<beach>
As far as I remember, it was just the original text. He later wrote a revised French version, but I don't know more about it.
<beach>
Though, the translation was made interactively, i.e., they met on a regular basis to discuss the material, so it is not a "blind" translation.
<jcowan>
Ah.
<beach>
But the translator had knowledge of Lisp, so was able to introduce improvements because of that as well.
<hendursaga>
beach: what's the (revised) French version called?
<beach>
I actually don't know. Let me see what I can find...
<beach>
It could be the same title, just a new edition. But don't quote me on that.
<hendursaga>
beach: OK but what's the French version called, either edition?
<jcowan>
jackdaniel: I saw a list of Russian surnames somewhere that look scary even to Russians because they are of (remote) Polish origin:
<beach>
Les Langages Lisp.
<hendursaga>
Cool. Any other translations you know of?
<jcowan>
Not as clever as the English title, which shows how flexible (twisty) English actually is
<beach>
hendursaga: No, I am familiar with the French one because I used it in a course, and with the English one because I know the translator.
<hendursaga>
beach: wait which came first, the English or the French version?
<jcowan>
jackdaniel: Here's a few of them: "Yastrzhembsky (the diplomat), Krzhizhanovsky (the writer), and even Przhevalsky (of the horse)."
<beach>
hendursaga: The French version is the original.
<jackdaniel>
I think that Russian nicknames are written in cirillic :) that would be Jastrzębski (Hawk-ski), Chrzanowski (horserasish-ski) and Przewalski (bulldoze-ski); sorry for bringing offtopic :)
<hendursaga>
beach: Principes d'implantation de Scheme et Lisp might be the new one??
<hendursaga>
I'm now looking through the publisher's catalog, fun books!
<Bike>
a little while back i wrote up this thing for a type-expand extension https://github.com/Bike/clhs-extension/tree/main/type-expand and i was thinking of filing a pull request to add it (i.e. type-expand(-1), not the other) to ECL, but i was wondering if anyone had opinions on typexpand versus type-expand versus typeexpand
pjb has quit [Ping timeout: 255 seconds]
<yitzi>
type-expand
<jackdaniel>
following convention used for macroexpand that would be typeexpand (and typeexpand-1)
<Bike>
right, but the double e is weird so maybe it should be type-expand, and alternately maybe it should be typexpand to collapse the double e (this is what sbcl does)
<Bike>
hardest problem in computer science etc
<yitzi>
Plus CL naming is a bit inconsistent.
<jackdaniel>
if sbcl already has that operator, then a pragmatist in me says: skip "e"
<beach>
hendursaga: Yes, I see.
<hendursaga>
I can't really read Russian, heh
<beach>
hendursaga: The title says "Interpretation", which looks strange.
OlCe has joined #commonlisp
<beach>
I vote for type-expand.
<jcowan>
jackdaniel: Sure, I just can't type Cyrillic easily so I do Russian in romanization.
<jcowan>
Part of the trouble is the cyrillicization of "rzh" as such rather than using just zh (or sh)
<jcowan>
So if I happen to mention Przhewalski's horse (rare, but not unknown), I call it "Shevalski's horse" (with silent "p" as usual in English).
<Bike>
ecl actually builds on my home machine without the weird problems about floating point i had before, neat
<Bike>
oh, and other wrinkle, ccl has type-expand (though it is unexported)
<jackdaniel>
perhaps ecl development isn't lightning fast but we are moving forward :)
<Bike>
i think this was probably more an issue with my build environment than ecl. plus i didn't try very hard to figure it out
<Bike>
anyway, time 2 patch
<Bike>
i expect there are very few users of sbcl's typexpand to begin with, so renaming things shouldn't be too horrible if it comes to that
<lisp123>
A philosophical question: How do you choose to order your functions? Say you have A calling B calling C calling D. Do you write D at the top of your file, then C, then B, then A or the other way? Writing bottom up means you will progressively build up the functions so easier to follow (somewhat), whereas writing top down is easier to understand the purpose (since A will contain the main goal, and the remaining functions help it achieve it)
<mfiano>
I suppose it depends if any are proclaimed inline, and if they even belong next to each other (same file, same package, etc)
<lisp123>
same file
<jackdaniel>
they are in the same compilation unit so inlining could take effect either way
<mfiano>
then depends on the design of my program, such as inlining, and intuition
selwyn has joined #commonlisp
<White_Flame>
I have big demarcations between sections of the file, and keep tightly/privately correlated functions together. Ordering has more to do how commenting works best
<lisp123>
I started doing topdown (start with exported functions and then working one's way down), although I'm finding today if I write literate programs, bottom up is easier
<lisp123>
White_Flame: "how commenting works best" -> that's a great way to look at it
<White_Flame>
any aesthetics of your source code files should be driven by documentation/readability, not the code specifically
<White_Flame>
and that will certainly be relative to the code in question
<lisp123>
White_Flame: Although one could argue having certain conventions (regardless of the code), helps in consistency - if every file is top down for example, then one would come to expect that format, and vice versa
cage has joined #commonlisp
zacts has joined #commonlisp
<Bike>
jackdaniel: if i want to add exported symbols to the EXT package, do i add them in symbols_list.h somewhere or is there a preferred procedure?
<jackdaniel>
yes, you add them to symbols_list.h; also you need to add the function to src/h/external.h with a C name declared in symbols_list.h (i.e cl_type_expand) and src/cmp/proclamations.lsp
<jackdaniel>
Bike: ^
<Bike>
oh, but i wrote the function in lisp, does it still need a C name?
<jackdaniel>
it doesn't, but if it is an exported interface it should (so C programmers may invoke it:)
<Bike>
rrrrright
<jackdaniel>
also you have a gain of direct call instead of dispatching the symbol (in compiled code)
<jackdaniel>
whatever you put in symbols_list as the C name that name will be used in transpiled code; symbols_list.h is arranged alphabetically afair
<Bike>
it has do-deftype followed by create-type-name, so i put it in there
<jackdaniel>
(macros doesn't have C names)
citizenajb has joined #commonlisp
derelict has quit [Ping timeout: 245 seconds]
Lycurgus has joined #commonlisp
derelict has joined #commonlisp
dsk has quit [Ping timeout: 240 seconds]
zacts has quit [Ping timeout: 246 seconds]
lisp123 has quit [Remote host closed the connection]
lisp123 has joined #commonlisp
lisp123_ has joined #commonlisp
lisp123 has quit [Ping timeout: 255 seconds]
Lycurgus has quit [Quit: Exeunt]
zacts has joined #commonlisp
<scymtym>
Bike: would it make sense for TYPE-EXPAND and TYPE-EXPAND-1 to specify the exceptional situations that TYPE-SPECIFIER is not a valid type specifier and ENV is not an environment?
jmhimara has joined #commonlisp
davep has quit [Quit: Connection closed for inactivity]
lisp123_ has quit [Remote host closed the connection]
lisp123 has quit [Remote host closed the connection]
zacts has quit [Ping timeout: 246 seconds]
domovod has quit [Quit: WeeChat 3.2]
gaqwas has joined #commonlisp
IPmonger has joined #commonlisp
IPmonger has quit [Remote host closed the connection]
lisp123 has joined #commonlisp
lisp123 has quit [Remote host closed the connection]
kakuhen has joined #commonlisp
tyson2 has quit [Ping timeout: 258 seconds]
pjb has joined #commonlisp
makomo has joined #commonlisp
lisp123 has joined #commonlisp
OlCe has quit [Ping timeout: 268 seconds]
aleamb has quit [Quit: bye]
luna-is-here has quit [Read error: Connection reset by peer]
luna-is-here has joined #commonlisp
amb007 has quit [Ping timeout: 252 seconds]
amb007 has joined #commonlisp
shka has quit [Ping timeout: 265 seconds]
citizenajb has quit [Quit: Client closed]
yitzi has quit [Quit: Leaving]
zacts has joined #commonlisp
zacts33 has joined #commonlisp
zacts has quit [Ping timeout: 246 seconds]
scymtym has quit [Ping timeout: 240 seconds]
<lisp123>
Why does (member nil (list 1 2 3)) return nil and not (nil)?
<lisp123>
Is there some sort of override on the last cdr being nil not being recognised as an element? Is this why some functions require proper lists as inputs?
<Bike>
member checks cars, not cdrs
<Krystof>
no cdr is considered to be an element
<aeth>
list iteration for the most part is effectively doing MAPCAR with emphasis on CAR (well, in that case, MEMBER could be implemented with MAPLIST because it needs to return the sublist, but can't be implemented with MAPCAR, but it still mostly cares about the CAR)
amb007 has quit [Read error: Connection reset by peer]
amb007 has joined #commonlisp
<lisp123>
thanks Bike, Krystof, aeth
<aeth>
A possible implementation of MEMBER (excluding the keyword arguments) could be something like: (defun member* (item list) (maplist (lambda (sublist) (if (eql (car sublist) item) (return-from member* sublist) nil)) list) nil)
<lisp123>
aeth: thanks, that was going to be my next question
<aeth>
You could get what you want (MEMBER, but for potentially dotted lists) if you wrote a LOOP (or some other iteration) to behave similarly, but when you got to the last element, you returned the last element instead of NIL
citizenajb has joined #commonlisp
<aeth>
but even then '(1 2 3) would return NIL and it would only behave differently when provided with, say, '(1 2 3 . 4) where it would return 4 instead of erroring.
<aeth>
since it's '(1 2 3 . NIL) not '(1 2 3 NIL) so returning the CDR would just return NIL
<edgar-rft>
cdr doesn't seem considered to be an element: (member 4 '(1 2 3 . 4)) => type-error: the value 4 is not of type LIST
<aeth>
(the built-ins MEMBER, MAPCAR, etc., will just error when given a dotted list)
Colleen has quit [Read error: Connection reset by peer]
Colleen has joined #commonlisp
<aeth>
'(1 2 3 NIL) would return (NIL) in our hypothetical, while '(1 2 3 . NIL) i.e. '(1 2 3) would still just be NIL
<lisp123>
aeth: yes exactly
<lisp123>
aeth: I'm just wondering if (car sublist) would cause an error at any point
<lisp123>
and there is some check that the cdr is nil and then the function stops there (hence the requirement for list to a proper list)
<aeth>
it will error at some point: if it turns out that the last "sublist" is '(1 . 2) instead of '(1 . NIL)
<lisp123>
ah
<aeth>
MEMBER and the things that you could trivially implement MEMBER with (such as MAPLIST) check for a proper list at the very end, because it's more efficient that way.
scymtym has joined #commonlisp
<aeth>
You won't notice unless there's a side effect
<lisp123>
so basically because (car nil) is defined, it works --> but if the last item was 2 (as in your example), the error comes from (car 2)?
<aeth>
i.e. it's more efficient to assume that it's the correct input, and fail on the rare case when it's not, rather than slowing down the common path for the fast error path
Duuqnd has quit [Remote host closed the connection]
<aeth>
lisp123: the error comes because '(1 . 2) isn't a proper list, so the sublist assumption is violated. You just won't find out until the final iteration
<lisp123>
aeth: (sorry to be obtuse), but that specific error occurs in the final iteration since car will no longer work on "2" as in your example?
<_death>
as an exercise, you can try to implement the basic MEMBER operation without using any of the existing mapping functions
<aeth>
lisp123: it doesn't work because list-iteration (or especially sequence-iteration that works on lists) tends to iterate until the CDR is NIL, so when that's not the case, the assumption has been violated. You usually have to work with dotted lists yourself.
<aeth>
worst case is actually infinite loop, never reaching the NIL. The built-ins are just friendly enough to fail with an error
<lisp123>
aeth: thanks, that was very helpful (esp the iterate until CDR is NIL part)
<aeth>
although I guess you'd (cdr '(1 . 2)) treat 2 as a sublist, then try to take the car/cdr of it and error
<aeth>
depending on how the iteration was written
<aeth>
unfortunately, there's a million and one ways to handle lists
<lisp123>
_death: I can now see the value of doing this, when I get time I'll try and re-implement the CL functions from scratch
<antoszka>
both proper and improper :)
<aeth>
right, what you'd want to do as an exercise (or for real, if you really need this behavior) is rewrite sequence/proper-list built-in functions on top of LOOP/DO/etc. to handle dotted lists
<aeth>
you lose elegance because now you're not sure that the CDR is a CONS-or-NIL, unlike a proper list.
luna-is-here has quit [Read error: Connection reset by peer]
luna-is-here has joined #commonlisp
<lisp123>
aeth: unfortunatley, there's a million and one ways to handle lists --> Indeed, it can get confusing at times. But at least today I finally learned WHY i needed to use proper lists (vs. just the standard says so)
<aeth>
oh, and you could also do tail recursion locally inside of LABELS (and arguably this is the most elegant way), it just won't be guaranteed to work, unlike in Scheme
<_death>
lisp123: actually it's very important that you do this and similar exercises if you plan on using Lisp, because they require you to learn and understand fundamental concepts
<lisp123>
within certain functions that is*
<aeth>
and sometimes abstractions do break down and you're just stuck working with raw sublists/CONSes inside of LOOP (or similar)
<aeth>
rare, but possible
<aeth>
you might also want to write your own cons-like thing, in which case you don't get access to any of the built-ins, but the API is well-known (so, foo-car, foo-cdr, foo-cons, etc.)
<lisp123>
_death: so much to learn, so little time ;) I've decided to go down the path of build first, fix later - it optimises the process and IMO one learns more from making mistakes and fixing them. Otherwise I would be stuck with too many books and concepts to read, and then forget it all anyway
<lisp123>
aeth: it sounds like an interesting project for when I have a holiday
<_death>
lisp123: this is not a good approach when it comes to concepts fundamental to Lisp, such as conses and atoms
cage has quit [Quit: rcirc on GNU Emacs 27.1]
<lisp123>
_death: you are probably right :) I'll try and do it (re-do all the basic functions to understand how they exactly work) sooner rather than later
<_death>
lisp123: the book ANSI Common Lisp is not long and contains good exercises.. the two first chapters are available on Graham's site.. there are other basic sets of exercises on the internet, such as "ninty nine Lisp problems" or "Lisp koans", though it's been a long time since I checked them out and I'm not sure about their quality
<pve>
didn't lisp koans get a make-over recently?
zacts33 has quit [Quit: Client closed]
dsk has joined #commonlisp
<_death>
pve: I remember phoe working on it, yeah
<pve>
oh yeah that's right
zacts has joined #commonlisp
<lisp123>
_death: thanks, I read that book. And I've been reading / re-reading CLTL2e a lot (have a hard copy on my desk :D). But this has been a very good discussion (thanks aeth in particular), since even the CLHS isn't 100% precise on the implementation details for MEMBER, a lot of it must be from other parts (quoting the CLHS: " each search list for item or for a top-level element that satisfies the test. The argument to the predicate function is
<lisp123>
an element of list." >>> which doesn't make the implementation 100% clear)
<lisp123>
so I now see the value of learning the implementation details as well :-)
<_death>
lisp123: the CLHS entry has a link to the traversal rules
<_death>
lisp123: if you read ANSI Common Lisp but didn't do the exercises, my advice is to go back and do them
amb007 has quit [Ping timeout: 265 seconds]
amb007 has joined #commonlisp
<lisp123>
_death: ok, let me do that
<_death>
(actually, the traversal rules link is not helpful.. but if you click on the "element" link to the glossary you can see what is meant)
<lisp123>
_death: thanks, where is that? I got to the traversal link but not to "element"
amb007 has quit [Read error: Connection reset by peer]