World: r3wp

<he he>

problem with the parens is that it gets in the way of compose

Yes, that's the basic idea. I'd say it's rare for people to use literal 
values in specs, but they *can* do it today. And, yes, parens conflict 
with COMPOSE but, again, how much code COMPOSEs func specs?

why not allow all the datatypes in the brackets ?, so only the words 
are datatypes for the value and the rest could be an initialization 
value

We can decide on any semantics, paren or any literal value, since 
it's really just a convention, like /local in the spec.

f: func [/opt n [#12 issue!][print "or something like that"]

this looks pretty natural IMO ?

more than with paren!

there was a ] missing

hum... not sure about the #  obscure, especially for newbies...  
depends on the datatype    ##{a}  ,   #'toto

We could also say that only the first value is the default if it's 
a literal; any number of options in this line. The remaining issue 
is how to define a default datatype! value.

I think he was using a literal issue! there Max.

sorry that was just because n was a issue! datatype - I thought

ok.

like f: func [/opt string ["hello" string!]][print string]

just for 'word the order would be necessary

else it could be free - but this would be bad for the habit and learning

This is something we could mock up today, to see how we like it.

Michael, is your example different from what I posted last?  I see 
no difference...

no :-) I see.

but keeping with consistency, not having any : in there does not 
seem right.

where you wanna put the :

HA!  if the value is a set word?

as in f: func [/opt val: 4 [integer!]] [print val]

one problem could be how to handle
f: func [/opt a-word [integer!]][...]

actually I kind of like this also - and wouldn't cause interpretation 
problems

it is very consistent with the rest of REBOL IMHO

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