AltME groups: search

My point is that I think it's an optimization that has bitten more 
than a few people

Maarten's S3 lib has a bug on this account.

That is not what MOLD is for, that is a job for custom formatting 
functions.

I think I'd like to see a flag or something that sets the number 
of decimal places for decimals, and number of places for time.

Given that the "missing" parts of the precision aren't actually missing, 
sure, that works. And the standard allows those portions to be not 
depicted, just assumed. If you have to generate something less flexible, 
that is a *different* standard, so a different formatting function 
is appropriate.

That diferent formatting should not be standard. Generating code 
that is more complex than it needs to be is just a waste of space. 
Remember that MOLD output need only be compatible with REBOL code, 
not with any other syntax processor, and you see that it isn't a 
problem.

Decimals aren't output with 17 zeroes either, because that would 
be a waste of space.

Yes, I'm suggesting that a system wide flag should control the display

Settable system-wide flags that affect MOLD are a bad idea, since 
they mean that you have to put wrapper code around every call to 
MOLD to make sure that it matches what your code expects. This makes 
very call to MOLD more complex and less task-safe.

That is why there is a proposal for R3 to make all such options be 
specified at the point of call, not globally. Any global option like 
that would be protected from modification, or else it wouldn't be 
allowed.

What you want isn't MOLD, it's a different formatting function. MOLD 
is for REBOL source, not for S3.

this who "binary" talk is quite fucked, btw. as if carl never worked 
w low-level stuff... but after seeing a whole nation (singaporeans) 
calling the desktop machine CPU, im not surprised... just disappointed..
wtf does binary-base mean? binary already means number-base 2...

if it's a date with no time portion, then date/date gives you an 
error.


It works for me. Or maybe I'm doing it differently. A date! always 
has a time value, correct, though it may be none? And if it's none, 
that affects the default formatting.


While I've had a few times that the trimming of zeros from time values 
annoyed me, it isn't high on my priority list. If I don't like REBOL's 
default format, or if I have to send data to another process, I just 
know I need to format it.

and now that we have now/utc, a lot of the pain is gone, IMHO.

either Rebol is non-deterministic, or, I'm having a bad day

Graham, have a look at http://www.rebol.org/view-script.r?script=form-date.r

Geomol, in R2 when you pass a word to a get-word parameter, the value 
assigned to that word is passed instead. There may have been a good 
reason for this initially, but in the long run it turned out to be 
a bad design choice, and was fixed in R3. It has nothing to do with 
the any-function! types.

There is a similar special case for when you pass a get-word value 
to a lit-word parameter, bot in R2 and R3. R2's APPLY function has 
code to undo these special cases, and R3's APPLY doesn't do the special 
evaluation; APPLY is used to break the evaluation rules, often for 
safety.

Tonight's Moment of REBOL Zen:


How should R2 functions be categorized? They're not really functions 
with vars only temporarely on a stack:

>> c: func [a b] [[a + b]]
>> do c 1 2
== 3

but also not really closures with individual contexts:

