World: r3wp
[!REBOL3 Proposals] For discussion of feature proposals
older newer | first last |
Andreas 20-Jan-2011 [769] | Also, get rid of the *NOT* mentions in the main body. If at all, mention that in a remark at the end of the ticket. |
BrianH 20-Jan-2011 [770x2] | Good idea. |
Done. | |
Ladislav 20-Jan-2011 [772] | BTW, Same? is still less strict than my Identical? (even for decimals) |
BrianH 20-Jan-2011 [773] | Interesting. How does that happen? I thought SAME? just did a bit-for-bit comparison. |
Ladislav 20-Jan-2011 [774] | yes, but the NEW-LINE? bit is ignored |
Andreas 20-Jan-2011 [775x2] | Heh :) awesome. |
Ok, ticket's good. Thanks Brian. | |
BrianH 20-Jan-2011 [777] | That's funny :) |
Andreas 20-Jan-2011 [778] | (Maybe add a blank linke before the - EQUAL? item.)( |
BrianH 20-Jan-2011 [779] | I didn't even know there was a newline bit, though it seems obvious in retrospect. It would be lost in the transfer of the value to the stack frame for the function call I bet, because stack frames and value slots of contexts don't keep track of newlines. You'd have to pass in a reference to the block the value is stored in, I'm guessing. |
Ladislav 20-Jan-2011 [780] | wrong |
BrianH 20-Jan-2011 [781] | Even more interesting. Say more. |
Ladislav 20-Jan-2011 [782] | written in http://www.rebol.net/wiki/Identity#The_new-line_attribute |
BrianH 20-Jan-2011 [783] | I used to think that newlines in blocks were hidden values in the block itself. It makes sense to just have it be a bit in a value slot. |
Andreas 20-Jan-2011 [784x2] | It is a value bit. |
>> a: copy [1 2 3] == [1 2 3] >> new-line next a on == [ 2 3 ] >> b: copy [] == [] >> append b first a == [1] >> append b second a == [1 2 ] >> append b third a == [1 2 3 ] | |
BrianH 20-Jan-2011 [786x2] | Guess it's in all value slots, not just the ones in block types, and just ignored when inapplicable. |
At least that makes the value slot easier to implement. Good choice. | |
Ladislav 20-Jan-2011 [788] | Well, it is not ideal this way, for two reasons: - it does not affect all possible line break positions in a block (there are n + 1 such positions in a block of length n, as can be easily figured) - it "pollutes" the values, affecting their identity, e.g. |
Andreas 20-Jan-2011 [789] | Well, the latter is probably why same? does not respect this bit, no :) ? |
BrianH 20-Jan-2011 [790] | It also makes the "immediate values aren't modifiable" argument a little more iffy. |
Ladislav 20-Jan-2011 [791x3] | But the differences are real, that is like putting our head into the sand pretending there is no danger nearby |
{It also makes the "immediate values aren't modifiable" argument a little more iffy.} - I do not use the notion of "immediate values", neverheless, it does not, I would say | |
(the NEW-LINE attribute is immutable) | |
BrianH 20-Jan-2011 [794] | It's mutable with the NEW-LINE function :) |
Ladislav 20-Jan-2011 [795x3] | No, see my article |
It is exactly as mutable as the sign of an integer is, when using the Negate function | |
(not at all) | |
BrianH 20-Jan-2011 [798x2] | Immediate values are a bit iffy concept in REBOL anyways, so it's probably for the best that you don't use the notion. Nonetheless, there is a documentary typeset in R3 called immediate!, which includes the values that are fully stored within a value slot, rather than referencing memory elsewhere. |
That is what I meant by "immediate values". | |
Andreas 20-Jan-2011 [800] | Let's move this to !REBOL3, shall we. |
BrianH 20-Jan-2011 [801] | Naw, let's let it go :) |
BrianH 21-Jan-2011 [802] | Strangely enough, while there is no obvious operator for EQUIV?, we could use === for STRICT-EQUIV? and !=== for STRICT-NOT-EQUIV?. |
Maxim 21-Jan-2011 [803] | EQUIV? could be ~ its the actual math symbol for it. http://en.wikipedia.org/wiki/Table_of_mathematical_symbols |
BrianH 21-Jan-2011 [804x3] | This would solve the operator problem for developers who understand the limits of IEEE754, and still let regular developers expect 0.3 to equal 0.1 + 0.1 + 0.1. |
EQUIV? is more strict than EQUAL?, so it would go the other way around. | |
We considered ~= in the last round, but that would be even more approximate than =, so the hierarchy doesn't work unless ~= means EQUAL?. | |
BrianH 23-Jan-2011 [807] | Remove ALIAS: http://issue.cc/r3/1835. Thanks, Andreas, for discovering the absence of this ticket. |
Maxim 27-Jan-2011 [808x2] | proposal for four very usefull series functions.... shorter?: func [a [series!] b [series!]][ lesser? length? a length? b ] longer?: func [a [series!] b [series!]][ greater? length? a length? b ] sortest: func [a [series!] b [series!]] [ either shorter? a b [a][b] ] longest: func [a [series!] b [series!]] [ either longer? a b [a][b] ] |
sortest == shortest | |
Steeve 27-Jan-2011 [810] | Is that so ? |
Maxim 27-Jan-2011 [811] | huh? |
Steeve 27-Jan-2011 [812] | I mean, usefullness |
Henrik 27-Jan-2011 [813] | I'm thinking, what kind of code is it that one writes, when you have to compare series lengths? |
Maxim 27-Jan-2011 [814x3] | I just used it 10 minutes ago again... checking if two series need to be synchronised. |
(though they don't use the same values, they are interdependent) | |
we could also add EQUAL-LENGTH? just for completeness | |
Henrik 27-Jan-2011 [817] | ok |
Maxim 27-Jan-2011 [818] | they could just be part of a delayed load series module. there are many missing series handling/probing functions in REBOL. we end up writing them over and over. |
older newer | first last |