r3wp [groups: 83 posts: 189283]
  • Home
  • Script library
  • AltME Archive
  • Mailing list
  • Articles Index
  • Site search
 

World: r3wp

[!REBOL3-OLD1]

Kaj
10-Apr-2006
[336]
Possibly Orca could be compiled in .Net
BrianH
10-Apr-2006
[337]
Probably Orca could be compiled in .NET using Portable.NET's C compiler 
without any changes to the source.
Kaj
10-Apr-2006
[338]
Basically, yes, although there could be problems with code that needs 
features that are not accessible in .Net managed mode
Graham
10-Apr-2006
[339]
Any reason why a pair! can only be integer! ?
Izkata
10-Apr-2006
[340]
I think it had to do with pair! being used in draw, offset, etc. 
to indicate pixels
JaimeVargas
10-Apr-2006
[341]
IIRC pair! will use floats in the next in R3.
Graham
10-Apr-2006
[342]
Glad to see that will be fixed.  Otherwise in the postscript dialect, 
you can't specify a point like 5.5x6.3 cms
Anton
11-Apr-2006
[343]
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.
Graham
11-Apr-2006
[344]
I think it is inconsistent for 'first to return an errror, and /1 
to return none.
Pekr
11-Apr-2006
[345x3]
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 ...
DideC
11-Apr-2006
[348x4]
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).
Graham
11-Apr-2006
[352]
perhaps we need a null datatype ?
Pekr
11-Apr-2006
[353]
I thought that none is our null ....
Henrik
11-Apr-2006
[354]
what would be the difference other than being able to tell them apart?
Graham
11-Apr-2006
[355]
only that .. need a way to distinguish.
Pekr
11-Apr-2006
[356]
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 :-)
Henrik
11-Apr-2006
[357]
why not take advantage of FALSE, then?
Graham
11-Apr-2006
[358]
what do you mean?
Henrik
11-Apr-2006
[359]
isn't this the issue of using an ordinal on a block with NONE as 
an element?
Graham
11-Apr-2006
[360x3]
perhaps it should return an error.
in all cases.
which is inconvenient ...
Henrik
11-Apr-2006
[363]
very
Graham
11-Apr-2006
[364]
whatever result is returned by an operation on the block can also 
be an element in that block.
Henrik
11-Apr-2006
[365]
yeah, what if your block contains an error! object?
Graham
11-Apr-2006
[366]
exactly.
Henrik
11-Apr-2006
[367x3]
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]
Graham
11-Apr-2006
[370]
found? is just not none
Henrik
11-Apr-2006
[371]
I thought it was smarter than that, but maybe it could be smarter 
in 3.0
Graham
11-Apr-2006
[372]
>> source found?
found?: func [
    "Returns TRUE if value is not NONE."
    value
][
    not none? :value
]
Henrik
11-Apr-2006
[373]
oh :-)
Pekr
11-Apr-2006
[374]
:-)
Graham
11-Apr-2006
[375]
I use it as a shortcut for not none?
Henrik
11-Apr-2006
[376]
well, it would also eliminate the performance advantage that ordinals 
apparently give
Pekr
11-Apr-2006
[377]
then we need some flag to be settable for none? strict? none? blk/3
Graham
11-Apr-2006
[378x2]
Perhaps we need a way to configure the behaviour we want?
if your data doesn't have none, then you can accept none for a range 
error.
Pekr
11-Apr-2006
[380]
I thought about it too :-) e.g. copy-by-default: true, etc. :-)
Graham
11-Apr-2006
[381x2]
I suspect it was a mistake to allow an out of range to return none.
Too late now though ..
Geomol
11-Apr-2006
[383x3]
Regarding pair and decimals; would it make sense to generalize pair 
further into a new vector datatype, that can be any dimension more 
than one? Examples: 2.4x8.0x5.5 would be a 3D vector with coords 
(2.4; 8.0; 5.5). Like the same idea with tuples, which can be 3 or 
more bytes separated by dots: 255.255.255, 255.255.255.255,... etc.
Or should that be handles with user-defined datatypes?
*handled*