World: r3wp

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

instead of strict-equal?

You can't have an op! call a function with a refinement. STRICT-EQUAL? 
is only there to be the prefix form of ==.

While we are at case sensitivity: any ideas how to proceed regarding 
a case-sensitive MAP!?

Brian, I think you mentioned a few days ago, that this issue needs 
dicussion.

Maybe adding a strict-map! datatype that would raise an error for 
path accesses could be a solution?

And if we are comfortable with the idea that m/a and m/A will typically 
return different values, then we could drop the path access restriction.

I believe the result of the discussion (so far) was to use binary! 
encoded keys for case-sensitive maps.

At least in my typical usage scenarios, a get from a map far more 
often than I put into a map.

Yup, and that is the usage pattern that maps are optimized for.

Using binary! for keys would then have two effects:
- Lots of code gets more unreadable
- A map! is unsuitable for anything performance-related

`a/(to-binary k)` vs `a/:k`, in the simplest case

performance will be less of an issue once we have support for a fast 
codec (utf-32/ucs-4), leaving mostly the extra function call(s)