dockimbel on interp-events
FEAT: more accurate input block… (compare)
>> to block! to string! %/z/f/e/ == ["/z/f/e/"]
>> make block! %/z/f/e/ *** Script Error: cannot MAKE block! from: %/z/f/e/ >> to block! to string! %/z/f%20f/e/ *** Syntax Error: (line 1) invalid path at f/e/ >> split %/z/f/e/ [before #"/"] *** Script Error: split does not allow block! for its dlm argument
[%/ %z/ %f/ %e/]instead of
[%/z %/f %/e %/]or
[%"" %z %f %e ""]
splitand to be honest, it's quite a complex script. Anyway.. I don't need to split files in such a way, so it's not a big issue for me. I would probably use some easy parse rule to count the number of file parts or use simple
split file #"/"and handle the edge cases.
count-file-parts: function[f [file!]][ n: 0 ch: complement charset #"/" parse f [opt #"/" any [some ch opt #"/" (n: n + 1)]] n ] count-file-parts %/z/f/e/ ;== 3 count-file-parts %z/f/e/ ;== 3 count-file-parts %z/f/e ;== 3
@Oldes my experiment is intentionally large in scope. Why do you care if it's complex? One of the goals with it is to have, e.g., @hiiamboris post an example that gives you exactly what you wanted, and that the intent is clear.
In the domain of splitting things into pieces, are we better off with a module that covers 98% of use cases, or a simple function that covers 50%, and having users write custom splitters for the other 50%, with all the edge cases, where more things can go wrong? That's something I hope to find out.
query. Where I could do:
>> query/mode url 'scheme == http >> query/mode url [scheme host] == [http "foo.cz"] >> query/mode url [scheme: host:] == [scheme: http host: "foo.cz"]
Why to have multiple string types when every type would have same meaning.
They do have different meaning, as their original type. So let's ask what happens if we do this.
Block! now has to understand the lexical form of
any-string! types, which couples it to those forms internally.
For each type, we have to decide what the constituent parts become. For
file!, all results can be
email!, should they all become strings? URLs? Does it handle path seps intelligently when round-tripping? Can all values round-trip? (side note: Ladislav did some great work on
split-path + rejoin, with round-tripping as a consideration.)
>> to url! ["http://" "a" "b/" "c"] == http://://a/b//c
Identifying use cases helps here, so we can see where gaps are that have real value.
I'm 100% behind writing these things down and analyzing it. These are important docs in any case.
query, so kind of like GQL @Oldes?
vet <spec>so you can confirm if data conforms to a given spec.
viewtoday, for dev mode work.
There are many aspects to modules. We do want people to be able to build, share, and use them, and for them to be bundled together. It should be possible for someone to group modules, put a consistent interface over them, and release that. Ideally, there is a package and organization system that supports this, and also an optional blockchain aspect for verification and tokenomics.
There are ways to hack around platform issues, but security is perhaps the most important element in all this.
To @hiiamboris' point, sometimes you won't even have access to a module's source, but I don't have a unified design for modules vs shared libraries.
My view is that filenames are strings, and conversion to block should treat them as such consistently. If we give them special treatment, then we should next ask what to do with URLs, and then emails and tags.
>> p: to-path "x/y/z" == x/y/z >> type? p == path! >> length? p == 1 >> length? 'x/y/z == 3