development release version 9.0.18

[Lutz]

Now list pattern searches and replacements as powerful as regular expression string searches and replaces can be performed in just one statement. The functions 'find', 'ref', 'ref-all' and 'replace' now all can take a custom comparison function as an optional parameter. Search pattersn can be nested list expressions when using 'match' or the more powerful PROLOG like 'unify' as comparison function.



files and changes notes here: http://newlisp.org/downloads/development/">http://newlisp.org/downloads/development/



Lutz



ps: was a few hours before released as 9.0.17, 9.0.18 contains a bug fix for (pop <string> <idx>)

[Lutz]

... the Win32 installer for 9.0.18 has been uploaded and newlisp-9.0.18.tgz was repackaged after removing some files.



Lutz

[cormullion]

Nice additions, Lutz!



I'm trying to get the new functionality working with strings. This seems to work:

Code Select Expand


(set 'lst '("elephant" "antelope" "giraffe"
 "dog" "cat" "lion" "shark" ))

(define (longer? x y)
  (set 'x (eval x))
  (> (length x) (length y)))

(set 'animal "tiger")

(find 'animal lst longer?)


but for some reason I have to 'eval' the string. Is this how it works?

[Lutz]

The syntax form of find:

Code Select Expand

(form <string> <list> [<regex>])

is not suitable for the new feature because when 'find' sees that you are seraching a string in a list of strings it will expect an regular expression option not the optional comparison function (see the last syntax of 'find' in the manual).



Passing the symbol 'animal,  you trick it into the other syntax form where it will accept a comparison functor.



I suggest we eliminate/change the 4th syntax form:

Code Select Expand

(form <string> <list> [<regex>])

and instead only permit:

Code Select Expand

(form <string> <list> [<comparison>])

this way we don't have the ambiguity and still can use regular expressions in the comparison functor. Of course this will not effect the very much used (find <string> <string>) form at all.



We would than have 2 easier distinguishable syntax forms or 'find':

Code Select Expand

(find <exp> <list> [<func>])
;and
(find <string> <string> [<regex>])

In that case than you could just say:

Code Select Expand

(find animal list longer?)
;or just
(find animal list >)


because you can use > for string-length comparison:

Code Select Expand

(> "tiger" "dog") => true

Lutz

[cormullion]

Interesting. So I could no longer write this:

Code Select Expand


(set 'sign-of-four (parse (read-file "/Users/me/Sherlock-Holmes/sign-of-four.txt") {W} 0))

(set 'loc (find "(tea|cocaine|morphine|tobacco)" sign-of-four 0))


What would I write instead...?

[Lutz]

You would write:

Code Select Expand

(set 'loc (find "(tea|cocaine|morphine|tobacco)" sign-of-four
                    (fn (x y) (regex x y)) )

x would get the value of (tea|...) pattern and y would succesively get the value of the words parsed out in the book.



So in list searches the option would always have to be a functor/function. The above is slightly longer but removes the ambiguity in the syntax.



Of course you could also still do:

Code Select Expand

(set 'loc (find "(tea|cocaine|morphine|tobacco)"
     (read-file "/Users/me/Sherlock-Holmes/sign-of-four.txt") 0) )

But then it would return the character position and not the word position, as in your example.



Lutz

[cormullion]

So in list searches the option would always have to be a functor/function. The above is slightly longer but removes the ambiguity in the syntax.

Hmm. Tough call.



I found my example using a quick search - I wouldn't be surprised if other people have used the same construction a lot. It extends naturally from the non-regex case...



On balance I'd vote for not changing basic syntax. Not with all that code out there in the field! Perhaps the (find 'animal lst longer?) syntax is acceptable because the more powerful form is slightly harder to use (and hence limits itself to the more advanced user...).

[Lutz]

Good news, we can have both! newLISP can switch on the type of the option argument. If the option is a number do the regex stuff. If the option is a functor or function than do the new functor stuff:

Code Select Expand

newLISP v.9.0.19 on OSX UTF-8, execute 'newlisp -h' for more info.

> (find "newlisp" '("Perl" "Python" "newLISP") 1) ;
2
> (find "newlisp" '("Perl" "Python" "newLISP") (fn (x y) (regex x y 1)))
2
>


Lutz



ps: I will rearrange the documentation for 'find' to make this case appear less confusing

[cormullion]

Good news, we can have both!

Excellent! If you put some string examples in the docs, that would be cool. :-)