World: r3wp

And if I want to use filenames as keys, I already need to do `to-binary 
to-string`

You can use filenames as keys as-is, if your code is portable.

No, I can't

Portability has nothing to do with it :)

Ah, your code must not be portable - if it was then you couldn't 
be using filenames that differed only by case.

Let's say I write a script that displays the number of files in all 
current subdirectories

Let's say I want to store those numbers in a map! associating the 
subdirectory name with the count of files

Perfectly portable code, but fails on case-sensitive filesystems

Yeah can't use different case names in map.

Right. Case-sensitive filesystems aren't portable to the main client 
OS'es, or even all server OS'es.

This is why portable use of those filesystems tends to not use filenames 
that only differ by case.

Yes, but that is totally besides the point

There is perfectly portable code that can work as expected both with 
case-sensitive and case-insensitive filesystems

But to write such code in R3, we _can not_ use filename as map! keys 
as-is

There is a way around that on windows I think.

Just collected the short name for all the files using dir/x and then 
you can create a map for all of them.

non-posix ntfs is case insensitive anyway, so it's not really an 
issue on most windows systems

the workaround to write portable rebol code in this situation is 
either not using map! or transcoding the file! keys to binary!

yeah that should work.

Yeah, on Windows the filesystems are case-preserving, not case-sensitive. 
You can mount a filesystem as case-sensitive, but most programs will 
fail when using such files. And most modern Windows don't use short-names, 
since that limits the number of files that a directory can hold.

On Win9x there were always short-names, but on NTFS its an option.

you just use dir/x on NTFS

No, I mean it's an option at filesystem creation time, and a rarely 
chosen option at that nowadays.

It's not an issue on OSX most of the time either since they act case-preserving 
too, afaik.

no rebcode in R3?

No rebcode in R3. Rebcode got its speed from certain tricks that 
don't work as well in R3 due to the changes in the context model. 
However, you can make your ow3n rebcode as an extension if you like 
(one of my pending projects).

Cool Brian.

It won't likely be compatible though - I'm planning to make a more 
REBOL-like dialect. A compatible dialect would be slow.

Yeah was looking for the speed.

It should even be easier with the changes to the command! type that 
are to be upcoming with the new host kit.

what is the command type?

Also can you tell me how to use tasks?

Also can you tell me how to use tasks?

A command is the type of function that you currently use to access 
extensions. Soon it will be more.

Tasks currently don't work.

they do something.

But that something isn't currently multitasking. What they currently 
do is crash REBOL :(

>> do b
Begin Task
End Task>>

Didn't crash it but not sure of the spec

Much of the code in R3 isn't task-safe yet. There is a planned tasking 
model, but it isn't implemented yet.

k

Really look foward to tasks.

As do we all (especialy Doc and Pekr).

an me... even if I haven't ranted about this... liquid is waiting 
for parallel node processing... which requires threads.

time events need that too.

actually i use current tasks to generate time events

Regarding Robert's question about not erroring out when accessing 
non-existent object words, I tend to agree with the current implementation, 
but not necessarily Brian's rationale that errors are our friends. 
There are a number of places where REBOL could raise an error, but 
doesn't, and more have been added in R3. It's a balancing act, and 
depends on what we think most people will use, and will lead to common 
cases being clearer and more correct. 


I think it would be great to collect language design questions, and 
have Carl answer them. It would be good for REBOL. Some answers may 
be "we tossed a coin", and that's OK too, but many will have deep 
or important answers that may just appear as caprice from a user's 
perspective.

On STRICT-EQUAL?, I'll also cast my vote that keeping doc strings 
short is a good idea. But if a doc string is unclear, incomplete, 
or just plain wrong just so it won't wrap on a text console in a 
HELP listing, Our priorities are severely out of whack.. Let me know 
if I need to take that opinion directly to Carl.

Proposal - Templates


Summary:  Templates would be code blocks that can be bound into other 
code and become part of the context in which they are called.

implements  a Template! type

template function 

template word block

The word argument is the template word that you define

The block argument is [some [word! block!]] where word is the different 
words you define for the template and the block is the code that 
gets reduced when the template word is encountered.

Operation:

mytemplate: make template! [count [print c] release [clear blk]]
mytemplate/release


Since I used /release which was defined in the spec all code where 
the word mytemplate is used will take on the action of the release 
which is to clear the blk word!

Rather than add a new datatype for case sensitive map!s, I've added 
a ticket #1494 requesting the hash! datatype be added to Rebol 3.