AltME groups: search

END means end-of-input, not end-of-rule. If you really want to break 
out, try putting the parse call in a LOOP 1 and then BREAK in a paren, 
or in a function and RETURN or EXIT.

i just read carl article about the call for making that idiom page. 
but when i checked it didn't have much stuff yet. thx for the reminder!

I wouldn't call it a trick John, just a non-obvious syntax. I haven't 
used it much, but I wrote a func a long time ago when I needed it 
for something.

literalize-int-rules: func [template /local mark] [
; Turn a single integer value into a quantity-of-one integer
; rule for parse (e.g. 1 becomes 1 1 1, 4 becomes 1 1 4).
	rule: [
		any [
			into rule
			| mark: integer! (insert mark [1 1]) 2 skip 
			| skip
		]
	]
	parse template rule
	template
]

Right, just wondered, now rebol call e.g. floats for decimals etc. 
many attempts to make the language more humane.

This alternative does not use the COPY call, so, it has to be faster:

alpha: make bitset! [#"a" - #"z" #"A" - #"Z"]
escape-amps: func [
	text [string!]
	entities [hash!]
	/local result pos1 pos2 pos3
][
	result: copy ""
	parse/all text [
		pos1:
		any [
			; find the next amp
			thru #"&"
			pos2:
			[
				; entity check
				some alpha pos3: #";" (
					; entity candidate
					unless find entities copy/part pos2 pos3 [
						; not an entity
						insert insert/part tail result pos1 pos2 "amp;"
						pos1: pos2
					]
				)
				| (
					; not an entity
					insert insert/part tail result pos1 pos2 "amp;"
					pos1: pos2
				)
			]
			| (insert tail result pos1) end skip ; no amp found
		]
	]
	result
]

The biggest problem would be the different datatypes for different 
versions of SQL Server, if there is no good documentation for the 
native format. But BCP does the job quite well. I CALL it when necessary 
and try to FIND if any error output. 

There is XML format files as well, easier to understand but no functional 
differencies betwenn non-XML format files.

2.7.7 release

Call
dockimbel:

About CALL console window issue, the CreateProcess( ) win32 call 
has flags to hide the window. There just need to be set.

In the STARTUPINFO used by CreateProcess( ), just set in dwFlags, 
the STARTF_USESHOWWINDOW flag and set wShowWindow to SW_HIDE.

maybe add a new refinement and let the users decide when they want 
to see the console window ?
or maybe just /show

Paul:
Run is not enabled

Graham

Is anyone concerned that shell windows opened in Encap do not contain 
the correct window title?
Rambo #3660 ( reported march 2005 )

Brian

For me, the big question is what kind of release we will be doing:

- 2.7.7: Patching glaring bugs in a few natives, VID fixes, and continuing 
the backports and mezzanine fixes.

- 2.8.0: Backporting some of the R3 native changes (function, not 
infrastructre), and the above.

I think that the decision a long time ago was to focus on R3 as a 
priority, and just patch up R2 as necessary.

At the very least, I would want a 2.7.7 to have a version that fixes 
post-2.7.6 mezzanine bugs, and 2.7 series regressions vs. 2.6.3.

Henrik
We also need to implement BrianH's new window resize scheme.

Ashley,Anton, Brian, etc ... VID fixes

Graham
Fixes to prot-http to support put etc.

BrianH

SQL_FLOAT and SQL_REAL are converted the same way, just with different 
sizes. And yet SQL_REAL works and SQL_FLOAT doesn't, at least with 
SQL Native Client (an ODBC 3.5 driver). Perhaps that difference can 
point you in the right direction.

Henrik
view/new make face []
a: open/binary/direct/no-wait tcp://:9000
forever [wait reduce [ a 0.001]]


This produces a 16 byte leak when started. And when I move the window 
and click in it, I get a lot of 64 byte leaks.

call works ...

call "demo.pdf" is the same as run "demo.pdf"

Afaict, RUN is basically CALL "start.exe ..."

I have to use 


call/show "cmd" to see the shell .. is that the expected behavior 
these days?

My recollection was that it was always just call until 2.7.6 ..

Sorry, the 2.7.6 changes are sticking. In terms of functions that 
have affected existing code, that means the changes to CALL and EXTRACT. 
We're trying to be more careful in the future, but we're mostly concerned 
with compatibility with the previous version. If you have a favorite 
app that needs to keep working, get involved with R2 development 
and testing.

