AltME groups: search

My point is: an undefined word error is a user error, and exiting 
the interpreter with an error message is currently the best thing 
to do. I've removed the exit points after such errors because you've 
asked me to for making your demos run without exiting. But I shouldn't 
have done that.

I meant the whole user input, mainly for catching undefined words/paths 
and hanlding the error out of DO.

7 failing tests to go until complete equivalence between Red compiler 
and interpreter. :-)

Great stuff guys,  been taking a bit more time to get to know RED. 
 Great work Doc, Kaj, Peter, and the rest of the testers and submitters.

The upcoming release will be quite recommendable, both the compiler 
and the interpreter. Until now, only Red/System was ready for real 
use

Brian, =end is not a termination condition, see these examples:

for i 5 5 1 [print i i: -5] ; this should print 5 and terminate
for i 5 5 1 [print i i: 3] ; this should be print 5 and terminate
for i 5 5 1 [print i i: 4] ; this should be an infinite loop
for i 5 5 1 [print i i: 5] ; this should print 5 and terminate
for i 5 5 1 [print i i: 6] ; this should print 5 and terminate

similar examples for negative BUMP:

for i 5 5 -1 [print i i: 3] ; this should print 5 and terminate
for i 5 5 -1 [print i i: 4] ; this should print 5 and terminate
for i 5 5 -1 [print i i: 5] ; this should print 5 and terminate
for i 5 5 -1 [print i i: 6] ; this should be an infinite loop
for i 5 5 -1 [print i i: 7] ; this should print 5 and terminate

and as I said for zero bump you do not have any reasonable termination 
condition to use that would allow you to iterate at least once but 
not infinitely many times by default, so you just have to terminate 
before starting

and, of course, it is immediately obvious why =end is not a termination 
condition then

'Ladislav, you are not getting that I am applying an *additional* 
termination condition before the start of the first loop, in addition 
the normal termination condition applied after every iteration of 
the loop, before the bump. Please don't mistake an intentional constraint 
for confusion.'  a couple of notes:


- you still don't get that if you are not consistent producing a 
lot of exceptions your code will be full of bugs and arbitrarinesses 
(there is absolutely no escape from this)

- you still don't get that there are concrete examples above demonstrating 
the problems you did not even consider yet

And I am not mentioning other problems I did not even discuss yet.

Brian and Ladislav, how can we resolve this? Maybe you could both 
look at %new-loop.r and it would unite you against my incorrect and 
overly complex attempt. :-)

At a quick glance, I believe for FOR and my LOOP have the same behavior, 
though I didn't address overflow as an initial goal.

And your approach with the bump overflow check is much cleaner.

You can just run it, and it will dump tests and output to the console.

And mine uses CFOR as the internal loop handler. As I noted briefly, 
it's just a dialect wrapper over CFOR.

(which leads to slowness and overhead)

My tests are actually "preconditions" at least in the specification, 
but due to the overflow possibility I converted them to one precondition 
and one postcondition to be able to handle the arithmetic issues 
before they occur.

once the condition allows another evaluation, I already know that 
the overflow does not occur and I can increment without taking any 
risk

And I assume you will add support for other datatypes back into your 
FOR, beyond integers.

Thanks for clarifying. And rememeber how much better your English 
is than my Czech. :-)


My LOOP, using CFOR, is slower to set up, but much faster in the 
loop than FOR (incl your new FOR), so I thought it might be worth 
it.

For those not following closely, the discussion about FOR is trying 
to clarify and document its behavior, while keeping it easy to use 
(e.g., avoid accidental infinite loops). Ladislav has also asked 
for better names for CFOR, his general loop func that is efficient 
and flexible, but requires a bit more care in use. There is also 
a general consensus that FOR takes more args than we would like, 
while noting that we have other looping funcs we can use in most 
cases.


I propose a new LOOP implementation that is compatible with the current 
LOOP func (and delegates to it internally), while also providing 
a dialected interface which is a wrapper to CFOR.

Goals:

* Provide a general loop that is both friendly and flexible
* Support multiple datatypes as FOR does today
* Use CFOR internally for efficiency
* Adhere to the latest model discussed here and on CC

I've posted %mezz/new-loop.r here, but the implementation should 
be considered preliminary, as it was meant mainly to experiment with 
the interface, generating CFOR calls, and analyzing the new behavior 
spec in terms of test cases. It can and should be improved.