>> f: func [a] ['a]       
>> word1: f 1
== a
>> word2: f 2
== a
>> get word1
== 2

aaaw... ask/hide doesn't work if i start rebol with the -w option, 
which i might accept, IF there would be a way to start it without 
a clear screen... it doesn't integrate nicely with unix this way...

Yes, we had a discussion about this in the Core group recently. See 
posts around 13-May.

FIRST, SECOND and THIRD can be used on functions like:

>> first :repend
== [series value /only]


SECOND and THIRD returns the function body and spec. FIRST returns 
a stripped spec, just the arguments and refinements. I notice, it's 
produced each time contrary to the other two:

>> same? second :repend second :repend
== true
>> same? third :repend third :repend  
== true
>> same? first :repend first :repend
== false


What is FIRST on a function used for? It may be used internally, 
but does anybody use it externally? It seems more logical, if FIRST 
on a function returned the spec, SECOND the body, and nothing else.

This is not a useful subject to discuss, due to the changes in R3

Geomol, that's very useful if you want to count the number of arguments 
of a function etc. - think of it as a pre-parsed function spec.

its a remove-each e spec-of fn [find type? e [string! block!]]

Geomol, using copy/deep by default would be extremely bad for speed 
and memory.   in most of the processing, you don't need to copy the 
deep content of a block, but the wrapper block itself, so you change 
the order or filter it.  


IIRC using copy/deep also causes cyclical references to break-up 
so using it by default would be disastrous.  


just look at how often we really need to use copy/deep compared to 
not and you'll see that the current behaviour is much more useful.

I imagined a can of worms. Guess I have to read and think it all 
through at some time.

The modulus operation from math is not defined for negative numbers 
at all. Most programming languages with a modulus operation have 
extended it to cover negative numbers, but there is no agreed definition 
for it. This is why *all* programming languages and math processors 
that have modulus of negative numbers defined, are using an arbitrary 
platform-dependent definition for it, *even Wolfram Alpha*.

The "correct answer" is NaN or to trigger an error, but since that 
is not useful, to pick a definition that is useful.

>> lesser? 'a 6
== false
>> lesser? 6 'a
** Script Error: Expected one of: integer! - not: word!
** Near: lesser? 6 'a

(the lesser? is from a sort/compare)

From HELP MOD: "Compute a nonnegative remainder of A divided by B."
MOD can produce negative results as seen above.

From HELP MODULO: "Wrapper for MOD that handles errors like REMAINDER."

So REMAINDER must give wrong result in some cases. What does REMAINDER 
say:

From HELP REMAINDER: "Returns the remainder of first value divided 
by second."

That's what I expect a modulo operation to do. A modern definition 
is given by Knuth in "The Art of Computer Programming" using floored 
division, and this seems to be also the definition, Wolfram Alpha 
use. So I would say, REMAINDER give the correct answer in the second 
case, but not in the first.


As I see it, REBOL have 3 modulo functions, and none of them operate 
as expected, if Knuth's definition is used.

would be nice if such discussion could be looked up when someone 
is curious why something has been implemented in a certain way... 
the rebol3 blog is a kind of raw material for such a "background 
documentation"...

none uses Knuths definition
 Ladislav, please!


Check mod in these languages: Clojure, Common Lisp, Filemaker, Fortran 
(modulo), Lua, Mathematica, MATLAB, R, Ruby (remainder), Scheme (modulo), 
Smalltalk (\\), VHDL


and maybe a few more. They all give the same result as from Knuth 
definition.

come on. If a function does not use a definition, then you cannot 
claim the function has a bug when differing from the definition in 
question.

In essence, the MOD function is a "helper" for ROUND. It uses the 
Boute's definition, but assuming that the divisor is positive. If 
you do want to use a more comfortable variant, you can use the MODULO 
function, which does not make such an assumption.

A bug?

>> cur: what-dir

== %/Users/peter/

>> cd %Code/Rebol

== %/Users/peter/Code/Rebol/
>> cd cur

** Access Error: Cannot open /Users/peter/Code/Rebol/cur/

** Near: change-dir to-file path

>> change-dir cur

== %/Users/peter/
Though this works:

>> cd :cur
== %/Users/peter/

<tab> completion of directories and files works, if you give argument 
as a file! datatype, but not when giving word! argument for CD. I 
believe, this is hard to get by.

>> blk: [a b c]
== [a b c]
>> path blk 'a
>> blk
== [a]
>> blk: [a b c]
== [a b c]
>> path blk 'b 
>> blk         
== [a b]
>> blk: [a b c]
== [a b c]
>> path blk 'c 
** Script Error: Invalid path value: c

Maybe for some internal use?

From group Core-old:


A: the PATH action is what the interpreter uses to evaluate VALUE/selector 
expressions for each datatype. It is an internal action and has no 
external purpose in programs. These kinds of words often appear as 
a sort of 

side-effect" from how REBOL is structured.  Datatypes are implemented 
as a sort of object class, where the interpreter "sends messages" 
to the class to evaluate expressions. The PATH action is a message 
that tells the datatype to perform a pick-like or poke-like internal 
function."

It seems to original come from a post in group "RT Q&A" dated 11-Dec-05.

yep, that's supposed to be unset but it somehow has been leaking 
out for a while.

is there any official way of using SORT/COMPARE on a block containing 
a mix of different datatypes?

or perhaps more correctly, a method to use LESSER? or GREATER? on 
a mix of different datatypes?

I made a block of all datatypes and sorted it. That was the outcome.

Since you can sort a block of logic! values, then <, > etc. should 
work on them, so that's missing. Doing to-integer on logics first 
solve it. And you have to check all the other datatypes by hand first 
to find out, where possible problems are, I guess.

SORT seems to sort anything that you throw at it and I think that 
makes sense, when making GUI lists. Right now I have a problem in 
that I can't control the input datatype and must sort anyway. The 
structure of the data is currently so that SORT/COMPARE is best to 
use, but LESSER? and GREATER? prevent this from being simple.

Yeah, looks like a bug.

The one that gets me is remembering that newline is a character and 
new-line is a function, rather than vice-versa.

Exchanging newline and new-line, and I bet a lot of people will mix 
those up. :) Why do you feel, they should be the other way around?

As for SORT, that's an interesting problem. LESSER? and GREATER? 
are supposed to be constrained to datatypes that are comparable, 
and that have some form of magnitude or ordering. For datatypes that 
don't really have magnitude or ordering they don't really work. When 
it comes down to it, true is not greater than false inherently (considering 
it to be so is more of a moral stand). And none is not greater or 
less than 'a, they just aren't comparable concepts.


SORT doesn't have that luxury though, because it is designed to not 
fail (or rather, not trigger errors because a comparison fails). 
So it has to define some extra comparisons that don't really make 
any sense, as a fallback in the cases where there is no comparison 
that does make sense. The datatype ordering trick is one of those, 
where they are ordered by their inner datatype number, and different 
data that isn't otherwise comparable is ordered by its datatype number 
too (words are greater than unset but less than none, for instance). 
R3 has a list of those datatypes in order in system/catalog/datatypes, 
but if there's a similar list in R2 I don't know where it is - Henrik's 
above is a subset, just the datatypes with externally referenced 
values. R2's and R3's datatypes are in a different order.


