World: r3wp

But what is the proper representation of a hex value in REBOL? An 
issue? An ENBASEd string?

it's an issue

why not write a converter and then
  skip bin &h #c4d9

Ah, but an issue is really a string, not a number. The TO-HEX function 
makes it look like this is the recommended approach (it's what I 
would say, too), but I think it's a type mismatch (unfortunately).

I see

That is, I don't think standard functions should take issue! params 
for hex values unless RT says, officially, that it's how you do hex 
values in REBOL.

Is hex notation something we should propose for R3? I'd bet money 
Carl thought about it long and hard in the original design, and may 
even have left some lexical wiggle-room to add it later.

propose = request.

well, I can understand it if there is no official way to represent 
hex values. I think it should be proposed for R3

Its nearly never needed, but if it is needed, its very usefull.

hex-editor or ascii or decoding this unix-rights-numbers or such.

REBOL is very high level, and you tend to use hex notation more in 
low level scenarios, but it's *so* handy to have it there when you 
need it.

yess the kind of thing you need when you are doing projects and the 
specs are not your own.  on the other hand, HTTP 1.1 uses hex values 
for chunk sizes (stupid design if there is one)... so they are still 
used.

Here's what I use:

    hex: func [
        {Returns the base-10 value of a hexadecimal number.}
        value [integer! string! issue!] "A hexadecimal number"
    ][

        ; Convert to an issue first, so integers can also be translated.
        to integer! to issue! value
    ]

When I first started in REBOL, I also aliased it as &H (as a func 
name), since that's the hex notation prefix in BASIC and can be used 
as a func name, unlike "0x"

It is a little extra work to use a func to convert values, but not 
awful. If you need to use it heavily in a particular app, I'd consider 
using a dialect.

binary tools powerpack then?

You bet. Outline the domain and we can cook up a killer dialect.

the problem I have with dialects is they are not extensible

it would be worthy of its own group, wouldn't it?

I think so Henrik, for better focus.

I'll create it now

I mean without rewriting the original dialect parser itself.

Who says Max?

OT: regarding dialects: could 'any be an option in parse? i often 
have
 parse blk [ any[  .. ] ]
would like 
  parse/any blk [ .. ]

when I tried to plug within VID... man it was awfull.

I ended having to piggy back on top of VID.

The Logo interpreter I did (early in REBOL for me) allowed user defined 
functions; basically it just added things to the list of parse rules 
it knew about, naive, but semi-functional. :-)

it predates the block-parser, and that shows.

and that means actually calling the VID parser many many times...

rebgui looks much cleaner IMHO.

Dialects have to be planned for extensibility, just like languages.

gregg, exactly... you have to dialect your dialect's  dialecting 
ability  ;-)

ANY - Not sure what you mean Volker.

but that's usually harder than the dialect itself, and there are 
no ways to ensure that this door, won't corrupt your dialect itself..

group created, lets move binary stuff to there

i need two nested blocks. nearly everytime i use 'parse.

i.e. why would a refinement be better than using PARSEs ANY keyword?

Ahhhh.

Would it always return TRUE if /any is used then?

I will try to re-introduce the previous block parsing engine I had 
built for glass into the newer code.

And that are often 3-liner, which are then 5-liner
parse/any files[
  file!(..) | url! (..)
]

that dialect (not parse based) could easily implement OOP style polymorphism 
within the dialect!

No, only 'true if the whole rule matches.

I think that might be confusing, because ANY in a parse rule implies 
optionality.

although an error would be nice too, if it does not
  parse/error blk [..]

would throw an error on fail. maybe with hints about the position.

In my use 'any means loop

How about just using a PARSE-ANY wrapper mezz of your own?

Ugly. parse/any looks nicer. And its a bit slower? But does the job.

and its an extra definition in every short script (i never use %user.r 
for libs..)