World: r3wp

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:

probably you have to modify do-request.
save %do-req.r mold do-request
edit in do.req.r the line 
User-Agent: "REBOL"
to whatever you desire, add the rebol [] header and do the file.

sorry 
save %do-req.r mold :do-request

hum, or you can pass a header block to the write function as is:
>> write [ url!  [ User-Agent: "TOTO" ... ]  #{...data...}]

but it's bugy, you have to add yourself some missing header properties 
in the block to generate a valid request.

like Content-Type: "application/x-www-form-urlencoded; charset=utf-8"

I liked list and hash and did use them a lot.  List was was buggy 
though.

eh ? bug in list ?

Yes, I reported it some time back.

http://www.rebol.net/cgi-bin/rambo.r?id=4314&

Because of list being buggy sort was modified so that it doesn't 
use list.

bah... not so painfull

it's a little incoherent to use sort on lists

it was slower than using blocks

there is someone using list!? I wonder if there is any advantage 
of list! over hash! and block!

No lists are faster than blocks for inserting data.

lists are fast with insertion and deletion, i use them sometimes

Oldes, yes there is an advantage to each.  Lists are faster for inserting 
and traversal.  Hash is faster for find operations.

by the way, some times ago, i made an algorhitm to simulate hash 
with blocks, it's quite fast and use much less memory than hash.

But it works only with integers key. i could search for it if someone 
is interested...