World: r3wp

problem compared to 
f: func [/opt a-word [the-word]][...]

Gabriele said there might be issues with using a set word within 
the func spec block,  but if func really is a dialect... I don't 
see how.

so what was the reason against your last (and has been before) idea 
?

ok

in any case, some words should be reserved  (like 'return)

So Gregg what do you think?

I think either one of these last two options we've come up with could 
work. I want to think about it a bit more, and others may chime in 
as well. I'm wondering if the extra block approach as easy to do, 
and had good performance, where this may have a bigger impact, but 
I like this line of thinking much better.

as easy to do = was easy to do

I do think that the set word approach is more approachable and much 
more readable... do you agree?

I'm not sure. At a glance I like it, but then I think about other 
things that we may want to do in the future, e.g. constraints.

constraints?

e.g. specify that an integer param must be positive.

honestly, Gregg, if you measure the times you'd need a default value 
wrt any other func enhancement ... I am sure default values are far 
ahead.

just about every other func I use would have default values in them. 
 hell in python I don't even recall one function which didn't have 
default values... they are just so usefull.

True, today, but I also know that I have a *lot* of code that validates 
parameter values, and if that could be done declaratively...

one thing that is better in the [] version is that it fits with the 
current model of annotating the value in front of it

It's the REBOL problem of being able to do anything, and we need 
to think about how we really want to write functions IF (and that's 
a big IF) it's something that affects R3.

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