Looking ahead to newLISP 8.0

[kazemori]

EddieR posted the following thoughts in the recent thread on "threads"; i think this deserves promotion to its own thread.



(hope you don't mind, Eddie!)



EddieR writes:

======================================================



Since we have find and slice we could get rid of "member"



I've seen the (cond (bool1 exp1) (bool2 exp2) ....) vs (cond bool1 exp1 bool2 exp2 ...) debated in several books. Would it be bad to implement the if or the cond like (? bool1 exp1 bool2 exp2 ...). Maybe even get rid of either "cond" or the "if" altogether?



I know we've tossed around getting rid of starts-with and ends-with string functions, but, since you also provide for lists???



Why have "first" and "nth 0?"



Do we really need let? Or if we need let shouldn't we also have a let! that allows something like



code:

--------------------------------------------------------------------------------

(let! ((x 1) (y x)) (func ....))  where the second variable can use the value of the first variable?

--------------------------------------------------------------------------------



Isn't lookup the same as (rest (assoc ....



how about a reverse-assoc?



I know I'm drawing flames here, but, ...



Eddie



======================================================

[Lutz]

I agree, just did an answer to Eddie on  'Threads' topic, but yes, lets continue over here. Here is what I plosted over there:



----------------------------------------------------------------------------------

You will definetely not draw flames from me. This is exactly the kind of comments I was looking for. In detail:



(1) 'member'

I thinks I have never even used it once! It's there only because of historical reasons and because it seems to mentined in all introductions to LISP. If no body else feels strong about it I also would like to get rid of it.



(2) 'cond'

The form with less parenthesis seems attractive to me and as you mention 'if' would then just be a special case of it. We could change 'if' to the newer multi arg form, then (who wants) could just do a (set 'cond if) to get a new 'cond'-binding. After a while we could mark the old 'cond' as deprecated and eventually throw it out. Never thought about it but seems attractive to me. What do others think? Isn't that the way AutoLisp is doing it?



(3) 'first' with 'nth 0'

Its such a frequently used function and the ex- 'car', 'head' etc.. I could imagine there is a lot oppostion. I myself sometimes use 'nth 0' for more readability, when I use a lot of other 'nth x' in the same area of code. I would like to hear more opinion that one.



(4) 'let' and 'let!'

let wasn't there until a year or two ago. Instead I had supplied a macro. Too many people where asking for it. let! alias 'letrec' .. yeah I agree. Personally I use 'let' rarely and use the 'local effect' of unused parameters instead. What I mostly dislike about 'let' is, that it adds to parenthesis clutter. If let! is cheap to do on top of 'let' I'll do it if its just another little bloat, I would rather like to get rid of it again because using the 'local effect' of unused parameters is a much nicer way to do locals when doing dynamic scoping anyway (in Scheme 'let' gives you at least lexical closure).



(5) 'lookup' versus (rest (assoc ...))



'lookup' can specify which position you want in the assoc list i.e.:



(lookup 'a '((x q w e r t y) (a q w e r t y)) 1) => q



I would love to keep it. although of course you could do (nth x (assoc ...)). Its just very handy when getting GET or POST or COOKIE parameters vi cgi.lsp and faster too, if you do a lot of it.



(6) 'assoc-reverse'

what is it? How would it work?



some other thoughts:

what about the way that 'for' works with the always positive step-parameter? Does this confuse everybody , or do you think its nice.



BTW for all Mac OSX users, just got 'import' working for Mac OSX. it will be included in the next distribution. If somebody needs it now, please contact me.





Lutz

[kazemori]

i think that Eddie has launched us off with a bang!



one of the things that we need to keep in mind is function ( or in this case primitive) interdependence.



most newLISP primitives are implemented internally via other primitives (a basic Lisp concept); it is easy to imagine, and perhaps even to produce, a dependency tree which illustrates this fact for newLISP.



if we assume as a design goal (as Lutz has stated previously) that it is desirable to keep newLISP:



(a) simple;

(b) transparent; and

(c) possessed of a small footprint -- both in static memory and within its runtime environment



then it follows that we can sort functions/primitives based on both their intrinsic usefulness and their resource dependencies.



take the newLISP primitive set!, which can easily be implemented externally: (setq set! setq). set! is presumably present only as a convenience to those who used it in a CL (or other) environment. this kind of "low-hanging fruit" begs for extraction from the newLISP executable, and re-implementation as a simple library file. i am sure that several other of the current primitives exist in this state.



in the case of deprecated primitives, perhaps a library could be created for these as well? if someone wants these (and can live with the possible implications for run-time performance), they need only modify their init.lsp file to load the "library of the damned" at start-up.



another category of primitives are the more esoteric, but nonetheless desirable, functions (advanced math, financial, statistical...). an argument can be made that these should be removed to a library, as well. a counter argument can be made that these functions benefit from being implemented internally (as fast C directives) and would be unacceptably slow if implemented in newLISP (the interpreted language).



again, i suggest that the dependency tree would be a useful tool in resolving this type of issue as well.



so, by all means, let's draw out our cutlery and sharpen our tools (assuming Lutz wants to prune newLISP ;-), but keep the following in mind:



"everything is connected to everything else"



evaluate and prioritize the associations, and then make good decisions, which we will not come to regret in later times. my two cents.



kazemori

[eddier]

Lutz has pointed out several reasons for "(set! "  and "(set '."  I have to aggree with him on this. Anything to speed up binding is a plus. We might would think to get rid of "(set " but this would be a dreadful mistake, for example how would you implement function parameters as symbols?



Keep lookup! I was just thinking out loud!



Actually I've seen "reverse-assoc" as "rassoc" in books. The function looks up the second element in a list of lists and returns the first element.  For example,

Code Select Expand


(set! record '((name (Bill Jones)) (salary 45000) (account 45000)))
(rassoc '(Bill Jones) record) => name
(rassoc 45000) => (salary account)


I'm not sure the above is correct when more than one range element matches?



Now that I think about the "if" what about the form ((if (< x y) + *) 2 2)? I have never used this but you have made it available. This functionality would not be available as a cond.



Ok, I agree with keeping "first"



I have never used "for"



Eddie

[Lutz]

(1) (rassoc ...)



Have to think about it ....



(2) new cond



((if (< x y) + *) 2 3) would still work work cond because this works now:



((cond ((< x y) +) (true *)) 3 3) => 6 or 9



and you can write it shorter now too:



((cond ((< x y) +) (*)) 3 3)  => 6 or 9



So in the new form it would be:



((cond (< x y) + true *) 3 3)



or



((cond (< x y) +  *) 3 3) ; which now looks like the old 'if'



When an action clause is missing than the value of the conditional expression gets returned. Of course in the new form of 'cond' only in the last condition-action pair the action can be omitted. So this would make the new 'cond' server like an old 'if'.



I really like the new 'cond' perhaps we start offering it as a new 'if' because it wouldn't break any old code. But one could use it with multiple action-true pairs making it the same as the new 'cond'. Whowever wants to get rid of the old 'cond' just does s (set 'cond if) and everybody is happy.



(3) setq set! (which point to the same function)



yes, I put that in because of speed, and like 'set' they also accept multiple symbol-value pairs. An ex AutoLisper requested this (Peter from .de are you still here?).



Lutz

[HPW]

>(Peter from .de are you still here?).



Sure, and I still like it. I do not miss any release of your great newlisp. And I am lurking here often to see what's happening.