World: r3wp

but the block also get ambiguous, as gregg pointed out, trying to 
set a default value of datatype gets pretty unobvious... and even 
quirky.

i.e. if we come up with a really ambitious func spec dialect, should 
we propose it now, for R4, or never (and just mezz it in for those 
who want to use it)?

hum... are default values part of  ambitious?

I think they're the first step on that slippery slope. :-)

Not too ambitious in themselves though, and *so* useful that I think 
it's worth pushing for it.

hehe, IMHO NOT having default values is a current REBOL shortcomming. 
 ;-)

a lot of code would get a few lines trimmed

I agree 100%.

especially if the values are reset at each function call.

Trimmed, and become much cleaner in intent.

cleaner = clearer. doh! :-)

yes, especially if the set-word approach is used... just a casual 
glance at the spec indicates something is being set.  otherwise, 
one needs to know it.

the datatype block is obvious because they are datatypes within the 
block.

Gotta run. Great chat guys!

square: func [x [decimal! (x > 0) complex!]][x * x]


will be very difficult to get it right if other things should be 
allowed later :-/

should have been sqrt :-)

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