World: r4wp

Giuseppe, I know you think it will help, but that doesn't mean it 
will. So, do an experiment to find out. Or look at other languages 
and see how many successful languages do it. VB was widely adopted 
by non-programmers and it had very few connecting words. FOR and 
FOR EACH being the main examples.

I still want to update FOR, or LOOP as was discussed here some time 
back. It would be easy to include support for optional connecting 
words in that small context to see how it is received.

Another question to ask is: would people use them, if the support 
was there? Experts likely won't, unless writing examples. Will new 
programmers? How often do new programmers comment their code well?

it will make it 90% less usable.

 - what I mean is that the beginner will grow out of this in a matter 
 of, perhaps, days and then it will only be seen as a nuisance than 
 an advantage. REBOL is about words and symbols and now we're spending 
 words and symbols for no real purpose.


I'm afraid it will just confuse and complicate programming in REBOL, 
when you first learn it with fill in words and then without those 
words, and simply slow down the learning process.

Good news are that there already is a language following this design 
goal:
#[[Wikipedia

One of the design goals of it was that non-programmers—managers, 
supervisors, and users—could read and understand the code. This is 
why it has an English-like syntax and structural elements—including: 
nouns, verbs, clauses, sentences, sections, and divisions. Consequently, 
it is considered by at least one source to be "The most readable, 
understandable and self-documenting programming language in use today. 
[...] Not only does this readability generally assist the maintenance 
process but the older a program gets the more valuable this readability 
becomes." On the other hand, the mere ability to read and understand 
a few lines of its code does not grant to an executive or end user 
the experience and knowledge needed to design, build, and maintain 
large software systems."
#]]Wikipedia

Some other good news:

- the wheel has already been invented:
- the language is mature, having been designed in 1959


So, Giuseppe, aren't you eager to try it? It might be quite an enlightening 
experience for you, realize that you would immediately understand 
the expresions!

And other good news: it shares 60% of REBOL's name!

The problem with naively catering languages to beginners is: beginners 
only stay beginners for so long.

None of our arguments is based on real world experiments. So my argument 
are still valid like yours. Ladislav, why don't you try to add this 
feature and lets see if the user will like it ?

COBOL?

Ladislav, why don't you try to add this feature and lets see if the 
user will like it ?
 - I think I did explained it sufficiently:

- such a feature has been implemented in a language since 1959

- I do not feel responsible for implementing every feature you may 
find useful

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