World: r3wp

Ok, after testing and reading again your comment in #564, my example 
in blog's article is wrong, it should have been :
>> if any [get/any 'tst 123] [print "ok"]
ok

My example raises an error (as it should do) : 
>> if any [tst 123] [print "ok"]
** Script error: tst has no value
** Where: any
** Near: any [tst 123] [print "ok"]

Yeah, that makes sense. Btw, option 2 has been mostly implemented 
since alpha 38, which came out in January.

So the silently ignored typo issue still exists, but would be much 
less frequent than I feared.

Part of the trick here is that you have to balance the benefits of 
error generation versus the overhead of error handling. We've been 
careful to make a lot of code that used to generate errors in R2 
just work in R3. If there is a good rationale for "just working" 
that is.

Is such move really going toward the PITL where R3 is supposed to 
bring us? It sounds more like going in the PITS way, making throw-away 
code even eaiser to write. Maybe I'm just not understanding well 
what your were saying.

I agree on the benefits of treating unset! as noops in such cases 
: 
ANY [( )] == none
ANY [( ) 1] == 1
It's usefull and is consistent with the way COMPOSE treats ( ).


But I still think that's some way of getting unset! values may lead 
to undetected errors like in :
>> test: func [a] [print a exit]
>> if any [test 123] [print "ok"]
123
== none
>> result: test 1
1
** Script error: result: needs a value


I understand why you were asking for such change, but it's hard to 
know if it won't cause more trouble than gain.

What I'm saying is that sometimes this kind of thing is not an error. 
The question is whether it is an error more often than not, and if 
the error is critical enough to justify the error handling code that 
comes from generating the error.


Take the ordinals, for example. We decided to redefine out-of-bounds 
for the ordinals as not-an-error. It now means return-none, where 
none is the possibly OK non-data that can be handled with low overhead.

Keep in mind that people already use ALL and ANY for error handling, 
and that these functions are lower-overhead than TRY and ATTEMPT. 
We are trying to reserve generation of errors for those cases where 
the situation is usually or always an error. If it is intended and 
sensible behavior in some cases, we tend to be less stringent.

I'm not saying that unset! values in an ANY or ALL is one of those 
cases where there would be benefits, just that it might be. Benefits 
like being able to use functions like PRINT in ANY or ALL without 
having to do tricks like (print 'hello true). If errors would be 
more common than beneficial code, then generate errors.

ANY and ALL are used as control structures too. If () was defined 
as a noop, I would use it that way on purpose. If not, I wouldn't.

It's hard to say in advance if it will do more harm than good. Unset! 
values can be generated from various semantic rules, I think it's 
 quite touchy to consider that all these cases are equivalent without 
exhaustively listing all ways to get unset! values and see one by 
one if the proposed change would impact it in a positive or negative 
way.

Not a bad idea, at least for the built-in functions. In my experience, 
the main use for PRINT in ANY or ALL is debug statements. Most of 
those go away now that we have ASSERT. We didn't have ASSERT in January.

Btw (digressing a litlle), I've always found inelegant the way unset! 
was used by PRINT or other console-oriented functions to avoid returning 
a value. I'm maybe too purist, but I would have expected PRINT to 
return the passed argument (making PROBE unnecessary). Other solutions 
for making functions (native or user-defined) more console-friendly 
could have been choosed (not having consequences on language's deep 
semantics), like adding a special flag in the spec block! (as 'save 
or 'throw).

choosed = chosen

I really don't mind having some functions return no-value. The interesting 
decision to be made on a case-by-case basis whether no-value is an 
optional return or all the time, and whether no-value is generally 
an error when used, or not. #[none!] is the no-value that is generally 
usable as a value, or at least not an error most of the time. #[unset!] 
is th no-value that really is not a value, and most functions treat 
it as an error, but not all.

I understand unset! values as an exception case where there's no 
value to work with. As such, IMHO, it should be treated as an error 
as much as possible. We should stick to the principle of least surprise. 
 

It wouldn't hurt if R3 unset! values were treated more consistently. 
But this is a deep topic, I remember that Ladislav had some interesting 
propositions about unset! (like, IIRC, removing it from user's eyes 
and keeping it internal only). While browsing about that, I've found 
a few interesting links :
http://www.rebol.net/cgi-bin/r3blog.r?view=0100
http://www.fm.tul.cz/~ladislav/rebol/rep.html#section-18

Bug #564 and option 2 were the result of the last time (January) 
we decided on a consistent treatment of unset! values:

- As an error in value contexts, like assignment, function parameters 
that don't explicitly support it.

- As a noop in control contexts, where the value would normally be 
thrown away, like DO blocks. ANY and ALL were added to this group.

funny, I hadn't realised that do blocks already ignore unset values... 
obviously.

so it makes sense with any and all too.

We get a different answer every time we have this discussion :(

Yeah, and it doesn'tt make sense to ignore unset! with REDUCE because 
that is a value context. With CONSTRUCT it is treated as no-value 
and not inserted. Both of these are the right choice in their respective 
cases.

The main difference between ANY and DO, aside from ANY stopping early, 
is that ANY has a default value: none. Having a default value means 
that no-value is acceptable, so it returns the acceptable no-value. 
DO doesn't have a default value, so if the last expression generates 
no-value, that is passed along. That was the rationale for #564 and 
option 2, at least.

I'm actually OK with either option 2 or 3, but there are tradeoffs 
to either. Which reminds me: Which built-in functions in R3 return 
unset! values? I can only think of PRINT and PRIN, off the top of 
my head. WRITE returns a value in R3. Even ASSERT returns true.

I just remembered to check the behavior of the other *conditional* 
control functions: IF, UNLESS, EITHER and CASE. They all treat #[unset!] 
like option 3, as an error. I guess option 3 is the most consistent.

Yeah, using the last A55, i got better perfs with my virtual block 
scheme (bug on files corrected).
On my small Celeron, i can do now: 
- 25000 read per sec.
- 20000 append/update per sec

quite good

(doing my test with recycle/ballast activated, so that the memory 
used stay low, arround 3500 Mb.
The test file containing 500000 records)

Oups !!! not 3500 Mb, but 3,5 Mb

3.5MB :-)

yes bytes not bits :)

Steeve - what is the speed compared to R2?

don't know

cause the scheme VBS has not been backported

..

sh*****t, i lost my post

I Don't write it back.
Summary:
We can't serialize vectors to save/load them into files.
We need decisions.

Designing vectors not serializable from the start was an error to 
my mind.

We need easy way (fast and not memory consuming) to convert and convert 
back vectors from binaries.

yes, this world needs restart. I advice, before you post, press CTRL+A, 
then CTRL+C to get your post to clipboard first, to save your sanity 
:-)

Maybe it would be get to post your idea to R3 Chat, R3/Datytypes 
section, or as a wish to CureCode, as Carl will not be able to read 
it here ....

yep, it's what i do usually, but sometimes i forgot

but we can discuss here about the proposal at first

Yes ... things should be serialisable, chainable, and streamable 
- I still wait for Codecs and Parse to handle streamed data input 
.... :-)