Changes to natives are tricky to backport, so CALL is unlikely to 
be fixed by R2/Forward. I suppose that's alright since no platform 
for which 2.5.0 is the current version supports CALL anyways. C'est 
la vie.

Confirming, HTTPS should work (after doing a net-install call) on 
Core 2.7.7.4.2?

I think I'll just call the CLI version... don't need anything other 
than smooth downscaling and a few other bits.

a clean installation and call "convert" is enough to give access 
under windows, so that's good enough for me.

My goal of looking at the API was to avoid the startup overhead when 
using CALL. While I wouldn't mind things being faster, we call it 
*a lot* and it works great. The upside of using the CLI is that you 
don't have to worry about a single instance being your bottleneck, 
and it's scalable.

is there any solution or idea for multiple feeding a running console 
app
started via call/wait/input/output ?
have tried a pass a open port but no luck. the console needs more
than one command to work properly. the ideal solution would be to

hold the console app permanently open, feed it via write-io or (something
like this) and parse the output. any hint?

like this?
the cli connector is using the cli component nearly all major
databases delivering. the connection is made via rebols 

call/wait/info/output/error and a simple parse after, for the resultset.
I am using this prototype mainly for a q & d connect

to mysql/postgresql/monetdb/sqlite. on my list are also connectors 
for

firebird/oracle/greenplum/sybase/ingres/infobright/frontbase and 
cassandra.
pros:

1. very fast for single requests
2. no rewrite of code needed if a new version or protocol is out
3. easy 'data migration' between the db's

4. adding new db's are a matter of hours only (see the cli spec thats 
all)
5. fast prototyping and testing for new db's

6. robust, never had any trouble with cli's even with bigger resultsets

7. should be perfect also for traditional cgi (the process starting 
overhead is minimal, execpt you name is facebook)

8. very small footprint (~120 lines for connecting to 4 db's, could 
be the half)

with a nice tcp-server component like rebservice the 
cli multi connector could be very usefull as a c/s connector.
I made a test with 2.000 concurrent calls (simple select) 
on a 4 gig quadcore. the cpu was only close to 50%, a good value.

cons:


1. slow if you have very much serial inserts (unless you shape them 
into one sql query)
2. need to start a cli process for every request
3. needs a tcp server for non-local connections
4. some more, but who cares ;-)

with a solution to keep the cli open from rebservice,

these cons could disappear and the speed diff overhead to a memory 
based lib
could be marginal.

call without /wait in a loop

is CLI connector done in REBOL? Or does it call some external command-line 
cross-db access tool and REBOL just parses the data?

Hello, I am having a small problem about CALL:
call  reduce ["C:\Windows\hh.exe" "C:/mybook.chm"] doesn't work
call/show  reduce ["C:\Windows\hh.exe" "C:/mybook.chm"] works !
Which is the difference ?

call/show rejoin  ["C:\Windows\hh.exe            " "C:/mybook.chm"] 

there's a bug with 'call

The problem is different:
call/show opens the guide

call only run the task but does not open the guide. You can find 
the task in Task Manager

I think in 2.6  the behaviour of 'call changed ...

Use a local reference to the old function, then call through the 
reference. You can do this with a private variable, or composing 
the code block of the new function to have a direct reference to 
the old function value. That last method can be awkward with functions 
called with refinements, but it can be done; the private variable 
metod is less awkward.

its hard when the damn paths are so obscure that you need to call 
the OS using libs to get the paths confidently.
its hard when those paths change all the time.
its hard where there are more than one path per application.


its just really complex when the darn paths could be simple... even 
on linux, they keep changing the paths almost every release on some 
distros.. it gets ridiculous.

brianh: what you call "profile" i call "package"

the installer would just setup the values it can find, or leave some 
of these values as run-time functions (some which would rummage registry 
keys, or call routines)

The runtime is /View doing something other than installing itself. 
And it needs settings, cross-platform settings that are made available 
inside /View without any script needing to check the registry of 
call GET-ENV, for scripts to know where to put or look for the stuff 
they need to run.

What would you call a REBOL binary that comes with GUI capabilities 
on Windows?

It depends. If it has all of View, with the viewtop, I would call 
it /View (or /View/Pro with library support). If it has none of that 
I would call it /Face. If it has all of that plus /Command stuff, 
I would call it /Command/View. There are 3 graphics builds on Windows, 
license depending.

