World: r3wp

Is 'dirize/off an option?

Chris, yes, but that would double the code of DIRIZE and add refinement 
checking overhead to every call, so the effect is worse.

Assuming 'dirize asserts a state on a file (dirized or not).

It's one logic check vs. an extra function.

Brian, that is the way I like to see you thinking.

Dirize only works on the file! value, not the file referred to by 
the file! value. It would be adding one logic check plus the entire 
contents of an extra function. The code added would actually be more.

Always think of the impact of a function regardless of size when 
it is done in a large loop.  All of those extra checks add up.

Yup. That's why they have me work on mezzanines :)

hehe

It's also one less function to learn.

Adding an option to a function that changes its behavior makes it 
harder to learn than a seperate function. The only thing you have 
to remember with a new function is the name. You have to do refinement 
processing in your head too, remember :)

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.