development release version 9.0.18
development release version 9.0.18
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/
Lutz
ps: was a few hours before released as 9.0.17, 9.0.18 contains a bug fix for (pop <string> <idx>)
files and changes notes here: 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>)
-
- Posts: 2038
- Joined: Tue Nov 29, 2005 8:28 pm
- Location: latiitude 50N longitude 3W
- Contact:
Nice additions, Lutz!
I'm trying to get the new functionality working with strings. This seems to work:
but for some reason I have to 'eval' the string. Is this how it works?
I'm trying to get the new functionality working with strings. This seems to work:
Code: Select all
(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?)
The syntax form of find:
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:
and instead only permit:
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':
In that case than you could just say:
because you can use > for string-length comparison:
Lutz
Code: Select all
(form <string> <list> [<regex>])
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 all
(form <string> <list> [<regex>])
Code: Select all
(form <string> <list> [<comparison>])
We would than have 2 easier distinguishable syntax forms or 'find':
Code: Select all
(find <exp> <list> [<func>])
;and
(find <string> <string> [<regex>])
Code: Select all
(find animal list longer?)
;or just
(find animal list >)
Code: Select all
(> "tiger" "dog") => true
-
- Posts: 2038
- Joined: Tue Nov 29, 2005 8:28 pm
- Location: latiitude 50N longitude 3W
- Contact:
Interesting. So I could no longer write this:
What would I write instead...?
Code: Select all
(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))
You would write:
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:
But then it would return the character position and not the word position, as in your example.
Lutz
Code: Select all
(set 'loc (find "(tea|cocaine|morphine|tobacco)" sign-of-four
(fn (x y) (regex x y)) )
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 all
(set 'loc (find "(tea|cocaine|morphine|tobacco)"
(read-file "/Users/me/Sherlock-Holmes/sign-of-four.txt") 0) )
Lutz
-
- Posts: 2038
- Joined: Tue Nov 29, 2005 8:28 pm
- Location: latiitude 50N longitude 3W
- Contact:
Hmm. Tough call.Lutz wrote: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.
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...).
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:
Lutz
ps: I will rearrange the documentation for 'find' to make this case appear less confusing
Code: Select all
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
>
ps: I will rearrange the documentation for 'find' to make this case appear less confusing
-
- Posts: 2038
- Joined: Tue Nov 29, 2005 8:28 pm
- Location: latiitude 50N longitude 3W
- Contact: