World: r3wp

It's easy to learn simple functions, but hard to learn complex ones.

Of course it takes a lot of work to make a function simple to learn 
and use.

dirize: func [file [file! url!] /off][
	file: back tail file
	either file = %/ [
		all [off remove file]
	][
		any [off append file %/]
	]
	head file
]

I guess it's a bit wordy.

You forgot the copy, but that is a good alternative.

It's slower (one more compare). We'll have to see which one is chosen.

It also shifts the index twice, whether the function needs it or 
not.

Three times, sorry : )

The one compare is dwarfed by the copy overhead though. Shifting 
the index only has significant overhead for ports, not series.

The list! type is gone from R3, and that was the only type with index 
overhead.

dirize: func [file [file! url!] /off /local l][
	l: last file
	either l = #"/" [
		all [off remove back tail file]
	][
		any [off append file %/]
	]
	file
]
that should be a little bit faster

; Might also be faster than mine:

dirize: func [file [file! url!] /off][
	file: back tail file
	all [
		file = %/ = off
		either off [remove file][append file %/]
	]
	head file
]

(again, no copy)

Hmm, maybe not.

The pitfalls of none vs. false.

dirize: func [file [file! url!] /off ][
	file: copy file
	either #"/" = last file [
		all [off remove back tail file]
	][
		any [off append file %/]
	]
	file
]

dirize: func [file [url! file!] /off][

    head remove back tail make file either off [file][compose [(file) 
    "/"]]
]

dirize: func [file [url! file!] /off][

    to type? file head remove back tail make file! either off [file][compose 
    [(file) "/"]]
]

still a bit buggy but throwing it out there to play with.

dirize: func [file [url! file!] /off][

    to type? file head remove back tail make file! either all [off #"/" 
    = last file][file][compose [(file) "/"]]
]

Eh.. I prefer BrianH's separate UNDIRIZE (or FILEILZE) function than 
this /OFF refinement.

I agree with Anton. IMHO, one should not build refinements that invert 
the behavior of a function. Refinements should extend a function's 
existing behavior, similar to what COPY vs. COPY/DEEP does.

in that light ...  does this solve >>exists? ; exists?/dir ; exists?/file 
exists?/...<< does this solve that problem too? >>- Using both DIR? 
and EXISTS? means two QUERY calls, which has overhead, particularly 
for networked files.<<

that's where I would use separate functions for each operation. no 
need for multiple queries or curious refinements.

maybe I understood Brian wrong.. I thought in current situatuion 
you need to call exists? somepath and dir? somepath to know that 
something exists and is a directory (which also means two query calls 
I suppose)

will R3 have a way to define custom infix words?

Janko, yes, the current situation is exactly that; to know that a 
directory exists, you need to call exists? and dir?, which causes 
two QUERY calls.

Re: /off - it's not that different from 'trace or 'new-line.  It 
switches a mode, albeit using a refinement instead of a value.

Dirized is a state that 'dirize alters.

In R2, there are only two 'un verbs: 'unset and 'unprotect.  'undirize 
seems contrived (yep, dirize is contrived too, but necessary for 
a state that has no other name).

R2 Core, that is...

Fair point about new-line. But does 'undirize seem more contrived 
than 'dirize/off ? The prior seems more like English to me, the second 
is more "implementationish". I understand the desire to prevent another 
word in the global namespace, but I don't think 'undirize is going 
to collide with anything a user is likely to want to use .. !

Could also be that 'dirize has a permanent second logic! arg. It's 
not so much about namespace as language space.

dirize file on dirize file off

This is a particular case.  I can see the useful ness from a mezzanine 
standpoint of having a function that does both add the "/" and subtracts 
the "/".  Because in the case of looping we can easily homegrow our 
own need there that would be more efficient.  But I agree the name 
of dirize is not so elegant.

There's a big difference between an inverting refinment and a logic! 
parameter: default behavior. 


I'm all for a better name. Even better than that, a convention. Adding 
"ize" (dirize) or "ify" (blockify) isn't a great solution, but there 
is some basis for them (compartmentalize, normalize, scarify, terrify). 


TO-* and AS-* have specific meanings, and are core funcs. What should 
the standard derivation be for this kind of behavior?

Including antonyms (for lack of a better term).

Janko: "will R3 have a way to define custom infix words?" To my knowledge, 
no.

As for the two query calls, look at the revised EXISTS? functions 
I posted above.

My original name for undirize was fileize, but that seemed even more 
contrived. The only advantage "undirize" has is that if you know 
what dirize does, it's not difficult to figure out what undirize 
does. The dirize function is only still called that for historical 
reasons, but we are trying to not just change the names of functions 
that act the same as R2 unless there is a really good reason for 
it. We prefer to only break compatibility for semantic reasons, not 
naming.

That said, I would like to have the BIND? function also assigned 
to the word BOUND? by default, or perhaps BINDING? or CONTEXT? given 
its behavior. Just a preference.

What is R3 replacement for List! is it Map! or Vector! ?

Neither - it's just gone.

The block-like types that aren't block-like enough to be bound are 
gone. Map! is not block-like, it acts more like object.

Vector! is more like a typed array. There is nothing in R3 like list! 
or hash!.

It was found that they were not useful or even used enough to be 
included.

Most uses of hash! are replaced by map!, the rest by block!. The 
only use of list! that couldn't be done with block! was found to 
be so obscure that no code was found that used that technique.

I found hash! a very useful datatype, I still don't get why it has 
to be removed. Map! looks less flexible because you have to conform 
to the key/value data model and it doesn't seem possible to navigate 
in a map! like in a hash!. Why can't we have both hash! and map! 
in R3?

Maybe would help to add indexing to Map! ie reverse value -> key 
?

Exists a way to change user-agent with R3-alpha? I try system/schemes/http/user-agent: 
"Mozilla/4.0" but I get ** Script error: cannot access user-agent 
in path system/schemes/http/user-agent: