World: r3wp

learned a lot :)

If 
length? none! 
returned none my code would have looked much cleaner
quite a good discussion though.... learning a lot. Thanks.

these are the tidbits we learn along the way.

there seem to be a few common milestones....  when you get to "grasp" 
that words aren't variables... that is usually one of the first big 
ones... and the big one is when you understand what/how binding really 
works.

realizing that a block can hold [ a a a ] and yet each 'a  is actually 
a different value.  ;-)

I think it was Gabriele, or maybe Ladislav that long ago posted an 
INDEX?? function that was "safe". i.e. it wouldn't crash given none. 
There's nothing stopping you from replacing LENGTH? with your own 
version, or creating a LENGTH?? func. 


There are tradeoffs of course. What may seem to make this particular 
piece of code cleaner may have a far reaching impact on other code. 
I don't always agree with Carl's design, but whenever I think he 
did something wrong, particularly early in my REBOL career, I later 
decided he was right. I still think he's wrong about a few things 
though. :-)

And in this case, it's easy to try and see if you like it.

length??: func [series [series! none!]] [
    all [series length? series]
]

also as a general learning experience.... code written by Carl and 
study it.


its very had to read, cause Carl optimised the word count so its 
ridiculously compact.. but there are a lot of little coding gems 
in some of the patterns he uses.  and it helps a lot to understand 
some of the ideas behind many functions which might look obscure 
or rarely used.

I personally prefer when a function accepts none value and doesn't 
stop with an error but returns none.

The code is more compact and I can write error handler only If I 
really need it.

AFAICT, this is the general direction which was taken in R3.   :-)

Not enough though. 

I complain too often that basic functions are sending too many errors 
instead of returning a default value (none is a good one). 
Which would allow a more compact code as you guys noticed.

why not just use ATTEMPT if you don't want errors?

errors are a good thing. forces you to tighten up your code.

R3 changed focus on errors.  indexes pop up less errors, datatypes 
pop up more errors

Thru the years I have come to the same conclusion as Henrik.  I have 
much less error trapping than I used to.  I'd rather have the crashes 
and fix them.
f

Everytime I'm writing (slow, but short) code like 

	>> unique append series 'value

or (very fast, but wordy)
 
	>> any [find series value insert series value]
	>> unless find changes 'weight [insert changes 'weight]


I'm wondering whether there's a nicer way to insert a value into 
a series only if it isn't in there yet. Something in the same line 
as ALTER.

This just reeks like the perfect situation for some Guru O'Brian 
or Gabriele D'Enciclopedia to point out that there's already a REBOL 
native which provides exactly that functionality ;-)


On a unrelated side note, I'm wondering if ALTER is missing an /ONLY 
refinement, too:

	>> alter series: [] [1 2] series
	== [1 2]
	>> alter/only series: [] [1 2] series
	** Script Error: alter has no refinement called only
	** Near: alter/only series: [] [1 2] series


Would that be worth adding to R3, I'm thinking about ticketing it 
as a wish in CureCode?

insert/not-found would be nice :-)

I've written such a function often.  its much more usefull than ALTER 
in my use... I'

I guess additional refinements to a function as fundamental as INSERT 
are a no-go for performance reasons. Probably ALTER/INSERT or ALTER/ONCE 
though:

	>> alter/once [] flag
	== [flag]
	>> alter/once [flag] flag
	== [flag]


See the dance REBOL/View's FLAG-FACE is doing to achieve something 
like that (and a little bit more):

	flag-face: func [
	    "Sets a flag in a VID face."
	    face [object!]
	    'flag
	][
	    if none? face/flags [face/flags: copy [flags]]

     if not find face/flags 'flags [face/flags: copy face/flags insert 
     face/flags 'flags]
	    append face/flags flag
	]

Agree, ALTER is definitivly useless.

Not the first time someone is asking to change ALTER in a better 
usefull behavior.

Carl uses ALTER in a few scenarios, for as a toggle mechanism.

Only him uses that, I guess...

Yes, from a logical perspective ALTER behaves like XOR, where often 
one only really needs an equivalent of OR.

I'd call the function include... and it could work on strings too, 
doing a find

once
 is good too, it's short, I like shorties