in my app, I ended up doing all URL manipulation in strings, and 
then just converting to url at the time of network call

The question is where. There was a similar call in R3 Chat at the 
beginning of the year, but no response there

write/binary %r278.exe bin
call/shell "r278.exe"
;-)

one thing to look out for in view (in any face using the caret and 
standard focus mechanism) is that when windows are closed, they do 
not unfocus their fields.  this has bitten me quite a few times which 
made other key handlers seem like they where dead.


this is why you should always call unfocus when you open or close 
a window in view.

No, I mean any web browser that the Prevx plugin is installed in, 
when Prevx is running. That's what they call a "secured browser". 
If Prevx is running, it restricts clipboard use to apps it has whitelisted.

That's why I'm tied to R2 Petr, and CALL is important to me as well.

Gregg - right, I forgot that one - 'call, and very bad console, which 
did not serve initial purpose - being usable via ssh etc connection 
anyway ...

Gregg - well, we have odbc for R3, as well as libCurl for networking 
(or Graham's networking protocols), call is here, it just does not 
wait nor does it read the output ....

Pekr, CALL in R3 is waiting (on Win32, at least).

???
>>  my-code-a: [a: [] append a 'x]
== [a: [] append a 'x]
>> do my-code-a
== [x]
>> do my-code-a
== [x x]
>> a: []
== []
>> a
== []
>> head a
== []
>> do my-code-a
== [x x x]
>> a
== [x x x]


what is the logic behind this? How could a be empty after a: [] and 
be filled will three 'x after just one call to do my-code-a

The first A is defined inside MY-CODE-A block. And because you do 
not use copy [], it's not rewritten every time you call MY-CODE-A 
block.

It looks to me like everytime you call my-code-a, you assign the 
block defined in my-code-a to the variable a which is globally accessible. 
When you write a: [] outside my-code-a, you assigne another block 
to a... a is a pointer and you swith the adresse it is pointed to.

>> my-code-a: [a: [] append a 'x]
== [a: [] append a 'x]
>> do my-code-a
== [x]
>> a
== [x]
>> a: copy []
== []
>> append a 'y
== [y]
>> a
== [y]
>> do my-code-a
== [x x]
>> a
== [x x]

I've tested both with INSERT and WRITE-IO, same result. But I've 
used CALL/OUTPUT on the test CGI script to simulate a call from a 
webserver.

If you try to CALL/OUTPUT this script from 2.7.8, it will just freeze 
your REBOL session.

and the print/prin thing obviously won't help with CALL/output crashing 
or freezing

I was wondering if it could be related to a CALL issue, but my own 
CALL.r implementation in Cheyenne shows the same result. So I guess 
it's definitely an internal CGI handling issue.

Launching the script with CALL on linux (using /Core 2.7.6) shows 
something interesting at the end :-))

>> s: "" call/output "rebol -c test.cgi" s
== 0
>> probe s                                
foo^/^/^M

I suspect that the problem is more likely to be with 'call than REBOL 
in CGI mode as REBOL/Services  runs as a CGI under Xitami on Windows.

The problem does not occur on OS X.

I have run a test which seems to show that the problem lies with 
'call.

This is the console output from the command line pgm:

C:\REBOLServicesTest>cr
)haracter 13 is enclosed in the parentheses (


I then checked that the command line pgm could be successfully called 
with the following two lines of Ruby:

	puts %x{cr}
	print %x{cr}.dump

Which gave the following output:
C:\REBOLServicesTest>ruby call_test.rb
)haracter 13 is enclosed in the parentheses (
Character 13 is enclosed in the parentheses (\r)

I then called the command line pgm from a REBOL Console session:

>> call/console "cr"
Character 13 is enclosed in the parentheses (
)== 0
>> print to-binary {Character 13 is enclosed in the parentheses (
{    )}
#{
43686172616374657220313320697320656E636C6F73656420696E2074686520
706172656E74686573657320280A29
}
>> buffer: make string! 256
== ""
>> call/output "cr" buffer
== 0
>> probe buffer
Character 13 is enclosed in the parentheses (^/)
== "Character 13 is enclosed in the parentheses (^/)"
>> print to-binary buffer
#{
43686172616374657220313320697320656E636C6F73656420696E2074686520
706172656E74686573657320280A29
}


As you can see both call/console and call/output turned the 0x0D 
into a 0x0A.

I concur, it's a CALL issue and not a --cgi one. I did more tests 
with my own CALL/OUTPUT implementation and it doesn't show any newline 
alteration in the binary CGI output.

Sometimes depending on a flag you might want to call a function with 
a refinement or not.

So:

either flag [ test/refinement ][ test ]


Is there a simpler way this could be done without passing a parameter?

We use it a lot in R3 for wrapper functions that forward refinements 
to the functions they call. The names can even be different because 
APPLY is positional. It is a little slow in R2 for small numbers 
of refinements when compared to the conditional code, but really 
easy to use, which makes the difference.

If you only need to encrypt data at a single source, you could easily 
call a command line tool such as OpenSSL to perform the encryption 
for you. (It could well be quicker than REBOL too).

is there a good way to use mingw with CALL? I need to call git through 
msysgit, while using ssh keys. From what I can find, this looks almost 
impossible.

Hm, maybe what I call integer refinements shouldn't be allowed at 
all, as I see no point in them. I can't get the desired path using 
integer refinements as in:

>> to-path [blk /2]
== blk//2

The correct way is:

>> to-path [blk 2]
== blk/2

So if integer refinements are useless, what's the point?

No, they're different. I know. You can use refinements to build paths, 
else refinements are used in functions. REBOL allow what I call integer 
refinements, as the scanner doesn't give error. I ask why is that?

There are a lot of values that can appear in paths that don't translate 
to refinements. Paths and refinements are only related in function 
call syntax; otherwise they are not related.

REBOL has 26 or so datatypes recognized by the scanner. That I would 
call complex lexical rules. Maybe a generated lexer will resolve 
many of the problems?

If you know the context you want to use and it is always the same, 
then it is a bit inefficient to call the BIND function, not to mention, 
that

    bind 'v 'f

is more efficient than
 
    bind 'v bound? 'f

can anyone confirm that 'CALL on windows 7 is unable to launch apps 
without using the /show refinement.... which is VERY annoying.

it seems that call/shell no longer works.

I use CALL without /show in Cheyenne to start worker processes. Anyway, 
CALL is quite unreliable in 2.7.8 on Windows as shown by this RAMBO 
ticket: http://www.rebol.net/cgi-bin/rambo.r?id=4416&

A few SQL implementations call the datetime type "timestamp" for 
some cunfusing reason. It's best to keep the concepts distinct.

Settable system-wide flags that affect MOLD are a bad idea, since 
they mean that you have to put wrapper code around every call to 
MOLD to make sure that it matches what your code expects. This makes 
very call to MOLD more complex and less task-safe.

That is why there is a proposal for R3 to make all such options be 
specified at the point of call, not globally. Any global option like 
that would be protected from modification, or else it wouldn't be 
allowed.

For all the above reasons, it is much better to call the #[none] 
and the likes "specially escaped format" rather than "serialized 
constructors".

I'll rephrase:


What I have a problem with, is that there are apparently degrees 
of serialization:


One that we call MOLD, but doesn't really work on all REBOL data. 
I very rarely use this alone.

One that we call MOLD/ALL, and works on nearly all REBOL data. I 
use this very often.


Then we have FORM, which should work on human readable output. The 
problem with FORM is that it isn't flexible enough. For example it 
should have been capable of reformatting numbers, such as 2E-3 to 
".002". It doesn't do that.

There is a lot of type checking in REBOL. I feel too much sometimes. 
Calling many functions involve two types of type checking, as I see 
it. Take ADD. Values can be: number pair char money date time tuple
If I try call ADD with some other type, I get an error:

>> add "a" 1

** Script Error: add expected value1 argument of type: number pair 
char money date time tuple

I can e.g. add pairs:

>> add 1x1 1x2    
== 2x3

and issues:

>> add 1.1.1 1.2.3
== 2.3.4

But I can't add a pair and an issue:

>> add 1x1 1.2.3
** Script Error: Expected one of: pair! - not: tuple!


So that's kinda two different type checking. First what the function 
takes as arguments, then what actually makes sense. If the user also 
need to make type checking, three checks are then involved. It could 
be, the first kind isn't done explicit for natives, and that it's 
kinda built in with the second kind. But for non-native functions, 
the first type checking is done:

>> f: func [v [integer!]] [v]
>> f "a"
** Script Error: f expected v argument of type: integer

I came across a funny thing with binding. We've learnt, that the 
binding of words in a block is done, when the words are put into 
the block. This little example with two functions illustrate that:

blk: []

f: func [
	v
][
	insert blk 'v
	g v
]

g: func [
	v
][
	if v = 3 [exit]
	print ["v:" v]
	probe reduce blk
	g v + 1
]


F puts the word V into the block, then calls G, that has its own 
V. When G reduce the block, we see the original value of V from F, 
even if Gs V is changed:

>> f 1
v: 1
[1]
v: 2
[1]


Then I tried this next function, which puts V in the block in the 
start, then call itself with changed V value:

f: func [
	v
][
	if v = 3 [exit]
	if v = 1 [insert blk 'v]
	print ["v:" v]
	probe reduce blk
	f v + 1
]

>> clear blk
== []
>> f 1
v: 1
[1]
v: 2
[2]


This time, we see the latest version of V. The first V, which has 
the value 1, was put in the block, and it's still there somewhere 
in the system, but we get the V value from the latest F.

Is this a problem or a benefit, or is it just a bit strange?

Doc, I think, you miss my point about recursion. See:

>> f: func [v][if v = 4 [exit] print v f v + 1 print v]
>> f 1
1
2
3
3
2
1


There are several versions of V, one for each call to F. In my original 
examples, I put the first version of V in the block, but I see the 
latest version.

Yes, you got it. Thanks!

I'm not saying, this is a bug, I'm just wondering about the behaviour. 
It might actaully be seen as a benefit, as this gives us 2 different 
behaviours depending on, if we use recursive calls or call another 
function (which can then be recursive), like the G function in my 
original examples.

Anyway, the explanation is as follows: since the function F is called 
twice, it creates two objects having the attribute A. While the first 
object has got the attribute A set to "ok" initially, it ends up 
having the attribute A set to the "bug!" string before the F is called 
for the second time. After the second call to the function F occurs, 
the function does not "see" the first object's A attribute when setting 
the A using the a: "ok" expression.

Regarding "There are several versions of V, one for each call to 
F" - the fact is, that there is only one version of the word 'V, 
not "several". If you wanted to have "several versions of V" you 
could have used a closure, as is demonstrated later.

About the bug thing. When returning to the first object, A is set 
again to "OK" in the line just after the call to F:
	f 2
	a: "OK"
]
...


That should be the A in the first object, shouldn't it? So I can't 
figure out the internals giving the result, we see.

Our understanding of "simple" is different, or I would go as far 
as saying, your understanding of "simple" is twisted.


It would be simple because it fits your model better? Or because 
the model to describe that behavior would be simpler?
I'm asking 
because the latter is certainly false, especially if you want to 
preserve things like dialecting.


I would say, the model giving my suggested behaviour is simpler. 
If you disagree, then look at the code again. 'a' is set to "ok" 
again, after the recursive call. A model giving some other result 
is not simple. If you think, it is, then describe that model in a 
simple way! A simple model should also be simple to describe, right?

Geomol, the behaviour of self modifying code is never simple to understand, 
that is where Gabriele and I can agree with you.


In contrast to that, what both Gabriele and I call simple is the 
suggestion to use the SAFE-OBJECT [...] (or MAKE OBJECT! COPY/DEEP 
[...]) non-modifying expression, which, indeed, exhibits the simple 
behaviour.

Regarding your 

this being a bug" - how that can be a bug of the language is beyond 
my understanding, when I know that it was intended."

*sigh* :)

How do you know, it was intended? You may know, because you've discussed 
it with Carl. How would other than you know?


When I say "bug", I might mean "design flaw". Have you considered 
that? If it was intended and can be considered a design flaw, why 
not just call it a bug then?


Never mind. As I expect, you won't eat your words about this being 
simple, I don't expect a reasonable answer anyway. :)

Geomol, your model is one based on "scope". REBOL's model does not 
have such concept, thus, it is "simpler" (less concepts). You have 
a different definition of "simple", which seems closer to "intuitive" 
to me. That's fine with me, but, there's no point in arguing using 
different terms. What me and Ladislav call "simple" is a different 
thing, and it seems Carl agrees with us; changing REBOL your way 
would not be "simple" in our (me, Ladislav, Carl, etc.) sense.

«When I say "bug", I might mean "design flaw".» - then call it design 
flaw. I will call it a designed feature, as it turns out to be very 
useful in practice. There are many alternative languages out there 
if what you want is intuitive behavior, for some definition of "intuitive".

then call it design flaw


When I first saw it, I didn't know, it was intentional behaviour. 
To me, it looked clearly as a bug, so I called it a bug.

Gabriele, if we continue with design flaws related to binding, the 
following is to me in that category:

>> blk: [x]
== [x]
>> x: 1
== 1
>> context [x: 2 append blk 'x]		; 1st alternative x

>> use [x] [x: 3 append blk 'x]		; 2nd alternative x just to show 
different ways to do this
== [x x x]
>> blk
== [x x x]
>> reduce blk
== [1 2 3]


I came to think of this from your comment on scope. To me, REBOL 
does have scope, it's just different from most languages. In REBOL, 
every word belong somewhere, and three times the same word in a block 
can belong to three different places. That's the scoping rules. Now 
I want to save and load that block:


>> save/all %/tmp/ex1.r blk	; using /all , even if it makes no difference 
here, but this questions /all, doesn't it?
>> blk: load %/tmp/ex1.r
== [x x x
]
>> reduce blk
== [1 1 1]


So doing that changes everything. This design flaw (you may call 
it a "design feature") can be the cause of so much confusion and 
program failures, that I might even call it a "bug". ;)

'This design flaw (you may call it a "design feature") can be the 
cause of so much confusion and program failures, that I might even 
call it a "bug". ;)' - that is (IMO) neither of "design flaw", "design 
feature", "bug". I think, that it is a problem, which you might help 
to solve if you come with a good idea ;-)

