<kotrcka>
Hello guys, LISP noob here. Actually, I finally got into input/output practising, can you please check if this code make sense and if there are no bad habbits? Thank you: https://pastebin.com/QB7t4HUh
<beach>
kotrcka: Sure...
<beach>
kotrcka: First, we have written it "Lisp" for the past few decades. :)
<beach>
You should use three semicolons for a top-level comment.
<beach>
kotrcka: You need to indent your code.
<beach>
kotrcka: Common Lisp programmers don't count parentheses. They go by the indentation of the code. If you do not indent your code properly, you force the person reading your code to count parentheses, and it is likely to irritate that person.
<krwq>
also `global` variables should be names like so: *this-is-my-var* (they are not exactly global though but anyway) but in this case even better use (let (first-num second-num) ...)
<kotrcka>
OK, makes sense
<beach>
krwq: you beat me to it.
<kotrcka>
how exactly with 'let'?
<kotrcka>
how it differs?
<beach>
kotrcka: LET introduces local variables.
<beach>
kotrcka: Do you know any other programming language?
<kotrcka>
Basic :-)
<beach>
Oh! :(
<no-defun-allowed>
Which BASIC? Some at least have structs and recursion.
<kotrcka>
so in this case if the variable is only for this function, I should use let?
<beach>
Yes.
<no-defun-allowed>
Yep.
<kotrcka>
the one on Spectrum..
<krwq>
also most of the people would use setf instead of setq
<krwq>
it basically is more generic version of setq
wusticality has quit [Ping timeout: 272 seconds]
<kotrcka>
but OK, this is a simple calc, just the sum.. but if I would like to extend this code into.. I do not know.. maybe a selection of what do you want to do with those input numbers, global variable is OK, right?
<no-defun-allowed>
Probably not.
<beach>
kotrcka: OK, you have a lot to learn. I recommend a good book on Common Lisp. And your questions are likely to be a bit too elementary for #lisp. So I recommend you join #clschool.
<kotrcka>
I have a book, I just like to (also) learn by examples..
<beach>
What book do you have?
<kotrcka>
CL: A gentle introduction to Symbolic Computation
<krwq>
kotrcka: do do what you said, first read i.e. symbol which would represent operation and then (funcall operation first-number second-number)
<kotrcka>
I will check that channel as well.
<beach>
OK. That one is what many people recommend for people without prior programming experience.
<krwq>
kotrcka: try this out: (funcall (read) (read) (read)) and then type: + 1 4
<kotrcka>
But a huge part of that book is about how Lisp works.. so, honestly, I was a bit impatient, so I mixed it with other sources (tutorials) :-(
<beach>
kotrcka: If you know some programming, you may want to try PCL instead.
<kotrcka>
krwq: that is the shortest cals possible? :-D
<beach>
minion: Please tell kotrcka about PCL.
<minion>
kotrcka: look at PCL: pcl-book: "Practical Common Lisp", an introduction to Common Lisp by Peter Seibel, available at http://www.gigamonkeys.com/book/ and in dead-tree form from Apress (as of 11 April 2005).
<kotrcka>
Thank you, I will check that book.
<kotrcka>
s/cals/calc
<krwq>
kotrcka: lisp is a calc on its own, since pretty much everyone uses repl no-one would likely write calc unless it changed syntax or something
wanz has joined #lisp
<kotrcka>
Yes, I just wanted to write something and then add and add more code when I get into advanced stuff..
<vms14>
Btw you have the "Land of lisp" book
<vms14>
Maybe you find it funny and easy to follow
<vms14>
If you feel so lost in programming there is a book named "A gentle introduction to symbolic computation" which is the best one for people who never seen code before
<beach>
vms14: That's the one kotrcka has.
<vms14>
And maybe it's fine that you are not so used to programming since learn lisp is a bit like start again to learn programming
<kotrcka>
that one I have, printed :-) I checked the "land of lisp" but I was a bit lost. I liked that it was going straight to the point, but.. I do not know.
<krwq>
i love the land of lisp website and video i haven't read the book though
<vms14>
Also Lisp is easy to learn, at least it has no syntax at all xD
<kotrcka>
vms14: not sure about that :-D yet
<vms14>
The hard part are maybe recursion, closures, macros, objects and this stuff
<vms14>
What you have learned for now?
<beach>
vms14: Not quite true. I like the way Paul Wilson puts it. Lisp has a 2-level syntax. The "surface syntax" is fairly trivial. But then there is the syntax of each special operator, in the form of S-expressions.
<vms14>
I'm starting with Lisp too
<vms14>
I wanted to see if it really has this power al Lispers say it has
<beach>
It does.
<vms14>
But this power will be revealed when we learn how to use macros properly
<beach>
Don't forget CLOS.
<djeis[m]>
Not all of the power of lisp comes from macros.
<kotrcka>
page 1-99 of that book
<djeis[m]>
They're just one, admittedly powerful, tool.
<krwq>
also there are things like #. and thinking about when something will be executed is sometimes taking quite a bit of time
<beach>
vms14: While macros are extremely useful, they are only used fairly rarely. Other features are more frequently needed.
<vms14>
I really like the bit I saw from Lisp even if I saw just nothing
<krwq>
beach: are used/should be used
<djeis[m]>
Well, new macros are needed fairly rarely. I'd like to note, however, that macros are being used all the time in most code.
<beach>
krwq: Right.
<djeis[m]>
They're just part of the language.
<krwq>
I overused macros quite a bit when I started and then learned the hard way to not write a macro unless you got at least couple of places where you need to use it
<krwq>
one is not enough, but I guess I was just looking for opportunity to write macros
<didi>
Macros are cool and all... but have you tried closures? ;-)
<krwq>
didi: you need to be more specific whom you are asking the question :) I guess most of the people here did
<djeis[m]>
lol
<vms14>
kotrcha: I saw your code
<didi>
krwq: It's just a general statement. :-)
<vms14>
Try to use let whenever possible
<didi>
Meaning: /me loves closures
<vms14>
This is functional programming stuff
<vms14>
Functional programming says that functions should not use global variables
<beach>
vms14: Not really. Common Lisp is an excellent imperative and object-oriented language as well.
<vms14>
And meta-programming and reflective programming paradigms
<vms14>
Btw it says not to use global variables, but in other words
<vms14>
It says functions shouldn't have side effects
orivej has quit [Ping timeout: 244 seconds]
<krwq>
i found closures have really hard name - it's much easier to get intuitive understanding rather than learning from definition + there if you accidentally see clozure or clojure you will be confused unless you aready know what they are
<kotrcka>
I will check that, I just know set* so I used it :-)
<vms14>
Then call them "let over lambda"
<beach>
vms14: Careful with such advice.
<didi>
vms14: Drink from the "functional programming" fount for a while, but snap out of it eventually.
<beach>
vms14: What didi says.
<vms14>
I know nothing about functional programming yet
<vms14>
I should at least understand it better and know when is good to use this style
<beach>
vms14: Then you should be even more careful about the advice you give.
<vms14>
I like that lisp lets you use a lot of paradigms
<djeis[m]>
vms14: Then it may have a lot to teach you, but no paradigm is perfect.
<beach>
vms14: You will find the functional-programming style in macro expanders.
<djeis[m]>
*functional
<vms14>
Which advice?
<vms14>
To use let whenever possible?
<beach>
vms14: "no global variables"
<krwq>
there is no silver bullet. global variables in lisp has very little downsides comparing to other languages
<krwq>
have
<beach>
Exactly.
<krwq>
they can simplify the code if used correctly and also make a giant mess if used incorrectly
<didi>
Inside packages, they are tamed. Also special variables are cool.
<djeis[m]>
Yea, but global mutation from disparate parts of the codebase is still a smell, imo.
<vms14>
The first time I saw let it was like, why I should want to use this if nothing can escape from let? XD
<vms14>
But I guess that a function should use let whenever possible
<vms14>
The only reason I have read to use let whenever possible is that is easier to debug due to isolation
<beach>
vms14: Again, be careful with your advice. A better version would be "given a choice between a special variable and a lexical variable, it is USUALLY better to define a lexical variable".
<beach>
vms14: Sometimes you need no variable at all, especially in the functional style.
<vms14>
I don't understand what it does the dynamic scope of a special variable yet
<beach>
vms14: Your advice implies (let ((x (f ...))) (let ((y (g x))) y)) is better than (g (f ...)).
<vms14>
But every time I learn of Lisp i fall more in love
<vms14>
Hope with time I won't change this
<vms14>
You have labels
<beach>
vms14: Blanket statements such as "no global variables" or "use LET whenever possible" are too simplistic to be useful.
<vms14>
Then, when is better to use let than global?
<beach>
I told you.
<vms14>
In your example you could use labels
status402 has quit [Quit: status402]
<beach>
No.
wusticality has joined #lisp
<beach>
No function is introduced. Only existing functions F and G are called.
<vms14>
Got it
<vms14>
But I'll try to use local vars whenever possible
<djeis[m]>
(instead of global vars?)
<beach>
Like my example shows, only if you need a variable at all.
<vms14>
Until global will be a better option
<vms14>
Yes, your example needs a global
<beach>
No, it needs no variable.
<vms14>
Well, is better with a global
<beach>
(g (f ...)) needs no variable for holding the value of (f ...) nor the value of (g (f ...))
<vms14>
I don't really exactly why, but I guess I should try to isolate things whenever I can
<vms14>
And just use global variables when is obviously a better option
<vms14>
Know *
<vms14>
XD
<beach>
Yes, that particular blanket statement is true: "use the best option at your disposal".
<djeis[m]>
"no blanket statement is always true, even this one?" :P
<kotrcka>
maybe a question for #clschool but.. you recommended to use let.. can I set variable with let to a value from input? like I did with setq?
<vms14>
But your asking to the user for two numbers, so your way was fine
<vms14>
Just wanted to show that you can directly do that
Bike has quit [Ping timeout: 256 seconds]
<vms14>
You're*
<kotrcka>
Yes, I saw a (funcall (read) (read) (read))
<kotrcka>
which is even simpler
<vms14>
Btw let works in a different way we are used to see
wanz has quit [Quit: wanz]
jello_pudding has joined #lisp
<didi>
Just brewed: https://paste.debian.net/hidden/93bccc33 My use case is that I have big matrices of data with lots of columns and I want new matrices with only selected columns so I can plot the data. I didn't test it enough for bugs. Too tired.
<vms14>
kotrcka: Are you in clschool?
jello_pudding has quit [Client Quit]
wanz has joined #lisp
<didi>
Eer, no need for the SORT. It's just a leftover.
<didi>
Hence, no need for COPY-LIST on KEEP either. OK, time to stop programming.
<beach>
Sounds like it. :)
<didi>
:-P
didi has quit [Remote host closed the connection]
pierpal has quit [Quit: Poof]
pierpal has joined #lisp
Elephant454 has joined #lisp
dale has joined #lisp
akoana has left #lisp ["Leaving"]
Lycurgus has quit [Quit: Exeunt]
psqueak has quit [Ping timeout: 268 seconds]
krwq has quit [Remote host closed the connection]
pierpal has quit [Ping timeout: 250 seconds]
wanz has quit [Quit: wanz]
pierpal has joined #lisp
ggole has joined #lisp
Bike has joined #lisp
seok_ has quit [Quit: Page closed]
rippa has joined #lisp
Bike has quit [Ping timeout: 256 seconds]
jinkies has quit [Ping timeout: 246 seconds]
dddddd has quit [Remote host closed the connection]
pierpal has quit [Ping timeout: 272 seconds]
moei has joined #lisp
megalography has quit [Ping timeout: 250 seconds]
pierpal has joined #lisp
megalography has joined #lisp
wusticality has quit [Ping timeout: 250 seconds]
Elephant454 has left #lisp ["ERC (IRC client for Emacs 26.1)"]
impulse has joined #lisp
wusticality has joined #lisp
wusticality has quit [Ping timeout: 250 seconds]
wusticality has joined #lisp
neirac has quit [Remote host closed the connection]
_whitelogger has joined #lisp
wusticality has quit [Ping timeout: 244 seconds]
heisig has joined #lisp
wusticality has joined #lisp
wusticality has quit [Ping timeout: 272 seconds]
pierpal has quit [Remote host closed the connection]
thodg has joined #lisp
random-nick has joined #lisp
wanz has joined #lisp
pierpal has joined #lisp
angavrilov has joined #lisp
makomo has joined #lisp
cage_ has joined #lisp
dale has quit [Quit: dale]
robotoad has quit [Quit: robotoad]
pierpal has quit [Ping timeout: 272 seconds]
xrash has joined #lisp
wanz has quit [Quit: wanz]
wanz has joined #lisp
pierpal has joined #lisp
pierpal has quit [Read error: Connection reset by peer]
pierpal has joined #lisp
wusticality has joined #lisp
wusticality has quit [Ping timeout: 250 seconds]
pierpal has quit [Read error: Connection reset by peer]
shifty has joined #lisp
pierpal has joined #lisp
glv has joined #lisp
shka_ has joined #lisp
wanz has quit [Quit: wanz]
robdog has joined #lisp
frodef has joined #lisp
frodef has quit [Ping timeout: 244 seconds]
wusticality has joined #lisp
pierpal has quit [Ping timeout: 250 seconds]
wusticality has quit [Ping timeout: 250 seconds]
pierpal has joined #lisp
glv has quit [Quit: Leaving]
pierpal has quit [Ping timeout: 244 seconds]
pierpal has joined #lisp
pierpal has quit [Ping timeout: 244 seconds]
pierpal has joined #lisp
wanz has joined #lisp
JetJej has joined #lisp
devon has joined #lisp
<devon>
How can I get some sort of xref to help understand an undocumented QuickLisp system?
<pjb>
You can still run some of the documentation generator on this system, even without docstrings, it may help.
<pjb>
devon: note that slime has some interactive xref features. slime-who-calls and other slime-who-* commands.
jmercouris has joined #lisp
<jmercouris>
good morning everyone
<pjb>
I would say the reason why tools like xref have not been further developed sincee the invention of the vty, is because we left behind batch development using punched cards and 132-column printer listings…
<pjb>
We do things interactively now.
<pjb>
(meaning, with a short cycle, in the REPL).
<pjb>
devon: otherwise, you can write your own analysing code, and generate dot files to be drawn with graphviz for example.
wusticality has joined #lisp
<devon>
Even here in the future, we must contend with obscure code. In my copious free time perhaps I'll make an interactive big-picture code visualizer.
wusticality has quit [Ping timeout: 244 seconds]
<pjb>
Or… you may count on the singularity.
<devon>
CCL has an xref feature dated 2003 same as the CMU xref.
FreeBirdLjj has joined #lisp
<jmercouris>
what is xref?
libertyprime has joined #lisp
<pjb>
cross reference
<jmercouris>
I saw the wiki article
<pjb>
tells who calls who, and who is called by whom.
<jmercouris>
but in this context I have no idea what you guys are talking about
<jmercouris>
doesn't a call stack also show who called what?
<pjb>
and by extension, shows other relationships, such as definitions and references.
<pjb>
the call stack is only one instance.
<pjb>
cross references gives a complete listing.
<jmercouris>
of all ever call stacks?
<pjb>
(as long as no run-time shenanigans are used).
<pjb>
yes.
<jmercouris>
interesting
<jmercouris>
and it make some sort of graph?
<pjb>
Yes. It's usually printed out in a listing, but ex. doxygen shows it as graphs.
<pjb>
Oh, then slime xref works in ccl, I just tried it on a function that wasn't called. But it doesn't show anything for slime-list-callees.
wusticality has joined #lisp
FreeBirdLjj has quit [Remote host closed the connection]
FreeBirdLjj has joined #lisp
orivej has quit [Ping timeout: 240 seconds]
FreeBirdLjj has quit [Remote host closed the connection]
FreeBirdLjj has joined #lisp
wusticality has quit [Ping timeout: 246 seconds]
frodef has joined #lisp
robdog has quit [Remote host closed the connection]
SaganMan has quit [Ping timeout: 272 seconds]
Essadon has joined #lisp
Essadon has quit [Max SendQ exceeded]
Essadon has joined #lisp
ebrasca has joined #lisp
n01 has joined #lisp
m0w has quit [Ping timeout: 246 seconds]
n01 has quit [Read error: Connection reset by peer]
vms14 has quit [Ping timeout: 246 seconds]
mercourisj has joined #lisp
FreeBirdLjj has quit [Remote host closed the connection]
FreeBirdLjj has joined #lisp
jmercouris has quit [Ping timeout: 272 seconds]
mercourisj has quit [Remote host closed the connection]
jmercouris has joined #lisp
FreeBirdLjj has quit [Ping timeout: 250 seconds]
wusticality has joined #lisp
iovec has joined #lisp
wusticality has quit [Ping timeout: 244 seconds]
mathrick has joined #lisp
vms14 has joined #lisp
sauvin has quit [Ping timeout: 250 seconds]
isBEKaml has quit [Quit: WeeChat 2.3]
Zaab1t has joined #lisp
robdog_ has joined #lisp
glv has joined #lisp
rjid has joined #lisp
robdog_ has quit [Remote host closed the connection]
rjid has left #lisp [#lisp]
sauvin has joined #lisp
gxt has joined #lisp
jfb4 has joined #lisp
makomo has quit [Ping timeout: 250 seconds]
milanj has joined #lisp
wusticality has joined #lisp
wusticality has quit [Ping timeout: 245 seconds]
vms14 has quit [Ping timeout: 246 seconds]
Lord_of_Life_ has joined #lisp
Lord_of_Life has quit [Ping timeout: 250 seconds]
Lord_of_Life_ is now known as Lord_of_Life
shka_ has quit [Ping timeout: 250 seconds]
ggole has quit [Ping timeout: 252 seconds]
cage_ has quit [Remote host closed the connection]
glv has quit [Quit: Leaving]
ggole has joined #lisp
orivej has joined #lisp
Zaab1t has quit [Ping timeout: 250 seconds]
frodef has quit [Read error: No route to host]
varjag has joined #lisp
orivej has quit [Ping timeout: 250 seconds]
orivej has joined #lisp
makomo has joined #lisp
m0w has joined #lisp
anewuser has joined #lisp
wusticality has joined #lisp
jfb4 has quit [Quit: ERC (IRC client for Emacs 26.1)]
jfb4 has joined #lisp
beach has quit [Disconnected by services]
beach has joined #lisp
rritoch has joined #lisp
wusticality has quit [Ping timeout: 250 seconds]
<rritoch>
Does anyone know where I can find a standard algorithm for the open parenthesis reader macro? It seems to be missing from the CLHS and is a vital part of the reader algorithm.
<beach>
rritoch: The existence of the reader macro is documented in the Common Lisp HyperSpec isn't it?
<rritoch>
beach: Thanks. I'm still wondering why so much of lisp is programmed in lisp, it seems to be a chicken and egg problem. I've made a small lisp implementation, with read, eval, and print, but its still mostly useless without the parenthesis reader macro.
<djeis[m]>
Well, it avoids depending on something external.
<beach>
rritoch: There is no chicken and egg problem.
<djeis[m]>
At the specification level, anyway.
<Xach>
rritoch: there are primordial chickens readily available these days
<beach>
rritoch: And presumably the reason someone wants a Common Lisp system is that the person thinks the language is quite good. Why, then, would that person write the Common Lisp system in a different language?
makomo has joined #lisp
<rritoch>
Well, I'm working in python. Originally I was just implementing lisp functions in python to make python more functional, but it didn't take long before I took it too far and am now working on a dirty lisp implementation.
<beach>
And what is it written in?
<jmercouris>
I don't understand the question, why wouldn't you want as much of lisp to be written in as lisp as possible?
<jmercouris>
I used to think that way as well, when I wrote a Lisp in C...
<rritoch>
beach: A common reason to implement one language in another is to make use of foreign libraries OR to parse foreign data, for example, not many data scrapers are written in Javascript yet most of them need javascript interpreters to read the javascript based data.
<jmercouris>
rritoch: but in this case, what is Common Lisp missing that you need to re-implement Common Lisp?
<jmercouris>
you could easily implement Common Lisp again in Common Lisp, much easier than you could in Python
<jmercouris>
the bootstrapping argument ONLY really works from ASM to C in my opinion
<beach>
rritoch: That's a different argument from the chicken-and-egg one though.
<beach>
jmercouris: Oh? GCC is written in C.
escanda has joined #lisp
<jmercouris>
Yeah, but OG GCC was written in Not C
<jmercouris>
I mean, we had to start somewhere
<jmercouris>
since C can't run directly on the processor
<beach>
Who cares where it started?
<jmercouris>
eventually it could bootstrap itself of course
<jmercouris>
I'm just saying...
<beach>
GCC was written in C because Unix had a C compiler.
<jmercouris>
Is that so?
<beach>
Of course.
<jmercouris>
I thought GCC was originally a free C compiler
<jmercouris>
I didn't realize it was to write compilers for other languages
<beach>
It still is.
<jmercouris>
or was it just to write a better C compiler than the one that came with Unix?
<escanda>
I am using the Djula templating library and trying to create my own filters, they need to be interned into djula.filters package to be used by the template, but whenever I intern a symbol, it gets iterned as |get-route|, such as when I later export it, it doesn't match its original name. are there any workarounds about this?
<beach>
But GCC was written in C, and they compiled it on AT&T or Berkeley Unix C compiler.
<jmercouris>
I see
<jmercouris>
good to know
<jmercouris>
I don't know much about the history of GCC
<jmercouris>
but however, somebody somewhere wrote the first C compiler in ASM
<beach>
Wow.
<rritoch>
I had a C compiler for an Apple IIc quite a number of decades ago and you had to write it out entirely in HEX
<beach>
jmercouris: Why do you think so?
<beach>
jmercouris: Why could it not have been written in Prolog or Pascal or Fortran?
<jmercouris>
beach: I can't think of a language that predates C that was high level in which they implemented a C compiler, maybe they wrote it in B, I don't know
<flip214>
(or lisp)
<jmercouris>
Ok yes, it is an assumption of mine that they went from C to ASM
<jmercouris>
I would be curious to know what the actual answer is
<flip214>
jmercouris: you may be right - if they had been using Lisp, they wouldn't have gone C ;)
<jmercouris>
s/C to ASM/ASM to C
<rritoch>
jmercouris: I think Pascal predated C
<beach>
rritoch: Of course it did.
<beach>
So did plenty of other languages like PL/I.
<jmercouris>
lots of languages predated C, but I think Assembly was still the most popular lang at the time
<jmercouris>
at least X86 Assembly
<beach>
jmercouris: *sigh*
<jmercouris>
however, I don't know much about history, and what I do know is highly influenced by my previous experience as a game dev
<beach>
jmercouris: Apparently.
anewuser has quit [Ping timeout: 250 seconds]
<jmercouris>
beach: which lang do you think the first C compiler was written in?
SaganMan has joined #lisp
<beach>
I have no idea.
<beach>
But I can look it up.
escanda has quit [Quit: Page closed]
<beach>
Knowledge of computing history is totally essential in order to understand why we are in the mess we are in, and how to fix it.
<rritoch>
beach: hahaha, it can't be fixxed! We're in the age of the tower of babylon, and there's millions of people out there spinning up languages with compiler compilers.
<jmercouris>
to understand the duct tape tower we've built :P?
<flip214>
jmercouris: you can be sure that x86 assembler was _not_ used for the first C compiler. x86 is much too young for that.
<jmercouris>
i386 chip predates C I believe, no?
<jmercouris>
well I guess I should look things up
<loke>
jmercouris: nope
<jmercouris>
C predates i386 by a lot
<jmercouris>
I thought they were both from the 70s
<jmercouris>
hmm, interesting stuf
<beach>
rritoch: We may have a possibility now. In the article in the November issue of CACM by Daniel Waddington and Jim Harris entitled "Software Challenges for the Changing Storage Landscape", they report that traditional kernel-based operating systems can not keep up with modern fast I/O devices.
<rritoch>
Looking back at my original questiohn about the left parenthesis, it seems to me that the reader isn't thread safe. It seems to me if two readers are running at the same time than there would be no way to know when a left-parenthesis is hit, which reader to stop.
<rritoch>
err, when the right-parenthesis is hit, which reader to stop
<beach>
rritoch: Obviously, two readers can not read from the same stream. Otherwise, it should be thread safe.
<jmercouris>
thread safe?
Essadon has joined #lisp
<jmercouris>
why would you have two readers reading the same thing?
Essadon has quit [Max SendQ exceeded]
<beach>
Like I said, you probably shouldn't do that.
marvin2 has quit [Ping timeout: 250 seconds]
<rritoch>
Looking at the hyperspec for the left-parenthesis and the reader algorithm, when the macro character is hit its function is called, right/left parenthesis are both examples of this.
Essadon has joined #lisp
<beach>
and?
<pjb>
beach: the reader macro for #\( cannot be implemented using just the reading functions exported by CL.
orivej has quit [Ping timeout: 240 seconds]
<rritoch>
Nevermind, I think I get it, the left parenthesis has to track which streams are being read so whent eh righ tparenthesis is called it stops the right one.
<rritoch>
Sorry for the bad spacing of that :(
<beach>
rritoch: Most functions are re-entrant, so they don't share data between threads.
<_death>
rritoch: a reader macro function takes a stream argument
<beach>
rritoch: The fact that the same function can be called in two different threads doesn't mean the code is not thread safe.
<pjb>
beach: I mean, using just READ or READ-DELIMITED-LIST. Of course, we can use READ-CHAR…
<beach>
pjb: Why are you telling me this?
<rritoch>
beach: Well, initially I thought I would only need a counter to count the number of left parenthesis, but that wouldn't be thread safe. Having one counter per stream would be though.
<pjb>
beach: Because you answered: "<beach> rritoch: The existence of the reader macro is documented in the Common Lisp HyperSpec isn't it?" but it's not so simple.
<djeis[m]>
rrtioch: why not use recursion?
krwq has joined #lisp
<beach>
pjb: Ah, that was a long time ago. :)
<pjb>
beach: implementing #\( either requires an internal API used by READ too, or requires re-implementing a lot of the READ mechanisms.
<beach>
rritoch: Sure, a counter would be fine. Just make it a special variable.
<djeis[m]>
rrtioch: and pass the stream currently being operated on into the parsing function?
<beach>
rritoch: But it wouldn't work very well.
wusticality has joined #lisp
<pjb>
rritoch: however, for a small lisp, or for bootstrapping purpose, one can implement a very simple reader macro for #\( ; basically, just using read-delimited-list, if you accept not reading literal conses.
<pjb>
(or dotted lists).
<pjb>
jmercouris: you cannot say things like "C cannot run directly on the processor." By definition, languages and processors are the same thing, and there have been processors able to run high level languages directly.
<jmercouris>
Ok, yes
<jmercouris>
"C cannot run directly on an X86 processor without being first converted to X86 assembler"
<jmercouris>
I hope we are on the same page now :D
<beach>
rritoch: Oh, you must be talking about implementing the reader in a language other than Common Lisp. It is extremely difficult to implement Common Lisp in something other than Common Lisp, at least if you want it to be fast.
wusticality has quit [Ping timeout: 268 seconds]
<pjb>
jmercouris: the first C compiler was written in B, not in assembler.
<jmercouris>
pjb: read further on, I guessed that!
<jmercouris>
I'm actually a little bit proud of myself for guessing
<beach>
pjb: Too late.
<jmercouris>
and guessing correctly :D
<beach>
jmercouris: You guessed assembler as I recall, no?
<jmercouris>
it was a pseudo-educated guess though, I knew B predated C
<jmercouris>
I guess assembler first, but then I guessed B
<rritoch>
beach: Yes, as I stated earlier, I'm implementing it in Python. Speed isn't an issue, this is mostly just for fun and for testing that the functions i'm writing in python perform the same as they do in lisp.
<pjb>
jmercouris: then read some wikipedia article, and don't guess anymore.
<jmercouris>
It was more for the sake of conversation than anything
<jmercouris>
I could have looked it up, but I was more interested in chatting about it
<jmercouris>
you can learn more that way, sometimes
<jmercouris>
for example, the source that death linked to, not on Wiki
<pjb>
Yes, it looks like computing history is become more important as it becomes longer. Not knowing that C was developped on minicomputers TEN years before the micro-processors sounds dangerous.
<jmercouris>
well, I am quite young, and CS history was not part of my curriculum...
<beach>
Lack of knowledge of computing history is a HUGE problem.
<jmercouris>
just today my father was telling me about the war between X11 and Sun's Post System (or whatever it was called)
<rritoch>
beach: You are assuming we did everthing RIGHT, and the BEST possible way, which we didn't!
<jmercouris>
I can't remember the name of the competing compositor
<jmercouris>
but Sun's sounded way better, wonder why X11 caught on instead
<beach>
rritoch: I know for a fact we did not.
<rritoch>
beach: Frankly I think if the next generations make their own mistakes instead of learning about ours than we may have progress.
<pjb>
jmercouris: You can run C programs on x86 processors without converting them to X86 assembler (or X86 binary code), by way of interpreters. Eg. Cint, Eic or others.
<_death>
jmercouris: the UNIX Haters book has a relevant chapter.. (the competing system was called NeWS)
<_death>
jmercouris: it used PostScript
<jmercouris>
_death: right, yes that
<jmercouris>
seems like X11 is a terrible idea compared to that
<pjb>
Well NeXTstep used Display Postscript, it was even better.
<jmercouris>
I had dreamed about things like NeWs, but I never knew something like that existed
<jmercouris>
but now that I know it existed, no need to implement it :D
<pjb>
Then it was bought by Apple, and Steve Jobs didn't want to pay Adobe anymore so they switched to a custom "Aqua" thing, and we lost a lot of features.
shifty has quit [Ping timeout: 250 seconds]
<beach>
rritoch: I can't for my life understand why you would think that.
<_death>
it's the utopian fallacy
<djeis[m]>
The way people make new mistakes is by knowing about the old ones...
<_death>
"if we start from scratch, we may do better"
khisanth_ is now known as Khisanth
<pjb>
There are obviously powers that are happy to see their brain washing work so well that people believe that.
<jmercouris>
I mean, it is kind of true
<jmercouris>
we could start with a better instruction set for one
<jmercouris>
and you know what, a lot of people believed that, and voila here we are, lots of ARM devices
<_death>
jmercouris: "better" implies you have a standard of reference
<djeis[m]>
Starting from scratch in terms of implementation is fine.
<pjb>
obviously, it never occurs. Just watch perl, python, ruby, etc.
<pjb>
They never do better than lisp.
<jmercouris>
ratio of power consumption/flops
<djeis[m]>
But you need to know the existing implementations to have any gauge for improvement.
<pjb>
I read recently that the 680x0 reached end-of-life because they couldn't cool it down anymore. So it had a better instruction set, but it was to hot.
<pjb>
too
<jmercouris>
I think you need to know your history to do better
<jmercouris>
however it is a delicate balance, your mind may be tainted by history
<jmercouris>
and box you into thinking about how things must be done
<jmercouris>
it requires an open mind, AND one knowledgable of the past
<rritoch>
jmercouris: One thing I would suggest you look into in your studies is LPC and multiple inheritance. Like many ideas we've seen in the industry, it was a useful one that fell throught the cracks. Now we have a ton of features just to mimic multiple-inheritance which has already existed for decades in LPC.
<djeis[m]>
Sure, but that's not an argument to stop teaching history.
<jmercouris>
rritoch: why me specifically?
<djeis[m]>
It's an argument to get better about open-mindedness.
<jackdaniel>
also that's not a topic for this channel, I'd recommend #lispcafe
<djeis[m]>
We've been off topic for a little while, yea.
<jmercouris>
is there some serious #lisp conversation that we should be having on New years eve?
<rritoch>
LPC is a matter of history, its industrially useless
<rritoch>
the Licence even forbits its use for business :(
<jmercouris>
I think fragmenting a small community into two smaller subsets is a mistake...
<jmercouris>
however I will cease
<jackdaniel>
I'm personally not interested in such discussions, that's why I'm on #lisp and not on #lispcafe
TMA has quit [Ping timeout: 246 seconds]
<pjb>
it's not fragmented, there's a big overlap; it's a question of context.
<jackdaniel>
given more lax channel specialization I wouldn't be on #lisp either
<rritoch>
jmercouris: Why you? Because I'm fairly sure you are the only melinial here. I'm in the 40+ range, and I don't even think I'm the oldest one here.
<djeis[m]>
Yup, it's a pretty popular feature of CLOS.
akoana has joined #lisp
<jackdaniel>
multiple inheritance in common lisp is frequently used, one interesting programming style is a mixin-based programming
<jackdaniel>
where you blend a certain functionality to created classes
<jmercouris>
jackdaniel: the channel is about what *everybody* is interested in, maybe we should have a vote on it
xantoz has quit [Remote host closed the connection]
<jackdaniel>
luckily for me I'm the channel operator so I don't need to vote. Channel topic is stated in the, uhm, topic
<djeis[m]>
No, that's lispcafe. This channel is about common lisp.
<flip214>
so, starting to talk about the weather could get me warned or banned? what about a meta-discussion about it, like that? or a meta-meta?
xantoz has joined #lisp
<flip214>
(yeah, I'll stop now. No, now really. Right now! ;)
<_death>
offtopic discussions are ok until someone notices that they're offtopic ;)
random-nick has quit [Read error: Connection reset by peer]
<rritoch>
Ok, so back to beating this dead horse about the left parenthesis. How about this for thread safety, I annotate (mark) the stream with some unique token, completely transparent to LISP, that way when the right parenthesis is hit, it can stop the correct loop and there's no risk of a problem even if you have two readers racing over the same input stream.
<djeis[m]>
Well, in CL, you never would have to readers going through the same input stream.
<djeis[m]>
That has problems well before you hit parens.
<djeis[m]>
A stream in CL tracks its own consumption, so two threads reading from the same stream will be competing for characters.
<djeis[m]>
Where are you tracking how much of the stream has already been processed?
<djeis[m]>
*two XD
space_otter has joined #lisp
shka_ has joined #lisp
<jackdaniel>
in gray streams you may track it however you want to. even more, I can imagine tracking it independently for each thread (so there are not races like the ones you have mentioned)
<jackdaniel>
as of ANSI CL streams afaik this is implementation dependent how it is tracked (i.e not specified in the standard)
<djeis[m]>
If you need the same text to be processed by multiple threads you have to buffer it, and if you're buffering it anyway then you can easily make separate streams for each thread.
wusticality has joined #lisp
<djeis[m]>
Fairly easily.
<jackdaniel>
sure, I'm just mentioning a possibility. also not all streams come from "somewhere", they may be accessors to your own data structures in memory
robotoad has joined #lisp
<rritoch>
jackdaniel: I was thinking along the lines of a more common case where you had a "good" thread, with good code under normal operations, and some hacker comes along to ruin your day by reading on your PTY
<djeis[m]>
That's an OS level problem lol
<jackdaniel>
I'm thinking in lines of gray streams because that's what I'm working on right now in McCLIM (and yes, concurrent access too! but with regard to output streams now)
<shka_>
moment
<shka_>
streams in mcclim are actually gray streams?
<djeis[m]>
The kinda have to be, don't they?
<jackdaniel>
they are, they have to be and they are mandated to be by the specification
<shka_>
hmmm
<jackdaniel>
how otherwise would it be possible to (format *window-stream* "hello clim!") ;?
random-nick has joined #lisp
<shka_>
but they are extended gray streams, right?
<jmercouris>
so gray streams, are they part of the official CL SPEC?
<djeis[m]>
jmercouris: no
<jackdaniel>
shka_: what do you mean by extedned gray streams? gray streams are all about subclassing and specializing on the class
<jmercouris>
CLIM is it part of the official spec?
<jackdaniel>
CLIM is a specification of a library in Common Lisp
<jmercouris>
okay so CLIM is just a library spec, outsdie of the CL Spec
<jackdaniel>
yes
<djeis[m]>
Yup
<jmercouris>
is the CLIM spec designed to work without augmenting the Lisp language?
<jackdaniel>
and gray streams are commonly implemented extension (like i.e mop)
<jackdaniel>
yes, it works on any conforming implementation
<jmercouris>
so then why must McClim depend on gray streams?
<jmercouris>
is an implementation that does not implement gray streams non-conforming?
<jackdaniel>
user should use clim-lisp package (instead of common-lisp)
<jmercouris>
s/implement/support
<pjb>
jmercouris: it is not.
<jackdaniel>
and gray streams may be implemented as a library (and generic functions reside in a separate package)
<pjb>
jmercouris: the CLIM spec augments defclass and defmethod for example.
<pjb>
Well, granted, by way of clim:defclass and clim:defmethod, not modifying cl:defclass or cl:defmethod.
<jmercouris>
ok, fair enough
<jmercouris>
why is it necesitated that gray streams exist for CLIM?
<pjb>
it is not. But it's cool.
<jmercouris>
okay, so was jackdaniel above, wrong?
<djeis[m]>
Because one of CLIM's basic abstractions is a stream you can also draw on.
<jackdaniel>
I've already mentioned an example: you wouldn't be able to use format on CLIM streams
<jmercouris>
"they are, they have to be and they are mandated to be by
<jmercouris>
okay, so once again, are they mandated or not?
<jackdaniel>
I believe that what pjb meant is that clim could be specified as not requireing gray streams in a parallel universe
<_death>
there are extensible stream interfaces distinct from Gray streams.. in fact the latter have bad design and I'm glad that they're not part of CL
makomo has quit [Read error: Connection reset by peer]
<pjb>
jmercouris: it's uncompleted, in future, because a lot of CL needs to be re-implemented for this feature.
<jmercouris>
what do you mean by a parallel universe? are you saying he is wrong?
<pjb>
jmercouris: with gray stream, it'd be already done.
<jackdaniel>
jmercouris: I'm not sure what is your point?
<pjb>
you would be able to use a clim:format that would re-implement cl:format (or call cl:format).
<jmercouris>
I don't have a point, beyond understanding
<djeis[m]>
CLIM needs something like gray streams to work and it happens to require gray streams in particular.
<jmercouris>
that's what I don't get
<jmercouris>
whoever designed CLIM, did gray streams already exist?
<djeis[m]>
Yes.
<jmercouris>
did they envision that they should exist?
<jmercouris>
okay, and so, despite it not being part of the CL Spec, they said "you know what, this standard common interface protocol, it will require this non-standard component"?
<jmercouris>
here's another question, if gray streams are so important, why aren't they part of CL?
marvin2 has joined #lisp
<jmercouris>
was it again an issue of time/money?
<djeis[m]>
CLIM needs something like gray streams to implement their behavior.
<pjb>
jmercouris: basically, the CL is specified to allow for optimized implementation, such as, hard-wired implementations, with very little introspection and genericity. But it also allow more introspection, genericity and modification of the implementation. If you cannot modify the implementation, or don't have hooks to modify its behavior clearly, then you have to re-implement it when you need features close to the language.
<pjb>
jmercouris: with things like gray streams, you get hooks into the implementation that allow you to implement things that are close to the language, without re-implementing the whole language.
<jmercouris>
ok, so far, I get it
<jmercouris>
who designed CLIM?
<_death>
jmercouris: CLIM predates the CL standard
<pjb>
Other projects went on, not waiting on the final release.
<djeis[m]>
If my timeline is correct, CLIM is at least based on the windowing system of genera isn't it?
<jackdaniel>
CLIM predates CL standard
<jackdaniel>
its development started in 87 (based on copyright headers in clim-tos)
<jackdaniel>
wikipedia gives date 88
<jackdaniel>
CLIM 2.0 was released in '93
<jackdaniel>
it roots in earlier toolkit called "Dynamic Windows" from Symbolic's Lisp machines
<_death>
jmercouris: to my mind, the principal designer of CLIM is Scott McKay
<jmercouris>
so here's a big question I've been thinking about a lot recently: why Common Lisp? why not another Lisp?
<jmercouris>
I mean, I'm pretty much all-in Common Lisp, but proponents of other Lisps, what are their reasons?
<_death>
jmercouris: you'll need to ask the proponents of other Lisps
<jackdaniel>
Common Lisp is an unification of all "serious" lisps with industrial baking of the time
<pjb>
well, for one thing, if you have a program in another lisp, then you can run it in Common Lisp, since it's a common lisp.
<jackdaniel>
so it was written to work on "all lisps" so to speak
<pjb>
On the other hand, if you have a program in Common Lisp, it may not run in some other lisp.
rumbler31 has joined #lisp
<jmercouris>
so Common Lisp is the lisp to unify all lisps
<pjb>
It was designed to be able to run programs written in other lisps.
<jmercouris>
that I understand
<pjb>
Yep.
<jmercouris>
however, there are other lisp-like languages like clojure
<Xach>
this info is in the spec itself, too
<Xach>
peter seibel's talk is a great history as well
<djeis[m]>
Well, Clojure is much younger than CL.
<jackdaniel>
we are past yule and I still haven't finished input refactor, so I'll detach now to waste rest of my sunday on programming ;-) see you later
<jmercouris>
_death: what are some of your reasons for choosing Common Lisp over other Lisps?
<jmercouris>
I'm sure at some point you investigated other languages before committing?
<rritoch>
jmercouris: I can answer that one. The main reason to use clojure is that clojure was designed to be a functional programming langauge, and it practically forces you to use fully thread-safe functional architecture, but it has no established standard. Even Python is lacking a standard. So there's no guarantee that 5 years from now the code you write today will still run when there is no standard.
<jmercouris>
Python is not lacking a standard
<jmercouris>
the standard is whatever comes out of Guido's mouth, no?
<pjb>
it has a written standard.
<djeis[m]>
Which can change at any time.
<pjb>
But there are PIPs and new versions.
<rritoch>
With CL, you can write your code and its guaranteed to run on ANY other CL that conforms to the standard.
<djeis[m]>
Also, did I hear right that Guido stepped down?
<pjb>
In CL, we have a standard, a few CDR that nobody consider, and no new version. So we're stable.
<_death>
jmercouris: well, I started with Paul Graham's book.. it was a lucky choice since it meshed best with my sensibilities..
<djeis[m]>
But yea- portable CL code from decades ago still works perfectly well on modern implementations.
<pjb>
And even lisp code from implementations 50 years ago still works perfectly well on modern implementations, with a few macros.
<djeis[m]>
And, apart from some a minor issue here or there, most of us find portable CL more than sufficient for our code.
<jmercouris>
many libraries have disclaimers at the top "only tested on SBCL"
<djeis[m]>
Where the spec is insufficient the community has come up with portability libraries. These libraries are, of course, less stable than the spec. But the presence of the portability library gives leverage for long-term support as well.
orivej has joined #lisp
<jmercouris>
I admit, I am guilty of this crime myself, for not fixing s-xml-rpc...
<jmercouris>
Xach: did you get the email from Pierre about putting s-xml-rpc in sharplispers so that we can fix some bugs and maintain it in the official QL dist?
<jmercouris>
djeis[m]: and yet many are missing, for example, where is my portability librarie for working with unix domain sockets?
<jmercouris>
s/librarie/library
thodg has quit [Ping timeout: 245 seconds]
<jackdaniel>
take action and implement it in usocket
<jmercouris>
I would like to, but I fear I lack the knowledge to do it right :|
<jackdaniel>
then you will rightfully claim that it is "yours"
<jmercouris>
I think maybe in a year's time I could do it
<jackdaniel>
fear not, I have it on my mile-long todo list, we'll get there one day ^_^
<jmercouris>
jackdaniel: what do you mean by that? Do I often claim things that aren't mine are mine?
<jackdaniel>
no, you said "where is my portability library for …"
<jmercouris>
or do you mean like I will have "taken over" the project and be now responsible
<jmercouris>
oh I see
<jmercouris>
makes sense :D
<jackdaniel>
it often does
<jmercouris>
it should really be called "bsocket" for bsd sockets
<jmercouris>
jackdaniel: how do you decide the order of your to-do list?
<jmercouris>
I'm just joking of course, as you can imagine where I am going with that
<jackdaniel>
some mix of randomness, curiosity and feeling guilty for leaving something for too long
<djeis[m]>
The point about the spec, tho, is not so much that all code should be portable- that'd be silly. However, it gives the different implementations a large space of common ground that library writers can work in and helps keep the community unified even over large stretches of time.
orivej has quit [Ping timeout: 272 seconds]
<p_l>
Python doesn't have a standard, afaik, PEP is just a community process they happened to implement but the "standard" is still "whatever is inside CPython right now"
nowhere_man has quit [Ping timeout: 252 seconds]
<jmercouris>
Python most definitely has a standard...implementation
<djeis[m]>
The spec is why you can just about be productive in CL nowadays reading only PCL, despite its relative age among programming textbooks. Only thing I'd add is some info about dev environments and ASDF etc.
<jmercouris>
which, tautologically speaking, makes it a standard
<p_l>
Ruby got (nearly?) an ISO standard, which forced them to adopt a more stable platform (most importantly they have official test suite that can be used to claim conformance instead of 'this implementation is considered standard')
<djeis[m]>
Heck, i could reach for much older books than PCL for learning lisp that are still (for the most part) valid and useful.
<buffergn0me>
I love how PCL is considered old now
SaganMan has quit [Quit: WeeChat 1.6]
<djeis[m]>
It's not that old, but among introductory programming textbooks it's not exactly new either lol
wigust- has quit [Read error: Connection reset by peer]
wigust has joined #lisp
<buffergn0me>
Touretzky's _A Gentle Introduction_ has aged really well. It's from 1990 and it had a re-printing in 2013 or 2014
<buffergn0me>
Imagine that happening with a Perl book
<pjb>
It's a dead language.
<pjb>
I've not seen perl for years.
<buffergn0me>
I had Perl programmers tell me Common Lisp was a dead language in 2001
<p_l>
I see Perl these days as a kind of CL in terms of popularity :P
<buffergn0me>
When I first started learning Lisp. I doubt any of them have touched Perl in years. I haven't stopped using Lisp in one form or another since that time.
vaporatorius has joined #lisp
<p_l>
Python _finally_ kicked it out in system administration (not sure if good thing, though), on Windows it lost to powershell and such, web... well, PHP was the killer, then ruby helped bring down the PHP monopoly
<buffergn0me>
Python is literally Y2K BASIC
Khisanth has quit [Ping timeout: 246 seconds]
<rritoch>
I'd say LISP is less of a programming language and more of an addiction. If there was ever an award for MOST LISP ADDICTED, This guy is certainly going to get nominated > https://github.com/kanaka/mal/
<aeth>
Perl is basically a regex DSL turned into a full language. Someone needs to make a cl-ppre (like cl-ppcre, but literally perl instead of just being perl-compatible).
Mr-Potter has joined #lisp
dale has joined #lisp
TMA has quit [Ping timeout: 244 seconds]
phax has quit [Quit: phax]
jmercouris has quit [Remote host closed the connection]
nowhere_man has joined #lisp
wusticality has joined #lisp
TMA has joined #lisp
<krwq>
has anyone tried dbus? I'm trying this: https://pastebin.com/XE1BrNtK and wondering what I'm doing wrong (cc: _death) error I'm getting is: The name org.krwq.MyService was not provided by any .service files
pierpal has joined #lisp
<krwq>
on one side i run (publish) and on the second one (example). publish runs without issues but example produces the error above
orivej has joined #lisp
wusticality has quit [Ping timeout: 250 seconds]
vms14 has quit [Quit: Bye]
vms14 has joined #lisp
<pjb>
aeth: you must be right. Notably that would explain why we have to use the sigils.
pierpal has quit [Ping timeout: 240 seconds]
phax has joined #lisp
shka_ has quit [Ping timeout: 272 seconds]
pierpal has joined #lisp
libertyprime has quit [Ping timeout: 246 seconds]
phax has quit [Quit: phax]
meepdeew has joined #lisp
meepdeew has quit [Ping timeout: 268 seconds]
notzmv has quit [Read error: Connection reset by peer]
notzmv has joined #lisp
<_death>
krwq: as of now, the published objects don't support generation of introspection xml (feel free to implement this...) try https://plaster.tymoon.eu/view/1066#1066 and replace the destination arg with your bus connection name..
<p_l>
krwq: you might want to create a .service file manually
<krwq>
_death: p_l: is there any way to connect without the .service file? I know very little about dbus
<p_l>
krwq: if you implement introspection, probably
<_death>
krwq: my snippet should work without writing one.. but, my dbus library is low-level, incomplete, and has some design issues.. so it's best to read the dbus specification, and expect to have to modify its code at some point ;)
<krwq>
_death: in that example you gave what's the :destination? is it bus connection name?
<_death>
yes
<krwq>
_death: I think that should be sufficient for me
<krwq>
thanks!
<_death>
cool
<krwq>
_death: is there any way to use it without the :destination other than generating that xml?
JetJej has quit [Quit: [Quit]]
<krwq>
that's the only thing the other side of the connection doesn't have
<_death>
krwq: you can request an alternative name from dbus and use that
<_death>
krwq: so that it won't change every time.. see dbus:request-name and the dbus spec
<krwq>
_death: i think it's stuck on request-name
nowhere_man has quit [Ping timeout: 252 seconds]
wusticality has joined #lisp
<_death>
interesting.. it doesn't seem to send back a method-return message... whereas with the dbus-send utility it does.. let me investigate
wusticality has quit [Ping timeout: 268 seconds]
robdog_ has joined #lisp
nowhere_man has joined #lisp
<krwq>
_death: thank you!
random-nick has quit [Ping timeout: 246 seconds]
nowhere_man has quit [Ping timeout: 252 seconds]
angavrilov has quit [Remote host closed the connection]
shifty has joined #lisp
rumbler31 has quit [Remote host closed the connection]