Good catch. I just added series support, and since it's a simple 
dialect, it won't like that. In the current version, you would have 
to use an interim var for 'end. e.g.:

>> b: (skip ser 6)
== [7]
>> loop compose [v ser b 2] [print v]

One of the downsides of dialects, and wanting to keep them simple.

The existing LOOP is used quite often, so any replacement for it 
won't go in R3 by default. However, the main reason LOOP is used 
is because it doesn't have the overhead that a lot of the other loops 
have, less than the other natives even. Its simplicity and definite 
form are its strengths - a loop with a more flexible form would be 
need to process that flexibility at runtime, which would add inefficiency 
that could easily be avoided by making that choice at development 
time by choosing the loop that meets your needs. And any loop construct 
that requires any kind of manual reducing of its arguments in order 
to have it take the result of an expression is a definite no-go. 
I just got rid of that in REWORD.


I like http://issue.cc/r3/884as a replacement for FOR. It keeps 
the local binding (unlike Marco's CFOR above, sorry) and is flexible 
in behavior without being flexible in form (it has a very simple 
implementation).

Watch out though, all mezzanine control structures that execute code 
blocks passed as parameters are be subject to http://issue.cc/r3/539
so they would need to be native until we have a solution to that. 
And not a command, because the necessary internal stuff isn't exported 
(purposely), so you couldn't do REWORD as a command.

ok, much better now, just add [catch] at the beginning and it will 
catch also errors.

No need, because this is an R3 function and R3 doesn't have [catch], 
it has better errors with stack traces instead. Improvement.

I had to get rid of [catch] in my first edit. And [catch] is a bad 
idea for loops because it hides where the real error is being triggered.

Better to test it in R2 then to not test it at all. (By the way on 
R2 mine is a little faster).
I changed :ret to get/any 'ret and it works but in R3 :
>> do [cfor [num: 0] [num <= 3] [num: num + 1] [num]] ; works?


and why is it important to keep the local binding ?(I am not an expert 
of binding)

The entire difference between CFOR and WHILE is that local binding. 
If you didn't need the local binding you should use WHILE.

Benefits to the local binding:

- You define new words that go away when the function ends, *if you 
want them to*

- The context created is an object context, which makes word lookup 
faster (O(1) instead of O(n))

- The context created can be references safely after the function 
ends

- All series in the loop body are copied, which makes them safe to 
modify during and after the loop, making binding loops even more 
task and recursion safe than non-binding loops.

Sunanda, agreed on not export complexity. Words are supported directly, 
and we can look at making everything easy that it should support. 
Today, words are supported. e.g.:

a: 1
b: 5
loop [i a b 1] [print i]


Series values, as in your first bug report, are the thing I have 
to look into. Beyond that, should it just evaluate everything it 
gets?


Marco, FOR-STEP sounds too close to FORSKIP to me. Have to think 
about how FORSKIP fits in to the model. For that, and IN-RANGE, the 
main question is what their purpose is. On your first CFOR tests, 
I get these results:

>> probe cfor [num: 1] [num <= 3] [num: num + 1] [print num "a"]
1
2
3
4
== 4

>> probe cfor [num: 1] [num <= 3] [num: num + 1] [if num = 2 [throw 
make error! "what 2?"] "a"]
** Throw Error: ** User Error: what 2?
** Near: throw make error! "what 2?"

@Gregg: >> probe cfor [num: 1] [num <= 3] [num: num + 1] [print num 
"a"]

for me it should print: 1 2 3 and give "a" as the result (as it does 
#884 NOW ;) )

@BrianH, when you say "And any loop construct that requires any kind 
of manual reducing of its arguments in order to have it take the 
result of an expression is a definite no-go.", does "manual reducing" 
mean having the user do it? e.g., if I get a spec passed to my dialected 
LOOP func, and I REDUCE it or DO/NEXT internally, is that a no-go? 
If so, where should I look for the reasons and guidelines about it?

Tested on Linux and OSX, interested in hearing whether it functions 
correctly on Windows.

I think we should consider this heavily. Ladislav's points, and Brian's 
analysis in http://issue.cc/r3/1946make it clear that we need to 
understand the differences, and that we can probably get a large 
gain with very small tradeoffs.

Important message for all R3 graphics fans:


I have finished IMAGE datatype(including all image codecs and other 
related code) change so it uses 'standard' alphachannel values (ie. 
0-trasparent 255-opaque)to be compatible with the 'rest of world'.

Without this change we would have problems to connect r3 with graphics 
systems on misc platforms/graphics frameworks etc.

This change will be in the upcoming revised R3 graphics code which 
is being worked on. So that is just FYI to avoid any duplicated efforts(in 
case you wanted to work on that in the feature).

I have an updated SPLIT-PATH, modeled on Ladislav's implementation 
where it holds that

   file = rejoin split-path file


This does not match current REBOL behavior. His version arguably 
makes more sense, but will break code in cases like this:

	%/c/test/test2/ 
	REBOL      == [%/c/test/ %test2/]
	Ladislav's == [%/c/test/test2/ %""]


Ladislav's func only seems to go really wrong in the case of ending 
with a slash an that's the only slash in the value which return an 
empty path and entire filespec as  the target.

Schemes (http://) don't work well either.


REBOL also dirizes the file path if it's %. or %.., which Ladislav's 
does not. e.g.

	[%foo/ %../]  == split-path %foo/..

split-path: func [

 "Returns a block containing a path and target, by splitting a filespec."
	filespec [any-string!]
	/local target
][
	either any [
		; It's a url ending with a slash. This doesn't account for
		; formed URLs. To do that, we would have to search for "://"
		all [slash = last filespec]
		all [url? filespec  slash = last filespec]
		; Only one slash, and it's at the tail.
		all [target: find/tail filespec slash  tail? target]
	][
		reduce [copy filespec  copy %""]
	][
		target: tail filespec
		if slash = last target [decr target]
		target: any [find/reverse/tail target slash  filespec]
		reduce [copy/part filespec target  to file! target]
	]
]

The above matches Ladislav's REJOIN requirement, and handles a couple 
edge cases better. I have about 35 tests here, if people want to 
see them for discussion.

And could/should it be generalized by adding a /WITH option to specify 
a path delimiter other than slash?

Well, it really is worth it to find out what the preferences are 
and whether people like the "invariant" I proposed.

It makes sense to me Anton. I don't know why SPLIT-PATH does what 
it does today, by automatically dirizing that result. If everyone 
agrees, then the next question is whether a trailing %. or %.. should 
be returned as part of the path, or as the target. That is, do we 
presume that they are directories?


SPLIT-PATH, today, returns the last dir in the path as the target, 
if the path ends in a dir. Here are some example values, and what 
SPLIT-PATH returns today.

By saying that SPLIT-PATH always behaves the same way, depending 
on whether the path ends with a slash or not, it may not shortcut 
a few cases for us, but it does make it easy to reason about, and 
also to wrap for other behavior. e.g., you can always dirize the 
path before calling it.

after thinking again, I would perfer %./ as the last part of the 
result of split-path, as it has a trailing slash and it  is still 
the samel

I think I would prefer split-path so split into the last non-slash 
component (target), and the original path with that last non-slash 
component removed.

Anton, but then you could never get an empty target, and you would 
have to compare to %./ as your empty value.

And then make sure that wasn't the end of the original path.

And here's where my proposed SPLIT-PATH fails:
Path quality failed: %. %/.
Path quality failed: %.. %/..

Here's a few example values and what I would expect: 

http://sprunge.us/AaDJ


Where there is a third column, current R3 split-path differs from 
what I'd expect, and the third column is what split-path returns 
currently.

But with a "path component"-based invariant, the %. %.. and %/ cases 
will require more work to reconcile.


With a "string"-based invariant (rejoin), those cases could more 
easily be described with the neutral %"" element:

And where it fails the path (p/:t) invariant is in these cases:
Path quality failed: %"" %/
Path quality failed: %foo %/foo
Path quality failed: %. %/.
Path quality failed: %.. %/..

I don't have a *nix VM up here to check basename and dirname results.

I haven't had the time to follow all the discussion in detail, but 
to me, the second part of split-path should NEVER return a directory 
path. 


when doing   set [dir file]  I should be able to count on the fact 
that the second part is either a file or none.  The same for the 
first part which should always be none or a dir.  I have my own implementation 
in R2 which makes this strict and it simplifies a lot of code.
so we can do with absolute certainty:

if second set [dir file] split  path [   ]


IIRC some of the versions of my split perform a clean-path to simplify 
and add robustness to the result.

Re:

%/c/test/test2/ [%/c/test/ %test2/]


- this test does not violate anything but it does not split the "pathfile" 
to "path" and "file" parts

question is, is that invariant useful? 


really, I like consistency almost above all else, but I prefer when 
it not just neutral.   getting empty file specs is very awkward to 
use and doesn't work well with all the none transparency which makes 
a lot of the conditional code so easy to read.  one reason this is 
so readable in REBOL is the limited use of equality operations, when 
doing complex decision making.

And the reason I posted the SPLIT-AT question was to see if we could 
find a solution for both.

And while I understand that a file with no path implies the current 
directory, we lose information by assuming it. For example, if I 
let a user specify a path or filename, and I split it, now I can't 
tell if they gave me just a filename, or if they gave me %./<file>.

And it doesn't satisfy either the string (REJOIN) or path invariant. 
If we care about either of those, it's a problem.

For those interested in the "alpha-channel change":

Here is the branch with first round of related code changes to the 
image! and image codecs: https://github.com/cyphre/r3/commit/472c106a0f177ead82a6f29be1ae98b4cd33b9ad


Note: This code doesn't contain any graphics related changes...just 
the image! datatype + image codecs so you can MAKE images and load 
BMP, GIF, PNG and JPG files. But it should be enough to test the 
change.

(I have this code already intergated with changed AGG graphics and 
it works well but I haven't published it as this part is not compatible 
with the 'official' git source at the moment.)

Note2: the code was not tested on big-endian systems so it is possible 
there can be some quirks. Use at your own risk and let me know about 
any problems.


The RGBA tuples on IMAGE! now work so if the fourth(alpha) value 
is not defined it is assumed the RGB tuple is opaque (ie. alpha = 
255) so 0.0.0 = 0.0.0.255 etc. This way color values in old code 
that doesn't explicitly define alpha values are still compatible.


If you are interested, try to compile and test a bit. Let me know 
if you see any issues. Thanks.

Isn't a convention that %foo/ is a directory while %foo is not?  
That's one way to tell if a given file! directory or not...  It's 
what I generally expect, and I agree with Maxim that it makes the 
most sense for split-path to return #[none] if there is no file.

if it where a generic string handling function I'd agree with you... 
but its not... it has added meaning, it splits filesystem paths. 
 its not just a string.  if it where, I'd use parse or some tokenize 
func.

I see absolutely no merit in trying to make split-path act like a 
generic string handling func.  the point of the func is to separate 
folder and file into two parts.   to me it comes down to either you 
decide that when there is no data you invent a default, or use the 
internal one which is none, which works well with soooo many other 
funcs.  if there is no directory part in the path, do not try to 
find a suitable value for it... there is none... funny, even when 
trying to explain my point of view, the actual sentence reads almost 
like a line of rebol source.  :-)

I understand your view Max, but that's not what I asked. It doesn't 
work the way you want today, but maybe there's a way to provide a 
solution that is better than what we have now. I'd love to see your 
custom version, so we can compare its results. And I'm asking about 
SPLIT-AT for a reason, separate from SPLIT-PATH. I'd love to get 
everyone's thoughts.


The funny thing is how much we can all care about the details of 
this func we (at least I) use a lot, and yet which none of us seem 
to like all that much. I think it points out that the normal case 
is the most important, where there is both a path and a file component. 
And maybe now is the time that we can make it just a little bit better, 
a little more consistent.

It's not a bug, it's a limitation of Rebol's binding model. Needs 
is called before the script is bound, and before the module context 
even exists (if the Needs is in a module header). Due to a couple 
of tricks IMPORT can mostly as a function running in scripts (shared 
globally referencable context), but it's impossible for it to work 
as a function in modules because the target scope is impossible to 
determine and the code was bound already before it even started running. 
So, long story short, IMPORT is for calling from scripts, or for 
Needs to call internally, or for advanced code where you are doing 
your own exporting.

The generic problem to solve is this: You somehow have to specify 
what should happen for different actions. 


Let's start with the "somehow have to specify what should happen". 
For this you have some options:

1. Write the application logic code in the GUI spec block. For sort 
stuff OK, for long not.

2. Just call a function from the GUI spec block and write the rest 
somewhere elese. That's IMO the best way. I used FSM and just send 
"application logic events".

The next part is the "for different actions". Same here:

1. Name them explicitly on-* and specify the code with one of the 
options above.BTW: IIRC R3-GUI has click and right-click blocks for 
convinience.

2. Define an implicit mappging from block order to event type. 1st 
block = click, 2nd = right click, 3rd = double left, 4th double right, 
etc. IMO that's not a good style.


Overall what I never liked about VID was that is was not explicit 
enough. For big projects that's a must. For small you might skip 
this but if those projects get bigger, you are hit again.

The problem is, that while the R3-GUI is now more flexible by removing 
reactors, it is also more difficult to understand. I remember trying 
to understand the 'on-action issue in the past, now I briefly re-read 
the doc, and I still can't understand the design. I need following 
things to be cleared up for me, so that I can both use it, and possibly 
explain it to others:


1) If you look into Actors docs - http://development.saphirion.com/rebol/r3gui/actors/index.shtml#
, there is no mention of 'on-action actors. There are many actors 
listed, but not the 'on action one


2) The 'on-action actor is mentioned in the attached doc at the same 
URL, describing, why reactors were removed. So here is the definition 
of 'on-action: 

        a) "The ON-ACTION actor is useful if the style needs to call some 
        default action from multiple places (actors) in the style definition." 
        - understand the purpose, but why and when I would like to do such 
        thing? Any example easy to understand? Just one sentence maybe?

        b) "For example, the BUTTON style needs to call the default style 
        action from the ON-KEY actor and also from the ON-CLICK actor, so 
        it is better to call the ON-ACTION actor from the both code points 
        to avoid the necessity to override multiple style actors." - looking 
        at button or even clicker style definition, I can see no such stuff, 
        as 'on-key or 'on-click calling anything named 'on-action. That is 
        the part that is most confusing for me, and which did not help to 
        understand the 'on-action a little bit. Are we talking about the 
        'do-face here?


