World: r3wp

Geomol: i was just using new-line recently for example to create 
a simple "json database". i was saving json-to-rebol object hierarchies 
into plain text files, but before that i converted each object into 
pure blocks, so it has less brackets... no #[object! ...] shit. but 
it destroyed the new-lines, so i had to but them back manually, so 
the text file is still human processable.

i think this new-line thing is a gem in rebol. one of those usability 
enhancements which are nicely hiding under the surface, not getting 
in the way, but does automagic if u want. out of the box... things 
like this makes rebol sexy. just like apple products... those lots 
of little things...

Ladislav, would you prefer, if lesser? and greater? worked on all 
combination of datatypes then? And then just let the sort rules deside 
the outcome.

would you prefer...

 - in this case, my preferences don't matter, as it looks, although 
 I think that I suggested what they are. Cf. also above " you have 
 to make a really complex comparator function" - I do not think this 
 is desirable.

I should have rather said, that I did not find that useful.

Is red greater than banana? Some comparisons are meaningless. The 
extra comparisons that SORT does are only useful as placeholders.

Exactly as I said: "meaningless" is not an argument

What is meaningful is the ability to sort

The errors triggered by LESSER? and such when presented with meaningless 
comparisons are useful, especially for debugging. I recognize that 
SORT benefits from these placeholders, but LESSER? and such benefit 
from their absence.

meaningless

 is meaningless, it is exactly the same argument as saying, "zero 
 as a number is meaningless". Whole nations Greeks, etc. maintained 
 that opinion, but their argument was proven meaningless.

The errors triggered are useful *for those functions*, as they help 
the developer track down places where their code doesn't make sense, 
usually because they are missing a guard or conversion somewhere. 
For SORT they aren't as useful, hence the placeholders and fallbacks.

Everything can be easily transformed to the zero case. The argument 
of "zero is meaningless" promoters was, that it helps the computers 
(people, at those times) to "track down the places where their calculations 
do not make sense"

Sorry, but I don't agree with the zero case, and I do agree with 
5 not being greater or less than yellow. So that argument falls down.

I just wanted to demonstrate the isomorphism of the two cases, so 
that everybody could see it.

NEW-LINE is magically delicious to me. I do quite a bit of code and 
data generation, so I use it a lot.

By dialected, I mean the arg to the func is a dialect. When discussed 
before, one question was whether to make the block a separate arg.

a: [a b c d e]
b: [1 2 3 4 5]
new-lines [
    all on in a
    on in b every other item
]


Ladislav is right on naming, that it violates the verb-first convention.

I called my dialected version NEW-LINES, to match the standard func, 
then tried LINE-MARKERS. I don't have a problem with adding SET- 
to the head though.

Ok, thanks Gregg. Cool with such dialect to make newlines in blocks.

Tonight's Moment of REBOL Zen:

>> s: [1 2 3]
== [1 2 3]
>> t: tail s
== []
>> remove/part s 2
== [3]
>> back t
== ** Script Error: Out of range or past end
>> index? back t
== 2
>> index? back back t
== 2
>> index? back back back t
== 1

Zen in this case just being R2's bad behavior with out-of-bounds 
references. You forgot this:
>> index? t
== 4
This is the only part of the behavior of INDEX? that makes sense.

>> s: [1 2 3]
== [1 2 3]
>> t: tail s
== []
>> index? t
== 4
>> remove/part s 2
== [3]
>> index? t
== 2

Never mind, INDEX? just sucks in R2 with out-of-bounds refs. That 
is part of what we tried to fix in R3.

Regarding the "comparison is meaningless", or "SORT doesn't have 
that luxury though, because it is designed to not fail" philosophical 
arguments. They, in fact, are not valid at all. The facts are different.


* For large lists which are frequently searched it *is* useful to 
have them sorted. 

** The reason is, that it is much easier to perform searches in a 
sorted list, than in an unsorted list.

** The "meaning" of the sort order is to facilitate searches, no 
other meaning is needed. (it is like the zero case, the meaning of 
zero is to facilitate the positional representations of numbers, 
no other "meaning" is needed)

* The whole "sorted list business" needs comparison functions (for 
searching, etc.)


The above "meaning" is one meaning comparisons do have. It suffices 
to prove, that comparisons are not "meaningless". (for that it would 
be absolutely necessary, that we can find no meaning at all)

It shouldn't be possible to order pairs, like complex numbers.

 - the set theory uses the axiom, that can be formulated so, that 
 it should be possible to sort any set so, that it becomes well ordered. 
 Of course, it is useful to have even partial order, like the one 
 you mentioned, but nobody said it was the only ordering possible.

