World: r3wp
[!REBOL3-OLD1]
older newer | first last |
BrianH 26-Jan-2007 [1890x2] | Hence the "if you can trust the source" comment :) |
I did mean "but if you can trust the source" though. | |
Volker 26-Jan-2007 [1892x2] | security - if it is has no link to to words with functions it can only trigger errors because the data does not match the spec. |
apply and refinements - in Gbriele example refinementsare handled like normal variables. append: func [series value /only /etc] [series: tail series head apply :insert [series value only etc]] Here they get their values by position. | |
BrianH 26-Jan-2007 [1894x2] | That's the way refinements are handled by the APPLY opcode of rebcode. |
As for triggering errors, I would prefer that argument type mismatches to APPLY would generate the exact same errors that a direct call to the function would generate - that way you wouldn't have to document 2 sets of errors. | |
Anton 27-Jan-2007 [1896x3] | I am not clear how GET on a block of variables would be different to REDUCE. |
Is it that GET would be selective about which values to reduce ? ie. only word! ("variables") ? | |
How would this block be treated ? [a b 1 + 2] | |
Ladislav 28-Jan-2007 [1899x3] | when speaking about the REBCODE APPLY, variables A and B would be examined to obtain their values. |
but when speaking about my proposed GET change, the block should contain only variables, similarly as the SET block is allowed to contain only variables | |
GET versus REDUCE: there is a difference. When a variable refers to a function, REDUCE evaluates the function, while get just obtains the function without evaluating it. | |
Anton 29-Jan-2007 [1902x2] | Ah now it makes sense. |
GET sounds good to me. | |
Pekr 7-Feb-2007 [1904] | hmm, almost 2 months from latest R3 related blog. And only 3plus months to DevCon ... I wonder if we will see running alpha at least? :-) |
Oldes 7-Feb-2007 [1905] | Carl is not writing blog, so he's writing code, that's good, isn't it? :) |
Pekr 7-Feb-2007 [1906] | if he is writing code, then yes, of course :-) |
Henrik 7-Feb-2007 [1907] | a couple of new blog entries discussing ++/-- and ranges |
Geomol 10-Feb-2007 [1908] | In the comments about ++/--, I suggested a new way of defining arguments to functions: >> mult2: func [value:] [value * 2] >> mult2 4 == 8 >> a: 3 >> mult2 a == 6 >> a == 6 With this addition to the language, INC could be written: inc: func [value:] [value + 1] Of course it would be better to have INC native, but with my suggestion, it will be possible to make our own functions, that works like INC and DEC. What do you think? |
Volker 10-Feb-2007 [1909x2] | is an extra get /set that much effort? |
but i dont like funcs that way. i read a and think it is evaluatet. leads to confusion. | |
Geomol 10-Feb-2007 [1911] | Volker, maybe not. But then we should just stick with a: a + 1 shouldn't we? |
Volker 10-Feb-2007 [1912x4] | if it looks like an operatorthat say "exception" |
but i prefer a: + 1 | |
or inc 'a | |
a: - 1 ; disambigius. | |
Geomol 10-Feb-2007 [1916x3] | Volker, I follow you. Our normal way of thinking about functions and lines of code in REBOL is, that if we see a word, and we recognize it as a function, we look for arguments after the word. And we wouldn't think, those arguments would be changed. If words (variables) change value, we expect a set-word (like a:). Conclusion might be, that my suggestion will probably lead to more confusion. Falling back to ++/-- (or INC/DEC), those might be confusing too. |
Problem with a: + 1 is, that the plus sign can be seen as a unary plus. Because what should this mean? a: + b | |
Same with unary minus as you point out. | |
Volker 10-Feb-2007 [1919x2] | yes, but if we think c, += and -= are a close accosiation. |
unary + makes no sense. unary minus makes, thatis a problem. | |
Geomol 10-Feb-2007 [1921x2] | a+: 1 maybe? |
Not good, because a+ is a valid word. | |
Volker 10-Feb-2007 [1923x2] | or without space, a:+ 1 |
but these break syntax. | |
Geomol 10-Feb-2007 [1925] | hmm yes ... and yes. |
Volker 10-Feb-2007 [1926] | although, an operator-word! as datatype? |
Geomol 10-Feb-2007 [1927] | argh, it's hard to define a language! :-) |
Volker 10-Feb-2007 [1928x2] | yep |
a:+ is already an url. | |
Pekr 10-Feb-2007 [1930] | Geomol - your function posted in blog works without the set-word, so why you needed it to work via a set-word? |
Geomol 10-Feb-2007 [1931x2] | Because: >> mult2: func [value] [value * 2] >> a: 3 >> mult2 a == 6 >> a == 3 a isn't changed. |
If ++/-- are introduced, they'll change a this way: >> a: 3 >> ++ a == 4 >> a == 4 | |
Pekr 10-Feb-2007 [1933] | ah, I see ... |
Geomol 10-Feb-2007 [1934x2] | My argument is, that if something like ++/-- are introduced in the language, I as a programmer would expect, that I can make my own ++/-- like functions very easily. |
I keep thinking about operators (of type op!). It's not possible to make new operators in REBOL afaik. Why not? Can we come up with an easy way to make new user-defined operators? | |
Pekr 10-Feb-2007 [1936] | I don't need such functions. IMO operators already break rebol left to right evaluation. IMO it only will cause more confusion. INC a, DEC a, is imo much more rebolish. |
Volker 10-Feb-2007 [1937] | Its not possible because Carl hardwired them in r2. AFAIK its posible in r3. |
Pekr 10-Feb-2007 [1938] | Volker - how do you know? :-) |
Volker 10-Feb-2007 [1939] | Because in some chat somewhere Carl hinted it. IIRC and all. |
older newer | first last |