Search found 17 matches
- Thu Oct 28, 2010 8:00 am
- Forum: Common Lisp
- Topic: Converting signed to unsigned: help, Lisp is in my way!
- Replies: 6
- Views: 43805
- Wed Jun 16, 2010 9:39 am
- Forum: Common Lisp
- Topic: Is this legal Lisp?
- Replies: 8
- Views: 9743
Re: Is this legal Lisp?
If generality and avoiding accidental complexity is the aim, we can decompose the problem like this: Mapping the structure: (defun map-tree (function tree) (typecase tree (null) (cons (map-tree function (car tree)) (map-tree function (cdr tree))) (t (funcall function tree)))) Counting objects: (defu...
- Wed Jun 16, 2010 7:41 am
- Forum: Common Lisp
- Topic: Is this legal Lisp?
- Replies: 8
- Views: 9743
Re: Is this legal Lisp?
Because if you doing the exact same operation on multiple variables then you almost always was a datastructure. If you're doing the exact same operation on multiple variables/values you want an operator, not a data structure. A data structure might make sense when there is a connection between diff...
- Tue Jun 15, 2010 5:12 pm
- Forum: Common Lisp
- Topic: Is this a bug in LispWorks?
- Replies: 8
- Views: 8628
Re: Is this a bug in LispWorks?
Tip: whenever you have (reduce <function1> (mapcar <function2> <list>) ...) you can replace it with (reduce <function1> <list> :key <function2> ...), avoiding intermediate garbage.
- Tue Jun 15, 2010 4:57 pm
- Forum: Common Lisp
- Topic: Is this legal Lisp?
- Replies: 8
- Views: 9743
Re: Is this legal Lisp?
I don't know why proposed solutions used an alist/hash-table. I think lispamour got it basically right. My proposed solution: (defun count-bases (tree) (let ((as 0) (ts 0) (gs 0) (cs 0)) (labels ((rec (x) (etypecase x ((eql a) (incf as)) ((eql t) (incf ts)) ((eql g) (incf gs)) ((eql c) (incf cs)) (n...
- Mon Sep 29, 2008 5:38 pm
- Forum: Common Lisp
- Topic: The Future of Lisp
- Replies: 25
- Views: 54594
Re: The Future of Lisp
Maybe someone should try it without any sort of optimizing algorithm. If massive mult-core is in the future, then I'd be interested to see how even a dumb implementation works. How about a Lisp where every variable clause of a let (not let*, obviously) is evaluated on a different core if the assign...
- Mon Sep 22, 2008 3:31 am
- Forum: Common Lisp
- Topic: Extending FORMAT
- Replies: 3
- Views: 11765
Re: Extending FORMAT
See http://cs-www.cs.yale.edu/homes/dvm/format-stinks.html. The OUT macro is easy to extend.
- Sat Sep 13, 2008 5:21 pm
- Forum: Common Lisp
- Topic: Rant: lisp is not C. Get over it.
- Replies: 47
- Views: 249201
Re: Rant: lisp is not C. Get over it.
I guess I should have been more specific about what I wanted to know. I wanted to know about the details of your particular case, i.e. what implementation you chose to use, what libraries you had trouble with, what that trouble was, how far did you go before you decided to use Ruby, why didn't you h...
- Sat Sep 13, 2008 11:36 am
- Forum: Common Lisp
- Topic: Rant: lisp is not C. Get over it.
- Replies: 47
- Views: 249201
Re: Rant: lisp is not C. Get over it.
Can you be more specific about these problems, and about how standardization might have helped?findinglisp wrote:With Lisp, I was fighting the libraries and sockets and streams and such.
- Sun Aug 17, 2008 3:19 pm
- Forum: Common Lisp
- Topic: Macro expansion, packages, and LET
- Replies: 9
- Views: 22697
Re: Macro expansion, packages, and LET
I'll keep all that in mind, it sounds like great advice, but my thinking is that there are certain macros which establish a context in which the body operates; for example, WITH-OPEN-FILE establishes the context of the file in the sense that it opens the file, lets you do whatever you need with tha...