World: r3wp

The implementation of ternary ops would probably not have the slowdown 
that the optional ELSE had for IF in R1, since the arity would still 
be fixed.

A similar method could be used to implement unary postfix and ternary 
ops in Red, though the tricks would be in the compiler instead of 
the evaluator.

Strangely enough, if ops were implemented using the R2 method - DO 
swaps the op keyword for its prefix equivalent, instead if the op 
itself redirecting - then unary postfix and ternary ops would be 
possible right now with the current op! type, no new internal flags 
needed. Prefix functions can have infix keywords already, as long 
as they are not optional - the arity of the function needs to stay 
the same, but there's nothing illegal about infix keyword parameters 
in REBOL.

The only trick with ternary ops or infix keywords in REBOL would 
be that any syntax error that you might want to throw if the second 
word doesn't match the list of accepted keywords, you can't trigger 
that error until after the other parameters have finished evaluating. 
It would be preferable to trigger that error ahead of time, but impossible. 
Oh well.

I managed to bring up my wiki again .. and the SOAP stuff is here 
http://www.compkarori.co.nz:8000/Rebol3/AWS but Amazon is going to 
require https so not sure how that is going to work.

I find myself often needing to sort in a file system on date, when 
the file name contains a date, but I have to manually build a new 
date string, where the month is a zero padded number.


Does it not make sense to have a file-system and sort friendly date 
stamp?

dir /od

so we just need 'call

what does that do?

Henrik, yes, I agree. I do that all the time.

something like YYYYMMDDHHMMSS would do fine

That's what I do in most cases, but HH needs to be HHH (24-hour time). 
Sometimes I need to have sub-second or added extensions, but that's 
the basic idea.

HHH still mapping to two digits of course, just a format convention 
used elsewhere that I emulate in my FORMAT func.

it should be simple to do as a mezz

I would still like to see a general FORMAT func, though mine hasn't 
generated any excitement in the past.

I have my own date-time function, its pretty complete IMHO.

don't know if it works in R3 though....

	;------------------------------------------------------------
	;- DATE STUFF
	;------------------------------------------------------------
	; use this to prevent having to supply a spec all the time.
    ; the /default option of date-time sets this.
	default-date-time-spec: "YYYY/MM/DD-hh:mm:ss"
	                             
	
	;--------------------
	;-    date-time()
	;--------------------
	date-time: func [
		""
		/with spec ; specify

  /using thedate [string! date! time!] ; specify an explicit date instead 
  of now()
		/default
		/local str date-rules thetime
	][
		vin/tags ["date-time()"] [date-time]
		
		str: copy ""
		
		
		either spec [
			if default [
				default-date-time-spec: spec
			]
		][
			spec: default-date-time-spec
		]
		
		unless thedate [
			thedate: now/precise
		]
		
		
		if thedate/time [
			thetime: thedate/time
		]
		
		filler: complement charset "YMDHhmspP"
		;spec: "YYYY/MM/DD-H^^hmmP"
		;error: spec
		itime: true
		
		unless parse/case spec [
			some [
				here:
				(error: here)
				["YYYY" (append str thedate/year)] | 

    ["YY" (append str copy/part at to-string thedate/year 3 2)] | 
				["MM" (append str zfill thedate/month 2)] |
				["DD" (append str zfill thedate/day 2)] |
				["M" (append str thedate/month)] |
				["D" (append str thedate/day)] |

				["hh" (append str zfill thetime/hour 2)] |
				["mm" (append str zfill thetime/minute 2)] |
				["ss" (append str zfill to-integer thetime/second 2)] |

    ["rrrr" (append str fill/with/right/truncate (remainder thetime/second 
    1 4) "0" )] |
				
				["P" (append str "#@#@#@#")] | 
				["p" (append str "[--:--]@[--:--]")] | 
				["H" (
					itime: remainder thetime/hour 12
					if 0 = itime [ itime: 12]
					append str itime
					itime: either thetime/hour >= 12 ["PM"]["AM"]
					)
				] |
				["h" (append str thetime/hour)] |
				["m" (append str thetime/minute)] |
				["s" (append str to-integer thetime/second)] |
				["r" (append str remainder thetime/second 1)] |
				["^^" copy val skip (append str val)] |
				
				[copy val some filler (append str val)]
				
			]
			(replace str "#@#@#@#" any [to-string itime ""])
			(replace str "[--:--]@[--:--]" lowercase any [to-string itime ""])
		][
			print ["date-time() DATE FORMAT ERROR: " spec]
			print ["  starting at: "  error ]
			print ["  valid so far: " str ]
		]
		vout/tags [date-time]
		str
	]

just remove  vin and  vout functions before running the func.

Regarding lit-words compared to other datatypes:

>> w: first ['a/b]
== 'a/b
>> type? w
== lit-path!		; this returns path! in R2
>> type? :w
== lit-path!

>> w: first ['a]
== 'a
>> type? w
== word!		; Why?
>> type? :w
== lit-word!


There is this double evaluation of words holding lit-words. Why is 
that? As far I can see, only words holding lit-words and functions 
(incl. natives ...) have this difference in behaviour, when refering 
to them as words or get-words. I understand why with functions, but 
why also with lit-words?

Word-active values - another one is the #[unset!] value, which is 
also actively interpreted (triggering an error).

Regading the word-activity of lit-words - it has been quite some 
time when I suggested to Carl to make lit-words "normal" in this 
respect, but he did not accept my proposal, so I expect he found 
it uncomfortable for some reason.

Breaking some scripts maybe?

yes, aggressive evaluation of lit-word types is very annoying, it 
easily provokes molding/loading errors if you're not carefull.

yes, As in I agree with Lad

My func is very similar to yours Max.

>> x: [16#ffffff] 
== [#6#ffffff]

how can i specify an integer! in hex format?

debase/base "ffffff" 16  returns a binary! which i mostly can smear 
on my hair, since most operators just doesn't play nicely w it...

same problem again... i tried to use rebol for byte level processing 
and it's just not suitable for it.. :/

imean not logical neither easy to remember.

would it really be a pain to support the usual 0xff format?... it 
doesn't really clash w anything i think. only numbers can start w 
zero anyway...

R3 is much easier to use with binary than R2.

just use a binary string.

>> to-integer #{ffffffff}
== 4294967295

thx

0xff format
: it does clash with the pair! datatype.

true.. damn :)

on the other hand:
>> to-integer #ffffff              
== 16777215
>> to-integer #{ffffff}
== 16777215

the issues is sort of a syntax sugar, the binary string is the actual 
value in ram.   so you can do things like:

a: #{0f0f0f0f}
b: 3520188881     
>> a and b
== #{01010101}

but you can't with issues:

>> b: #d1d1d1d1
== #d1d1d1d1
>> a and b

** Script error: and does not allow issue! for its value2 argument

but if u have to turn it into integer anyway, then the issue is shorter

the only  real thing to be aware of is that to-binary of an integer 
will give you a 64 bit binary!

>> to-binary 22
== #{0000000000000016}

here is my ObjectID routine a'la mongodb.

wondering how much simpler could it be in r3?...  not that i could 
use r3 any time soon for production stuff, but i would love to, of 
course

  rejoin probe reduce [
    to-hex date-to-epoch now

    enbase/base copy/part checksum/method system/network/host 'md5 3 
    16
    skip to-hex access-os 'pid 4
    skip to-hex random/secure to-integer #ffffff 2
  ]

Geomol, the ticket for the lit-path problem you mentioned is here: 
http://issue.cc/r3/1434

Brian, the ticket you mentioned is not related to the problem Geomol 
mentioned.

Question: how many REBOL users prefer:

a: make object! [b: does ["OK"]]
a/b ; == "OK"
do 'a/b ; == a/b

versus

a: make object! [b: does ["OK"]]
a/b ; == "OK"
do 'a/b ; == "OK"

?

I prefer the latter

(seeing it as more convenient)

latter

And, how many users prefer:

a: make object! [b: does ["OK"]]
type? do in a 'b ; == function!

versus

a: make object! [b: does ["OK"]]
type? do in a 'b ; == string!

I prefer the latter again

The latters seems more logical to me in both cases.

The latters seems ok to me. But what if w is a word holding 'b or 
'a/b, as I was testing, in relation to the object a? This is what 
I get:

In R2:
>> a: make object! [b: does ["OK"]]
>> w: first ['b]
== 'b
>> type? :w
== lit-word!
>> a/:w

** Script Error: Invalid path value: b	; To me, that error is wrong 
worded, it should show 'b.
>> in a :w
== 'b		; Confused, as a doesn't hold any 'b
>> do in a :w
== 'b		; Why?
>> type? do in a :w
== lit-word!

Same in R3:
>> w: first ['b]
== 'b
>> type? :w
== lit-word!
>> a/:w

** Script error: cannot access :w in path a/:w		; Not sure about 
this error. Could be better, I think.
>> in a :w
== 'b			; ?
>> do in a :w
== b			; ??
>> type? do in a :w
== word!

And now the 'a/b:

In R2:
>> a: make object! [b: does ["OK"]]
>> w: first ['a/b]
== 'a/b
>> do w
== "OK"
>> do :w
== 'a/b

In R3:
>> a: make object! [b: does ["OK"]]
>> w: first ['a/b]
== 'a/b
>> do w
== 'a/b
>> do :w
== 'a/b

wrt:

And, how many users prefer:

a: make object! [b: does ["OK"]]
type? do in a 'b ; == function!
versus

a: make object! [b: does ["OK"]]
type? do in a 'b ; == string!

============================

the first should be supported via the 'GET word, so I'd say the later 
is better, otherwise, there is no point with 'GET. 

basically, this was perfect in R2, why did it change in R3?

seems like a bug