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 - JeremyDunn

Pages1

newLISP newS / Re: newLISP Development release 10.4.8

May 12, 2013, 05:10:39 PM

I tried installing newLISP on my windows system and I keep getting this message when I try to open it

run shell:

Could not start C:Program FIles(x86)newlisp/newlisp.exe -C -w "C:UsersJeremy"

I've tried uninstalling newLISP and loading again but no luck. Any suggestions anyone?

Whither newLISP? / Re: How to get newLISP popular?

February 11, 2013, 05:52:05 PM

I wish I knew more about programming. I can tell you right off the bat that if someone could figure out a way to interface with AutoCAD so that one could use NewLISP rather than AutoLISP, that the language would immediately have a large community. AutoLISP exists in several CAD programs now but none of them have deigned to improve AutoLISP. The users keep begging Autodesk to improve AutoLISP but it falls on deaf ears, they have decided for us that we're supposed to use VB.NET. And yet everyone defies them and keeps using AutoLISP! They just don't get it.

Whither newLISP? / Idea for MAP function

July 22, 2010, 09:38:44 PM

I was thinking of a new form of the MAP function that would be useful. I would like to have a form of it where you could write (map func list true) where instead of a second list you have a truth flg to denote the new form. In this arrangement what happens is that func is mapped onto list. The values of the mappings are compared to each other, if they are all equal then the value is returned else nil is. This doesn't break the current syntax and adds another useful feature but maybe others disagree.

Whither newLISP? / Re: Nesting and Booleans

July 06, 2010, 12:48:41 PM

For those that want to play with the boolean statements it doesn't involve changing too many functions. Here is my list:

Code Select Expand

;Redefine all of NewLisp's boolean functions
(define (array??     x A B)(bool-if array?     x A B))
(define (atom??      x A B)(bool-if atom?      x A B))
(define (context??   x A B)(bool-if context?   x A B))
(define (directory?? x A B)(bool-if directory? x A B))
(define (empty??     x A B)(bool-if empty?     x A B))
(define (file??      x A B)(bool-if file?      x A B))
(define (float??     x A B)(bool-if float?     x A B))
(define (global??    x A B)(bool-if global?    x A B))
(define (inf??       x A B)(bool-if inf?       x A B))
(define (integer??   x A B)(bool-if integer?   x A B))
(define (lambda??    x A B)(bool-if lambda?    x A B))
(define (legal??     x A B)(bool-if legal?     x A B))
(define (list??      x A B)(bool-if list?      x A B))
(define (macro??     x A B)(bool-if macro?     x A B))
(define (NaN??       x A B)(bool-if NaN?       x A B))
(define (nil??       x A B)(bool-if nil?       x A B))
(define (null??      x A B)(bool-if null?      x A B))
(define (number??    x A B)(bool-if number?    x A B))
(define (primitive?? x A B)(bool-if primitive? x A B))
(define (protected?? x A B)(bool-if protected? x A B))
(define (quote??     x A B)(bool-if quote?     x A B))
(define (string??    x A B)(bool-if string?    x A B))
(define (symbol??    x A B)(bool-if symbol?    x A B))
(define (true??      x A B)(bool-if true?      x A B))
(define (zero??      x A B)(bool-if zero?      x A B))
(define (not??       x A B)(bool-if not        x A B))

The booleans work out nicely from a naming standpoint in that all I had to do was add a second question mark on the end to make them distinct. A concern was expressed that treating booleans this way might make code unreadable or confusing to people from other LISPs. That may be so but one might say the same thing about implicit indexing. The point here is that any language has syntax quirks that have to be learned. There is no point in creating a language if it does not attempt to do one or more things differently to keep advancing better notions. In practice I have tried using these on a code module of mine and didn't find it the least bit confusing but I am admittedly a biased observer. It has the virtue of not forcing you to change your ways but allows the opportunity for those that are bent in that direction just as one is not forced to use implicit indexing but eventually discovers its awfully nice to have sometimes.

The make-pass method of nesting I find the most acceptable because it allows brevity for short nestings and the & on the end of the functions make it clear that something is going on. I do not see composing being used in the sense that Kaz does it because it does not have the simplicity of appearance that make-pass does. Kaz's method may be more traditional but it is too much trouble for short nestings, which is the typical case. I think people will just type (sin (cos x)) rather than go through all the extra trouble just to be traditional. The nestings have to be too deep to gain an advantage in typing. Now suppose we end up taking the make-pass approach and write (sin (cos x)) as (sin& cos& x), have we gained anything? The total characters typed was the same so we gained nothing in typing. Arguably we might say that it looks cleaner in that the parentheses seem more distracting than adding the two &. It takes a second level of nesting before we gain a definitive advantage. But if we rewrite the functions to nest as part of their nature then we can write (sin cos x) and gain advantage at the first nesting. In Paul Graham's Arc language one could write the statement as (sin:cos x) which allows us to type one less symbol than make-pass. But I think its even better to not have to type extra symbols at all. A change in syntax could be nice. What if we could write something like (sin cos | x) where the vertical line delineated nesting and a separation from the functions and the arguments. This would allow nesting to be visually distinct, it would require only one symbol for any level of nesting and give advantage at the first nesting. Of course only Lutz could make this happen unless he gives us reader macros to play with.

