• Home
  • Script library
  • AltME Archive
  • Mailing list
  • Articles Index
  • Site search
 

World: r4wp

[!REBOL3] General discussion about REBOL 3

Andreas
13-Apr-2013
[2358x2]
Ok.
(Or a gob, maybe.)
Ladislav
13-Apr-2013
[2360x2]
Yes, the reason why GOBs needed GC was that they did not fit within 
128 bits.
(GOB is 512 bits)
Andreas
13-Apr-2013
[2362]
So there's a "gob reference" value type?
Ladislav
13-Apr-2013
[2363]
Yes
Andreas
13-Apr-2013
[2364]
Ah, I see. A "gob value" is just a pointer to the real gob structure.
Ladislav
13-Apr-2013
[2365]
REBGOB (the part needing GC) is 512 bits, while Reb_Gob (fits within 
128 bits and points to a REBGOB)
Andreas
13-Apr-2013
[2366x2]
REBGBO! :)
Thanks for clarifying.
Ladislav
13-Apr-2013
[2368x3]
Yes, sorry, it is just struct Reb_Gob called REBGBO.
BTW, REBGBO looks quite ugly to me
(I mean just the name)
Andreas
13-Apr-2013
[2371x2]
Maybe REBGBI (in analogy to REBSRI) would be better?
Is the "index" field of REBGBO presently used?
Ladislav
13-Apr-2013
[2373x7]
yes
you can write:

next gob
So, actually, the "full GOB" is 544 bits, not just 512
(when summing REBGOB and REBGBO while subtracting the pointer.
I am quite curious whether it would be possible to fit a Rebol value 
to less than 256 bits when using 64-bit memory pointers
I originally guessed 160 bits might suffice, but I would not bet 
on it now.
if not wanting to make some "big adjustments", it looks like absolutely 
necessary to go to at least 224 bits.
Andreas
13-Apr-2013
[2380x2]
I'd be quite interested in that as well.
And I'd generally try to stay 64-bit aligned.
Ladislav
13-Apr-2013
[2382]
...which yields exactly 256 bits :-(
Andreas
13-Apr-2013
[2383]
192 or 256, yes.
Ladislav
13-Apr-2013
[2384x2]
some "values" contain 3 pointers, which gives 192 + type information 
+ alignment = 256
Hi, all, a "stupid" question: R3 is still called "alpha" (and there 
*are* issues I want solved before moving it to beta). One of the 
issues is the "gotcha" represented by the DECIMAL! name. I know that 
it is used consistently in Rebol, but it is still a "gotcha" for 
any possible newcomers actually stating something like: "here mathematics 
is not welcome", which is not true so much as I (mathematician by 
the education) would say.


Also, having a "truly decimal" datatype called MONEY! in R3, I would 
prefer a rename:

MONEY! rename to DECIMAL!

DECIMAL! rename to REAL! or FLOAT! (or something else that could 
be popular)


So, how many of you prefer to keep the DECIMAL! name for the 64-bit 
IEEE 754 binary floating point format used in Rebol and

how many of you prefer to rename the DECIMAL! datatype to something 
else?
Henrik
13-Apr-2013
[2386]
I would not mind this change.
Andreas
13-Apr-2013
[2387]
I'm strongly in favour of this change (and would prefer float! over 
real!).
Gregg
13-Apr-2013
[2388]
Not a stupid question, a hard one. 

1) Keep money! as it is.
2) Use new decimal type for decimal!  +1
3) Use float! (not real!) as the name for IEEE754  +1
Ladislav
13-Apr-2013
[2389]
Thanks for 3). As far as 1) and 2) go, it looks that you did not 
read

www.rebol.net/wiki/Money


yet?
Robert
13-Apr-2013
[2390]
Lad: +1
DocKimbel
13-Apr-2013
[2391]
That should be more in line with Red's type naming. So:

* Float!: +1 (though I'm not against real!, float! is more CS than 
maths)

* Decimal! for a BCD type (could use money literal form, so, +1 for 
renaming money!)
Ladislav
13-Apr-2013
[2392]
It looks www.rebol.net is down?
Robert
13-Apr-2013
[2393]
for me too
Gregg
13-Apr-2013
[2394]
Me too. Can't read the link.
Gregg
14-Apr-2013
[2395]
rebol.net is back up, so I looked at the wiki artilcle. To clarify, 
I *did* know money changed in R3. What I meant was that I want that 
to stay the same as it is now, in R3.
Rebolek
15-Apr-2013
[2396]
Good idea, Ladislav, I agree.
Endo
15-Apr-2013
[2397]
+1 for Ladislav's idea.
Ladislav
15-Apr-2013
[2398x3]
Clarification: as far as I know nobody plans to change the implementation 
of the datatype. However, it is not money in fact, it is actually 
better characterized as a decimal datatype. That is why I did not 
understand why did you suggest any new decimal type since it already 
exists using just an inadequate  name.
or maybe adequate... The fact is that the syntax corresponds well 
to the money! name, and it makes sense to keep the syntax as is.
If counting just the votes for/against naming the IEEE 754 binary 
floating point datatype as float! and adding BrianH as one who prefers 
the decimal! name for backward compatibility reasons (he perceives 
a datatype name to be influencing language syntax in a big way) I 
am currently getting:


For float! name: Ladislav, Henrik, Andreas, Gregg, Robert, Doc, Rebolek, 
Endo
For decimal! name: BrianH

I would like to get more votes on this, though.
Pekr
15-Apr-2013
[2401]
Not sure if my "vote" applies, but in the early stages of R3 development, 
I radically protested against anything being called Money, which 
I found being a capital nonsense. Also the "$" char representing 
the datatype notation is OK mostly for US, but not e.g. EU, where 
EUR is represented by its own char. 

So - not sure what my suggestion alligns with, but:


- remove Money datatype altogether, or let it be reserved for money/conversion 
purposes, along with $ char.

- use decimal! for BCD, no $ char, but if we need to distinguish 
from IEEE754, I can live with that 
- use float! for IEEE 754 stuff
PeterWood
15-Apr-2013
[2402]
float! instead of decimal!, decimal! instead of money! +1 (for both)
DocKimbel
15-Apr-2013
[2403]
Pekr: how do you propose to distinguish literal forms of decimal! 
vs float! if you remove the $ prefix? Though I agree that the $ doesn't 
look nice from here (EU).
MaxV
15-Apr-2013
[2404x3]
I love the mone! type, moreover you may use EUR$4 for EURO
It reduce to only 2 decimal automatically, it's very useful!
It advice you if you are macking some mistake
Maxim
15-Apr-2013
[2407]
IEEE renamed to float!,   money! renamed to decimal!  


this way, the vast majority of apps which used decimals before will 
simply continue to work, but be more precise (albeit a bit slower).