SORT/compare is supposed to allow you to provide your own ordering 
function if the standard ordering doesn't make sense. However, if 
you want to support all of the comparisons that the built-in ordering 
supports, you have to make a really complex comparator function with 
a lot of special cases, and in the case of R2 replicate a lot of 
internal data; that function would be pretty slow too. This is why 
SORT/compare is more often used for more restricted cases, like reversing 
the order, or comparing based on object keys.

Good points about SORT, Brian.


One small observation. SORT has a /reverse refinement, so /compare 
is not needed for simply reversing the order of a sort.

I would still like to see a dialected new-lines or line-markers func. 
I don't get the char and func names confused today.

Gregg, what do you mean by a dialected new-lines func?

Regarding the NEWLINE and NEW-LINE names. Consulting the function 
naming convention described in the documentation, it looks, that 
the NEW-LINE name is not adequate. (violates the function naming 
convention) That deficiency cannot be corrected by renaming NEWLINE. 
The SET-NEW-LINE name would be a preferable solution.

How many are using new-line anyway? Maybe I should do a search in 
the library at rebol.org.

LESSER? and GREATER? are supposed to be constrained to datatypes 
that are comparable

 - in fact, this is a kind of a circular reasoning (cf. "Comparable 
 values are values that are comparable")

In fact, the example of SORT proves, that comparability of all values 
is useful and desirable (we can sort). This situation is quite typical 
in mathematics. For example, is zero a number? The answer is quite 
trivial: yes, because it is useful. Not "philosophical reasoning" 
collecting reasons why not (we cannot divide by zero, zero does not 
express the number of elements of any nonempty set, etc.) matters.

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

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.

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.

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.

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)

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

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

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)

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.

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.

On R3, TAIL? is a redefinition of EMPTY? with fewer supported types. 
Internally they are the same function code. This was done in order 
to have one version that is more flexible, and another that triggers 
useful errors.

Getting an error when sending bulk email: 

** User Error: Server error: tcp 501 <>: missing or malformed local 
part
** Near: insert smtp-port reduce [from address message]

The number of email addresses is 52. 

I can send using the same settings one at a time and I have succeeded 
sending  8 addresses at one time. But it bombs on my whole list.

Found a bad address thats probably the problem....

Has anybody built a binary diff/patch function set?

If I want to store some fairly big data as undo information, it seems 
to make sense to store it as a diff, and load the data that I want 
to undo/redo to. Then it would also be possible to store the entire 
changes sequence to disk.

I did some a long time ago Henrik. It isn't fast enough to work on 
data of any size though. I can dig it out if you're interested. Can't 
remember what state of completion it's in.

Isn't unary minus introducing a third semantic rule? Functions are 
prefix, operators are infix with precedence over functions. And then 
unary minus is prefix with precedence similar to operators?

Functions with literal arguments works about the same.

>> f: func ['a] [probe a]
>> f 2 + 2
2
== 4

So f gets the value 2 in this example.

Tonight's Moment of REBOL Zen:

>> switch/default 'a [a 1] 2 
== 2

>> switch/default 'a [a [1]] 2
== 1

Isn't it strange, that if the value being searched for (in this case 
a) is found, and the next item in the block isn't a block, then it 
fails to defaul?

From the docstring for SWITCH: "Selects a choice and evaluates the 
block that follows it."

>> switch 'a [a b [1]]
== 1
>> switch 'b [a b [1]]
== 1

must be a block, nothing else

Oh, the docs are different at
http://www.rebol.com/docs/words/wswitch.html
It sais "Selects a choice and evaluates what follows it."

Must be a block
 ... hm why?

Yes, I think back in 2.5 (or earlier), switch 'a [a 1] actually returned 
1.

the change to switch was a good thing... wasn't it also mezz code 
a wee back?  IIRC this happened at the same time... and it made A 
LOT of code much faster.

1) There are not unary version and binary version of the - operator 
in R2, there is just one - operator in R2, which is both binary and 
unary depending on the "situation"

2) The statement "there is no unary version of the - operator" may 
be true only if you state, that NEGATE is not a unary version of 
the - operator

Would people miss unary minus in R3?

 - Initial testers reported its lack as a bug. The bug was dismissed, 
 since this was an intentional change. The benefits of the reduced 
 ambiguity won them over once they got used to it.

There is a trick in R3 for variadic functions, but it only works 
for the last arguments of a function, not the first, and only when 
the function is called at the end of the block/paren/script.
>> a: func [x [any-type!]] [type? :x]
>> a
** Script error: a is missing its x argument

>> a: func [:x [any-type!]] [type? :x]
>> a
== unset!

>> a: func ['x [any-type!]] [type? :x]
>> a
== unset!


The trick is to use a lit-word or get-word argument and allow it 
to accept unset! values. This is used mostly for console interactive 
functions like CD.

In R2, the first example would work too:
>> a: func [a [any-type!]] [type? get/any 'a]
>> a
== unset!

But in R3 that behavior is being discouraged on purpose, to make 
code easier to debug, so the alternate argument types are required.