World: r4wp

- such a feature has been implemented in a language since 1959
I think it had a great moment.

Moving to Languages...

How far is tasks implemented in R3? It's possible to make them:

>> probe make task! []
make task! [
    title: none
    header: none
    parent: none
    path: none
    args: none
]


, but are there examples of use? Are they supposed to be kinda stackless 
tasklets or some threading thing?

not finished imo. But I tried to put some code in a task - wait, 
print, and IIRC it did so ... console was freed, later it printed 
the message. But it was long time ago ...

I'm about to look deeper into tasks and networking and was wondering, 
if Carl wrote something about this, and how much is already there?

As for networking, R3 uses devices. Please consult the rebol.net/wiki 
docs, there's quite a bit info about it. As for tasking, during one 
session we asked Carl to clarify, so he did. BrianH or others would 
be most probably able to describe, how Carl envisioned it to work. 
The only thing I can remember is, that it was supposed to be called 
task! datatype, but internally using threads with some automatic 
syncing, or something like that ...

Missing a yield return function to have rebol tasks really usefull

Steeve, do you have experience wiht protothreads?

protothreads?

http://dunkels.com/adam/pt/

I was just thinking, because they're lightweight and also have the 
yield functionality, you just mentioned.

ok

#[[AdrianS
...if you have the following in a script:

print sumn 1 2
print "hello"

The "hello" doesn't print.
]]AdrianS


Yes, that is not surprising. SUMN (referring to its last version) 
is taking unlimited number of arguments and stops taking them only 
if it obtains an argument that is not a number. In the above case 
SUMN consumes the ''print word, that is why nothing is printed. To 
stop SUMN before it consumes the 'print word, you can use either 
paren:

    (sumn 1 2)
    print "hello"


or just supply NONE (or some other non-numeric value)  to be consumed 
by SUMN as the last (stopping) argument

    sumn 1 2 #
    print "hello"

In your example the 'print word is not evaluated because the ARG-ADDER 
function uses the unevaluated argument passing style. It could be 
possible to use evaluated argument passing style for the ARG-ADDER 
function obtaining slightly different behaviour. You can experiment 
with that, the main problem being that in such case the expression 
(sumn 1 2) would not work, since SUMN would always require some stopping 
argument.

On the other hand, using evaluated argument passing style, the expression

    sumn 1 2 print "hello"


would work as you expect since the PRINT call would be evaluated 
and its result (the #[unset!] value) would be used as the SUMN stopping 
argument.

#[[Adrians

Among other things, how is it OK to invoke arg-adder without providing 
the one arg it expects when you have "return/redo :arg-adder?
]]AdrianS


RETURN/REDO is a construct returning (in this case) the ARG-ADDER 
function and setting up an indicator telling the interpreter that 
after obtaining the function as a result it should reevaluate it 
collecting the respective number of arguments for it (one in this 
case).

also, note that e.g.

    retutn :arg-adder

would just return the ARG-ADDER function without evaluating it.

err.

    return :arg-adder

is what I meant

Thanks, Ladislav. I was hoping that there would be a "magical" way 
of telling Rebol to somehow back up and re-evaluate the consumed 
stop argument. Maybe return could have a /back refinement which you 
could use when exiting a variadic function. What do you think?

Carl has been talking for some time about integrating streaming protocols 
into Rebol (probably like h264, mpeg4, mp3, wmv, etc.).  Is that 
something that could be plugged into the existing codebase rather 
directly, or will it take a lot of changes to make it work?

avconv (formerly ffmpeg) is open source, so I imagine some or all 
of that could be used as a starting point (if the licenses are compatible).

I think gstreamer is also open source, and might be less complex 
than avconv.

Maybe if you could find libraries, that can do this, and call them. 
World can call routines in libs, and REBOL can too (afaik).

Yes, but I think Carl was talking about making it more of an integrated 
component so it can be easily accessed Rebol-style.  It's like the 
difference between loading a jpg in Rebol (it just works) or trying 
to link Imagemagick (or comparable) to load a jpg into a binary image 
format that can be modified by Rebol.

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...