Comments on: TRIM Block
Like trim on strings you can now do trim on blocks. But, rather than remove spaces, trim on blocks removes NONEs.
Valid refinements are /all, /head, and /tail, and work as you would expect (same as strings).
Example is:
>> blk: reduce [1 none "test" none 'word]
>> trim/all blk
== [1 "test" word]
This native action is much faster than doing it at mezzaine level.
Perhaps later we can add /with refinement to trim other types of values, or even values by datatype (like trim/with block string! to remove all strings).
7 Comments Comments:
Brian Hawley
5-Apr-2007 20:35:38 |
This seems much faster than REMOVE/EACH. I can definitely use something like this. | Edoc
5-Apr-2007 21:27:40 |
Sweet. | Edoc
5-Apr-2007 21:30:58 |
Sometimes (like after a parse) there are empty strings in the block-- it would be nice if trim could clear those out as well. | Maxim Olivier-Adlhoch
5-Apr-2007 23:39:01 |
Edoc is right, when I read trim on block "" was the first thing I hoped it would clear...
honestly, I don't even remember when I've needed to remove nones, but I have many scenarious with parsing and tokenizing where a block ends up with useless empty strings. | Robert
6-Apr-2007 7:09:14 |
Does a TRIM/SKIP makes sense to be used with HEADER / TAIL? Often blocks are used to store records. | Mario Cassani
6-Apr-2007 14:42:02 |
This will speed things up with files management (riding the 'move wave):
files: read %/path/to/dir/.
trim/with files something_that_means_file_or_dir
Should be really quicker and better than checking the block with 'forall and 'dir?
The problem is that file! means also "dir" and path! is not what's returned by:
type? dirize %/any/path | Brian Hawley
7-Apr-2007 10:39:53 |
Mario, try REMOVE-EACH for that kind of thing. It's a native and you'd be surprised how fast it is already.
files: remove-each x read %/path/to/dir/ [dir? x] |
Post a Comment:
You can post a comment here. Keep it on-topic.
|
