v9 to v10 migration issues

[cormullion]

In version 9:

Code Select Expand

(define-macro (ecase _v)
 (eval (append
   (list 'case _v)
   (map (fn (_i) (set-nth 0 _i (eval (_i 0))))
    (args)))))

(define (test n)
   (ecase n
    ((/ 4 4)     (println "n was 1"))
    ((- 12 10)   (println "n was 2"))))

(set 'n 2)
(println (test n))
;-> n was 2

In version 10, this version, using the recommended replacement form, returns nil:

Code Select Expand

(define-macro (ecase _v)
   (eval (append
     (list 'case _v)
     (map (fn (_i) (setf (_i 0) (eval (_i 0))))
      (args)))))

I think it's because set-nth returns the list but setf doesn't? Or is this an unreferenced list?



I didn't write the original (it's from wayback on these forums)...

[Lutz]

Yes, 'set-nth' returned the list whole list and 'setf' returns whatever the place in the list was set to. There is no reference problem for 'setf' , as the list is anchored in variable _i.



The idea here is to transform a list into a list where the first element is evaluated. The following definition of 'ecase' will work:

Code Select Expand

(define-macro (ecase _v)
 (eval (append
   (list 'case _v)
   (map (fn (_i) (cons (eval (_i 0)) (rest _i)))
    (args)))))

(define (test n)
   (ecase n
    ((/ 4 4)     (println "n was 1"))
    ((- 12 10)   (println "n was 2"))))

(set 'n 2)
(println (test n))
;-> n was 2


[cormullion]

thanks - works fine in 10

[newdep]

Well migrating...



If i would migrate all my script from Pre 10.0 release i will be bussy

for some days ;-)



Lutz, would be nice if you would have a script

(like python has for for 2.6 -> 3) to migrate pre-10 to 10.. ;-)

[cormullion]

Yes, a script would be cool....



One of the things I was hoping to find out with my current project (see recent blog entry blah blah) is whether it's as easy to modify newLISP source code as it is other types of data. It should be possible to search for patterns and then to change them. For example, consider Lutz' latest tweak - swapping the order of the arguments in write-line. First, I can generate an s-expr representation of the source and find the references to write-line:

Code Select Expand

(set 'sx-refs  (ref-all '("symbol" "write-line") sx))

This finds all places in sx that start with write-line. Then with each sx-ref:

Code Select Expand

(set 'w-l (sx (chop sx-ref)))
(swap 3 5 w-l)

which isolates the expression and changes the order of the first and second arguments. (There's whitespace elements at locations 2 and 4...). The output looks hopeful, at least:

Code Select Expand

.../examples/tcltk.lsp
before: (write-line (append ".colorlabel config -background " color) myout)
after:   (write-line myout (append ".colorlabel config -background " color))
../utils/syntax.lsp
before: (write-line lne buff)
after:   (write-line buff lne)


Perhaps I could use set-ref-all... However, at the moment I'm not sure whether this approach will work 100% reliably, and it would only work in cases where simple swapping of functions or arguments are required, not for those changes where you have to recode... So writing a script might ending up being more work than doing all the changes manually... :)

[Kazimir Majorinc]

I think the best guess is to define your own set-nth, and put it into init.lsp.



Automatically replacing (set-nth n L) with (setf (L n)) will work in simple cases but it is hard to write program that can resolve all (*) generated cases

Code Select Expand

(eval (append '(set-nth) expr1 expr2))
((if condition set-nth list) expr1 expr2)
and it cannot work if (**) name of the function itself is generated

Code Select Expand

(set x (sym (append "set" "-" "nth"))
Defining your own set-nth can solve all these problems, but still I can think about problems (***) with code that tries to go "behind" name like

Code Select Expand

(primitive? set-nth)
(reverse (string set-nth))
However, there are few of these, I believe.



For write-line, I think good guess is to write your own function write9-line which does the same as write-line in v9, put it into init.lsp or on the beginning of each old file, and search & replace write-line with write9-line. On that way, you'll solve simple occurences of write-line and problems of the kind (*), but not (**) and (***) and I believe there are few of these.



In both set-nth, you have identifiers to remind you in the case some problems are left.

[cormullion]

Yes, that's probably a safer approach - particularly if your code is rich in that kind of expression. And it's a good way to quickly get code running in later versions.



It might after all be not too difficult to write a script (or add definitions in init.lsp) that re-define missing and modified functions so that unmigrated code runs without error. It would fail on your ** and *** cases, and would also restrict portability. So perhaps the time would be better spent migrating properly...

[cormullion]

Lutz - is newlisp.org running on v9.3/4 or 9.9? If 9.3 or 9.4, how are you planning to migrate the site? I've updated everything on my site locally but don't know if I can upgrade the newlisp version running on the server...

[Lutz]

newlisp.org is still running 9.3, but most of the other demo files on the Tips&Tricks page are running the latest development version, using #!/home/htdocs/cgi-bin/newlisp in those scripts, and a version of newLISP compiled for FreeBSD 6.3. See for example here: http://www.newlisp.org/environment.cgi">http://www.newlisp.org/environment.cgi



Perhaps after the release of 10.0 we can ask the folks at nearlyfreespeech.net to upgrade /usr/local/bin/newlisp to version 10.0



On my MacBook and MacMini I am running always the latest, and have newlisp-wiki and newlisp-ide updated and ready to be posted one of these days. The changes are minimal (some of 'inc' and 'dec').



ps: edited to: /usr/local/bin/newlisp

[cormullion]

OK, thanks. I'll be ready when they upgrade to v10 (which I'll run using "#!/usr/bin/env newlisp" since they don't install it in /usr/bin...).



The Intro doc is also ready to go, if there are no more changes...! :)