freenode/#lisp - IRC Chatlog
Search
21:41:14
Bike
it's not that important. instead of the compiler, you have me telling you you made a mistake. artificial artificial intelligence, it's called
21:41:45
Bike
you understand, right? you quoted `word`, so it's not evaluated, so the argument isn't used, drakma only sees the actual symbol WORD
21:45:40
dwts
Bike: yep, that did the trick! Also type-of looks helpful if you are unsure what you are passing to your functions I guess
22:58:11
mrottenkolber
spreadable argument list designator n.: a designator for a list of objects; that is, an object that denotes a list and that is a non-null list L1 of length n, whose last element is a list L2 of length m (denoting a list L3 of length m+n-1 whose elements are L1i for i < n-1 followed by L2j for j < m). “The list (1 2 (3 4 5)) is a spreadable argument list designator for the list (1 2 3 4 5).”
22:59:33
mrottenkolber
so if a spreadable argument list designator is a “non-null list L1”, that means nil is not a valid s a l d, right?
23:06:19
mrottenkolber
I seems to indicate that (apply 'list '(1 2 3 (4 5))) ≡ (apply 'list '(1 2 3 4 5)) which is luckily not true on i.e. CCL
23:11:58
mrottenkolber
the + led me to believe apply would accept one or more spreadable argument list designators
23:14:25
pjb
mrottenkolber: but you have to remember that &rest gets a list of arguments, so when the spreadable argument list designator takes for example (1 2 (3 4 5)) it means that the function was called with the rest arguments 1 2 (3 4 5) like this: (apply 'list 1 2 '(3 4 5)) for example
23:51:29
k-stz
is there a protable way to translate a c array to a lisp array, or can I just leave it in its cffi SAP form? Efficiency actually matters in this case
23:57:48
k-stz
I'm not sure what counts as keeping it around. As its set up to be I have to use it multiple times. I'd have to test it
23:58:21
pjb
But remember that you have to free C data yourself (unless you use a underlying C garbage collector such as the BoehmGC.
23:58:41
pjb
k-stz: if you only need to access the elements of the C array once, there's no point in copying it.
0:02:47
pjb
You may want to optimize safety and ease of use; lisp data is easier to use than foreign data.
0:04:01
dwts
mrottenkolber: is there an alternative that returns same results across implementations?
0:06:01
k-stz
But also the idea to make a lisp-array from pointer data sounded mildly exciting ;), so I thought it made by even a common thing to do!
0:06:44
pjb
It's only that it's slow. So you need to be able to amortize it, if your purpose is to optimize execution speed.
0:07:13
Bike
it basically amounts to making a lisp array of the length of the c array and copying the c array contents (translating as you go)
0:07:58
mfiano
dwts: The author of Common Lisp Recipes gives an example, `(type-of "foo")`, giving 4 different results across 6 different implementations. To be portable, you probably want to check for an explicit type/subtype with TYPEP/SUBTYPEP, or perhaps someone more familiar can give more help.
0:09:08
k-stz
Bike well just have lisp use the exact addresses pointed to, not freshly allocate an array
0:09:30
Bike
but it's a c array. lisp arrays have type information and stuff. and can be garbage collected.
0:13:03
dwts
I was wondering, is anyone here using common lisp at work? I've only used scheme (in the past) common lisp (now) for some toy projects
0:16:52
dwts
Xach: Given that there aren't many (to my knowledge) common lisp positions, how many years of experience one would require to get a senior common lisp position?
0:20:19
Xach
There are CL projects in many companies, but they are not often made public. They are often the work of enthusiastic individuals who really want to use Common Lisp and have some discretion at work. That might be because they are founders or just given a lot of independence.
0:22:19
Xach
Before I did contract CL work, I used CL to write tools to make life easier in various ways - to process or generate data, or to generate code for tools in other languages.
0:22:20
dwts
Yeah, I've noticed that you can't get much info on that subject. Apart from a few companies that were using common lisp and then turned to python/whatever it's really hard to get any info
0:24:32
Xach
dwts: rob warnock has written quite a bit on the topic. he uses the CL pretty-printer in nice ways to generate code.
0:27:13
Xach
here's a small bit: https://www.xach.com/rpw3/articles/mbudnVpUvZKbC8XVnZ2dnUVZ_vudnZ2d%40speakeasy.net.html
0:28:58
dwts
Xach: this kind of info make lisp's power look unlimited...or only limited to one's imagination
0:39:56
mejja
(format t "~%foo_t ~a_foos[~d] = {~ ~%~{~<~%~1,68:; {~/0x/, ~2/0x/}~>~^,~}~%};~%" instance (/ (length data) 2) data))
0:42:28
dwts
Xach: how feasible do you think it would be to write a linter in common-lisp? I was thinking about a chef linter
0:43:45
pjb
Very feasible: https://www.google.fr/search?client=safari&rls=en&q=common+lisp+lint&ie=UTF-8&oe=UTF-8&gfe_rd=cr&dcr=0&ei=qHYTWq3jGrGJgAborLiQAQ
0:46:02
aeth
mejja: format takes in streams, so you can break it up into smaller parts and even mix non-format writing/printing things in as well
0:46:53
aeth
(only format nil would make this hard, but you could use with-output-to-string instead to generate a string that way)
0:49:53
aeth
mejja: Here's an example (but, of course, this is a toy example and I wouldn't break this up): (progn (format t "Hello, ") (format t "world!"))
0:51:24
mejja
code snippet is from the link pasted by Xarch a page up. original author is Rob Warnock not me..
0:55:46
aeth
mejja: if it ran (it doesn't!) and if Lisp Paste was still up, I'd try to make it more readable
1:00:19
aeth
If you want to see a completely different approach to generating C-style syntax, I generate a subset of GLSL (which uses C-style syntax) recursively here: https://gitlab.com/zombie-raptor/zombie-raptor/blob/79ba7be2b51ca8992c453490fb9a7bb109027818/data/generate-glsl.lisp
1:03:05
aeth
It's not very efficient because it recursively returns strings generated by format nil, but it runs while compiling to produce constant strings so I don't really care about performance. If I had to write it today, I might consider a with-output-to-string stream instead of returning and concatenating strings.
3:49:04
mfiano
just ask your question, and understand that 'clisp' refers to an implementation, and not common lisp the language
3:51:23
internet_cafe
ok, i have a list like (('a' 1) ('b' 2) ('c' 3)), is there a way to get 3 by looking up 'c' ?
3:53:58
pjb
internet_cafe: (let ((list (quote (('a' 1) ('b' 2) ('c' 3))))) (cadadr (assoc 'c list :key (function cadr)))) #| --> 3 |#
3:55:53
pjb
internet_cafe: read https://sourceforge.net/p/clisp/clisp/ci/tip/tree/doc/LISP-tutorial.txt
3:56:15
pjb
internet_cafe: if you want more: Common Lisp: A Gentle Introduction to Symbolic Computation http://www.cs.cmu.edu/~dst/LispBook/ http://www-cgi.cs.cmu.edu/afs/cs.cmu.edu/user/dst/www/LispBook/index.html
4:01:20
pjb
internet_cafe: if you read a tutorial, you'd know that 'x is equivalent to (quote x) and quote is a symbol just like any other.
4:10:13
pjb
You will have to use the :test option, since in general, you don't keep references to the string used as keys…
4:12:38
pjb
internet_cafe: one advantage of lisp is also one inconvenient. Since it's written using syntax for data, almost all forms are valid. As data of course, but also as lisp source, since you can always interpret any lisp data as lisp code. At worst, it will signal an error (and this may be what you want, who are we to say otherwise?).
4:13:09
pjb
internet_cafe: the big advantage from this is that it gives the programmer great freedom to transform the code as you wish, and to process it very easily thru functions and macros.
4:14:19
pjb
There are still some texts you cannot read as lisp data. For example if you have unbalanced | or if you have multiple dots in lists or vectors, things like that.
4:14:28
pjb
(foo|bar) #| ERROR: Unexpected end of file on #<string-input-stream :closed #x302008CDECCD> |#
4:14:36
pjb
(foo . bar . baz) #| ERROR: Reader error on #<string-input-stream :closed #x302008CFECCD>: Dot context error in ".". |#
4:15:11
pjb
(foo ') #| ERROR: Reader error on #<string-input-stream :closed #x302008C5ECCD>: Unmatched ')' . |#
4:16:27
pjb
More than 2 colons too, depending on the implementation: (quote cl-user:::bar) #| --> \:BAR |# but ccl accepts it.
6:59:17
vtomole
I don't know where to ask this, but I've been trying to implement a lisp parser in C using recursive decent, and it's recursive more than in should. I've looked at it for a week now, so this is my last resort:https://gist.github.com/vtomole/5ec6bb35080c3c544682eaa58c19604e
7:05:16
jasom
vtomole: unless it's specifically a common lisp parser, that's off-topic here, perhaps ##lisp? One on-topic answer I can give you is to point you to http://clhs.lisp.se/Body/02_b.htm which describes the algorithm used by common lisp for parsing
7:06:18
jasom
jasom: http://www.lispworks.com/documentation/HyperSpec/Body/02_da.htm describes the default behavior of the "(" character
7:08:17
vtomole
Yeah. I've read those, and I'm pretty sure my implementation idoes it. There is just a small bug with mine. It recurses more than it should using a token list
7:08:19
jasom
The core algorithm is a very simple parser with essentially only 1 character lookahead
7:09:21
jasom
vtomole: slight nit-pick; you do not use that algorithm, since it is character based and you are tokenizing your parens
7:14:47
jasom
consider perhaps using a debugger to inspect your call stacks, that would make what is going on obvious
7:16:49
vtomole
next for token_list? That's what I had earlier. I switch it back to that after the remove front segfaults
7:19:38
vtomole
token list before car :+ ( - 2 3 ) 7 ). token list after car: + ( - 2 3 ) 7 ) ( - 2 3 ) 7 ) - 2 3 ) 7 )
7:23:55
jasom
hmm, I would expect that you'd end up with a cons containing two pluses, but I can't see all the code, so don't know for sure
7:25:26
jasom
parse_pair is called with a token list beginning with the token before the CAR. That is very counterintuitive
7:27:42
beach
vtomole: A function such as parse_pair or atom must return two things, the result of the parse, and the remaining token list. Otherwise, you will end up calling the same function over and over again on the same list of tokens.
7:29:11
vtomole
jasom: Sorry sorry it is. i forgot to change that, but is call strcmp, but i don't have to type "==0".
7:30:03
beach
vtomole: Also, in parse_pair, once you parse the CAR, you parse the CDR by calling parse_pair, but parse_pair starts by removing the first token, assuming it is an opening parenthesis, but that is not the case for the remainder of the list of tokens.
7:30:23
jasom
vtomole: alternatively to returning the remaining token list, you can destructively modify it, since lisp's parsing algorithm will never backtrack. But you need *some* way of signaling how much was parsed
7:32:31
vtomole
jasom: I tried destructively modfiying it by calling a remove_front() procedure, but that caused a segfault after a couple of calls to parse_pair()
7:33:11
jasom
vtomole: destructively modifying it is perhaps harder to get right, but getting anything right without planning it out is going to be hard
7:33:21
vtomole
beach: Would removing the token from the list be a better solution than returning two things?
7:33:45
jasom
vtomole: for returning multiple values in C, it is idiomatic to have the return value be an indication of success, and then pass all of the "output" values as pointer parameters
7:35:33
beach
vtomole: You need to return two things, both the result of the parse, and the remaining tokens. But you can do it as jasom says, or you can return a struct.
7:36:07
jasom
so e.g. int parse(object **parsedObject, token_list ** tokenList); // which is invoked like {object *result; if(parse(&result, &theList)) ...
7:46:27
beach
vtomole: And you need to remove the left parenthesis before calling parse_pair. And parse_pair should be renamed. Call it parse_list instead, because the list can be empty.
7:48:00
pjb
vtomole: you cannot implement a Common Lisp parser without implementing the whole Common Lisp. Read chapter 2.
7:48:01
beach
vtomole: By having blank lines, there are fewer lines displayed simultaneously, making it harder to read.
7:48:49
beach
pjb: vtomole has some more fundamental problems with programming in general that we need to address first.
7:56:37
pjb
vtomole: you could use an enum for the token type instead of strings. This would simplify testing, and also it would be faster.
7:57:24
vtomole
Yeah. I'm going to do that now that it works. I always try to get a dirty implementation working first.
7:58:11
pjb
vtomole: you should start by writing the grammar you want to parse. Then you can either implement the parser by hand, or use a parser generator from the grammar.
7:58:48
pjb
Using flex and bison (or lex and yacc), you could implement the lexer and parser in 2 hours.
8:09:38
beach
vtomole: Then, when you get this version to work, I suggest you rewrite it completely using getchar() so that it will be closer to what Common Lisp READ does. As you can see from the Common Lisp HyperSpec, the Common Lisp READ function does not tokenize first.
8:10:31
beach
vtomole: Also, by using getchar() you don't have to return two values, since the stream is destructively modified by getchar().
8:11:43
beach
vtomole: Section 2.2 of the Common Lisp HyperSpec is very detailed and phrased in terms of an input stream.
8:32:37
loke`
On page 24, the following sentence can be foundL “The commas in writing S-expressions may be omitted. This is an accident.”
8:33:54
pjb
Yes, the initial sexp syntax used comma instead of space, so symbols could have space in their name!
8:35:18
pjb
loke`: see: http://informatimago.com/develop/lisp/com/informatimago/small-cl-pgms/m-expression/index.html
8:55:23
loke`
pjb: I saw that in the original paper from McCarthy. But I didn't know how it worked in LISP 1
8:56:00
loke`
So are you saying that spaces was not allowed in symbols in LISP 1, but it was intended to work just like the original paper?
8:57:11
loke`
This means that they have four different notations in this document: Maths, M-exprs, comma-separated expr and finally, the actual sexprs used in the implementation.
8:59:04
loke`
It's clear that at the time of writing, they still saw sexprs as being a hack, and something to be replaced by m-exprs at a later time.
9:01:47
loke`
Hmm, they use the term SAP in this document. It seems the history of that term's use in SBCL dates back to the beginning.