freenode/#lisp - IRC Chatlog
Search
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.