World: r3wp

In R2:

>> type? :sine
== native!
>> type? :sine/radians
** Script Error: sine expected value argument of type: number

In R3:

>> type? :sine
== native!
>> type? :sine/radians
== native!
>> do :sine 30
== 0.5
>> do :sine/radians 30
== 0.5			; Wrong result!?

Shouldn't things like :sine/radians just be invalid get-paths?

Think about passing :sine/radians as an argument to a function. So 
when using that argument in the function, the user would expect sine/radians 
to be calculated, but it doesn't, and it will be very difficult to 
implement that feature, if at all possible.

In R2:

>> type? first [:sine/radians]
== path!

in R3:

>> type? first [:sine/radians]
== get-path!

(R2 does not have get-paths)

Think about passing :sine/radians as an argument to a function.
 - you mean like this?

  type? first [:sine/radians]


? As far as I am concerned, I did not expect any additional evaluation

Aha, you probably meant that you did not like

    same? :sine :sine/radians ; == true

You can put that into CureCode as a wish, stating, that you prefer 
an error to be triggered instead

Today's Moment of REBOL Zen:

>> f: func [a op b] [a op b b]
>> f 1 quote / 2              
== 1

>> f: func [a op b] [op a b]  
>> f 1 quote / 2            
== 0.5

Note: That is in R2, where QUOTE word! doesn't work (known limitation). 
On R3, the / is not dereferenced.

Also, in R2 operators are evaluated by DO itself, which has a set 
of keywords that it transforms from operator to prefix function syntax. 
R3 does this swap by value, not by name, so operator renaming is 
possible. However, this leads to behavior like this:
>> f: func [a op b] [a op b b]
>> f 1 get quote / 2
== 2

>> f: func [a op b] [op a b]
>> f 1 get quote / 2
** Script error: op operator is missing an argument
** Where: f
** Near: f 1 get quote / 2


This is why, when you are accepting and calling function values, 
it's best to either limit yourself to the types of functions you 
are expecting, or use APPLY.
>> f: func [a op b] [apply :op [a b]]
>> f 1 get quote / 2
== 0.5
>> f 1 :divide 2
== 0.5

R2 has an APPLY too, in mezzanine but it works the same way. It was 
added for security and function wrappers.

Ladislav, Geomol, that same? :sine :sine/radians bug is already in 
CureCode here: http://issue.cc/r3/1559- please add your comments 
there.

That issue is a really good reason to use ASSERT/type to validate 
your paths.

I see it as a minor issue. I would not be disappointed even if it 
stays as is.

Brian, aha, "Assert": another one of the newer, non-dictionary functions. 
Thanks for pointing those out to me the other day. I now have a list.

It is a potential security hole, but not more of one than assigning 
a function to an object field. It requires the same ASSERT/type call 
to screen for it. Still, it would be nice if it triggered an error 
on evaluation, especially since newbies would benefit from that error 
when they naively try to do a get-path for a function call instead 
of using APPLY or a direct call.

James, ASSERT in R2 is not yet as good as ASSERT in R3. There are 
some limitations, most notably that you can't use ASSERT/type to 
validate a path. A proper native ASSERT is on the top of the list 
to add to R2 in the next version, whenever that comes.

To be frank, it is most likely down the road before I ever use the 
new functions. I can tell just by perusing it that I would need to 
spend some time trying to understand what they do. But thanks for 
the input.

APPLY is a lot more useful in R2 than ASSERT; be sure to take a look 
at that one.

I will. Thanks.

Regarding my UNLESS TAIL? NEXT 'blah thing, perhaps this is more 
elegant:

blah: min next blah back tail blah

hmm... that does a comparison on the first value in the block instead 
of the index. is that useful?

That compares strings, (more general, since you can compare any strings, 
not just parts of the same head string starting at different positions)

yes, you are right.

Today's Moment of REBOL Zen:

>> length? charset ""           
== 256
>> length? to binary! charset ""
== 32

1 byte = 8 bits so 32 * 8 = 256bits:)

Bingo! But why? Does it make sense, that the length of a bitset! 
is reported as being 256? I guess, it does, as we can insert values 
from 0 to 255 into a bitset.

Why isn't the length of a char one?

>> length? #"a"
** Script Error: length? expected series argument


Kinda related: it's funny, that a bitset! isn't a series, even if 
we can ask the length of it:

>> series? charset ""
== false

Or the length of a char could be 8, if we count in bits. But I feel, 
it would make more sense to give the length of a char as being 1.


(I was working on a mezzanine version of string parsing, where skipping 
is much easier, if LENGTH? worked with chars too.)

>> length? make bitset! 1024
== 1024

Wow, didn't see that coming! Now, what does that mean? (Always more 
to learn.)

A bitset is just a collection of N bits which are either set or cleared.

A charset is a 256-element bitset, as R2 recognises 256 distinct 
characters.

I know the benefit of bitsets in parsing. For what use are other 
kinds of bitsets?

Why isn't the length of a char one?


Because characters are no series datatype and therefore it does not 
make much sense to speak or their length.


That's about the same as asking "Why isn't the lenght of an integer 
one?" or "Why isn't the length of a logic! one?"

Nah, I don't fully agree on that. Some code (as my string parse example) 
would benefit, if we could ask the length of a char.

And some code might benefit if we could ask the length of an integer.

:)

http://www.rebol.com/r3/docs/datatypes/bitset.html(for R3)
http://www.rebol.net/wiki/Bitsets(also for R3)

(Bitsets are vastly more useful in R3.)

<Other uses of bitsets>
One use is conformity validation. eg:
    allowed-letters: charset [#"a" - #"e"]
    find allowed-letters "aaadddeeebbb"
    == true
    find allowed-letters "aaadddeeebbbx"
    == none

Yes, but that's the charset kind of bitset. I guess, other kinds 
of bitsets (other lengths than 256) can be used just to hold a bunch 
of flags or something. I haven't seen them used like that.

Bitsets are useful for intexes and certain kinds of parsing (LL first 
and follow sets, not just character sets). Other stuff too.

intexes -> indexes

Geomol, because of Unicode, "charset kind of bitsets" need more than 
256 bits.

But, there are so many other ways to use them. For example, to implement 
a bloom filter: http://en.wikipedia.org/wiki/Bloom_filter

I can imagine length? on char! value in unicode context - it could 
return number of bytes needed to store the char with the utf-8 encoding:) 
But I'm sure I can live without it. It would just add overheat to 
the length! action.

It probably won't add overhead to length?, because that function 
already works with different datatypes, and char! is just another 
one in the switch already there.

Oldes, the char! type in R3 refers to a Unicode codepoint, not a 
character. So, length still doesn't apply.

I want to share with you an "interoperability problem" I encountered. 
In Windows (at least in not too old versions) there are two versions 
of string-handling functions:

- ANSI (in fact using a codepage for latin charset)
- widechar (in fact UNICODE, restricted to 16 bits, I think)


It looks, that Apple OS X "prefers" to use decomposed UNICODE, also 
known as UTF-8MAC, I guess. That means, that it e.g. for a Robert's 
file it generates a filename looking (in a transcription) as follows:

%"Mu^(combining-umlaut)nch.r"

As far as the UNICODE goes, this is canonically equivalent to

%"M^(u-with-umlaut)nch.r"

, but:


- Windows don't consider these file names equivalent, i.e. you can 
have both in one directory

- When using the former, the ANSI versions of Windows system functions 
"translate" the name to: %"Mu^(umlaut)nch.r"

-- the %"Mu^(umlaut)nch.r" is a third file name, distinct from both 
of the above, so, if the R2 reads it in a directory, it is unable 
to open it