Whither newLISP? / Nesting and Booleans

July 04, 2010, 05:02:31 PM

My mind wanders around a lot and I find that I have something more to say about function nesting and how it turned out to be involved with boolean statements. To see the relation takes a while but please bear with me.

If we have a nested statement such as (sin (cos 0.5)) we instinctively want to simplify it to (sin cos 0.5) but are frustrated in that the current syntax doesn't allow us to do that. So the good lisper can write himself a function that we will call NEST and then be able to write something like (nest sin cos 0.5). This may be elegant but in most cases does not satisfy because we must type another five characters (don't forget the space). Often the nesting you actually run across only goes for two levels and it is just easier to type the two parentheses, this approach only starts to have value at three levels of nesting. We can't get rid of that desire to type (sin cos 0.5)! A lisper always wants to do the least typing possible. For fun I wrote this function

Code Select Expand

(define-macro (nest)
  (setq op (args 0) rargs (rest (args)))
  (op (eval (if (symbol? (rargs 0))
                 (begin
                   (setq r   (rest (rargs))
                         lst (rargs -1)
                         r   (if (symbol? lst)
                                 (setf (r -1)(list lst))
                                 r
                             )
                   )
                   (apply (rargs 0)(map eval r))
                 )
                 (rargs 0)
             ))))

I hope someone writes a better version of this because I am pretty sure I didn't take the best approach. This function takes advantage of the fact that all functions that are capable of nesting only have a single argument. And we can use this frame to redefine all of the existing single argument functions if we wish. Here is a demonstration example with the SIN and COS functions:

Code Select Expand

(define-macro (sn)   (nest sin  ))
(define-macro (cs)   (nest cos  ))

Using these new functions you can now write (sn cs 0.5) and get the desired result. If you redefine all of NewLisp's single argument functions and your own this way you can have built-in nesting the way God intended!

However I ran across a case where making all single argument functions act this way is undesirable. I found that boolean functions that take single arguments should be treated in a different manner. I came up with this fun little piece of code:

Code Select Expand

(define (bool-if func x A B)
  (if (or A B)
      (eval (if (func x) A B))           
      (func x)))

What this function does is allow any boolean function to double as its own if/then/else conditional statement. How does this work? Suppose we define a new version of the INTEGER? function as

Code Select Expand

(define (new-integer? x A B)
   (bool-if integer? x A B))

Now if we write (new-integer? 3) this behaves the same way as integer? does. But if we were to write (new-integer? 3 "A" "B") it now behaves like (if (integer? 3) "A" "B"). We now don't have to write the IF statement!

So we have two conflicting desires here, we can't make all single argument functions have nesting behavior and be able to have built-in conditionals at the same time. I have concluded that this is not a problem in practice because almost all nested statements that I have run across do not tend to have conditionals in them or at least rarely. Therefore I propose that all boolean functions (functions that return true or nil) have built-in conditional capability and that all other single argument functions have built-in nesting. This could be further advanced by having two new functions DEFINE-BOOL and DEFINE-NEST so that users could define such functions right from the beginning. How would this work? Let us say that we want to define a new boolean function that determines whether a number is even or odd. We will call this function EVEN?. I envisage writing something like

Code Select Expand

(define-bool (even?)
  (zero? (% $X 2))
)

The user only has to supply the name of the function and the code for the logical test. $X represents an internal variable that stands for the single argument that the function takes for the default case. All of the rest of the overhead is taken care of by DEFINE-BOOL. A similar technique would be used for a DEFINE-NEST function.

I believe that there cumulative advantages to implementing both of these approaches to NewLisp. It doesn't break previous code but adds a great enhancement. Wouldn't it be nice to get rid of a lot of IF statements? Anyone have any thoughts on the matter?

newLISP in the real world / Re: How to treat a function like a list?

July 04, 2010, 09:54:09 AM

Thanks so much. I was thinking that I had to write a define statement rather than define-macro because I had a fixed number of arguments rather than a variable number but these subtleties often elude me. To paraphrase Yogi Berra: LISP is so simple no one can understand it!

newLISP in the real world / How to treat a function like a list?

July 03, 2010, 11:52:43 PM

I was trying to write what should be a simple function but found that I didn't know how to treat a function expression like a list. What I was trying to do was this; I wanted to write a function that I will call REV. What REV does is take a function expression as an argument and it executes the function except with its arguments in reverse order. So (rev (div 3 6)) executes

(div 6 3). This can be handy for rearranging an expression to a more aesthetic appearance. So how does one do something like this?

newLISP in the real world / Another option for FOR-ALL?

May 06, 2010, 08:41:48 PM

