r3wp [groups: 83 posts: 189283]
  • Home
  • Script library
  • AltME Archive
  • Mailing list
  • Articles Index
  • Site search
 

World: r3wp

[!REBOL3-OLD1]

shadwolf
2-Jun-2009
[14907x2]
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.
Pekr
3-Jun-2009
[14940]
but then he realised, that we have already #[none] for serialisation 
... but I can be wrong ...
Henrik
3-Jun-2009
[14941]
Pekr, yes, although [] directly, won't work. I'm assuming that we 
could basically do something like ![m / s] or &[m / s] and have that 
work as a datatype.
Pekr
3-Jun-2009
[14942]
or ~[m / s]
Henrik
3-Jun-2009
[14943]
good one
Pekr
3-Jun-2009
[14944]
Will something like that work with user types? Can I define its "lexical 
form" (?) so that REBOL parser would accept that?
BrianH
3-Jun-2009
[14945]
User types won't be able to affect the lexer.
Pekr
3-Jun-2009
[14946]
So how REBOL identifies my user type?
BrianH
3-Jun-2009
[14947]
MAKE or serialized forms, I expect.
Ladislav
3-Jun-2009
[14948]
constructors: I guess, that it is actually "nonstandard" to call 
#[...] representations "constructors", since they actually aren't 
"methods used to create instances of...", in fact, they actually 
aren't "methods", but rather "textual representations"
BrianH
3-Jun-2009
[14949]
They are constructors internally, as you describe - try doing a bad 
one and read the error message.
Pekr
3-Jun-2009
[14950]
BrianH: but I somehow have to distinguish usertype from e.g. decimal? 
So how do I do it? And how does REBOL's interpreter know it is mytype? 
How do I match it in parser for e.g.? Any example?
BrianH
3-Jun-2009
[14951]
And they aren't textual representations - the data inside the serialized 
representation is REBOL data, not raw text.
Ladislav
3-Jun-2009
[14952x2]
the error message is: "** Syntax Error: Invalid construct -- #[**" 
how does that tell it is a method?
and, BTW, "construct" and "constructor" does not have the same meaning 
for me
BrianH
3-Jun-2009
[14954x2]
Between that and conversations with Carl, it has become apparent 
that deserialization is done on a type-specific basis, and that the 
supported types have internal chunks of code that handle the data 
in the representations. You are being too specific in your definition 
of "constructor" - even in the OOP languages it means "something 
that constructs".
The internal code is something like MAKE or TO - type-specific.
Ladislav
3-Jun-2009
[14956]
Wikipedia: Constructor (computer science), a special method used 
in object oriented programming which puts the object's members into 
a valid state.