World: r3wp

On one hand, I like the idea that a none LENGTH? means "this value 
has no length", on the other the idea of a pickable! typset (maybe 
a different name though) gives us the ability to use it in func specs 
and such.

I'm not ready to say change LENGTH? without further thought.

Max, your plan is unrealistic

note, that this proposal is strictly related to functions which have 
an '? at the end.  


if we go ahead with changes to the style convention which clearly 
define what a "truthy" function is and state that ****? is generally 
used to define such a function, I think that we could clean up a 
lot of the guess work in how to handle this often recurring case.

in what sense is it unrealistic?

e.g.:

a: make object! [a1: 1]
length? a
pick a 1

, etc....

well, if an object has a length? why can't I pick it?  that is the 
error IMHO.  though this is not the debate I want to start ;-)

You already did

There are many such cases you don't like

obviously not all cases will fit perfectly.  and the above was just 
one (simple) example, where you can get 95% of the work done in one 
line and then tailor the few special cases after.

Maxim <If an object has length, why can't I pick it?>
Maybe they are like SQL tables.....
A table has a length, so this is valid

   select count(*) from ....   -- to get the length of the table (ie 
   number of rows)

But, in the absence of an ORDER BY the rows do not have a user-accessible 
sequence, so

  select first from ....   -- is not valid syntax, nor (without an 
  ORDER BY) is it even meaningful

(Sorry, I know you did not want that debate)

btw the fact that pick can't use objects isn't related in any way 
to what length? can or cannot do.


I just gave an example to *illustrate* how clean it is to use thruty 
returns in real code.

whatever the algorithm or functions we use we will always have to 
handle the special cases (like 0 in maths)

The fact, that the code actually cannot be used means, that your 
idea is not supported by a real usage example, and is not completely 
thought-out.

Taking into account, that the disadvantages of the change are real, 
while the advantages are just virtual, it is hard for me to support 
it.

Lad you are well placed to know that iterating over ANY random data 
list in ERBOL will require special cases in EVERY single algorythm 
you can think of.  every datatype has its own idiosyncracies.  


in a way, this is the point of datatypes in REBOL. They aren't generic. 
 so I don't expect them to behave so in the first place.

give me your perceived disadvantages.  I've been pulling my own weight, 
but I'm not seeing alot of points related to LENGTH? and other such 
funcs...  I'm not talking about a specific function chain.

Generally, it looks, that REBOL is headed towards "less error triggering" 
approach, and I don't feel any of the changes as a problem, so, you 
may be right. But, there should be some limits, where to stop. One 
of my limits is the usage of NaNs in REBOL, I prefer clean errors 
triggered to NaN dissemination. So, in that case, I know where my 
preferred boundary is. In case of LENGTH? and INDEX? function, I 
am not totally sure, but I am sure, that any change to the existing 
state is expensive (postponing the release, taking resources needed 
to solve more important problems, ...) So, I would support such a 
change only when I would get really convincing arguments.

yes, in such a sense (expensive change), I understand.  


I will wait for brian to step up and get his opinion.  I know we've 
spoken about this somewhat before, but not as head-on, for myself... 
 With the recent talk about naming, IMHO it has put a new light on 
the possibility for this to be a bit more appreciated, adding ? at 
the end would now mean something concrete.


let it be known that I do like errors, I am not against errors, I 
have been putting less and less error recovery in my code to make 
sure it crashes and I fix bugs early.


its just that I can see many if not most ****? functions (my own 
included) being truthy and this is very usefull to facilitate  control 
flow.  This, as oposed to always putting error handlers in places 
where the error is only used as a negative reply, for which we can 
supply, IMHO, a reasonable value/standard.

another proposal:


have info? support more datatypes.  it would be very nice for a single 
function to return information about any datatype in a single call.

ex:
>> a: make string! 1000
>> a: next append a "12345678"

== make object! [length: 7 index: 2 size: 8 buffer: 1000 references: 
1]

the references would tell us how massively this string is being used 
within the application and allow us to track if we are leaking data 
in a way that it will never be able to GC it.

That "references:" may be expensive, since I doubt there is code 
doing that now.

(very expensive, I dare to say)

...and, the GC is able to collect a string no matter how many references 
refer to it

on objects info? could just return all the various reflective properties 
it has (words-of spec-of) and a few more like ram being used by object. 
   all types would benefit from this sorely lacking feature in REBOL.

(REBOL GC does not use reference counting)

really ?
Which algoritm is Rebol using then ?

I do not know, which one, but about this I am sure

in any case, the idea is to put as much information there as is possible. 
 


this would be VERY usefull for debugging, dialecting, and inspecting 
untrusted coded

I don't like these secrets

one problem with reference counting is cyclical reference.  they 
are hard if even sometimes impossible to collect in some sequences 
of execution.

(generally, reference counting is not a true garbage collection)

cyclical references is a problem with any sort of algoritm.

yeah but for a garbage collector its a major issue.

so, the proper GCs don't count references

I do wonder how it knows that all references have been terminated.

You can understand the whole referencing business as a kind of a 
graph - A refers to B, B refers to C, C refers to A, ...

ok, just read a few papers on current GC techniques (including MS's 
pretty competent algorithm)

anyhow... we are a bit off topic from my original post.    I now 
understand why GC is very slow on large datasets.

but its still possible to get that information, maybe it could be 
a refinement, as well as one for MEM stats (if its also heavy to 
resolve)

but its still possible to get that information,
 - which one, references are not counted

no but traversing the "heap" (which is what I am guessing he is doing) 
he can count all references to a particular item.  and YES it wil 
be slow.  but for debugging it could be EXTREMELY usefull.  even 
more would be returning all the items which the GC has encountered 
which have references)

I do not say reference counting *cannot* be done. I say referece 
counting *is not* implemented.

ah ok  ;-)

(I may be wrong, though)

but, taking into account, that it is not needed (the GC does not 
need to know that), it would be a waste of time/code

There are things I would rather see time spent on than the proposed 
INFO? enhancement.

REBOL isn't heading towards less error triggering as a rule (though 
there may be less in practice); it is headed towards making errors 
trigger on more useful occasions. The principle is that errors are 
your friends, and if they aren't, we need to reevaluate them on a 
case by case basis. In some cases we have made things trigger an 
error in R3 that didn't in R2, with the hope of overall benefits 
in security, stability and debuggability. We even added ASSERT to 
explicitly trigger errors.

In the case of LENGTH? and INDEX?, we are only allowing them to return 
none when passed none, using none as the equivalent of SQL's unknown, 
not N/A. And even those are a bit iffy - we are only planing to allow 
those to have fewer intermediate none checks when doing none pass-through 
on FIND and SELECT return values. However, the disadvantage is that 
errors aren't triggered close enough to the source of the error. 
Hopefully they will be triggered later by ASSERT calls.

My preference would be to not lose the valuable information about 
which values have length and which shouldn't be passed to LENGTH?. 
We definitely don't want too many nones to be propagated to data 
that doesn't expect them; none leaks are tough to track down, which 
is the whole purpose of the unset! type.

maxim I vote for your proposal legth? to return none if the argument 
can't be traversed  could be a test on the type of the tested thing 
but arfter ready your  way to present this I'm kinda convinced ... 
As for the GC discussion I very liked the " it doesn't work like 
this but I don't know anything about how it works" isn't that a mutual 
exclusion ?