World: r3wp

and for sure no x * x in the end - too late today

hehe

actually I don't mind both things, but I would like to see support 
for conditions or general assertions and other stuff and wouldn't 
like to compromise a larger concept for having a little bit easier 
default values in a different way

is like always designing something good and useful is a difficult 
job

the parens make a lot of sense here.  they imply evaluation.  :-) 
 thus you expect that to be evaluated wrt any integer! value... good 
idea

I meant decimal! value , doh

I thought it looked quite nice, but if you think about more elaborate 
guards it might get fast confusing - e.g. would be nice to define 
a guard for a return value or an general condition to be met not 
regarding the arguments ..... but having an interesting dialect there 
would be nice IMO

but on could use the restricted 'return you where talking about

square: func [[(return > 0) (return = x * x)] x [integer!]][x * x] 
 
even if stupid in this case :-)

hum  I wonder if very elaborate entry checks are such a boon directly 
within the func spec ... I mean, it amounts to the exact same code, 
but being place there instead of within the body... I wonder, because 
the use of all/any shrinks this so much... code wise...

we dont have to do nested if / then within rebol.. so checking all 
the args can be done in one simple line using all [ () () () ]

you're right - I guess that's the problem with the dynamic languages 
which are already very concise

but what I like about the approach of design by contract and the 
like, is the separation of who is responsible to do what - I think 
this counts not only in OO programming (eiffel like)

e.g. if you know that you function has to do a certain job, then 
the function shouldn't be necessarily responsible to do all the checking 
in can think about, but the sourrounding code should call it like 
it is  supposed to do

and expressing this a bit separetely might be ok - question is where 
to draw the line - but having guards like other languages would be 
good I think

for simple verification, the parens look ok to me... if you really 
want to go far out... nothing stoping us from including elaborate(ugly) 
verification in those parens.  (using an all for example)

Max, the problem with set words is that they are already used for 
routine! specs, for return: .

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"?