World: r3wp

So, my "rule of thumb": REBOL expressions should not yield non-moldable/loadable 
values (#[unset!] and errors aside), what do you think?

correct imo, because if we allow that, how could be bet upon reflectivity 
and self-inspecting code principles?

imo it is that - error you can catch, but non-expected result is 
worse than error :-)

non-expected result is worse than error

 exactly what I mean.   but to consider "what is expected" one has 
 to back away from "computer science" and think about the meaning 
 of most of the types.

x: 2x2 loop 40 [print x: x * 2x3]  getting negative numbers is just 
plain wrong.

maybe in C its ok, cause you (should) understand about CPU registers, 
binary calculus in finite space etc... but for a REBOL application.

if integer (or whatever datatype) space is not sufficient, we should 
forbid overflows. I would expect an error - size/number overflow. 
Then it is up to programmer to accept another technique ...

And maybe part of the documentation should be section about datatypes, 
their ranges, etc.

an int is a number and substracting from a negative value should 
return a negative value, or error if the result is out of bounds. 
  I really think that is the POV of REBOL itself... its meant to 
make programming simple... not complicate thing by re-introducing 
things like overflow causing the carry bit to roll number around, 
like in C...

there is a section on datatypes, but they do not go in depth at the 
limits, the conversion, the "expected" behaviours, the overall line 
of conduct on "strange events"

another food for thought. What do you think about this?

equal? to file! " " to file! "^(20)"

(the result is == FALSE), while

    equal? mold to file! " " mold to file! "^(20)" ; == TRUE

this is where objectivity is at loss.  they are equal and not depending 
on what you consider equal, or rather if:
- the evaluated human concept is equal (a space)

- the rebol value can be converted to from two types symbiotically.

- they obey a specified set of guidelines like (if converted to string 
both are equal)

- they must be strictly equal (of same type, but not the actually 
same instance)
- the same (actually two references to the same value)

(but you know that... hehe ... you did a thesis on REBOL equality 
 ;-)

Ladislav there's problem with files with SPACE on begining (and end 
too I think), it's in RAMBO.

looking it up in RAMBO...

yes, Rebolek, that is a good suggestion solving the issue

so to file! " " should be %%2520 while to file! "^(20)" should 
be % , right?

yes, I think so. Little bit messy, I think.

do I understand correctly that you don't like it? (do you want something 
better then?)

we want the whole truth ,   NOW  ,  (sorry... chit chat seems to 
infect me somtimes)

Good points here! :-) I now see the problem. It might be best to 
return an error, when subtracting 1 from the lowest value of a date. 
Make sure, you think it through as much as you can, and then be consistent. 
If one datatype return an error in such a situation, another might 
as well.

Date again to be specific, I think, that REBOL has to pass this tests 
(and similar):

		any [
			error? try [date-d: 1/Jan/0000 - 1]
			not error? try [load mold date-d]
		]

I agree

On the subject of date! and values having meaning. I think that the 
zone refinement needs to be looked at again:

>> dt: 17-Jan-2007/9:52+25:00
== 17-Jan-2007/9:52+25:00

but 

 >> 17-jan-2007/9:55+5:45
** Syntax Error: Invalid date -- 17-jan-2007/9:55+5:45
** Near: (line 1) 17-jan-2007/9:55+5:45


To the best of my knowledge +25:00 is not a valid time zone offset 
but +5:45 is (Nepal).

zone has a resolution of 30 minutes. it is indeed a problem for a 
couple zones (like the one you pointed out).

Not handling the 45 minute zones (I don't think that there are any 
15 minute zones) isn't a big problem. Its the inconsistency that 
bugs me - GMT +25:00  is a less correct value than GMT +5:45.

..to me.

yep, but rebol is not actually doing sanity checks on zones. the 
45 problem is only due to a limitation of the implemetation.

it looks, that the current zone range is -32:00 to +31:30. The range 
can be transformed to -16:00 to +15:45, which should be sufficient, 
shouldn't it?

A day no Mars is 24.6 hours, so I think, we're ok with -16:00 to 
+15:45 timezone.

A day *on*

uses: func [args [block!] spec [block!][
    args: context args
    func [options [block!] compose/only [
        options: make (args) options
        do bind (spec) in options 'self
    ]
]

Usage:
>> f: uses [x: y: 1][print y]
>> f []
1
>> f [y: 2]
2

Although arguments for any 'uses based functions must be contained 
in a block, it does allow for optional arguments with preset values.

Any suggestions/bugs?

Hmm, lost a close bracket in a VNC post...

uses: func [args [block!] spec [block!]][
    args: context args
    func [options [block!]] compose/only [
        options: make (args) options
        do bind (spec) in options 'self
    ]
]

does anybody know if there is any difference between negate bitset 
and complement bitset ?

i think they are the same.

That looks pretty good, Chris. Can you post any examples where you 
used it ?

how  about  locals too? then you have closures. And itdoes not work 
recursively, how about copying the  body when binding?

Locals ? You can have as many locals as you want in the args block.

true, everything is  optional. late here^^

a part for a little bit of excentricity on your part... do the trailing 
^^ you add on most/all post mean something I have been missing?

Anton, I don't have any good samples at the moment -- it's part of 
an unfinished project.  I'll try and come up with some based on the 
usage requirements I have.

I see it mostly as an alterate way of writing functions that would 
otherwise require many refinements.  The benefit being neater presentation.

print-cgi: uses [
    status: 200
    type: 'text/plain
    content: ""
    location: %/
][
    print switch status [
        200 [rejoin ["Content-Type: " type "^/^/" content]]
        302 [join "Status: 302^/Location: " location]
    ]
]

print-cgi [content: "Text"]
print-cgi [type: 'text/html content: "<html>Text</html>"]
print-cgi [status: 302 location: http://www.rebol.net/]

A quickie example, but illustrates the flexibility and readability.

Nice one.