World: r3wp

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.

The additional case-sensitive map! type idea sounds better to me 
than hash!, but I'll wait for consensus.

Gregg, the reason for the most of the changes where R2 threw errors 
and R3 doesn't is specificly to make errors more friendly. We're 
trying to limit the situations where errors are thrown to ones where 
you want errors thrown. This makes errors more useful. And there 
are workarounds for the occasions where the condition isn't an error. 
In the case of object! field behavior, there are two workarounds: 
Using SELECT, or using the map! type instead. Both workarounds are 
simple, and commonly used in mezz code in those occasions where field 
absence isn't an error - rare occasions merit SELECT, common occasions 
merit map!.

This is one of those cases where this is an example of errors being 
our friends, rather than that being the rationale. An example of 
errors not being friendly was the R2 bounds checking error on ordinal 
functions, so that condition was redefined as non-erroneous. If you 
need series bounds checking to be erroneous it is quite easy to check 
for that, efficiently (I'd recommend ASSERT). Years of REBOL code 
have shown that this is the less common case though, so R2's behavior 
led to a lot of extra screening code.

Paul, how is that different from an object full of no-argument functions? 
And keep in mind that code doesn't actually exist in a context. Words 
are bound to a context; blocks aren't. Ironically, this means that 
contexts aren't contextual - it's kind of a bad term for the concept.

So in your example, mytemplate/release wouldn't be able to get the 
bindings of 'clear and 'blk from the calling context, since there 
isn't one. In order for the template to know what context to bind 
those words, a reference to that context would have to be passed 
as a parameter. The way that nested contexts are emulated in REBOL 
is through iterative overrides, not real nesting.


Making template! a datatype wouldn't help with this - it's part of 
the core semantics of REBOL. This is the same reason why the script 
or module Needs header can know what the target context to bind or 
resolve to is, but the IMPORT function can't.

Gregg, as for the STRICT-EQUAL? doc string length limit not allowing 
us to have its most important behavior mentioned, we don't have evidence 
yet that this is the case, and it seems unlikely. Noone mentioned 
the case sensitivity needing to be there before, and now noone has 
tried to phrase the doc string accordingly. I suggested that a documentation 
ticket be submitted with new phrasing, and just mentioned the limit 
(and its rationale) for the information of the person doing the submitting.


We need to have some limit on the length doc strings for a variety 
of reasons, not the least of which is that it is good to be concise. 
Many built-in functions can't have thorough documentation in their 
doc strings no matter how long we make them. The doc string is just 
a smmary for some functions, a reminder for others. The full docs 
should go on the web site accessible from HELP/doc. And if there 
isn't a web site for one of the system words, or if it's wrong or 
outdated (which is a lot at this stage) then report it.

Peter, I added a supporting comment for your ticket. Good luck!

Brian, agreed. My point was that we should'nt have a fixed limit 
of 70 characters (for example) that prevents us from using 75 characters 
for a func that really needs it. STRICT-EQUAL? was just the example 
at hand.

Brian, the reference would be the template word that is defined. 
 The word would be bound to the context and assigned to the block 
when called.

So the mytemplate would be the word that gets bound to the context. 
 mytemplate/release is just a way of telling it BEFOREHAND what block 
to bind to the word.

The problem may be where we would want to switch context again  for 
example ifI wanted to later use count.

A correction to BrianH's STRICT-EQUAL? response: "noone has tried 
to phrase the doc string accordingly" is factually incorrect, as 
can be easily seen in the log. I posted two rephrasal suggestions.

The two suggestions from Andreas:


1) "TRUE for values that are equal and of the same case and datatype." 

2) "Returns TRUE for EQUAL? values that are of the same case and 
datatype."

I'll add the following option:


Returns TRUE for values that are equal and of the same case and datatype.
 


Which is just Andreas's #1 with "Returns" at the head, to match the 
doc string for EQUAL? and others.  That makes it 73 chars total. 
I don't think that's a problem, but I also don't think it's neccessary 
in this case. It wouldn't hurt of course, but certain information 
may have to be elided from doc strings, and this piece of information 
for STRICT-EQUAL? is easy to deduce and understand IMO.

I have two refined suggestions posted as bug#1497.

Returns TRUE if the values are equal.

And regarding the necessety, maybe it's just me, but when I compare:
- Returns TRUE if the values are equal. 
- Returns TRUE if the values are equal and of the same datatype. 

I would deduce that "and of the same datatype" is the only difference 
between those functions. I personally have been with REBOL long enough 
to know that this is not true, but I still think that these docstrings 
in this case are misleading.