The only thing not possible is to sort the complex numbers so, that 
the ordering is in some useful way "compatible" with arithmetic operators.

The problem of SORT, which I am not sure we are able to address, 
is the Unicode-aware sort ...

Individual nations have individual collating sequences - norms prescribing 
how strings shall be ordered. Thus, "Unicode-aware sort" is something 
like a unicorn.

It definitely makes sense to me to expose SORT's basic grouping or 
sorting mechanism, so you can build your own sorter around its logic. 
I'm not sure I care about what datatypes come first or which order 
the "meaningless values" come in, just as long as it's consistent 
with SORT.

You can just use SORT to access SORT's sorting mechanism, no?

(Obvious performance implications left aside.)

Ladislav, you are arguing that those comparisons have *use*, not 
*meaning*. They definitely have *use* in SORT, mostly as placeholders 
and fallbacks, so that SORT can be used as you describe above on 
heterogeneous data. But that doesn't mean that those comparisons 
have meaning.

SORT needs there to be an ordering between pieces of data in order 
to sort them. Whether or not that ordering has meaning, SORT needs 
it to exist because it need to use it. So in the cases where there 
is no ordering that has meaning, SORT uses ordering methods that 
don't have meaning. They are useful, but not meaningful.

SORT itself is useful for the reasons you give above.

They definitely have *use* in SORT

- as far as I am concerned, I find it "meaningful" to implement a 
feature of the language that is "useful" (but that may be just me)

But there are much more important issues:


* the users shall be able to use their own sorting functions applying 
useful comparison operators (SORT has known issues)

* the users shall be able to utilize the advantages of having the 
data sorted, which, again, is possible if the compatible comparison 
functions are available

Regarding the "meaning" of ordering. If we examine some of the orderings 
you eventually might find "meaningful" we can come to the conclusion 
that they are not the only alternatives possible, and thus are actually 
"meaningless" as well in that respect. To support the "most meaningful" 
ordering for the specific data SORT supports the /COMPARE refinement, 
which proves the point, that even the ordering one user finds "meaningful" 
may lack "meaning" for another.

For example, I bet that the order REBOL uses for strings currently 
is "meaningless" for Pekr, who would prefer something more "meaningful".

Is there a way to retrieve the name of an object that is referenced 
by another word?
layout  [ a_field: field [ ]  ]
b:  a_field
....
What I want is to somehow get "a_field" given b.

Is there a way to retrieve the name of an object that is referenced 
by another word?

 - only if you provide some (keep track of such things in your program)

Is that right. I would think that it is stored somewhere in the system.

for example, it is quite common to do something like:

a: make object! [name: 'a]

You can even define a function doing that for you.

Yes, I see that. I'll just go that route then. Thanks Ladislav.

James, in th case of LAYOUT dialect you can get the name this way:

>> b/var
== a_field
>> type? get b/var
== object!

etc.

Cyphre, thanks a milion!

This is about the HTTP scheme, but I can't find a group for R2 schemes.


Does anyone have a patch for the HTTP scheme that handles 204 (No 
Content) responses where no headers are returned? The standard scheme 
throws an error as there are no headers to parse. Here is the 'success 
case handler:

        success: [
            headers: make string! 500

            while [(line: pick port/sub-port 1) <> ""] [append headers join line 
            "^/"]

            port/locals/headers: headers: Parse-Header HTTP-Header headers
            port/size: 0

            if querying [if headers/Content-Length [port/size: load headers/Content-Length]]

            if error? try [port/date: parse-header-date headers/Last-Modified] 
            [port/date: none]

            port/status: 'file
    ]


For anyone familiar with the scheme, would the proper behavior be 
to set all related 'port fields to zero or none? e.g.

            port/locals/headers: headers: none
            port/size: 0
            port/date: none
            port/status: none

And should it only do that in case of a 204? It's not clear if a 
304 response may also be affected.

RFC2616 says 304 MUST inlcude a date field.

If it's just 204, it looks like the cleanest solution would be to 
add a success-204 response action block.

The main problem with R2's HTTP scheme is, that it does not provide 
response-code even in cases where it should, like:

port: open/direct some-url


Without available response-code you have no chance to differentiate 
responses like 204 or 205 which has special meaning =

http://benramsey.com/archives/http-status-204-no-content-and-205-reset-content/

I think the most practical solution is to provide response-code in 
port/locals and return none for 204 and 205.