freenode/#lisp - IRC Chatlog
Search
12:31:06
clothespin_
autocad will never move away from autolisp so long is there is an autocad because of the huge volumes of autolisp code out there
12:32:13
beach
However, there was a time when the company announced that they were going to rewrite it in Common Lisp. That project was canceled, though.
12:33:31
p_l
this led to situation where there was (still is?) a separate company providing an IDE for AutoLISP, because the VBA approach didn't win much support from userbase, no matter how much it was pushed
12:34:54
p_l
AFAIK it was due to AutoLISP that my parents home had a book called "LISP Programming Language", which set me on a slow, long road to Lisp :)
12:36:48
p_l
clothespin_: IIRC it started not on DOS but some Unix platform, but quickly cornered the market by going for DOS
12:37:48
p_l
and due to availability on random PCs, similarly to Turbo Pascal, it took over Poland in a storm
12:40:37
jackdaniel
in scale from -3 to +3 in on-topicness it has +0.001 because words phrases and "lisp" and "common lisp" pop up every now and then ,-)
12:41:59
thijso
Funnily enough, I used AutoCAD and never encountered Lisp during that time. Only much later did I learn about Lisp and retroactively saw that AutoLisp existed...
12:44:47
p_l
on more Common Lisp (well, pre-common but works on CL) CAD software, ICAD apparently was still available to some extent
12:45:47
clothespin_
dassault systemes bought ICAD and that was pretty much the end of new development
12:49:35
p_l
yes, in my infinite(simally small) free time, I was thinking of adding one of the things missing from the free software version back, using a lispy (scheme-y?) geometry library
12:50:09
p_l
because the FOSS version of gendl misses few components, due to them being dependant on closed-source commercial packages
12:53:19
p_l
... I just found that a project in which I had put my fingers a tiny bit and always thought was underfunded, has enough budget that if someone talked right way they could finance a lisp bonanza...
13:06:47
minion
The URL https://gitlab.common-lisp.net/users/sign_in?secret=c86b369e will be valid until 13:15 UTC.
14:48:59
rumbler3196
anyone having issues with paredit mode lately? Its letting me delete closing parens which is frustrating
15:03:03
Xach
rumbler3196: I don't use anything. If a form becomes too long to use simple paren balancing in the REPL, i write it in a file (sometimes a temporary one) to manage it.
15:38:08
pjb
note that paredit disables itself when parentheses become unbalanced in a buffer, outside of its control. So: (write-line "1) then repl is not a lisp buffer!")
15:43:50
rumbler3196
paredit in the scratch buffer works fine. I issue m-x slime and then activate paredit and parens don't keep
15:46:36
rumbler3196
this is where I get mixed up sometimes. I installed slime from the package manager, then after I installed quicklisp I installed the quicklisp-slime-helper
16:25:44
minion
The URL https://gitlab.common-lisp.net/users/sign_in?secret=97a2b8a1 will be valid until 16:30 UTC.
16:30:58
jasom
A stackless coroutine is a coroutine that cannot context-switch in a nested function.
16:32:30
samlamamma
Finally a proper reason to use Common Lisp. http://quickdocs.org/trivial-left-pad/api
16:32:57
jasom
Josh_2: so the "stackless" part is that the TCB for the coroutine need not include a separate stack.
16:37:00
Bike
wouldn't the issue be that you can only resume the yielded coroutine at certain points, that is while the condition is being handled? you can't actually return to the caller and do something you were already doing.
19:49:27
jcowan
Can sbcl statically type-check keyword actual arguments when the type of the corresponding lambda argument is known?
20:23:34
pfdietz
If you declaim the type of the function using FTYPE, it will flag the type incompatibility at the call.
22:58:56
jcowan
Another question. If a lambda list specifies both &optional and &key, is it necessary to fill all optional arguments in the call before any keywords are detected, or is the presence of a keyword enough to trigger keyword processing?
23:01:16
no-defun-allowed
You can test with read-from-string, which takes two optional arguments then keyword arguments.
23:06:11
clothespin
i'm not talking about the heavy handed stuff like immutable datastructures and atoms and such
23:06:53
aeth
jcowan: (let ((l1 (list 1 2 3 :c 42)) (l2 (list 1 :c 42))) (flet ((test-optional-with-key (list) (destructuring-bind (foo &optional bar baz &key a b c) list (values foo bar baz a b c)))) (format t "~{~S ~}~%~{~S ~}~%" (multiple-value-list (test-optional-with-key l1)) (multiple-value-list (test-optional-with-key l2)))))
23:07:04
aeth
SBCL even gives a style warning there, although it exists in a few older functions in the standard
23:08:09
aeth
For those who don't want to run it, the first line is "1 2 3 NIL NIL 42 " and the second is "1 :C 42 NIL NIL NIL ", so when the optionals aren't filled in the keyword is treated as an argument. And yes, this has caused a bug in my code before.
23:10:07
aeth
And without destructuring bind: (let ((l1 (list 1 2 3 :c 42)) (l2 (list 1 :c 42))) (flet ((test-optional-with-key (foo &optional bar baz &key a b c) (values foo bar baz a b c))) (format t "~{~S ~}~%~{~S ~}~%" (multiple-value-list (multiple-value-call #'test-optional-with-key (values-list l1))) (multiple-value-list (multiple-value-call #'test-optional-with-key (values-list l2))))))
23:31:35
aeth
SBCL does have the most helpful compiler, it warns you about stuff like a special variable without earmuffs. CCL can catch some bugs that SBCL doesn't because it interprets the standard differently, though
23:32:59
aeth
jcowan: The default value of optionals and keywords are nil unless you specify one like &optional foo (bar 42) ; in this case foo is nil and bar is 42 if nothing is passed in
23:33:28
aeth
jcowan: In CL, there is no #<unspecified> or whatever a Scheme might use for stuff like that. Pretty much anywhere where there is a default value, it's nil, unless you explicitly use (values) or use an API that does
23:34:48
jcowan
So in fact you must specify all optional arguments, none can remain optional, if keyword arguments are to be processed as such.
23:35:34
aeth
jcowan: It does make sense from the perspective of &optional, which is to get to the later, you have to go through the earlier parts, even if it just means a bunch of ugly nils that were already the defaults
23:35:47
Bike
it would probably be even more complicated to try to interpret it another way, given the other parts of how keyword arguments (you can use non-keyword symbols, and pass keyword arguments not specified in the lambda list, plus you don't statically know the lambda list anyway)
23:36:31
jcowan
I'm beginning to grasp why Racket and Kawa treat keywords as syntax rather than Lisp objects.
23:37:05
Bike
yeah i kind of like how lisp works well enough, but it does have some really confusing parts
23:37:09
aeth
jcowan: Right, because if you see :foo :bar :baz :quux you don't know if you have 0, 2, or 4 keyword arguments.
23:37:33
jcowan
I think the moral is not to mix keywords, optional arguments, and rest arguments: pick one.
23:38:33
aeth
jcowan: &allow-other-keys is imo pretty much mandatory in higher order functions (at least ones that take in lambdas that use keywords) in Common Lisp because you can't pin a library to a version in Quicklisp, so if an API adds another keyword input, your version is now an error at whatever point it's funcalled.
23:41:47
aeth
There's some advantage to simple lambda list syntax, e.g. you can destructuring bind a plist tail with (... &key ... &allow-other-keys) to parse it... That's convenience you don't get for alists.
23:42:53
jcowan
whereas even if keywords were not self-evaluating, (foo 'a 32 'b 45) is perfectly readable and no more verbose than :a :b