Ok, now we're getting somewhere. A question is raised, if MAKE should 
copy arguments given to it. This isn't the bug, as I see it, and 
I'll explain that a bit later.


But first, if MAKE disn't copy the body block when making a function, 
then we would be able to change the function by changing the original 
block. Like:

>> b: []   
== []
>> f: make function! [] b
>> f
>> insert b 42
== []
>> f


After the last call to f, we would get the result 42, if the body 
block wasn't copied. This is not desirable to me. Is it to you guys?

I have got a question of soon-to-join-us-here reboller, asking about 
the possibility to launch new rebol process, using lowered security.

launch "some-script.r" works
lanuch "--secure allow --script some-script.r" does not work

I think I might use 'call instead?

I suggested my friend to use: call "rebol.exe -si my-script.r"

LAUNCH, RUN, and CALL make things confusing. I almost always use 
CALL now.

Thanks for the update, including the great docs Ladislav. I will 
try to give it more thought, and incorporate the new version in my 
work. In the meantime, here are some quick comments.


Have a naming convention for scripts that define include directives. 
e.g. %localize.r could be %#localize.r or %incl-directive-localize.r. 
Short is good, but special characters may affect portability.


If a directive doesn't require per-script or environment specific 
changes, like #comment, make it standard. And the way you designed 
#localize is very nice, in that it gives you control. Do you have 
helper functions for updating 'translate-list? I might call it translation-list, 
since 'translate sounds like an action.

