World: r3wp

max, refinements are logic (none or true), they don't get a value

what about using a refinement in general for a optional intialization 
block ?

Yes, I'm in agreement with you here Max, just not the = syntax.

and depending on the needs of the func spec, it switched to closure

so you'd have /option val: 77, but this is a potential problem with 
return: in routines for e.g.

Michael, I don't know if that's any better than an extra block, because 
you have to redundantly name the values.

why use two words.

because you have refinements without args, with one arg, with two... 
and so on

I think default values need to be specifiable like help strings are, 
but I haven't thought about the specific syntax yet.

/option, /option val, /option val1 val2

what I think is that not everybody wants it (because could be optional) 
and a refinement would add it if wanted

but the word is ALWAYS set, so in the context of its useage, its 
not optional.

I know there are drawbacks, but why not 
f: func/init [arg] [print arg] [arg: 2]
and
f: func [arg][print arg]

cause the init block can be 2 pages further down the editor?  ;-)

this breaks no code and uses the existing facilities 

yes that's the drawback

I thought of that too, and came up with the same problem Max did. 
:-\

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?