World: r3wp

Gabriele, Yes. In this case the name typeset! is better.

Would be nice, for tidyness, if R3 had some place to release resources 
before the app closes. As far as I know the only place currently 
is the close event of a port because ports get closed when REBOL 
quits.  Would be good to have something more purpose made. For example, 
Delphi offers a "finally" clause companion to Try and also a unit 
level "finalization" clause - guaranteed to run when closing down. 
Delphi is compiled, so don't know if REBOL can offer similar.

My hospital was recently acquired by a private company. Today we 
got the order that the new direction is MS .Net and only this.
Are there any chances to get Rebol3 running under .Net?

I remember A.J.Martin proposing that already and maybe Terry moaning 
too.
Anyone else interested in that?

my long time proposal was to get Rebol running under other virtual 
machines, as those became de-facto platforms - Java, Tao, .Net .... 
the question always is, how fast would rebol be then ....

In java i got 2.5* - 1* the speed of rebol in a little POC. I guess 
 a full implementation will loose a bit, but could be more or less 
on par.

(and the cpu was a k6. such things depend on proper pipeline/cache-use, 
and i doubt rebol is optimized for that cpu. i guess comparison on 
a p4 may look different by a factor of ~2)

sqlab: maybe not what you mean, but there is a project to handle 
Rebol syntax in DotNet (first named as Spirit, but now known as RLike)

Sorry for you, but it's done by a Belgium guy, sot the site is in 
French.

http://spirit.easybraine.org/

French=French speaking, I mean.

...as I'm not sure he is from Belgium, right now.

Possibly Orca could be compiled in .Net

Probably Orca could be compiled in .NET using Portable.NET's C compiler 
without any changes to the source.

Basically, yes, although there could be problems with code that needs 
features that are not accessible in .Net managed mode

Any reason why a pair! can only be integer! ?

I think it had to do with pair! being used in draw, offset, etc. 
to indicate pixels

IIRC pair! will use floats in the next in R3.

Glad to see that will be fixed.  Otherwise in the postscript dialect, 
you can't specify a point like 5.5x6.3 cms

About FIRST, SECOND returning NONE instead of an error:

I suspect this change may cause trouble for not much gain, but I 
would like to see Carl's new way of coding with ORDINAL.

I wanted ALL to accept a lit-path! , and this would traverse the 
path safely, returning NONE when any of the the path elements returned 
none, eg:
	ALL 'face/pane/1  
	; == NONE if any of face, pane or 1 return none.


It would also be good to be able to use set-lit-path!s this way, 
eg:

	ALL 'face/pane/1: make-face ...    

 ; ALL returns NONE when any of face, pane returns none, or 1 is out 
 of bounds, but returns a set-path! when it's all ok.

I think it is inconsistent for 'first to return an errror, and /1 
to return none.

I do agree with Graham here - unification does make sense imo. The 
only "trouble" I see is, how you distinguish what is the cause of 
'none - is it returned as a legitimate value, or because of non-existant 
element request or other kind of "error"?

It is similar "inconsistency/limitation" as with refinements /can-not-use-this-word 
.... I would prefer change to use /refinement in function body instead 
of word ....

... but maybe too many scripts would break ...

too many=probably all ;-)

I'm not sure why but it feels "safe" to me to have two way to acces 
data : one that return none! and one that throw an error! (even disarmed).

I used to use one or the other way in my code depending the possibility 
of missing values can happen or must not be.

So having:
- pick => none!
- value/word => error!

is good to me. I use 'first, 'second... as shortcut for the second 
case.

But if Carl want to make them works as the first case, it's OK too.

I'm like Pekr, I just want to distinguish between awaiting missing 
value (none) or not (error).

perhaps we need a null datatype ?

I thought that none is our null ....

what would be the difference other than being able to tell them apart?

only that .. need a way to distinguish.

but block is kind of storage for us ... so the trouble is, that we 
may obtain those nulls from two different reasons - as a result of 
an operation, or simply because we wrongle adress block itself ... 
not sure what we can do about it :-)

why not take advantage of FALSE, then?

what do you mean?

isn't this the issue of using an ordinal on a block with NONE as 
an element?

perhaps it should return an error.

in all cases.

which is inconvenient ...

very

whatever result is returned by an operation on the block can also 
be an element in that block.

yeah, what if your block contains an error! object?

exactly.

but then the problem exists in FIND to for example

which returns none on not found, but there we have the FOUND? to 
help us. perhaps the ordinals should use FOUND? as an indicator?

found? second [true none]

found? is just not none

I thought it was smarter than that, but maybe it could be smarter 
in 3.0

>> source found?
found?: func [
    "Returns TRUE if value is not NONE."
    value
][
    not none? :value
]

oh :-)

:-)

I use it as a shortcut for not none?