This is the mail archive of the guile@cygnus.com mailing list for the guile project.
Index Nav: | [Date Index] [Subject Index] [Author Index] [Thread Index] | |
---|---|---|
Message Nav: | [Date Prev] [Date Next] | [Thread Prev] [Thread Next] |
| Recently I had cause to use the `expect' module. It is pretty | convenient, but I noticed a couple things I don't like or don't | understand. | | First, since it works on a per-character basis, it is very slow (I | attribute this slowness to expect.scm and not Guile, but I admit I | haven't run any tests). In my case, I know I want to operate only on | entire lines. It would be nice if there were an `expect' option to | enable this. True. I had a vague idea of rewriting part of it in C. Adding a per-line mode may be a good idea too. Perhaps implementing expect-strings directly instead of as a front-end to a more general expect would help. At least once the basic design seems to be correct. One thing that's a bit dubious is the way the parameters are set outside the body of the form. Using keywords instead would make it more regular. The disadvantage is extra verbosity if several expect forms need the same args. | | Second, I don't understand the usage of `$' in regular expressions | here. Or, rather, I think I understand it, but I don't like it. The | manual implies that $ will match newlines. In reality it matches the | end of any string -- rendering it useless for my purposes. The | appended program demonstrates the problem: the regex is matched | individually for each character of /etc/passwd. This behavior | suprised me; I think it would be more natural if a `$' in an expect | regex matched only a newline. (In this case it might be possible for | expect-strings to automatically notice when line-by-line mode could be | entered. (But an explicit flag is good enough for me.)) That wasn't the way it was supposed to work. I intended $ to match only a newline or end of file, since that's the usual interpretion in the context of multi-line text (where expect is most likely to be used?) Fixing $ would take some rewriting. I guess expect-strings would need to set up a more complex matching function which uses look-ahead to decide whether to call the regexp matcher with regexps that contain unquoted $.