World: r3wp

Regarding the values of "refinement arguments" - I still miss more 
opinions, than just Max's.

On one hand is the fact, that we have lots of code using this.


On the other hand is the fact, that it is a beginner's gotcha being 
incompatible with the help string of the VALUE? function, as well 
as with the behaviour of the interpreter in other, quite similar, 
cases.

If it can be changed in R3, I think that unset! makes more sense.

For unused /local values. For unused refinements I think they must 
be #[none] to be able do code like:
f: func[/switch][ if switch [ true ] ]

why unset! ?  If you've defined them, presumably the intention is 
to use them

The gotcha is not whether a variable is "defined", but whether it 
has been set.

Nevertheless, if we have a comprehensive documentation mentioning 
this, we can easily use either, since for every experienced user 
it is easy to remember that "unused refinement arguments" are set 
implicitly to #[none]

I tend to like them being NONE, but I'm not strongly opposed to using 
UNSET instead

thanks

I'm with Gabriele on that.

I am strongly in favor of optional function arguments being none 
by default. When combined with type tests that prohibit the none! 
type, it allows you to easily use data flow analysis to handle the 
control flow of the different options. You have to realize that none 
is a non-value too. The main difference between none! and unset! 
is that unset! is usually chosen when a non-value is an error, and 
none! is chosen when it is less likely to be an error. And for function 
arguments, not choosing an option is normal behavior.

Oldes, /local is just another function option, nothing special. It's 
only treated specially by the HELP function, not by function evaluation.

I thought I posted my opinion, but I prefer none. I only use unset, 
intentionally, in exceptional cases.

Ladislav, I don't have to "remember" that optional arguments are 
#[none] by default: Most of my code absolutely depends on it. Handling 
unset values is a big hassle, on purpose. I don't want to go through 
that hassle for a normal situation, just for exceptional situations. 
We are supposed to use unset! to trigger errors.

none none none...

my opinion is optionnal though

but not unset

Apparently the option was taken :)

steeve.... ;-)

Thanks, Gregg, for reminding me, I somewhat missed that your previous 
post mentioned your preference

So, currenlty I am having 9 opinions. Hoping, that I can get even 
more.

My opinion is none

None for me!

None - add an /any refinement to value? (consistent with 'get)

chris, your /any refinement would likely always return true.

when rebol encounters (loads) a word with never encountered before, 
its automatically added to the globals and its is set to unset!  


so just the fact that you've actually put the word in a script, even 
if its never explicitely been explicitely managed by code yet, will 
force the value to be unset!

ex: 
>> ['!!!!!!!!]
>> probe copy/part ( sort first system/words ) 10
[! !!!!!!!! != !== * ** + ++ - --]


so you see, even using it as a lit-word, its already in the system 
words, so asking for an /any, will always return true.

Hi Chris, how a /any refinement to value shall influence the behaviour?

Max, I was thinking kind of the opposite, though it'd break the current 
usage of value?  (in truth it needs another function probably, but:

>> apple: none
== none
>> value? 'apple
== false
>> value?/any 'apple
== true
>> value?/any 'orange
== false  ; in /core at least

AFAIK, your last example would trigger true no matter how we try 
to define it, cause the fact that you wrote 'orange and loaded it, 
it is defined as unset!  ' :-/


the reason is that words actually are just integers internally, and 
loading a word adds it to that list, so it can be used later.  this 
is why word comparison is so fast, its just comparing two integers.

Chris, we have another function already: DEFAULT. It converts none 
or unset to a default value. This deals with the most common case 
of what to do when you have uninitialized values. The other cases 
are handled by ASSERT/type or conditional functions, though conditional 
functions won't work without extra help if we make optional function 
args unset by default (the extra help being UNSET?, VALUE? or get-words 
and op tricks, the hassle I was talking about earlier).

I have a host-kit, that allows multline commands.

I am thinking, if it makes sense to extend it to mulitiline strings.
How far is the console mode for R3?

seems to work

I don't think that there is somebody working on console code.

console hasn't moved and likely won't move until hostkit is done.

Carl says he has tried to build R3 for Solaris, and AmigaOS

And is going to try a 64 bit build since the Solaris pc provided 
by TomC is 64 bit ( .. umm... aren't all PCs 64 bit ?? )

New ones are. Most PCs are not new.

I'd say all PC's are mentally from 1981. :-)

You are generous, Henrik :)

so Carl is doing a C64 build?

Commodore 64? That would be something, but I doubt it.

No ...

I was just adding voluntary confusion  ;-)

he would have to build a REBOL using BASIC hehehe

Well as long as you weren't forced to, I'm sure you'll be fine. Get 
well soon! :)

Maxim, there are C compilers for 6502 :-) I think we discussed this 
earlier.

64 bit CPUs have been around for some years now

whether people are running a 64 bit OS is a different matter

I'm happy to see a Solaris build being attempted.

he doesn't say what fails though ... whether it was the core or the 
gui