There is also a question, if better name could be found for 'on-action. 
Unless I can fully understand, what happens here, difficult to suggest. 
Now to make it clear - I am not judging architecture, just trying 
to get my head around the docs and button/style examples. And being 
average reboller - if I have difficulcy to understand it, the chances 
are, there is more ppl, which will strugle in that area?

Another interesting thing I noticed:

    facets: [
        init-size: 28x28
        bg-color: 80.100.120
        border-color: 0.0.0.128

        pen-color: ; set by on-draw
        area-fill: ; set by on-draw
        material: 'chrome
        focus-color: guie/colors/focus
        draw-mode: 'normal
        materials: none
        face-width: none
    ]


Normally, in regular Rebol code, 'pen-color and 'area-fill, would 
be set to 'chrome, if I would use it to construct an object. But 
maybe it is just a spec block, so I should not care? I mean - what 
about setting them initially to 'none too, for a convenience? :-)

MaxV: "This way you have to write very long commands to achieve the 
most simple tasks (show mybuttob/gob ... mybutton/gob/size). Is it 
just my impression?"


My guess is you are not using R3GUI correctly. If you are using the 
current included R3GUI styles you shouldn't be forced to write any 
SHOW commands at all(the SHOW command is considered 'internal' in 
R3GUI and shouldn't be used anyway). Just use the SET-FACE/GET-FACE 
api to make changes to the specific style.

In worst case (usually when some ON-GET/ON-SET handler is unfinished/incomplete 
in some style) you can either try to enhance/fix that style part 
or

if this is too difficult for you you can try to use SHOW-NOW <face> 
to really force 'show' on the specific element.

Pekr: I agree the docs are still not corrected...infact it is a mix 
of old(patched) docs from Carl and some '"dev notes" docs from Saphirion 
team who did significant changes.

I started to at least review the Carl's docs to fix the most confusing 
or obsolete parts but I relaized I have not enough time now for that 
instead of programming. 

If you want to help clean-up the documentation or even write new 
document...kind of "User guide" for newcomers I'm offering you a 
help/support with any questions issues etc. during the doc writing, 
just le me know. Also we can discuss the issues in the R3GUI group 
here (I still wonder noone is asking anything...probably noone is 
interested?)

I think ppl in kind of an wait mode. Some interested in Android in 
general, some interested in Red progress, som interested in Ren, 
most of us busy other way.  Max in fact is doing a good job - he 
tries to use the system in a practical way. My questions are just 
theoretical, just by reading docs and looking into the code. I know 
I will be back to GUI at some point, just dunno when ...

Robert, people like me feels they wont be able to face all the problems 
that will arise from uncomplete/unwritten documentation and prefer 
a REBOL2 version.

 it is also more difficult to understand
 - frankly, *this* is difficult to understand:
* before, you had to understand both actors and reactors
* now you need to understand just actors, reactors vanished

...and you call it "more difficult to understand"?

I don't know anything about R3GUI
There is an uncomplete documentation

It is difficult for me to understand new things. Since the documentation 
is uncomplete and refers to outdated concept it will be more difficult.
RMA has promised a new documentation
Since then I can wait to work in REBOL3
Also REBOL3 has many bugs and it is still in ALPHA

(Please note, no accuses of any king, only direct word from my mind)

Also REBOL3 has many bugs and it is still in ALPHA

 - what about the (already known for a while) info that R3 has less 
 bugs than R2?

That has been announced in the "Testing and tools" group long time 
ago.

Excuses have reasons.

Lets dress the clothing of someone which should adopt something new 
rather and unknown instead of something old and well known.

That programmer should adopt an ALPHA labeled product that let flash 
in his mind difficulties like "BUGS, NO DOCUMENTATION, SUDDEN CHANGES"

Apart from Unicode, we have no comparison over REBOL2 for new and 
better feature which could motivate the programmer.


Ladislav, consideer that people are humans. They have obstacles in 
their life. It is our role to understand which obstacles they have 
and how to "reframe the context" to avoid them.

I think that my situation is more common than we think.

R3 needs some marketing action to promote itself and lets people 
feel they can use it.

Apart from Unicode, we have no comparison over REBOL2 for new and 
better feature which could motivate the programmer.
 - wrong again, you surely heard about:
- essentially all cycles being natives in R3
- money implemented as a "truly decimal" format

- functions implemented differently to be compatible with multithreading, 
etc.
- closures implemented natively
- Parse improved significantly
- R3GUI improved
- new modules feature
- I do not even have the time to list all...

As I said, and need not take back: excuses

Ladislay - you yet again missinterpret what I expressed in my message 
above. I don't care about removal of reactors, it is not about actors 
vs reactors. I clearly posted points, which I don't understand - 
simply I don't understand, what is architecture behind on-action. 
And that's all.

You can ask all questions, and we will answer.

About excuses - there are imo no excuses. As I said - we are just 
few, and ppl are busy with other things too. As for those really 
needing GUI right now (it's not me for e.g.), I think, that some 
ppl prefer what they know R2 VID, RebGUI, just because of typical 
entry barrier. There is nothing wrong with R3-GUI imo, and from what 
I studied in the past, it is much better system than R2. Sometimes, 
it is difficult to find out real reasons, why ppl react this way, 
or that way, I just dunno ...

And while doing this, if you start writing it down for others that 
would be great. And, we get feedback what's not a good design etc.

I'm just wondering why things don't lift up... and the explanation 
given. I'm just wondering.

Well, just count ppl here ... how many ppl are active? Even this 
channel is now split between here and Stack Overflow ...

Sure, but if this is the conclusion, we better stop today and use 
something different.

Yes, I know - if I would have to write some small util for me, it 
surely would be R3 nowadays. The only thing I might miss is better 
CALL and maybe ftp protocol. But it can be solved ....

And of course time is limited, tell me. Nevertheless, if it's important 
people will do things.

I'm not waiting for anything in particular WRT R3. I am very anxious 
to have time to start using it more, and I am grateful to the Saphirion 
team for taking the lead on it and doing so much work. Because they 
have, I decided that what time I can make right now I will put behind 
Red, as I think I can provide more value there, and to give Doc some 
support for all his work too.

I'm also going to post more thoughts and questions about funcs, like 
I did with SPLIT-PATH, because now is the time to make any changes, 
IMO.

(even if two functions have the same SPEC and BODY, they always have 
distinct ARGS)

Only series and GOBs need GC

REBGOB (the part needing GC) is 512 bits, while Reb_Gob (fits within 
128 bits and points to a REBGOB)

(when summing REBGOB and REBGBO while subtracting the pointer.

And I'd generally try to stay 64-bit aligned.

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?

I'm strongly in favour of this change (and would prefer float! over 
real!).