World: r3wp

why not:

 f: func/init [arg] [[arg: 2]  print arg]

since its a dialect, func could just steal the first block... IF 
its a block

It could alsmost work with the existing syntax, in the type spec 
for an arg, because you can use example values in the spec for a 
type.

it also allows local vars within face action  :-)

I don't like that Max, as it's totally different from the norm.

There are problems if we use the existing syntax, so it's a question 
of how it would break things, and how many things would break.

e.g. you could use a paren! value, since they aren't evaluated in 
the spec, but that will break the .0000001% that use it today.

f: func [arg (1)][print arg]

?

e.g.  fn: func [/opt n [(0) integer!] [print n]

Gregg, you mean:

f: func [/opt value [44 integer! none!]] [ print value]

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