Who tested map! with case-sensitive lookup capabilities.  And what 
workaround did you used ?

One workaround is to not use MAP! at all. The other workaround is 
to convert keys you want to be case sensitive to BINARY!.

Nice, here i go for binaries.

Andreas, what about something like one of these:


- "Returns TRUE if the values are strictly equal and of the same 
datatype." 

- "Returns TRUE if the values are strictly equal and the same datatype." 

- "Returns TRUE if the values are strictly equal, including their 
datatype." 

- "Returns TRUE if the values are strictly equal, including datatype." 


We can argue that just adding the word "strictly" doesn't help, but 
then the help for EQUAL? isn't very helpful either. :-) My thinking 
here is that there are a number of things that may seem confusing 
about strict equality, and we can't address them all in the doc string. 
Case sensitivity is important, and if we want to single that out, 
I'm OK with it, but might there be other cases as well?

>> strict-equal? d1 d2
== true
>> d1
== 16-Feb-2010/13:25:30-7:00
>> d2
== 16-Feb-2010/14:25:30-6:00
>> equal? [a] [A]
== true
>> strict-equal? [a] [A]
== false
>> strict-equal? 'a 'A
== true 


R3 addresses those cases, but are there others? What about user defined 
types (not sure what the status or goal is on utype! values at this 
point)?

Yes, just rephrasing the strict-equal? docstring as "Returns TRUE 
if the values are strictly equal." woul also be an option

I would then drop mentioning datatype equality, so that an interested 
user will have to consult more detailed documentation on how strict 
equality is defined

And yes, all the cases you mention no longer hold for R3.

But actually, I quite like "Returns TRUE if the values are strictly 
equal." This does not lead a user who reads only the docstring to 
wrong conclusions.

Request for help received via REBOL.org's feedback form. If you can 
help, please post here and I'll forward him the URL of the archive:

===============

Using Rebol 3.0 Alpha, 2.100.97.3.1, how can I save the value removed 
from a series when I use the remove function? See example 1 below; 
I would like to be able to save the value "red" in a variable.  Can 
a "parse" statement be used instead of the remove. How would it be 
coded?

See example 2 below. Should'nt the value be "red"

example 1
text: "redblueyellow"
== "redblueyellow"
remove/part text 3
==text: "blueyellow"

Example 2
saved-text: "redblueyellow"
== "redblueyellow"
difference saved-text text
== "d"

I tried this an hour later and got 
== "rd"
===============

Save the value: use TAKE instead of REMOVE

And DIFFERENCE treats the two strings as _sets_ of characters (i.e. 
they are internally UNIQUEd) and returns only those characters which 
are not present in both strings.

Here's an example for TAKE:

Is there a useful DIFF-type function anywhere that extracts the substring 
differences between strings?

>> text: "redblueyellow"
== "redblueyellow"

>> take/part text 3
== "red"

>> text
== "blueyellow"

IIRC Gabriele and Bohdan both have provided diff-style scripts for 
R2 in the script library.

Strictly
 per current behavior of R3, just tested:

- For decimal! it means more precise comparison (17 digits versus 
15 by default, also with EQUIV?).
- For string types it means case-sensitivity.

- For word types it means case-sensitivity and binding (only binding 
for EQUIV?).
- For block types it means strictly equivalent contents.

This seems reasonable to me, but it should be documented. I'll review 
the ticket mentioned above.

Thanks Brian, much appreciated.

I updated the docbase "comparisons" page to reflect this: http://www.rebol.net/wiki/Comparisons#EQUAL.3F

Added a comment to that ticket, with a suggestion for doc strings 
that fit the limit:

- STRICT-EQUAL? "Returns TRUE if the values are equal and of the 
same datatype, case."

- STRICT-NOT-EQUAL? "Returns TRUE if the values are equal and of 
the same datatype, case."

Nice, consise, and 68 and 69 characters, respectively, no problem. 
You can even change "datatype, case" to "datatype & case".

eh?

STRICT-EQUAL? == STRICT-NOT-EQUAL?

Sorry, replace TRUE with FALSE (as I did in the comment).

That was a typo above.

why do we need both?

Because != and <> need a function to redirect to.

And you can use STRICT-NOT-EQUAL? as a function value if need be, 
but not NOT STRICT-EQUAL?.

maybe we should dispense with all infix operations

make life very messy!

People like them. And they'll like them more when you can make user-defined 
op! functions.

Returns TRUE if the values are equal and of the same datatype, case.

That ending doesn't read very well to me.