INCLUDE in R3 is not a global word, in the code im currently writing

	>> include package/changes 'weight


reads very nice. Sadly, it's signature wouldn't be compatible with 
EXCLUDE, which only allows series and sets as it's second argument. 

The two refinements /INCLUDE and /EXCLUDE though would make ALTER 
more usefull.

I am more in favor of finding a short name, it's a very common idiom.

Yeah, it is a common idiom. But some symmetry to REMOVE FIND FLAGS 
FLAG would be nice, and I don't expect Carl or anyone to be willing 
to replace REMOVE FIND by another native or mezzanine. That wouldn't 
be worth it.

For now, I've decided to go with 

	>> union package/changes [weight]
	>> exclude package/changes [address]

since speed is really nothing to worry about in my case now.

I thought ALTER was going to go away in R3, because nobody uses it. 


As an example of a func that operates conditionally, it's nice, but 
I can't remember ever *needing* it.

I would still like to set up metrics to see what funcs are used most, 
for both development and production (i.e. profiling), and set up 
a rating system. There have been some ad hoc analyzers in the past, 
but no reference system.

Yes, Graham, I know. I should just do it. :-)

I wasn't going to say anything ...  my interest in r3 development 
is rapidly waning ...

Graham - we should stick it into REBOL3 channels and post to Carl 
via all possible channels. R3 "developments" once again completly 
sucks...

The lack of carry thru from Carl just totally sucks ... and is extremely 
disincentivizing

Carl posted a bug in curecode today, so I guess he's back to R3 coding.

---

ok.. moving here from !REBOL3 talking about a sandoxed execution 
option and option to somehow separate native Rebol pure and unpure 
functions

for example you know join will just "calculate" result and you can't 
screw up anything existing with it... where append can , or set can 
even more

well, you can scan the incoming function and disallow 'set

or create a safe dialect that looks like rebol ...

I will give another example where I claim doing a dialect for it 
all is useless option. So you have a rebol server that holds a big 
block of users in ram you send it 2 functions a filter >> function 
[ U ] [ all [ greater? U/age 20 lesser U/age 30 equal? U/gender 'female 
] << and a mapping function >> function [ U ] [ uppercase rejoin 
[ U/name " " U/surname ] ] << server will accept the code and collect 
items where first returns true then process them vith mapping function 
join them with reducing >> function [ U ACC ] [ rejoin [ ACC ", " 
U ]<<  function and return the result.

- the point here being that all functions used rejoin greater? equal? 
lesser? uppercase? are pure functions and can't screw up anything 
whatsoever

- second point is that to do this via dialect you would have to recreate 
whole rebol in rebol which is very very suboptimal (why do we have 
an interpreted lang then??)

- so if you could sandbox execution of functions , for example by 
only allowing pure rebol functions this would be solved

No you don't ... only one person has to do it and shares it with 
everyone else.  Thank you very much.

You can't really sandbox R2, but R3 was designed with that in mind 
so it should be easier.

somehow specifying pure functions or limiting their side effects 
is not only good for security but for writing more bug free code. 
If I could say, raise an error if this function that I wrote to just 
calculate something does anything else would be good for writing 
less bugs.

BrianH: yes, I am throwing this into discussion for R3 ..

Graham: I don't know what you meant with that scentence. If I came 
out as arrogant or attacking you in my writing above, I can say I 
*really* didn't mean it. I am just trying to get my message accross, 
which I am not so good at since english is not my native lang, it's 
1:25 in the night here and I am a little nerwous since I told someone 
I will finish something before tomorrow and I am chatting here instead 
of doing it :)

You don't have to limit to pure functions if you limit access to 
data. Even modifying functions are OK if they only work on legit 
data.

That's the difference between sandboxing and going side-effect-free.

yes, that would be even 10x better :) if runtime could wrap something 
and not allow it mess anything whaterver it calls!

so you are saying something like this could be possible in R3.. well 
you have my and Sunanda's vote for that :) (we talked in !REBOL3 
earlyer)

I'm saying that if you create a safe dialect that people can use 
for sending functions across the network in r2 .. well, great ... 
we can all use it.

aha, but wouldn't that be recreating rebol in rebol. and chance is 
that that rebol will behave a little different than normal rebol 
in some edge cases