Comments on: FIND/in - a pattern I use a lot
I often store records as blocks. The blocks follow a standard format. For example, if you look at the R3 chat message file, you will see such a format.
So, this common code pattern appears a lot. I often use it for finding a user in a user database:
foreach user users [ ; or similar FORALL loop
if user/3 = name [return user]
You will recognize this as a linear search. I use it in cases where its not worth building a hash (map!) on the target field, normally because it's rarely needed, or the database is small.
It's time to abstract this type of search. The key elements are:
- Search block of blocks
- A specific field of each
- That equals a given value
So, it could be something like:
user: find/in users 3 name
And user is probably the index into the users block, allowing us to do things like:
remove find/in users 3 name
The method could be extended to blocks of objects:
rec: find/in objects word value
The same as:
foreach obj objects [ ; or similar FORALL loop
if obj/:word = value [return obj]
This is one of those cases where you begin to ask, is this more of a native or a mezzanine function?
Of course, another approach would be to add a function that is a bit similar to an SQL select, but it's also more work, and I'm not sure how much use it would get.
Let me know your thoughts.
Hello. Here's my feedback.
I am not sure find/in does not mess with 'find for very specific purpose, which I am not sure is related to a search?
What is currently close to above described functionality is 'forskip, no? There you specify kind of record type (rows - block) of data you want to skip.
Other not much used concept is - we established remove-each native, which is pretty fast, has a dialect. Some time ago I thought about its counterparts - change-each, extract-each, etc.
If you do this as a FIND option, you might consider that you are getting the value and accessor arguments reversed. The value is what you are searching for (name), while the /in argument (the accessor spec) is an additional option. So the call would be:
user: find/in users name 3
The option name seems weird. Aren't you always finding something in the data? Perhaps /at might be better.
This seems related to the FORFIND and GATHER proposals. GATHER would be like FIND/in/all, returning a block of all values found. FORFIND (your suggestion, Carl) would be like FORSKIP, but the skip is a FIND rather than a fixed value.
FORFIND has been waiting for some equivalent of the [throw] attribute to be added to R3 - until then mezzanine loop functions that do block arguments are a bad idea.
You might consider that the name for the comparable option to EXTRACT is /index.|
To my this looks more like a FIND/DEEP way of seaching. You search through "block OF blocks", "block OF objects" etc.
Overall a good pattern to add.
I could really use a similar pattern for string parsing: PARSE strings in a block.|
... ah, my first message misses why I mentioned remove-each, change-each - I wanted to propose find-each - it could have its dialect as well as remove-each has, and sort function has ...|
I generally prefer mezzanines over natives, as long as the performance isn't magnitudes different. And if it is, that's a hint about what natives might be useful for writing better mezzanines. That is, rather than hiding more functionality in natives, provide the natives I need to write killer mezzanines.
If you distill transformation and filtering functionality, what natives do you really need, that you can build everything else on? What would Lisp do? :)
I reiterate that sentiment--which I've stated before--because this is a good example of "I want something different". That is, Carl's proposal is to use ordinal values for block searches, but allow words for objects.
I don't want to be limited to index values on blocks. I generally avoid using blocks of values that are referenced by position because 1) the data isn't self-describing, 2) it's more fragile, and 3) user/3 just isn't meaningful. I don't like dealing with code I wrote that does it, and I *really* don't like dealing with code someone else wrote that does it.
Post a Comment:
You can post a comment here. Keep it on-topic.