World: r3wp

I'm sorry, wrong group, that's R3 here, so the above simply doesn't 
apply.

Time for you to chime in, Henrik :)

Hmm... let's see. :-)

I don't think caps lock is possible to capture right now.

Regarding alt-up and alt-down, you just check for them in the ON-CLICK 
actor:

	on-click: [ ; arg: event
		if arg/type = 'alt-down [foo]

When investigating the creation of a MAP function in REBOL 2, I found 
that sending functions with refinement to map required some extra 
work (the need for a DO). The rules about get-words as arguments 
has changed in REBOL 3. Maybe I should talk to Carl about it, but 
I could discuss it with you guys first to not disturb Carl too much. 
First a REBOL 2 version of MAP, that can't cope with refinements:


>> map: func [:f l /local r] [r: clear [] foreach i l [append r f 
i] r]
>> map sine [0 30 90]
== [0.0 0.5 1.0]


f is the function, l the list and r the result. i is an item in the 
list. The critical part is

append r f i


The function f is evaluated taking the argument i. Easy to read and 
understand. But it can't cope with refinements, which are seen as 
the path! datatype. Example:

>> map sine/radians reduce [0 pi / 6 pi / 2]
== [sine radians sine radians sine radians]


This can be fixed by putting a DO before f. Now it works both with 
and without refinements:


>> map: func [:f l /local r] [r: clear [] foreach i l [append r do 
f i] r]
>> map sine [0 30 90]
== [0.0 0.5 1.0]
>> map sine/radians reduce [0 pi / 6 pi / 2]
== [0.0 0.5 1.0]

In REBOL 3, the function is not evaluated:


>> map: func [:f l /local r] [r: clear [] foreach i l [append r f 
i] r]
>> map sine [0 30 90]
== [sine sine sine]

Including DO just makes it worse:


>> map: func [:f l /local r] [r: clear [] foreach i l [append r do 
f i] r]
>> map sine [0 30 90]
== [make native! [[
        "Returns the trigonometric sine."
        value [number!] "In degrees by default"
        /radians "Value is specified in radians"
    ]] make native! [[
        "Returns the trigonometric sine."
        value [number!] "In degrees by default"
        /radians "Value is specified in radians"
    ]] make native! [[
        "Returns the trigonometric sine."
        value [number!] "In degrees by default"
        /radians "Value is specified in radians"
    ]]]

To make map behave correctly, I have to do something like:


>> map: func [:f l /local r] [r: clear [] foreach i l [append r do 
reduce [f i]] r]
>> map sine [0 30 90]
== [0.0 0.5 1.0]
>> map sine/radians reduce [0 pi / 6 pi / 2]
== [0.0 0.5 1.0]

Is this ok and accepted behaviour? Will it break many scripts?
(Sorry for the long post, but I wanted to be precise.)

BrianH: re #1210 - "--import path" ... I almost everytime prefer 
the concept of "current directory". I hate systems, which pretends 
to be "installed somewhere", and then, working with stuff in different 
directory, still pretends the current directory is that of user profile 
or installed app. That sucks big time. I always prefer simplicity, 
or at least things to be settable ...

This seems to work for R3

>> map: func [:f l /local r] [r: clear [] foreach i l [append r do 
get f i] r]
>> map sine [0 30 90]
== [0.0 0.5 1.0]

But it ignores refinements like in sine/radians.

sorry, I did not look

carefully enough

BrianH: thinking about submitting 'Call function for fixes. I gave 
it some thoughts, and I think I am not satisfied with answer, that 
'call will be part of Open Host code - we are waiting for host code 
for 2 years, and there is no guarantee, that we will see it anytime 
soon. I think call should be fixed, or it is big let-down in comparison 
to R2. It messes with console in such a way, that it looks inconsistent, 
and its output can't be trapped easily. It might be a show-stopper 
for some ppl, in regards to R3 deployment. What do you think? Maybe 
it can be improved a bit? We are seening good changes to many natives, 
so why to wait with call for host code release?

Speculating about set- and get- datatypes in relation to:
http://www.rebol.net/cgi-bin/r3blog.r?view=0229#comments


In R2, we have get-word!, set-word! and set-path!. R3 brought us 
get-path! too. Is it a good idea to have things like get-paren! and 
maybe even get-block! and set-block! ?

Carl's set-word! in a block problem could be solved with:

user: [name: "Steve" age: 38]
user/:(age:)


About get-block! and set-block!, today we can set many values with:

set [a b c] [1 2 3]

Why not just write:

[a b c]: [1 2 3]

And a get-block! like:

:[a b c]

should return a block with values like

reduce [a b c]

Just thoughts.

user: [name: "Steve"  age: 38  country: France]
I just have a question. 
How Carl knows my Vital record...

hahahaha

[a b c]: [1 2 3] and :[a b c] , very nice, very rebolish 8)

you really think he meant you?  you're giving yourself to much importance 
 ;-p

Did you noticed that too ?

I did actually hehehe

About set-block and get-block.

If it's only to save the use of SET and REDUCE, i think it's a little 
luxurious.

It would have to work like set-word!s for contexts, to have more 
meaning. Could save a line of code.

I don't see your point Henrik, can u give an example

context [
	foo: fum: none
	set [foo fum] 3
]


'foo and 'fum stays in context with the NONE line. Without it, they 
don't.

...
it's not a good example ;-)
i do this, context [foo: fum: 3]

whoops, I meant like the get-block example above.

set [foo fum] [3 5]

could also reduce the size of some object specifications:

ret-value: [test 7]

make object! [
	[fnc arg]: :ret-value
]

you can with R3
>> set c: construct [a: b:] [3 5]
== [3 5]

>> c
== make object! [
    a: 3
    b: 5
]

or more generally: it can occur often that you need to set multiple 
words sequentially. there should be a syntax for that.

steeve, contexts usually contain much more than that, so CONSTRUCT 
is very limiting here.

it works with CONTEXT too

set c: context [a: b: none] [3 5]

same problem

To me EEBOL is about syntax, and the get block set block idea seems 
very interesting.

what happens when you say:

[a [b c]: d]: [1 [2 3] 4]

very rebolish, but is that very usefull ?

its just like op vs function notation to me...
z: ADD x y 
vs 
z: x + y

I'm not sure it is. :-) but many things don't seem very useful on 
the surface. I'm still thinking in terms of setting mulitple words 
with multiple values in one operation. I hate picking words out of 
a block, one at a time. It becomes more powerful when you replace 
the blocks with words. Then you can use the same program structure 
to set one-to-many, one-to-one, many-to-one and many-to-many words.

yep... like :

z: [b c] 
[a :z d]: [1 [2 3] 4]

rough

if z s a word, IT gets assigned [1 2]  if z is a get-word, its content 
is assigned to the content [1 2], so in the above, b and c would 
be 1 and 2 respectively.

but then:

z: [b c]

:z: [3 4]

or what? :-)

i would prefer another syntax to assign the content instead of the 
container

z:: [3 4]

double :

not bad eh ?

well, its the current syntax  :z already means what I contain.

double colon makes no sense... what are you assigning to z?  a new 
datatype?

but Henrik's  :z:  has me puzzled here:

[a :z: d]: [1 [2 3] 4]

what would the above mean?  hehe

(in current form  of syntax)