World: r4wp

yes, and it would be lovely to be able to do that in REBOL and World. 
But (I can only talk for World) the language needs to have legs first, 
before we can think about flying.

wings to fly, legs to run.

and World can barely crawl now.

Maybe return could have a /back refinement which you could use when 
exiting a variadic function.

 - not a good idea. Variadic functions don't differ from "normal" 
 functions in this respect. If consuming an "undesired" argument, 
 it actually is an error. That is a good enough solution as far as 
 I am concerned. In case of SUMN this behaviour can be also implemented 
 by requiring the argument to always have a specific type. e.g. [number! 
 none! unset!], where number! would be a "normal" argument while none! 
 and unset! would be stopping. Any other argument causes an error, 
 which should suffice for you to note that something went wrong.

A question for AdrianS or other lurkers: I already mentioned that 
SUMN actually used unevaluated argument passing style (APS). Do you 
find that style appropriate or would you prefer SUMN to use a different 
APS? (Consult https://github.com/saphirion/documentation/blob/master/argpass.mdp
if you don't know what I am talking about).

Advantages of using evaluated APS for SUMN:


- argument can be a result of an expression, i.e., the function would 
be referentially transparent in the sense that it would accept expression 
results, e.g. sumn 1 2 * 3

Disadvantages of evaluated APS for SUMN:


- (sumn 1 2) would not work since the function would miss a stopping 
argument

Advantages of using literal APS for SUMN:


- partiall referential transparency, the function can accept result 
of an expression, if the expression is in parentheses, i.e. sumn 
1 (2 * 3) would work
- partial referential transparency, sumn 1 :x * 3 would work

- (sumn 1 2) would work, since the literal APS obtains the stopping 
#[unset!]

Disadvantages:

- sumn 1 2 * 3 would not work
- sumn 1 x would not work either

Advantages of using unevaluated APS for SUMN:


- (sumn 1 2) would work, since the literal APS obtains the stopping 
#[unset!] at the end of the paren
- sumn 1 (2 * 3) can be made to work if desired
- sumn 1 x can be made to work if desired

Disadvantages:

- sumn 1 2 * 3 would not work
- sumn 1 :x * 3 would not work

I will have to think about this. I'm curious, though, what your opinion 
is of return/redo given that BrianH said in the SO chat that it had 
been decided to remove this and yet you documented it and showed 
its usefulness. Later, Brian also said:


Ladislav proved that RETURN/redo needed to be removed, by writing 
example code that was safe to run, but used methods that were provably 
unsafe if used mistakenly or maliciously. It would actually take 
a programmer of Ladislav's calibre to use the feature safely. But 
DO function is provably OK.

So, is the intent to remove the feature?

BrianH said in the SO chat that it had been decided to remove this 
 - I do not know about such a decision yet

Read the SO chat from around 22:55, yesterday. Curious about your 
take on that discussion.

The link, for those here that don't visit SO regularly:
http://chat.stackoverflow.com/transcript/message/9837385#9837385

Well, I was originally against /REDO, taking a more moderate point 
now, but, as I said, I am not sure there was an agreement to remove 
it.

In /REDO case it looks that I am something like  "permanent opposition". 
When there was a "hurray /REDO" atmosphere I was trying to chill 
it down pointing at the disadvantages, now, when there is the "phew 
/REDO" atmosphere, I seem to be an opposition as well...

The word is contrarian :-)

I'd like to hear more about the security implications it has vs existing 
ways of affecting interpreted behaviour by self-modifying code.

Is it significantly worse?

Or fickle

Is READ %/ supposed to work as in R2, or is the current R3 behavior 
(reads root of current drive, rather than enumerating volumes) the 
new normal?

Gregg, BrianH reported this issue as a bug today:
http://issue.cc/r3/2031

Funny timing. :-)

cant' we press escape to halt a script or when at an    'ASK  prompt?