Yes, I do.

And I'm thinking, if it would be an idea to let functions like that 
take word arguments handling them like call-by-reference. Then it 
would be possible to change chars too.

Has anyone said the following before?

call-by-word

I suggest: skip ++ and use NEXT with call-by-word to do the same. 
Less functions to remember that way.

using NEXT with call-by-word (I like the name :) ) looks ok to me, 
but I remember that, "guru"s may say "it leads performance overhead 
for next, as it is a native and used a lot. it should check the argument 
and get-value if it is a word."

Yeah, and some may argue, it's less readable with call-by-word options. 
But some probably also finds it strange, that NEXT string doesn't 
alter the string, while LOWERCASE string does.

Yes, REBOL makes it possible to do all this already. In fact, all 
the natives could be recreated as mezzanines supporting call-by-name, 
but that'll be slow of course.

My suggested NEXT can do that also. I just suggest adding the possibility 
to call those with call-by-word.

Geomol, if you change NEXT to call-by-word then in order to have 
it work on the results of a function you will need to assign those 
results to a temporary word, then in a separate statement run the 
NEXT. No more chaining.

I didn't suggest changing NEXT to call-by-word. I suggest adding 
that possibility beside its current behaviour.

I think, the ideas can be seen as: like other languages have call-by-value 
and call-by-reference (maybe using pointers as in C), REBOL could 
have call-by-value and call-by-word, both working with the same functions, 
as it's all by value, but we just give the word (REBOL's kind of 
reference) as an argument.