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).
>> 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).
This seems much faster than REMOVE/EACH. I can definitely use something like this.|
Sometimes (like after a parse) there are empty strings in the block-- it would be nice if trim could clear those out as well.|
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.
Does a TRIM/SKIP makes sense to be used with HEADER / TAIL? Often blocks are used to store records.|
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
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.