World: r3wp

my implementation of PIPE is only a few lines. i think it should 
be native to R3.

my lower level is working like this

write port [ RETR "bigfile" %bigfile ]

how does switch on type? work?

switch type? %test.r [ .... ]

what do I need to write in the block to catch it ?

Gab, you should pipe up with the source to pipe :)

Graham:
>> switch type?/word 1 [integer! [print "ahoj"]]
== ahoj

Graham, weird, but you can try:

>> switch to-word type? %test.r [file! [print "... a file"]]
... a file

so return of 'type? is not a type? Well, we have not a datatype type? 
Yes, we have - datatype! .... but help reveals you can't do "to-datatype" 
...

Also this works:

>> switch type? 1 reduce [integer! [print "ahoj"]]
== 
ahoj

type?/word is here for that

Pekr, return of type? is datatype!! but the datatype in the switch 
block is just word!, not datatype! .

So you need word! from type! or reduce the seitch block to get datatype! 
instead of word! .

why is datatype a word? :-)

Hmm, you are right:

>> type? file!
== datatype!

>> type? first [file!]
== word!

because the block is not evaulated

>> type? first reduce [word!]

== datatype!

It may look confusing, but it makes perfect sense, it same as:

>> a: 1                 

== 1


>> type? first [a]       

== word!

>> type? first reduce [a]
== integer!

Graham: Binary is the default for read & write in R3. The documentation 
doesn't seem to have been fully updated for R3 yet,

Rebolek - then switch should be supplied a reduced block :-)

We are not talking about block here, but a function body. And if 
I write switch type? %user.r [file! [print "... a file"]] ... it 
is imo supposed to work ...

...switch should be supplied a reduced block

no, that's wrong. See:

>> a: 1
== 1
>> switch 'a [a ["ok"]]
== "ok"


>> switch 'a reduce [a ["ok"]]

== none

>> a: 1
== 1
>> switch a reduce [a ["ok"]]
== "ok"

how is novice supposed to know, that actually submitting result of 
type? %user.r is not going to work with file! datatype in a switch 
body?

no need for reducing
  type? first [#[datatype! file!]]

By reading manual probably

file! in the switch body is not datatype! but word! Understanding 
this will help to better understand how REBOL works.

Pekr, an old Reboler like you...

:)

the idiom [switch type? /word [...]] is used in such lot of places 
in mezz functions.
You should be well aware of that now ;-)

including R2-forward.r , 14 occurences in R2
8 occurences in R3

Steeve - I don't care. type?/word looks awfull ...

The reason why /word has to be introduced is imo because exactly 
'switch is not able to handle datytype directly in its body, and 
that is what I am pointing out ...

uhuh

Help string to 'switch does not reveal much. And docs are imo even 
incorrect:


Switch also returns the value of the block it executes. The cases 
can be any datatype. If none of the other cases match, use the /DEFAULT 
refinement to specify a default case.

If the case can be ANY datatype, and it works with xy datatypes, 
there is no point into turning datatype! dtype into word first, no?

http://www.rebol.com/r3/docs/functions/switch.html.... or someone 
should correct docs so that this special case is more obvious ...

i don't see anything wrong in the definition, but yeah, we could 
add some use cases

The cases can be any datatype

 - is imo wrong, as it is not obviously true. You can't use datatype! 
 type for the case. You have to convert it to word! type ...

It might be usefull to add idiom like you mentioned to the end of 
examples? Now I at least know, what type?/word exists ...

Or maybe a new mezz would be good to have.

Krenzelokize: func [bum this [block!]][
	switch type?/word bum this
]

It was Graham who actually asked, how is he supposed to handle datatype! 
datatype in 'switch function. If he was confused for a fraction of 
minute, then novices could be confused too. The function behaviour 
is inconsistent, at least in reference to docs, period. Even if I 
never used type?/word (as I don't work with dynamic code much), I 
used to-word type? value in 20 seconds, so I found may way around 
the "problem". 


Maybe now I understand, why some external ppl see REBOL community 
as bunch of "we are best, we know the best" luxury fools - we try 
to make idiots from ppl not actually as knowleable as some elite 
members.

Pekr my friend, it was just a little tease :-)

Pekr, you may be right about correcting docs, I'm not sure, haven't 
read them in a while. But in all other aspects you are wrong. What 
you want is basically same as what that crazy spammer on blog wanted 
few weeks ago. Blocks always reduced.

And that's wrong. And if people don't get it, they're free to use 
some other language.

I surely don't want all blocks being reduced. I think I know what 
you are talking about. But then let's stop claiming 'switch can accept 
any datatype for the case branching. It can't ...

But - was switch always native?

It is difficult for me to explain, but - I thought, that 'switch 
case block could be treaded some other way internally. Not reduced, 
but in kind of  "DELECT" or dialect kind of type. Then you could 
really write any datatype for the case ..... not sure it is doable 
nor neccessary, just thinking aloud ...

What you want is that words that get evaluated to datatype! should 
be evaluated but other words shouldn't. That's inconsistent and for 
everyone trying REBOL is better to understand the difference between 
word! and it's value than otherwise.

I agree that it may look confusing to some people, same as:

>> f: func [a][append [] a]       

>> f 1
== [1]


>> f 2

== [1 2]


But as I said, it's better to understand why works this way than 
dumbening the language just because newbies may be confused.

no, you don't understand. It is just you understanding the only one 
holy way - submitting function a regular REBOL code :-) Whereas I 
was just wondering, with rather uniform design of switch (case followed 
by code to execute), if we could supply kind of dialect to switch 
function as a body. The same way as how we have 'secure, 'get-modes 
or other dialects ...