World: r3wp

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)

Not necessarily - most map usage with non-word keys tends to not 
use literal key values. Case-sensitivity wouldn't affect word keys 
(your m/a vs. m/A) so it would mostly affect data that can be kept 
binary end-to-end, if necessary. Still, I wouldn't mind case-sensitivity 
as an option, as long as there was a syntactic way to specify that 
option. No, MAKE can't have a refinement.

Once someone comes up with a decent syntax for specifying case-sensitivity, 
we can do case-sensitive maps.

words have case as well, so word keys are affected as well

is an additional datatype too heavy a way for this?

No, they wouldn't be. Words are case-preserving, not ever case-sensitive.

>> strict-equal? 'a 'A
== false

>> select/case [a 2 A 3] 'A
== 3

>> select/case [a 2 A 3] 'a 
== 2

Weird, I wonder when that started to behave that way.

An additional datatype is a possibility - suggest it in bug#1437.

I wouldn't expect it to succeed though - case-sensitive maps have 
been suggested twice, and dismissed twice.