World: r3wp

So, what do you suggest?

>> d: 15-may-2011/12:00:00.00
== 15-May-2011/12:00
>> d/time
== 12:00

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.

Maybe that different formatting should be standard

Keep in mind that times in REBOL and most other systems are fixed-point, 
not floating point. There is no loss of precision.

Having something that changes the display depending on what time 
it is ... is ... annoying

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.

True, we just get unintelligble scientific notation

>> 1.00000000000000000
== 1.0
What you are suggesting is this, but for dates:
>> 1.0
== 1.00000000000000000

>> d: .01
== 1E-2

Keep in mind that the main intended purpose of MOLD is to generate 
REBOL source code. You are suggesting that it generate more complex, 
larger source code.

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

I just can't imagine any scenario when the above example is useful

ie. 1E-2

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.

R2 has no tasks

Recursion-safe then, or async-safe, whatever. Yes, this includes 
system/options/decimal-digits.

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.

This would mean that you would replace this code:
    saved: system/options/binary-base
    system/options/binary-base: 64  ; or 16, whatever
    output: mold data
    system/options/binary-base: saved
with this:
    output: mold/with data [binary-base: 64]


This saves code since you can't trust that any global option will 
remain even its default value without data flow analysis unless it's 
protected.

In any case, you were still leaving parts out of your date formatting. 
If you left it all in it would look like this:
>> 15-may-2011/12:00:00.00
>> 15-May-2011/12:00:00.000000+00:00

Sorry, I forgot 3 zeroes: 15-May-2011/12:00:00.000000000+00:00

I'd prefer that

I can always reduce the numbers for display

It's much more work to increase the numbers

Not for source code output you wouldn't, especially since those extra 
zeroes don't add any information. It's no work at all to increase 
the numbers, since all of those zeroes are there in the original 
date value. So if need less flexible formatters, they're easy to 
write.

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

If you do MOLD output and then reduce the number of zeroes output, 
it requires parsing MOLD's output. Working straight from date! values 
means no parsing required.

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.

The default format will never be right for all uses.

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

Gregg ... now it doesn't give me an error!

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

The issue is that web apis using different languages don't use datatypes 
in the same way.

I'd be okay if I only used Rebol web apis!

Having QUOTE, would it be an idea to have CITE like this?

cite: func ['word] [:word]


Only difference, I think, is when passing any-function! types to 
it:

>> type? quote next
== action!
>> type? cite next 
== word!

All other types seem to return the same for QUOTE and CITE.

Passing an unset word to QUOTE will return unset! in R2, and will 
return the word in R3. CITE returns the word.

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.

Didn't know about Chris' date formatting

Great work on that date formatting! I prefer compiled dialects over 
interpreted ones for volume work, but it's definitely the right idea 
:)

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.

Sorry, my last post here was an answer to something in the !REBOL3 
group.

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

I see, they're all produced each time in R3:

>> same? reflect :repend 'spec reflect :repend 'spec
== false

Guess the R3 implementation is better in this case.