I would suggest generalizing FOR-ALL further to handle a list of test conditions as well as a single condition. There would also be an optional argument at the end where the user would define which logical operation is to be performed with all of the test conditions. The default for the optional argument would be the AND function. So

(for-all '(integer? zero?) '(0 0 0)) is the same as

(for-all '(integer? zero?) '(0 0 0) and)

this returns true if all members of the list satisfy all of the test conditions. If we wrote

(for-all '(integer? zero?) '(0 1 2) or)

this returns true if any of the test functions apply. Here is a sample implementation of the function:

Code Select Expand

;; New FOR-ALL
(define (forall test lst (op and))
  (if-not (list? test)
     (for-all test lst)
     (apply op (map for-all test (dup lst (length test))))))

Anything else we might add? / Re: Useful list function

April 25, 2010, 03:04:54 PM

Here is yet another enhancement I have recently added. We can now compare the lengths of two lists. So the expression

(length? list-1 list-2) returns true if the two lists are equal in length or one can add a comparison operator. For instance,

(length? list-1 list-2 <) returns true if the length of list-1 is less than the length of list-2. Here is the new code:

Code Select Expand

(define (string-or-list? x)(or (list? x)(string? x)))

(define-macro (length?)
  (let (len (length (args))
        fst (eval (args 0))
        scd (eval (args 1))
       )
  ;....if we have two lists to compare
  (if (and (<= 2 len 3)
           (string-or-list? fst)
           (string-or-list? scd))
      ((if (= len 2) = (eval (args 2)))
         (length fst)
         (length scd))
      ;....otherwise operate on a single list
      (apply length2? (map eval (args)))
  )
 )
)

(define (length2? lst (n 1)(op =) booltest)
  (and (op (length lst)
           (if (string-or-list? n)(length n) n))
       (if booltest
           (if (list? booltest)
               (for-all true?
                  (map for-all booltest (dup lst (length booltest))))
               (for-all booltest lst))
           true
       )))

#10

Anything else we might add? / Re: Wish list

April 08, 2010, 09:08:02 PM

Thought I would get this thread going again with some more simple things that we might do to jazz things up.

1. I also put my vote in for Kazimir's operators +. and such. They look better and are easier to read.

2. I would like to see some of the math functions overloaded to do common vector operations. For instance, if vec

is a vector (a list of integers or floats):

(+ vec) returns (apply + vec)

(add vec) returns (apply add vec)

(* vec) returns (apply * vec)

(mul vec) returns (apply mul vec)

(pow vec) returns (apply add (map mul vec vec)) ;the sum of squares

(pow vec n) returns (i1^n + i2^n + .... + iN^n) the sum of the nth power of the elements

(sqrt vec) returns (sqrt (pow vec)) ;the vector norm

(div vec) returns the unit vector vec/norm

The cost of adding these is minimal but the gain for vector math is great in that we can use conventional functions

instead of a plethora of new ones. Vector expressions will also be greatly simplified.

#11

Anything else we might add? / Useful list function

April 08, 2010, 08:01:58 PM

As we all know ideas build up over time and turn into things we didn't initially imagine. In my case I started with a basic function that I used that was simple and useful and it has recently grown into something more useful. First, the code:

Code Select Expand

(define (length? lst (n 1)(op =) booltest)
  (and (op (length lst)
           (if (or (string? n)(list? n))(length n) n))
       (if booltest
           (if (list? booltest)
               (for-all true?
                  (map for-all booltest (dup lst (length booltest))))
               (for-all booltest lst))
           true
       )))

We often want to see if a list's number of arguments fits within a certain range and whether all of its members satisfy some criteria. Now we can test for both with the length? function. The length? function takes a list as argument and optionally can include an integer to test the length against, a comparison operator and a boolean test function to do a for-all comparison on the list. If all conditions are satisfied then true is returned. The test defaults to 1 and the comparison operator defaults to =. Here are some examples of how this works:

(length? lst) - does the list have 1 element?

(length? lst 2) - does the list have 2 elements?

(length? lst 3 >) - does the list have more than 3 elements?

(length? lst 3 = integer?) - do we have a list of 3 integers?

(length? lst 3 = (list integer? zero?)) - do we have a list of 3 integers that are 0?

That is pretty neat but there is more! If we have another list instead of a comparison number we can use a comparison operator to see how the number of arguments compare with one another. In this case we can only use <, = and > as comparators. Here are some more examples of how this works:

(length? lst1 lst2) - are the lists of equal length?

(length? lst1 lst2 >) - does lst1 have more arguments than lst2?

(length? lst1 lst2 <) - does lst1 have fewer arguments than lst2?

Of course one can compare string lengths this way as well. I think it is clear that this makes life much easier. Here is an example of how one could use the function in a practical way. The integer-vector? function determines if its input is a non-zero length list of integers.

Code Select Expand

(define (integer-vector? v)(length? v 0 > integer?))

So let the votes begin, should this be a new function in the language? Can it be generalized even more?