World: r3wp

If you ask me it is that head seems to be a problem with the file 
port.

unless we mean to modify those ports now without setting the port.

in other words head and next operate on file ports much differently 
then I would have expected.  I would have expected to have to do 
this:

port: head port

but this works:

head port

Next is the same way.

Again, if this is the intention - then I like it - and not sure if 
there is indeed a problem with length? but maybe our need to understand 
how to use it R3 ports.

I made some significant changes already to R3DBMS based on some of 
these findings and getting great results.

Doh wrong group.

R3..."Cannot upgrade from web."


using a96...is the server down or is there a prob with this version?

working now...never mind

Here is something I think that could be changed in R3 (and I'm pretty 
sure a lot will now explain me why it's not possible):

>> a: [1]

== [1]


>> a/1

== 1


>>
 a/255

== none

If we now have an object:

>> a: make object! [a: 1]

== make object! [
    a: 1
]


>> a/test
** Script error: cannot access test in path a/test


IMO it would make our life a lot easier of the last one would return 
NONE as well.

As object! is being used more and more now in R3 and (within the 
GUI) a lot of words in objects will only be present if there is a 
value available, we have to cross-check a lot more if specific words 
are present. And this can pollute the code.

so you want to access a missing value in an object and have it return 
none?

That's going to make it more work to determine if the value is none 
because it's missing or because it's none

It could be unset! or even a special NP! (not present). Javascript 
has a nice rule that it just skips things that are not there without 
an error. It makes the code very simple. And you can still test explicitly 
if it's available.

I would worry that it would make finding bugs harder

Anyway it sounds like a fundamental change .. to make all paths return 
an unset! value instead of an error if the path is absent.

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...