Re: [Jscheme-devel] string.scm from MIT Scheme 7.7.1

[Ken A. <kan...@bb...>]

At 09:15 PM 1/14/2003, Geoffrey Knauth wrote:
>On Tuesday, Jan 14, 2003, at 20:54 US/Eastern, Ken Anderson wrote:
>>While Scheme's built in string handling is minimal, did you do this to be portable among Scheme's or because JScheme's Scheme + Java did not provide what you wanted?
>
>I confess I did not have a concrete plan, I was just mucking around.  I had a "/path/to/a/FILE.ext", and I had to pull out just the "FILE" part [1], and I thought, gee, I bet MIT Scheme has string stuff I could use.

If you already have the file, f, you can get the FILE part by doing something like:
(.substring (.getName f) 0 (- (.length (.getName f)) (.length ".ext")))
or
(car (crack (.getName f) ".")) which is shorter but does a bit more work.

See using/run.scm for examples of file hacking.

>Well, it worked, but after I did it, I realized I probably had to pull over more MIT Scheme than I strictly needed, and Java has String search/index functions already, and I could have done it that way.  In fact, over lunch today I was telling a colleague I should time my FILE extraction with the code I've got, and compare it against doing it with Java String methods.

This would be interesting to profile.  I've found that if JScheme is used as a wrapper around Java, the performance difference is pretty low.  For example, JScheme is well suited for GUI layout, system bulding, or JDK 1.4 regular expression manipulation.


>Geoffrey
>
>[1] (I have other JScheme routines that return the nnn number given a demand stream's name, which you get by first looking up the filename given an MInvocID, for ICIS JChem.)