World: r3wp

IIRC routines only use return:  ...  so just make it a reserved word 
in general.

really, not being able to set one word within the func spec isn't 
a big deal, especially one which isn't a good habit to overwrite.

and as you mention... return is used in routine!  not function! datatypes... 
so they dont really overlap anyways.

The big benefit I see in having constraints in the spec is that they 
become declarative, and are automatically handled in a consistent 
manner. Of course, there's nothing stopping us from doing things 
the way PREBOL was done either.

I'm turning against packing more into the func spec. Constraints 
can be easily coded with an extra function that builds functions, 
eg:
	constrained-func: func [spec constraints body][
		func spec compose [
			(constraints)
			(body)
		]
	]

That's really simple to do, separates the constraints from the rest 
of the code, and results in a normal rebol function. Furthermore, 
the constraints can be any rebol code, not just some restrictive 
dialect.

Carl is searching for a way to add commenting to his rblog3.r script. 
How long will it take us to add this feature for him? IMO he should 
spending his time doing R3 and not enhancing blogger scripts.

Can't answer how long it will take, but we probably need to meld 
code from these two scripts together:
Carl's blog.r

http://www.rebol.org/cgi-bin/cgiwrap/rebol/documentation.r?script=blog.r

http://www.rebol.org/cgi-bin/cgiwrap/rebol/download-a-script.r?script-name=blog.r

BBS Tutorial page (link appears to be broken):
http://www.rebol.com/docs/cgi-bbs.html

Regarding typemap! isn't this like trying to creat abstract classes, 
and if so why not have support inheritance?

(BBS Tutorial page is in Google's cache though.)

its more like interfaces/multiple inheritance than inheritance IMHO. 
means you are not forced to a tree, and you dont share code.

and sometimes the types have nothing in common. think of a function 
which accepts a file, logic or none (as 'echo does).

Jaime, it's like a bitset; there is no inheritance involved.

http://www.rebol.com/docs/cgi-bbs.htmlworks here. WOuld be nice 
if the seperat e files would be included too

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 ...