freenode/lisp - IRC Chatlog
Search
19:35:54
skidd0
hello! With multi-line doc strings (and strings in general) do I need to escape a newline?
19:39:13
verisimilitude
If so, you'll find it much quicker to simply test questions such as this there, in the future.
19:41:27
verisimilitude
Still, you can get caught believing something is standard when it isn't this way, so do use proper judgement, yes.
19:45:51
skidd0
okay. I've not gotten into reader macros yet. All i know is that they are 'a thing'. #'something has a # reader macro then, right?
19:46:28
verisimilitude
The # reader macro is a dispatch reader macro, which reads in the next character and calls a reader macro with an extra argument and whatnot.
19:47:17
verisimilitude
Still, shka_ is on point; you don't need to worry about this right now, skidd0.
19:48:53
shka_
skidd0: really, if you want to save yourself some time ensure that you understand packages and read time evaluation, that would be enough to know for now
19:49:06
skidd0
i'm assuming you all are long time lispers, but, i'm curious if you remember how long it took after starting to learn lisp for it all ti "click"
19:50:05
shka_
yeah, well, that's the thing that you should understand the following things about the reader to safely go forward
19:50:12
verisimilitude
I don't believe it's bragging when I tell you it all clicked fairly easily, at least after the first month or so, skidd0.
19:51:03
skidd0
verisimilitude: how would you define that "click"? like what observation or pattern/conenction did you see?
19:51:07
shka_
skidd0: i am pretty sure that practical common lisp is the best reference you can have
19:52:31
verisimilitude
That and some light reading should be enough; once you understand that, it ``clicks'', I suppose.
23:34:50
verisimilitude
I suppose I most commonly use IGNORABLE for special variables that I bind with &AUX but don't otherwise use.
23:36:30
verisimilitude
(LAMBDA (&OPTIONAL (STREAM *STANDARD-OUTPUT*) &AUX (*STANDARD-OUTPUT* STREAM)) ...)
23:38:32
aeth
Oh in case I was unclear, by in the style of WITH-ACCESSORS, I mean essentially a double binding. In with-accessors it's a let then a symbol-macrolet, and it's possible that the symbol-macrolet is working on a NIL list while the let binding is provided like this: (with-accessors () foo ...) ; more of something you'd see from a generating macro than something you'd write directly
23:39:04
aeth
The main difference between the with-accessors in the notes and with-accessors in an actual implementation's macroexpand-1 is probably the IGNORABLE declaration. http://www.lispworks.com/documentation/HyperSpec/Body/m_w_acce.htm
2:09:23
pjb
(let ((let (let ((let 'let)) (list let let let)))) (flet ((lєt (&rest let) let)) (lєt let let let))) #| --> ((let let let) (let let let) (let let let)) |#
2:29:30
verisimilitude
I just always use &AUX if I want a binding to apply to the entire body; it's clearer than a LET or LET* that likely covers the entire body, but would perhaps need to be checked for this.
3:22:45
verisimilitude
It's a certainty with &AUX, but not quite with LET, even if in practice a LET will always be indented properly and whatnot.
3:23:06
verisimilitude
So, it's the difference between being certain or being pretty sure at a glance.
6:15:26
beach
margaritamike: You are comparing apples and oranges. Python doesn't have a standard the way Common Lisp does, so as a language Python does not have ANYTHING built in.
6:15:40
beach
margaritamike: Now, perhaps you mean Python the programming system as opposed to the language.
6:16:07
beach
margaritamike: Then you can't compare it with Common Lisp, because Common Lisp is a standard, and you have to compare it to a particular implementation, or you have to look at some libraries.
6:19:31
margaritamike
i care about built in so i don't have to worry about whether some library maintainer screwed their implementation up and i don't have to write it myself :p
6:20:07
beach
margaritamike: Then don't say Python has it built it, because they can screw things up overnight, given that they don't have to respect any standard at all.
6:20:11
shka_
margaritamike: the only reason python includes this is because it is impossible to have efficient enough implementation in the python
6:20:16
verisimilitude
Well, (APROPOS "64") in SBCL reveals nothing at all what you want, margaritamike.
6:21:26
shka_
but sbcl for instance produces efficient code so it can be just ordinary normal library
6:23:01
verisimilitude
Don't worry, margaritamike; there are plenty of people perfectly happy to write ``Common Lisp libraries'' that are actually C and only work on one implementation, just like Python.
6:26:20
shka_
and any illusion of it can be shattered once the glorious overlords decides that any given feature actually sucks
6:27:30
verisimilitude
To be fair to Python, there are multiple implementations; the lack of a standard means the CPython implementation's C API has effectively become part of the language they can't change and is a great issue with every other implementation, though.
6:28:28
verisimilitude
That's the least of Python's worries, though, considering the implementation also sucks.
6:31:04
verisimilitude
I'm vaguely aware of one Python subset implementation that attempts to be efficient at the cost of many language features that can't be optimized, so we can call that another.
6:32:44
fiddlerwoaroof
Yeah, there's micropython that's designed to run on microcontrollers and rpython that's subset-ish and designed to be easy to compile
6:34:20
fiddlerwoaroof
As far as using C libraries goes, I've mixed feelings about that: I'd honestly rather interface with something like libuv than using epoll/select/kqueues directly