Hi,
Your observation was reported to feedback by me before and it has
been assigned ticket #2409.
OTOH, if you check the code more thoroughly, URL! never changes to
File!.
Regards,
Ladislav
>
> Hi folks,
>
> I was just playing around with Ladislav's fix of SPLIT-PATH. I
was
> wondering why he converted the argument values to strings, since
this
> has the disadvantage that if the argument is a URL the result
will
> eventually get changed to a file.
>
> Then I noticed something really weird:
>
> >> path: file: %dir/file.ext
> == %dir/file.ext
> >> parse path [any [#"/" file: | skip]]
> == true
> >> file
> == "file.ext"
> >> insert path "parent/"
> == %dir/file.ext
> >> path
> == %parent/dir/file.ext
> >> head file
> == "parent/dir/file.ext"
>
> Even though we're parsing a file! , any pointer set within the
parse
> rule becomes a string! , and yet it's still pointing to the same
> underlying data. It can't, however, be used as an index with
COPY/PARSE:
>
> >> parse path [any [#"/" file: | skip]]
> == true
> >> copy/part path file
> ** Script Error: Invalid /part count: file.ext.
> ** Where: copy/part path file
>
> I never realized that you could view the same data with two
different
> datatypes. Is this intended? I think it would be much better to
have
> get-words in parse rules use the type of the data being parsed.
>
>
> BTW, I agree with Andrew that this behavior of SPLIT-PATH is
better
> than Ladislav's fix (unless READ is also fixed to read the
current
> directory for %""):
>
> >> split-path %file.ext
> == [%./ "file.ext"]
> >> read first split-path %file.ext
> == [%USER.R %TALK.R %rebol.r %REBOL.exe ...
>
> >> sp %file.ext ; Ladislav's version
> == [% %file.ext]
> >> read first sp %file.ext
> ** Access Error: Cannot open /C/prog/rebol/.
> ** Where: read first sp %file.ext
>
> See you,
> Eric
>
>
>
