World: r3wp

none uses Knuths definition

 - you should try to comprehend. None of the functions you mentioned 
 uses the Knuths definition.

In case you again try to misunderstand, then it is "none of the Rebol 
functions you mention"

And, moreover, you can easily redefine the MOD and MODULO, since 
they are mezzanines

Ladislav: I misunderstood it too as "no fucking body is using knuths 
definition"

s/is using/uses/

come on. If a function does not use a definition, then you cannot 
claim the function has a bug when differing from the definition in 
question.

Oh, sorry. None of the REBOL functions use Knuth's definition. Got 
it. :)

Due to specifics in REBOL arithmetic it was deemed desirable to remain 
compatible with some of them when defining more arithmetic functions

In essence, the MOD function is a "helper" for ROUND. It uses the 
Boute's definition, but assuming that the divisor is positive. If 
you do want to use a more comfortable variant, you can use the MODULO 
function, which does not make such an assumption.

Still, there are arithmetic specifics, regarding rounding.

A bug?

>> cur: what-dir

== %/Users/peter/

>> cd %Code/Rebol

== %/Users/peter/Code/Rebol/
>> cd cur

** Access Error: Cannot open /Users/peter/Code/Rebol/cur/

** Near: change-dir to-file path

>> change-dir cur

== %/Users/peter/
Though this works:

>> cd :cur
== %/Users/peter/

>> ? cd 
USAGE:
    CD 'dir


Notice the non-evaluated Literal Argument. So when you use CD, the 
argument isn't looked up.

>> ? change-dir
USAGE:
    CHANGE-DIR dir


With CHANGE-DIR, it is looked up. It is expected behaviour, but maybe 
confusing, that CD and CHANGE-DIR are different.

If I remember correctly, CHANGE-DIR came first, and it's suited for 
being used in scripts. CD is suited for using at the prompt.

<tab> completion of directories and files works, if you give argument 
as a file! datatype, but not when giving word! argument for CD. I 
believe, this is hard to get by.

And then, maybe if CD were constructed like this:

	cd: func [
		'dir [file!]
	][
		...
	]

What does the PATH function do?

>> blk: [a b c]
== [a b c]
>> path blk 'a
>> blk
== [a]
>> blk: [a b c]
== [a b c]
>> path blk 'b 
>> blk         
== [a b]
>> blk: [a b c]
== [a b c]
>> path blk 'c 
** Script Error: Invalid path value: c

Maybe for some internal use?

From group Core-old:


A: the PATH action is what the interpreter uses to evaluate VALUE/selector 
expressions for each datatype. It is an internal action and has no 
external purpose in programs. These kinds of words often appear as 
a sort of 

side-effect" from how REBOL is structured.  Datatypes are implemented 
as a sort of object class, where the interpreter "sends messages" 
to the class to evaluate expressions. The PATH action is a message 
that tells the datatype to perform a pick-like or poke-like internal 
function."

interesting, thanks

It seems to original come from a post in group "RT Q&A" dated 11-Dec-05.

yep, that's supposed to be unset but it somehow has been leaking 
out for a while.

is there any official way of using SORT/COMPARE on a block containing 
a mix of different datatypes?

or perhaps more correctly, a method to use LESSER? or GREATER? on 
a mix of different datatypes?

Looks like SORT uses this datatype map internally:


[unset! datatype! native! action! function! object! word! set-word! 
get-word! lit-word! refinement! none! logic! integer! decimal! money! 
time! date! char! pair! event! tuple! bitset! string! issue! binary! 
file! email! url! tag! image! block! paren! path! get-path! set-path! 
lit-path! hash! list!]

how do u know?

I made a block of all datatypes and sorted it. That was the outcome.

Nevertheless, it seems the method is going to be complicated and 
slow for /COMPARE as I don't know how it handles periferal cases 
like:

sort reduce [true false]
== [false true]

which cannot be compared outside SORT using:

lesser? true false
** Script Error: Cannot use lesser? on logic! value


and I don't know and should not need to know how many periferal cases 
there are.

the solution to me would be that comparison functions use the same 
logic as SORT.

Since you can sort a block of logic! values, then <, > etc. should 
work on them, so that's missing. Doing to-integer on logics first 
solve it. And you have to check all the other datatypes by hand first 
to find out, where possible problems are, I guess.

Sorting pairs. hmm...

>> sort [1x2 2x1]
== [2x1 1x2]

Doesn't make sense.

It shouldn't be possible to order pairs, like complex numbers. (Unless 
you define your own rules.) :)

But as pairs are used to make GUIs, it maybe makes sense to sort 
them in this case. Top of screen is before bottom.

SORT seems to sort anything that you throw at it and I think that 
makes sense, when making GUI lists. Right now I have a problem in 
that I can't control the input datatype and must sort anyway. The 
structure of the data is currently so that SORT/COMPARE is best to 
use, but LESSER? and GREATER? prevent this from being simple.

Today's Moment of REBOL Zen:

>> forever [prin now/time // 7 wait 1 loop 20 [prin bs]] 
0:00:00.000000002

Very cool John.

:)) i didn't know about bs until now...

forever [prin now/time // 7 wait 1 prin cr]

(remainder on time is funny)

Yeah, looks like a bug.

onetom:

>> ? char!
Found these words: 
   backslash       char!     #"\" 
   backspace       char!     #"^H" 
   bs              char!     #"^H" 
   cr              char!     #"^M" 
   escape          char!     #"^[" 
   lf              char!     #"^/" 
   newline         char!     #"^/" 
   newpage         char!     #"^L" 
   null            char!     #"^@" 
   slash           char!     #"/" 
   tab             char!     #"^-"

And then there is one string related to those, crlf.

The one that gets me is remembering that newline is a character and 
new-line is a function, rather than vice-versa.

me too.  I always mix them up... isn't this something that could 
be changed in R3?

Wait for R3

Exchanging newline and new-line, and I bet a lot of people will mix 
those up. :) Why do you feel, they should be the other way around?

newline could be called EOL?
http://en.wikipedia.org/wiki/Newline

I don't feel that they should be the other way around. The problem 
is that there is no obvious reason why it should be one way or another, 
so when trying to remember it I get it wrong about half the time. 
Using 'eol would be good, but wouldn't help the problem because we 
can't undefine 'newline in R2 because of the backwards-compatibility 
rules.

new-line could be called set-newline? :)

You can't get rid of the old name in R2, you can just add new names. 
You have to get rid of the old name to solve the problem.

Get rid of the bad old name and change the few scripts, that might 
use new-line. Problem solved!

If people don't want to change old scripts, then just make some script 
to be included (maybe by default using some option when calling REBOL), 
which define things like:

	new-line: :set-newline