My thanks to Don, Jay, and anyone else who is trying out stuff related to
patterns. I am on the road ATM but will work on improving the diagnostics
related to Jay's experiments. Regarding Don's original request and Jay's
comments on it: backquotes in patterns is not a full "eval" interpreter that
will take arbitrary Icon strings and turn them into code. Maybe we need that,
and maybe someone will build it some day. In the meantime, after figuring out
the best workarounds that may be available, you can judge for yourself whether
the patterns are still useful, or whether they remain unfinished business.
The basic question is: given a regular expression supplied as string data s,
how best should we construct a corresponding pattern. The answer sadly is not
<`s`>. The Unicon translator has a parser for regular expressions and emits
pattern function calls for them, but we want to do it from the Unicon VM.
Options include: write a library procedure that parses the regex and builds the
corresponding pattern; write a library procedure that invokes the translator to
do the work and use dynamic loading to get the code loaded; extend the language
with a new built-in that does the same or similar; extend the backquotes
operator to do what we want here; or use another idea that you think up.
Don: great minds think alike. When I started to update the Unicon book to talk
about patterns, I immediately figured we needed to update the "grep" example to
use patterns, and came up against the same issue you're asking about. I
haven't implemented a solution yet, but perhaps we should do option #1 and see
what that looks like.
Cheers,
Clint
________________________________
From: Jay Hammond <homem...@talktalk.net>
Sent: Tuesday, November 29, 2016 1:55:07 PM
To: Don Ward; unicon-group@lists.sourceforge.net
Subject: Re: [Unicon-group] Converting strings to patterns
Hi Don,
I tried running your program.
To get it to do anything I had to change line 2, separate the local declaration
and the assignment.
to clarify, repat is a (new) variable that I intend to hold a pattern
procedure main(args)
local f, line, re
re := pop(args)
write(re)
repat := re
every f := open(!args, "r") do {
while ( line := read(f) ) do {
if line ?? repat then write(line)
}
}
end
I created qqq.txt with the lines
QQQ
qqq
cqcqcq
and ran testpat QQQ qqq.txt after compiling testpat.icn
Output was
QQQ
then the contents of qqq.txt
as if repat always matches. (it has the null value??)
I tried forcing repat to be a pattern (utr18 says that patterns are composed of
strings concatenated or alternated) so I tried
repat := re .| fail()
repat := re .| re
but the pattern building process gave me node errors at compile time.
dopat2.icn:6: # "re": syntax error (237;349)
File dopat2.icn; Line 16 # traverse: undefined node type
line 16 is the line after end in main, i.e. program source end.
I tried using the -f s option at the compile step, so as to use unevaluated
expressions in patterns
like
repat := < `re` >
# that syntax ought to force a pattern!
node traversal errors again. And the backquotes were not recognised. Perhaps I
put the -f s option in the wrong place?
I also tried
repat := < Q > || < Q > || < Q >
dopat2.icn:6: # "repat": invalid argument in augmented assignment
File dopat2.icn; Line 16 # traverse: undefined node type
so it is not considering || to be pattern concatenation
repat := < Q || Q || Q >
gave the same error!
So although UTR18 seems to give options for converting strings to patterns I
have not had any luck so far.
Jay
On 29/11/2016 14:33, Don Ward wrote:
Here is a very simple (and simple minded) grep program. The idea being to apply
a Unicon regexp pattern to a series of files, just like grep
procedure main(args)
local f, line, re := pop(args)
every f := open(!args, "r") do {
every line := !f do {
if line ?? re then write(line)
}
}
end
Of course, it doesn’t work because in line 6 I have a string instead of a
pattern.
Is there any way to convert the contents of re from a string to a pattern?
After reading UTR18 again (and again), I’ve come to the conclusion that there
isn’t any way to do it.
The pertinent extract from UTR18 is in section 4.5.3 "Limitations due to lack
of eval()”.
But before I give up on the idea entirely, I thought I’d check to see if my
understanding is correct.
Don
------------------------------------------------------------------------------
_______________________________________________
Unicon-group mailing list
Unicon-group@lists.sourceforge.net<mailto:Unicon-group@lists.sourceforge.net>
https://lists.sourceforge.net/lists/listinfo/unicon-group
------------------------------------------------------------------------------
_______________________________________________
Unicon-group mailing list
Unicon-group@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/unicon-group
