World: r3wp
[!REBOL3-OLD1]
older newer | first last |
Maxim 2-Jun-2009 [14890] | I remember eagerly waiting for view :-) |
BrianH 2-Jun-2009 [14891] | The View alpha/beta list was fun :) |
Pekr 2-Jun-2009 [14892x2] | It was called Ally, and I still have it archived :-) |
Sterling Newton, Jeff Kreis, Holger Kruse, Jim Goodnow - RT was big company back then :-) | |
Maxim 2-Jun-2009 [14894] | the thing I miss most is reading about REBOL on every tech news site on the net every other week. |
Pekr 2-Jun-2009 [14895] | well, we are so small, that we don't even update rebolweek properly. It will be more difficult to get noticed once again, as we missed some momentum, but it can be done. Done by example, by some work - e.g. posting news to OSNews.com etc., or wrapping something like Google Wave, showing the world JS UI is still slow crap :-) |
Maxim 2-Jun-2009 [14896] | and the helpfull and always generous support that Bo would give out |
Pekr 2-Jun-2009 [14897] | Shouldn't do/next not allocating new block be called do/next/into instead of coming with other tricks? |
BrianH 2-Jun-2009 [14898x3] | No, the /into option doesn't work like that. The /next word could be named cont, since it is a kind of continuation :) |
I would really rather have the non-block-allocating DO/next, even if it isn't consistent with LOAD/next or TRANSCODE/next. DO of block is lower-level than those two, in terms of overhead. | |
However, if we want to change LOAD/next to match it's an easy fix. | |
Chris 2-Jun-2009 [14901] | 'do/next - I use it in a function as a subverted version of 'case. Perhaps if that's a bad function, there is an alternate way to implement it? |
BrianH 2-Jun-2009 [14902x2] | We are implementing it in the alternate way already :) |
Oh, you meant your subverted (?) CASE, not DO/next. CASE itself is very good, and we use it extensively. | |
shadwolf 2-Jun-2009 [14904x5] | rebol/next ? |
Carl > Have you seen wave.google.com ? why isn't that kind of project made with Rebol ? I mean most of the technologies involved in wave could be done using rebol and even in a better way if instead of jave/python xml and html you can design a wave oriented dialect . Your clever than me so I think you already got the point. | |
next ask is do you think somthing like colaborative "at the same time" could be possible to do with R3 for example hum lets be crazy in futur viva-rebol IDE offers a way to make several ppl working on the same project at the same time use the viva-rebol IDE and sharing in real time information | |
for example you and me works on the same file at the same time using viva-rebol ide and you fill a part of the file i fill another part of the file and we both see in real time what the other is doing. (for example you do the parse parse rules and i write the GUI of an applicaton things like that) | |
well that's not a new thing Moon edit propose that kind of collaboration real time since some years already. what i like in wave is the modular aspect you are not limited to a conversation you can create "wavelets" to anykind of use and extrapolating that system to the already existing rebol tools (rebol.org, view/desktop, ios etc...) would be really a big thing | |
Chris 2-Jun-2009 [14909x3] | B: does block if case is false. Sort of like 'all, but with a reason for each failing case (provisionally called 'assert-all): either assert-all [ case-a [raise "Case A failed"] case-b [raise "Case B failed"] 0 < 1 [raise "Something is very wrong"] ][ print "Both Cases were true!" ][ probe raised-val ] Makes more sense when each case is dependent on the previous one, for validating input, etc. |
All cases were true! - I added one : ) | |
Might be easier to do with parens instead of do/next, but the case-like construct is more readable... | |
BrianH 3-Jun-2009 [14912] | Take a look at the ASSERT function in R3 - it might do what you need faster and safer. Or it might be off-topic :( |
Chris 3-Jun-2009 [14913] | Never mind, I read a point above incorrectly. |
Pekr 3-Jun-2009 [14914] | Another attempt (I don't give up yet :-) - has anyone problem, if money! datatype would be renamed to unit! datatype? I think "money" is really a bad name for something being more general and precise... |
Henrik 3-Jun-2009 [14915] | Yes, I have a problem with it, due not being able to identify money during parsing, if we lose it. I think there should be more focus on having a generic BCD number type. As money is now, I think it should be left alone, but add other datatypes that are more appropriate to specific jobs. |
Pekr 3-Jun-2009 [14916x2] | Some ppl still confuse what I am proposing. The same goes for Carl. I don't want to remove anything. I just want to change the really bad name. I refuse to accept the fact, that such general mechanism as BCD is linked to as ugly name as money! is. So what I want is - either another general BCD datatype, or - rename money! to unit! and it could work that way: g$100 v$100 km$100 USD$100 |
Of course I am not sure it is flexible enough, as how would I express e.g. km/h? | |
BrianH 3-Jun-2009 [14918] | Calling it "money" makes sense when you consider that the only available character for the literal representation is $. |
Henrik 3-Jun-2009 [14919] | renaming it sounds very much like removing it. |
Pekr 3-Jun-2009 [14920] | I have to be really stupid, or I really can't understand, how renaming something = removing something? So are we going to remove 'map, just because we are going to rename it to 'map-each? |
Henrik 3-Jun-2009 [14921] | also tieing a unit to a number directly might limit the applicability of unit calculations as used in physics and symbolic math. |
BrianH 3-Jun-2009 [14922] | I don't want to call it "unit!" because the type would be really poor for that, and we don't want to reserve the word "unit" for a poor implementation of the idea, especially when we have user-defined datatypes. |
Pekr 3-Jun-2009 [14923] | BrianH: then think of $ as a sign of measure (that was another name for money, but unit is shorter and more to the point). Why is file represented by % sign then? It has nothing in common with percentage = $ has nothing in common with money. Maybe in US. |
Henrik 3-Jun-2009 [14924] | Pekr, renaming a function is not the same as renaming a datatype. You lose functionality and gain something specifically different. When renaming a function, you don't lose anything. |
BrianH 3-Jun-2009 [14925] | File is being represented by % since that is what was left. |
Pekr 3-Jun-2009 [14926] | Henrik - how can you loose functionality by just renaming it? :-) |
Henrik 3-Jun-2009 [14927x2] | Pekr, you don't have money anymore. That's the loss. |
And it's important to have as many datatypes as possible for dialects. | |
Pekr 3-Jun-2009 [14929] | I know. I just thought, that money (better let's call it currency), is just another unit ... |
BrianH 3-Jun-2009 [14930] | $ is used as a sigil of money in many countries, not just the US. |
Pekr 3-Jun-2009 [14931x2] | OK, so give me BCD! type then. I will not do make money! just because I want some precision. That reads badly ... |
IIRC there was a blog what to do with money! datatype, and if the datatype should be more "complex". That is still not resolved. | |
Henrik 3-Jun-2009 [14933] | In school, units were always encased in [], such as 5 [m / s]. I think it's possible to do something similar in REBOL. |
BrianH 3-Jun-2009 [14934] | More complex = "like R2". He was asking about restoring the unit prefix. |
Henrik 3-Jun-2009 [14935] | could a serialized item be considered its own datatype?, such as #[none] |
Ladislav 3-Jun-2009 [14936] | I do not understand your question |
Henrik 3-Jun-2009 [14937] | I'm not sure it makes sense anyway. :-) I guess it's about how the scanner interprets certain characters and from that works out the datatype, and what limitations there are in detection. |
Pekr 3-Jun-2009 [14938] | Henrik probably wanted to introduce new form to REBOL's parser: 100[m /s] |
BrianH 3-Jun-2009 [14939] | There are a few serialized keywords, but the rest are constructors. |
older newer | first last |