Menu

Show posts

This section allows you to view all posts made by this member. Note that you can only see posts made in areas you currently have access to.

Show posts Menu

Messages - shercipher

Pages1
#1
newLISP in the real world /
May 24, 2009, 02:15:39 PM
Okay so all I have to do is evaluate the symbol from dotree.
#2
newLISP in the real world / Hashes
May 21, 2009, 03:02:53 PM
Why does this work?


Code Select

(new Tree 'hash)
(hash "x" 0)
(hash "y" 1)
(hash "z" 2)

(hash "x")
0


But this not work?


Code Select

(dotree (x hash)
 (print x " " (hash x) " "))
#3
newLISP in the real world /
May 20, 2009, 03:32:48 PM
Right, maybe this is just another "nil is not ()" difference with Common Lisp. Sorry, CL was what taught me how to think Lisp.
#4
newLISP in the real world / first gives errors on empty lists
May 20, 2009, 12:20:44 PM
Calling (first) on an empty list gives an error instead of returning the empty list. This is inconsistent with the documentation, which claims that first behaves the same as car in other Lisp implementations.



On the contrary,


Code Select

; sbcl
This is SBCL 1.0.18.debian, an implementation of ANSI Common Lisp.
More information about SBCL is available at <http>.

* (car nil)

NIL

* (car ())

NIL


CL (and Scheme as well, I believe) return empty lists when car or cdr (which are first and rest in NL) are called on empty lists.



This behavior of the function gives a lot of errors in instances where lists are being checked using functions such as filter, which may return empty lists. I doubt that modifying this behavior would cause existing programs to break.
#5
newLISP in the real world / List access times versus array access times
May 17, 2009, 04:18:40 PM
For very large lists/arrays, what is the time improvement for accessing the last element of either structure? I imagine that for arrays, the time taken to access the last element is flat, but for lists grows as the list size grows.



Do arrays have restrictions on size (e.g., can't be indexed past the size of a 32-bit int?)
#6
newLISP in the real world /
May 15, 2009, 10:15:58 AM
You can turn off prompts with the -c option. Don't know how to get a () (I don't think readlines even supports that, emacs probably does). There doesn't seem to be a quiet or suppress option; that needs to be added.
#7
newLISP newS /
May 14, 2009, 10:44:20 AM
I don't see anything on the newLisp website guaranteeing that the API is stable anyway. If he wants to remove something or change its behavior, the worst you have to do is probably a find-replace. Unless the behavior of a fundamental, commonly used function is totally changed, which isn't what this was about.
#8
newLISP in the real world / I suppose there is no progn
May 13, 2009, 09:18:58 PM
For expressions that need to be evaluated sequentially in newLisp, there is no progn special form that says "evaluate these and return the last".



So how do I make code like this valid?


Code Select

(if (expr)
 ((eval 1) (eval 2) (eval3))
 (eval4))


It seems to execute the forms correctly, except that at the end of executing the forms it says "ERR: value expected: (whatever the last form was)"
#9
newLISP in the real world /
May 11, 2009, 11:03:01 PM
Too late, already wrote my own function. Will consider replacing if necessary later (I have doubts that mine works correctly).
#10
newLISP in the real world / Importing C libraries
May 11, 2009, 09:02:41 PM
I need to use the SHA1 function in libssl.so. The function has the following syntax:


Code Select

unsigned char *SHA1(const unsigned char *d, unsigned long n,
                  unsigned char *md);


With the explanation



SHA1() computes the SHA-1 message digest of the n bytes at d and places it in md (which must have space for SHA_DIGEST_LENGTH == 20 bytes of output). If md is NULL, the digest is placed in a static array.



So I was like okay, well I can't find a newLisp NULL, but I think nil should do it...

Tried


Code Select

(SHA1 etc (length etc) nil)


Which crashes with a segfault if I try to do that again.



So then I was like, okay, maybe I can store it in a variable:


Code Select

(SHA1 etc (length etc) *resultant*)


And reading *resultant* gives me


Code Select

?


Interesting. Anything else gives me segmentation faults. How can I get these two languages to work with each other, or is the answer "write a glue library"?
#11
newLISP Graphics & Sound /
May 10, 2009, 09:06:47 PM
In CL the answer would be macros. In NL I'm pretty sure the answer is still macros. What exactly are you trying to accomplish (explain)?
#12
Whither newLISP? /
May 10, 2009, 09:05:15 PM
I think you can in Scheme define if as a function; however, in CL, because the rest of a list is evaluated before the head is, if must be a special form, and cannot be written as a function.
#13
Whither newLISP? /
May 10, 2009, 06:52:54 PM
I don't understand this misconception that Common Lisp/Scheme are faster just because they are compiled. In most benchmarks they perform worse than Perl (which we'll call a "fast" interpreted language) even when speed 3 safety 0 is on.



When I saw the mergesort benchmark, I was pretty impressed; newLisp seems to perform on par with Perl, so I have no trouble with speed in NL at all (if I did, I have old faithful C, and the fact that newLisp has a FFI that makes sense to turn to).



That aside, these concepts of macros seem to be a bit troublesome. In CL, you used macros to redefine the language and selectively expand/replace expressions, choosing which parts of the expression you wanted to eval now and which parts you wanted to eval later.



I suppose I would be a little more comfortable if NL had support for that `( , ,) syntax that I'm used to.



EDIT.



Cool, it clicked. So a macro in newlisp is just a function that doesn't evaluate its arguments when passing them, unlike in CL where its a replacement sort of thing.
#14
Whither newLISP? /
May 10, 2009, 10:36:16 AM
I'm knew CL first, so the closing ) on their own lines looks wrong to me. Stacking parentheses on the end of lines has always seemed the logical thing to do (unlike }'s, which look ugly when stacked together).
#15
Whither newLISP? / Macros need explanation
May 10, 2009, 10:27:57 AM
I hail from Common Lisp, where the entire idea of macros is completely different, it seems, from that of newLisp.



Could someone please explain to me exactly what a newLisp macro does? Does it evaluate its body and not evaluate its inputs? Or does it evaluate its inputs but not its body? How can I use these macros to turn newLisp into a programmable programming language - the Lisp I know and love?



And slightly off topic, but the (clean ...) function seems to have a bug that produces a segmentation fault.
Pages1