escape doesn't work, but ctrl-c works (on Windows), it returns "** 
Access error: read failed: [scheme: 'console] reason: 87" but remains 
in the console.

when its launched from windows it closes the whole intepreter  :-(

Interesting, I tested with the old R3 version and the latest Saphirion 
version, it doesn't close the console.

(I'm on win8)

Is it possible to acess UNIX sockets?

Currently, there is no support for Unix domain sockets implemented 
(neither high- nor low-level).

I thought so...

Did anyone started a R3 code-review and already took notes that are 
published?

I think it makes a lot of sense to publish all notes in a structred 
way, so it's easier to work on the R3 code base.

I think that 'subtract should allow for binary values:

>> help subtract
USAGE:
        SUBTRACT value1 value2

DESCRIPTION:
        Returns the second value subtracted from the first.
        SUBTRACT is an action value.

ARGUMENTS:
        value1 (scalar! date!)
        value2 (scalar! date!)
>> subtract img1b img2b

** Script error: subtract does not allow binary! for its value1 argument

Rebol 2.101.0.4.20:

>> difference #{FFFFFF} #{EEEEEE}
== #{FFEE}

I would expect it to return #{111111}

Why not use XOR?

>> to binary! (to integer! #{ffffff}) - to integer! #{eeeeee}
== #{0000000000111111}

I think that 'subtract should allow for binary values


Hm, what if they're not of the same length, the two binary sequences?

What if they're longer than 8 bytes?

#[[Bo
Rebol 2.101.0.4.20:

>> difference #{FFFFFF} #{EEEEEE}
== #{FFEE}

I would expect it to return #{111111}
]]Bo

That is not a well informed expectation, Bo.:


* in Rebol, binary values are series of octets (small integers, 0 
to 255)
* in Rebol, set functions handle series as sets of values
* DIFFERENCE is a set function yielding set difference

* in the above case the first st contains #{FF} (=255), which is 
not contained in the second series

* the second series contains #{EE} (=238), which is not contained 
in the first series
* thus, the set difference is #{FFEE}

Does this help:


>> to binary! difference to bitset! #{FFFFFF} to bitset! #{EEEEEE}
== #{111111}

hum, wow.  there always seems to be a conversion path to get the 
numbers do what we want... I'm sure accountants would love rebol 
 ;-)


want a deficit... just turn it into a binary, want a profit, just 
turn it into a bitset first   ;-)

Gregg already mentioned XOR, I'll repeat: why not XOR?

>> #{FFFFFF} xor #{EEEEEE}
== #{111111}

Ladislav: I was expecting 'difference to treat binaries the same 
as the 'difference in the 'draw dialect in R2.  I seem to have been 
mistaken.

Geomol: If subtracting two binary numbers of different lengths, it 
would be like subtracting two decimal numbers of different lengths.

Gregg and Andreas: 'xor seems to work, for the most part.  I have 
to do some more testing to know for sure.

Thanks for your help, everyone!

Bo, I'm not sure, if that makes sense. What you're suggesting is, 
that this should be possible:

	(read/binary %file1) - (read/binary %file2)


So it's like looking at a long sequence of binary data as a number? 
And if the series are of different length, they should be right aligned. 
Is that really useful? :)

Arithmetic on series ... like arithmetic on strings!? Funny language, 
that do things like that.

R2 can use strings in AND, OR and XOR, like binary!, but they're 
not right aligned.

R2 and R3 works the same in this:

>> (to integer! #{1111}) or (to integer! #{22})
== 4403
>> to integer! #{1111} or #{22}
== 13073

I guess, that's expected behaviour?

I would say so.  The great thing about datatypes is that they can 
save us a lot of work doing manipulations.

The downside to datatypes is that it is hard for the developer to 
determine proper behavior of different operations on the different 
datatypes.  Like, what should happen when you add a char! and an 
integer!...  My opinion would be that because your first argument 
is a char!, you want to increment/decrement it by the value of the 
integer!.  This could be useful in some situations.

I would expect 'or to be right-aligned on binary.

I would expect 'or to be right-aligned on binary.

My example above is not right-aligned. This:

>> to integer! (#{1111} or #{22})
== 13073

This is right-aligned:

>> to integer! (#{1111} or #{0022})
== 4403

I was agreeing with you that 'or should be right aligned, even though 
it isn't.