r3wp [groups: 83 posts: 189283]
  • Home
  • Script library
  • AltME Archive
  • Mailing list
  • Articles Index
  • Site search
 

World: r3wp

[!REBOL3-OLD1]

Gabriele
6-Apr-2006
[209]
max, refinements are logic (none or true), they don't get a value
MichaelB
6-Apr-2006
[210]
what about using a refinement in general for a optional intialization 
block ?
Gregg
6-Apr-2006
[211]
Yes, I'm in agreement with you here Max, just not the = syntax.
Maxim
6-Apr-2006
[212]
and depending on the needs of the func spec, it switched to closure
Gabriele
6-Apr-2006
[213]
so you'd have /option val: 77, but this is a potential problem with 
return: in routines for e.g.
Gregg
6-Apr-2006
[214]
Michael, I don't know if that's any better than an extra block, because 
you have to redundantly name the values.
Maxim
6-Apr-2006
[215]
why use two words.
Gabriele
6-Apr-2006
[216]
because you have refinements without args, with one arg, with two... 
and so on
Gregg
6-Apr-2006
[217]
I think default values need to be specifiable like help strings are, 
but I haven't thought about the specific syntax yet.
Gabriele
6-Apr-2006
[218]
/option, /option val, /option val1 val2
MichaelB
6-Apr-2006
[219]
what I think is that not everybody wants it (because could be optional) 
and a refinement would add it if wanted
Maxim
6-Apr-2006
[220]
but the word is ALWAYS set, so in the context of its useage, its 
not optional.
MichaelB
6-Apr-2006
[221]
I know there are drawbacks, but why not 
f: func/init [arg] [print arg] [arg: 2]
and
f: func [arg][print arg]
Maxim
6-Apr-2006
[222]
cause the init block can be 2 pages further down the editor?  ;-)
MichaelB
6-Apr-2006
[223]
this breaks no code and uses the existing facilities 

yes that's the drawback
Gregg
6-Apr-2006
[224]
I thought of that too, and came up with the same problem Max did. 
:-\
Maxim
6-Apr-2006
[225x2]
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
Gregg
6-Apr-2006
[227]
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.
Maxim
6-Apr-2006
[228]
it also allows local vars within face action  :-)
Gregg
6-Apr-2006
[229x3]
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.
MichaelB
6-Apr-2006
[232x2]
f: func [arg (1)][print arg]
?
Gregg
6-Apr-2006
[234]
e.g.  fn: func [/opt n [(0) integer!] [print n]
Maxim
6-Apr-2006
[235]
Gregg, you mean:

f: func [/opt value [44 integer! none!]] [ print value]
Gregg
6-Apr-2006
[236]
<he he>
Maxim
6-Apr-2006
[237]
problem with the parens is that it gets in the way of compose
Gregg
6-Apr-2006
[238]
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?
MichaelB
6-Apr-2006
[239]
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
Gregg
6-Apr-2006
[240]
We can decide on any semantics, paren or any literal value, since 
it's really just a convention, like /local in the spec.
MichaelB
6-Apr-2006
[241x4]
f: func [/opt n [#12 issue!][print "or something like that"]
this looks pretty natural IMO ?
more than with paren!
there was a ] missing
Maxim
6-Apr-2006
[245]
hum... not sure about the #  obscure, especially for newbies...  
depends on the datatype    ##{a}  ,   #'toto
Gregg
6-Apr-2006
[246x2]
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.
MichaelB
6-Apr-2006
[248]
sorry that was just because n was a issue! datatype - I thought
Maxim
6-Apr-2006
[249]
ok.
MichaelB
6-Apr-2006
[250x3]
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
Gregg
6-Apr-2006
[253]
This is something we could mock up today, to see how we like it.
Maxim
6-Apr-2006
[254]
Michael, is your example different from what I posted last?  I see 
no difference...
MichaelB
6-Apr-2006
[255]
no :-) I see.
Maxim
6-Apr-2006
[256]
but keeping with consistency, not having any : in there does not 
seem right.
MichaelB
6-Apr-2006
[257]
where you wanna put the :
Maxim
6-Apr-2006
[258]
HA!  if the value is a set word?