REBOL values only need to be serializable in REBOL format from the 
start - that is all the datatype! spec allows. That means MOLD and 
MOLD/all formats, and vectors support those peoperly as of alpha 
55. There are only so many operations that a datatype! can support 
internally. These operations are known as action! functions.


All other operations on a datatype! can be implemented as REBOL or 
native functions, and these functions can be added later if need 
be. They don't need to be there from the start. Codecs seem like 
a likely choice in this case, once the codec model changes to allow 
streaming. The current model is a just-for-now placeholder.


Welcome to the wonderful world of alpha software that is still being 
designed :)

I just wanted to underline that it's not good to postpoint the design 
of vectors.

Currently their design is too limited to be usefull (not serialisable, 
no scalars operations).

I hope there will be not huge drawbacks when the time will come to 
complete them like they should behave.

I'm a little disapointed about how Carl deals with the design of 
vectors.

Vectors are serializable in the only way that REBOL datatypes can 
be inherently serializable: through MOLD. This is a basic limitation 
of how datatypes are implemented in REBOL. All other forms of serialization 
*have to* be implemented with other functions.

The actions are the only functions that can be implemented *by* a 
datatype. All other functions are addons.

R3 is being incrementally designed. Incremental design is by far 
the best design approach for programming langages.

Serialization is a general concept here.

I'm talking about convertions of vectors into another formats (like 
blocks or binaries).

molding a vector is of no use in real applications.