World: r3wp
[!REBOL3]
older newer | first last |
BrianH 21-Apr-2011 [8257] | The current version supports chat just fine. |
Maxim 21-Apr-2011 [8258x2] | there are a lot of things I'd setup as an OP. the FROM example from geomol is a really good example of how this makes code sooo much more readable. |
it also allows to alleviate some parens in expressions if the functions are ops instead. | |
BrianH 21-Apr-2011 [8260] | There are some real limits to op! evaluation that makes them unsafe for general use for now. For one thing, the type of the first argument is not checked at call time relative to the typespec by the evaluator - it has to be checked by the function itself internally. This is not a problem with most existing ops because they map to actions (which have their type compatibility handled by the action dispatcher), or in some cases natives that perform their own internal type checking. I believe this was a speeed tradeoff. If you allowed full user creation of ops even with their current restriction to actions and natives, you could bypass the typespecs of natives and corrupt R3's memory. Adding in that typespec check to the op! evaluator would slow down op! evaluation a little, but would be necessary if you really wanted to make user-defined ops possible. |
Maxim 21-Apr-2011 [8261x3] | I don't mind since we need to build a stub anyways... its easy to add this checking there. |
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. | |
BrianH 21-Apr-2011 [8264] | 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. |
Maxim 21-Apr-2011 [8265] | 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. |
BrianH 21-Apr-2011 [8266x9] | 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. | |
GrahamC 24-Apr-2011 [8275] | 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. |
Henrik 27-Apr-2011 [8276] | 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? |
GrahamC 27-Apr-2011 [8277x2] | dir /od |
so we just need 'call | |
Henrik 27-Apr-2011 [8279] | what does that do? |
Gregg 27-Apr-2011 [8280] | Henrik, yes, I agree. I do that all the time. |
Henrik 27-Apr-2011 [8281] | something like YYYYMMDDHHMMSS would do fine |
Gregg 27-Apr-2011 [8282x2] | 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. | |
Henrik 27-Apr-2011 [8284] | it should be simple to do as a mezz |
Gregg 27-Apr-2011 [8285] | I would still like to see a general FORMAT func, though mine hasn't generated any excitement in the past. |
Maxim 27-Apr-2011 [8286x3] | 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. | |
Geomol 27-Apr-2011 [8289] | 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? |
Ladislav 27-Apr-2011 [8290x2] | 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. | |
Geomol 27-Apr-2011 [8292] | Breaking some scripts maybe? |
Maxim 27-Apr-2011 [8293x2] | 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 | |
Gregg 27-Apr-2011 [8295] | My func is very similar to yours Max. |
onetom 28-Apr-2011 [8296x2] | >> 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... | |
Maxim 28-Apr-2011 [8298x3] | R3 is much easier to use with binary than R2. |
just use a binary string. | |
>> to-integer #{ffffffff} == 4294967295 | |
onetom 28-Apr-2011 [8301] | thx |
Dockimbel 28-Apr-2011 [8302] | 0xff format : it does clash with the pair! datatype. |
onetom 28-Apr-2011 [8303] | true.. damn :) on the other hand: >> to-integer #ffffff == 16777215 >> to-integer #{ffffff} == 16777215 |
Maxim 28-Apr-2011 [8304] | 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 |
onetom 28-Apr-2011 [8305] | but if u have to turn it into integer anyway, then the issue is shorter |
Maxim 28-Apr-2011 [8306] | 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} |
older newer | first last |