World: r3wp

Well, that has to be done by functions that are not inherent to the 
datatype, addon functions. Those addon functions can be built in 
or put into plugins, or both.

Except for the conversion to blocks, which is supported as of alpha 
55.

are you serious ?
to block! and to binary! should be provided

especially to binary!

aswell as-binary

Yes they should. And they will, along with better binary conversion 
methods than to-binary.

AS-BINARY and AS-STRING will not exist in R3 - no type aliasing allowed.

Wtf, i want the reference of the hardstored binary data of the vector.
What the prob ? it's stored as a binary stream

It's a safety issue. That kind of access will be done through accessor 
functions.

you mean the data will be copied ?

I mean the access will be through functions which will hide the internal 
implementation. That doesn't mean the data will be copied.

there is nothing to hide, a vectors is a binary serie

That's the plugin model, in theory (we'll see in practice). R2-style 
structs and routines are insecure.

so to secure it, there will be a copy. If not it can be secured

*can't be

It can be secured if access is through bounds-checked accessors.

By "we'll see in practice", I mean that the current model is not 
yet documented, and has gone through design changes this month.

i don't see your point, if i want a binary serie of the internal 
data of a vector, it's to do all sort of operations we can do on 
binaries

accessor will not protect anything

Except inserting, or changing the length, or changing the data to 
something the vector type doesn't support, or...

Oh Geez, you want protect the vector from modifications ?
So forget my request, vectors will be of no use

i will continue to manage my indexes with plain binaries

No, I want to protect the vector from *bad* modifications. That's 
easy to do, as long as you *don't* do type aliasing.

what kind of bad modification could exist with a binary serie ? there 
is noone.

To my mind a vector should be just a wrapper on a binary serie.

just a new handy way, to modify or get values from a binary

That's my point. There are no bad modifications to binaries, but 
there *are* bad modifications to vectors, depending on the type.

There are unsupported floating point numbers (inf, nan), and vectors 
must be a multiple of their component parts' size.

The types are limited to integers so there are no *bad* modifications.

Oh yes, i forgot about floats

No, decimals are supported too.

yeah yeah ,my bad...

(slow altme)

i vote to discard decimals, if it can be of any help :)

they can use fixed point decimals instead, so users will not complain

Ladislav will complain :(

who's that ? :-)

Quick discussion needed, and here because more people need to chime 
in:


There is a proposal to change the name of the MAP function to MAP-EACH. 
Here's why:

- There's a map! type, and this function is unrelated - except in 
CS theoretical terms, which is why we suggest the name MAP-EACH.

- The other functions that have the name of a type without the ! 
are constructors for that type. The map! type could use one.
- This function is behaviorily one of the *EACH family already.

- This is *not* the functional language map function, and it might 
be good to emphasize that...


In functional languages, functions like map take functions as parameters. 
However, such languages tend to be compiled and the function values 
they take are constructed ahead of time. Since REBOL is interpreted 
and functions are created at runtime, that kind of code pattern tends 
to be inefficient. That is why REBOL control and loop functions tend 
to take blocks instead, and have any argument words to those blocks 
as a separate parameter: It's much more efficient that way.


There is precedent: The REBOL function that corresponds to the functional-langage 
filter function is REMOVE-EACH.


We ask this question now because now is the time to make the change, 
if ever. Not many functions in R3 use MAP yet (the only one I can 
think of off the top of my head is LOAD). This will change when we 
do a hand-optimization pass of the mezzanines, and it will definitely 
be too late once we hit beta.


What do you all think? Please chime in in the next couple days if 
you can (and have an opinion).

No problem to rename it now

I'm taking votes. If it happens it will likely do so in the next 
release.

Thanks for the opportunity to comment.....
I'll vote yes to renaming it away from 'map.

Not sure 'map-each is an _ideal_ alternative, but it is better than 
'map for the reasons given by BrianH.

My vote: I don't want it to be called MAP because of reasons you 
named.. anything reasonable else is ok... 


I can't decide if I like map-each remove-each *-each ... naming convention... 
 

just thinking outloud..

1) you named fold/reduce accumulate ... if you name map/filter in 
similar vein they could be something like  map -> transform  translate 
  alter   apply ?     remove-each -> filter  purge ...


2) common to these functions is that they take a block of code (and 
a series) ... each hints about the serries but maybe more specific 
about them is first part - block of code (function in classic functional).... 
one idea for the common word that hints about  do something with 
block of code as a rule IMHO is with


map -> map-with , transform-with , ... ; remove-with  filter-with 
purge-with ;  fold-with ??

I am OK with renaming too. OTOH I too dislike map-each, remove-each 
names, but not a big deal here ...

(agh ... altme ate my post 2 times!!)


I use the similar with naming for other types of combinators ( functions 
taht take blocks of code) for example


with-sqlite %a.db [ SQL "select * from t;" ]   ( opens db ; runs 
block of code (could bind to words but not needed here) ; closes 
db  ; returns result )

I'm fine with changing it.

Two questions:
1.  is there a way to load-gui from local file ?
2. How is unicode in rebol3 working ?  (is it working ? ) :)

Well, one advantage for calling them something other than map and 
filter is that you could put functional map and filter functions 
in a module somewhere and not have naming conflicts. They'll be less 
efficient and less flexible, but at least the functional programming 
fans would be happy :)

The only reason the *EACH makes sense is the word parameter that 
comes first:
    foreach x data [code]  ->  For each x in data do code
    remove-each x data [code]  ->  Remove each x in data if code
    map-each x data [code]  >  Map each x in data to code

i don't like verbose naming conventions.

vote for change.


funny that I sometimes add the 'in word when typing code ... then 
rebol pops an error... ehhehe  that 'in doen't work on blocks.  ;-)