World: r3wp

the to-op function could easily just raise an error if the first 
paramater has any type spec.   that' how I'd handle it.

this forces people to make the stub, so it becomes a programming 
error, not a language bug.

That would fail for = and all other functions that allow the any-type! 
value (for unset! and error! support), and make it difficult to understand 
the help of all op functions, which use the typespec of the first 
argument for documentation purposes. Plus, the argument list for 
the op! is taken directly from the function it is derived from - 
it can't and shouldn't be able to be specified separately.

brian we are talking an api issue.  what happens before application 
starts is irrelevant.   on init, let R3 do whatever it wants.


once we start running the script, have an api-minded function which 
just makes sure that any function you send to the core used as an 
op is safe.  I don't care for any limits... just document them and 
I'll live with.   whatever the core has which I can't have... who 
cares.


as far as error reporting goes, that is the reason for the stub. 
  IT will have to either handle the error appropriately or just raise 
an error.   


really, there is no technical reason for this not being done.  its 
just a question of doing it.    limited user ops are still infinitally 
better than none.

The other trick that would need to be accounted for is that the actual 
process of calling functions is different for every function type, 
and afaict the differences are implemented in the evaluator itself 
rather than in some hidden action! of the function's datatype implementation. 
This is why I was glad to figure out that the command! type was sufficient 
to implement what we needed user-defined function types for, because 
it appears that user-defined function types are impossible in R3, 
even potentially. The op! redirector needs to be able to understand 
how to call the function types it supports. R2 ops only understood 
how to call actions (technically, DO did the redirection in R2, not 
the op! code itself). R3 ops can also redirect to natives, which 
is why some functions are native! now that were action! in R2. In 
order to support making ops from user-defined functions, the op! 
redirector code would need to be expanded to support calling those 
function types.

I am not disagreeing with the need for and value of user-defined 
ops, Maxim, just saying what needs to be done to make them possible.

Of course in Red, the method for doing them would be completely different 
:)

It would be theoretically possible to make unary postfix ops in REBOL, 
as long as you used a different datatype or some flag in the op! 
value which could be set at op! creation time - the evaluation model 
of REBOL could allow such a thing. Ternary ops would be trickier: 
You would have to have the second word be a get-word parameter of 
the word! type be the underlying function's third parameter, and 
the third parameter of the op would be the fourth parameter of the 
function. All ternary ops starting with the same word would need 
to be implemented by the same function, which would behave accordingly 
based on which word is passed as its third parameter. The ternary 
op value itself would be assigned to the first word, because REBOL 
doesn't have multi-word bindings.

type be the -> type as the

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