World: r3wp

this was a clear question imo :-)

everything else is unrelated. making closure the default would probably 
be a performance hit, and most people wouldn't really notice the 
difference (newbies don't expect closures, unless they come from 
lisp)

Kind of what I was thinking. At the base level, for most users, it 
would be very nice to have default values, but not many folks will 
even know what closures *are*.

but I think they don't expect some of the side-effects which wouldn't 
be there with closures - at least I thought this until now

closure does not remove the side effects

I don't like the extra block syntax, as that seems clunky. I don't 
care for Max's = syntax, because the = is just non-REBOlish in the 
context of setting a value.

closure allows you to do things that you can't do with funcs

I'd prefer /option: 6

I mean the examples from Ladislav when you use some of the capabilities 
of Rebol and get hit by not copying the context

but is that possible in rebol?

I think we need an extended func dialect.

that's exactly what I mean.

Yes, max, it is.

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