World: r3wp

All for the sake of not having to write some error trapping code

Robert, the whole advantage to objects is that for them it actually 
matters whether the field is there. Otherwise, binding wouldn't work. 
If you need the kind of behavior you propose, use the map! type instead 
- it acts exactly like that.

We like errors in R3, they are considered the programmer's best friend. 
The error you are complaining about is considered a feature.

What about a way to set an error level?  Only want to see levels 
of a particular severity ...

It is not for us to say how severe an error is, short of a system 
crash; that is up to the programmer. The SECURE system can declare 
some things as being allowed or not. For the rest, use TRY/except 
and check the error code in the exception block, and retrigger the 
error if it isn't something you can handle.

Why is "foo" equal?/= "FOO" but "foo" not strict-equal?/== "FOO" 
?

Brian: Ok, but I never liked the difference between block!/map! and 
object!. Looked always artificial to me. I chatted about this with 
Carl some long time ago. And IIRC he said that he thought about the 
split as well and if it can't be eleminated.

Andreas, strict-equal? does case-sensitive comparison. That's why 
it's a separate function :)

Then the docstring is misleading, I guess.

Will report a bug that the docstrings of equal? and strict-equal? 
are extended to mention behaviour wrt case.

The current docstrings:
equal?: "... if the values are equal"

strict-equal?: "... if the values are equal and of the same datatype."

There are character length limits to what you can put in a doc string. 
That is why we make the manual web page accessible from the R3 command 
line. It was the same in R2.

Please note that I don't consider "it was the same in R2" to ever 
be a legitimate answer to R3 quirks :)

Got it, I should see bug#666 :)
But that's not a quirk, that's part of the design.

The docstring length is by design?

Robert, the reason that we have the map!, block! and object! types 
is that they behave differently. If they behaved the same, we would 
only need one type. Pick the type that behaves the way you want for 
the circumstances, and pick another type for different circumstances.

Andreas, the docstring length is limited by what won't word-wrap 
in an 80-character console when you use HELP. For more details, use 
HELP/doc to get to the web page for the function.

See, that's what I call a quirk. We could simply use a word-wrapper 
to format help output in the console, and allow the docstring to 
be slightly longer.

>> help/doc map!
map! is a datatype
It is defined as a name-value pairs (hash associative)
It is of the general type block

No values defined for map!

ie. no web entry

The limit is considered a feature, to keep the doc string short, 
easier to read quickly. There's a web page with more details. You 
keep calling quirks what we are doing on purpose :)

Yes, I understand that feature. Only the limit is arbitrary.

Graham, that's a bug in HELP, so report it :)

For example, when using the "search mode" of help, docstrings are 
truncated (using "..."). Or the indentation by 8 spaces in HELP robs 
the docstring of 8 possible chars.

I'd rather have a limit to be exposed explicitly: document somewhere 
that docstrings are to be of 72 chars max. And then have HELP take 
care of how it formats the output given this constraint.

It doesn't matter what the limit is, only that there be a limit. 
Be consise in your doc strings, detailed in the manual.

do any of the datatypes have web entries accessible by help?

A doc string that is longer than the limit can be reported as a bug.

Graham, don't know. Check it out.

what is the limit? 71 as per the current HELP output?

It's a bug in the help system

Andreas, doc strings have to fit on a punch card

So? It's an advantage to make the doc string only fit on one line 
- it takes less space and is qicker to read. The doc string is more 
of a reminder than detailed documentation. Most functions need a 
full manual page to explain their behavior.

Yes, that's great

I will figure out a way how to squeeze a case sensitivity remark 
into the strict-equal?

If you can phrase it,m suggest it. And remember that most types that 
== applies to don't even have a concept of case, but have other constraints 
that == makes that = doesn't...

if the values are EQUAL

uses no more characters

Case is pretty important, though, so it warrants en explicit mention 
in the docstring.

The other constraints are not even documented on the docs page, at 
the moment.

So if you know any such constraints off the top of your head, please 
add them to the page.

Two suggestions:

>> length? "TRUE for values that are equal and of the same case and 
datatype." 
== 65

>> length? "Returns TRUE for EQUAL? values that are of the same case 
and datatype."
== 70

but i guess you'll want a mention then that case is not applicable 
to all types ...

>> strict-equal? 1-Jan-2010 1-JANUARY-2010
== true

since date has no case, it doesn't matter ...

>> 1-JANUARY-2010
== 1-Jan-2010
>> 1-JAN-2010
== 1-Jan-2010

Yeah, I guess it's a question of what would be considered more irritating: 
STRICT-EQUAL?s docstring pretending that it only differs from EQUAL? 
in that it also considers the datatype. Or mentioning case-sensitivity 
explicitly.

Robert, if you want object! to behave like map!, use SELECT. SELECT 
object! 'field returns none if the field isn't there.

Thx. Yep, that's a good way.

If you're talking about changing object behavior, that would require 
rewriting a lot of mezzanine code. There are many cases where a field 
not being in an object is an error, and it triggering an error is 
relied on in a lot of mezzanine code. If it stops triggering an error 
then we would have to change a lot of code from o/field to EITHER 
in o 'field [o/field] [cause-error ...].

interesting ... 'select now works on objects ... whereas I would 
have normally used 'in

Since the /case refinement is used elsewhere .. why not have

equal?/case