AltME groups: search

forth computers are single stack .. they haven't conquered the world

I have added a new function type today: routine!. It allows to write 
a Red/System function in a Red program. The compiler will marshal 
(or type-cast) the arguments back and forth automatically.

Here is the Fibonacci example rewritten as a routine:

Red [ ]

fibonacci: routine [
    n          [integer!]
    return: [integer!]
][
    either n < 2 [
        n
    ][
        (fibonacci n - 1) + (fibonacci n - 2)
    ]
]


The function body is Red/System code, so it will run at full Red/System 
speed.


Integer! and logic! values are converted automatically, other Red 
datatypes are passed boxed but type-casted as Red/System counterparts 
(as defined in the Red runtime). Hint: floats will be converted automatically 
too.

So, passing and processing a block! series would look like this:

Red [ ]

add-one: routine [
    blk       [block!]
    return: [block!]
    /local value tail int
][
    value: HEAD(blk)
    tail: TAIL(blk)
	
    while [value < tail][
        if TYPE(value) = TYPE_INTEGER [
                int: as red-integer! value
                int/value: int/value + 1
        ]
        value: value + 1
    ]
    RETURN(blk)
]


I haven't yet released the code, it needs a bit more work, it should 
be ready by tomorrow.


The purpose of routine! datatype is to provide access to ultra-fast 
and low-level code for Red program in a simple way. The design is 
not yet fully set in stone, so suggestions and comments are welcome.

Another thing: are natives more efficient than routines?

  Routines and natives are both Red/System code that use Red runtime 
  internal API, so they perform the same. In case of routines, you 
  might have a tiny overhead for integer! and logic! that are converted 
  back and forth between Red and Red/System, but it is really very 
  small, and only significant if you iterate a lot of times over a 
  routine call.


From the memory and boot time perspective, natives are more efficient 
because their body block is not stored internally  for reflection 
like routines. So, for functions like QUIT that should be part of 
Red core, it is better to implement them as natives, to save memory 
and booting time.

Forth and RPL (I've done a lot of code in RPL long time ago) use 
DUP as abbreviation for "duplicate".

Normally, you would bind low level interfaces or code using Red/System, 
or the DLL interface in R3, or an extension in R3. You would then 
marshall all the arguments of the low level functions back and forth 
to Red or REBOL all the time

I'm happy to announce that we reached a major milestone and can release 
a bunch of new things. All the different versions have been merged 
into one code base which makes things easier for us. This was possible 
because the new 'retargetable' graphics subsystem was finished. This 
allows us to port R3 to other platforms much easier. Next target 
Linux. The release in detail:


R3-GUI: Quite a lot of fixes and enhancements. Thanks for all the 
feedback. The main milestone we achieved was to switch to a resolution 
independent sizing system. This will scale your app widgets to look 
the same on different display densities. It's a must have for mobile 
apps. Next for R3-GUI is to create a simple mobile style set. Fruther, 
we are going to push the source code to GitHub. We need to setup 
a bridge to our internal SVN repository, so expect some back and 
forth on Github before we are stable.	Anway feel free to help making 
R3-GUI better and better.


Android: This release is now mostly the same as the windows release. 
So, yes, it's now possible to do R3-GUI apps on Android. I'm going 
to try to run Treemapper on it. Type DEMO to see the new R3-GUI version 
and widget scaling feature. Post as much screenshots / pictures of 
your phone as you can :-)


R3/Saphir: New version for windows with bug-fixes are released as 
well. Please see the change-log on our web-site for details.


Thanks to all the team for the great work! I really think we are 
close to have a very good and stable base with R3 and R3-GUI. Looking 
forward to see more and more people joining and becoming part of 
it.

Links:
http://development.saphirion.com			(Change Logs, Downloads, etc.)
http://development.saphirion.com/experimental	(Android)
https://github.com/organizations/saphirion		(Documentations)

Forth

Or some type of account that we can switch back and forth to, maybe 
a read only account.

I've been using Altme for a project with a guy who is very non-tech. 
He did not know how to drag a window. Anyway, it is working out great. 
We are using File sharing to re-format a bunch of text files and 
with the abilty to add comments and check lists its saving a lot 
of time over traditional Email. He is still not really up to speed 
so once he is it wil really shine. And with the abiltty to just add 
new members where they can read any old messages to see where we 
are and what we have been doing.


I regret not using it for my Appraisal business. My partner and I 
had to email files back and forth all the time. And sometimes we 
needed to get files from one another but one of us was away or not 
at our computer. If we used Altme we would never have had that problem.

maybe it should really be a docu-rule. Forth has some flag-letters, 
like M: multitasking-impact etc. We could have C: copies/not, calls 
wait, what else?

Hmm.. I don't know the correct terminology, so I can't explain what 
I mean very well...

>> smtp: open/lines tcp://bible-way.org:26
>> insert smtp "HELO Louis-here"
>> probe copy smtp
** Access Error: Network timeout
** Near: probe copy smtp


SMTP ports stay open while data is transferred back and forth.  Copy 
doesn't return until the port is closed - so in the above line, copy 
is waiting until the server closes SMTP, and the server is waiting 
for a command from the client.


It's the reason why (as I understand it) Grahams "pick smtp 1" worked, 
but copy did not - SMTP was still open, even though there was data 
for the client to read.  (I was stuck on that myself for a long time 
 ;-)

annoying .. can't use those forth tricks that require 0 to be false!

So for anyone new to REBOL or more generally to Forth (being one 
of the inspirations behind REBOL) I'd like to strongly recommend 
reading Leo Brodie's Thinking Forth - free PDF here - http://thinking-forth.sourceforge.net/


I stumbled across this group of programming books http://prog21.dadgum.com/19.html
and it reminded me I had meant to do some reading on Forth.  I'm 
now a third of the way through the Thinking Forth book kicking myself 
for not having dug into this earlier.  Just like learning about the 
functional perspective with Lisp and Erlang this reading is expanding 
my programming perspective with every chapter.  In addition to being 
valuable in the REBOL context it is simply a great book on programming 
in any context.

Rod.   Classic.  Not as classic as Starting Forth, but hey.   Marcel 
Hendrix has posted Starting Forth as well, but had trouble with the 
cartoons, and the replacements are not quite as "fun".  And just 
so ya know, only Marcel was given the right to copy, explicity only 
Marcel, by Forth Inc.   http://home.iae.nl/users/mhx/sf.html

Whoa.  Elizabeth has posted a much nicer reprint on the forth.com 
site.    http://www.forth.com/starting-forth/
Nice!

Thanks Brian, will check out starting forth as well.

Most of had Starting Forth and Thinking Forth so our bosses bought 
us great huge fat Thesauri  thinking it would make us better  coders. 
 We laughed at first, then our dictionary grew to the 100,000 word 
mark and they started to get  dog eared.  :)

the thing to know about parse mhinson is that you want to set forth 
the righ  matching conditions to get to the end of the string that 
your parsing because if something doesn't match it will abort at 
that point and return false.

Hello again all,  I'm BrianD (but be glad that's not my alias or 
it would make the Wiki back-and-forth with BrianH even harder to 
read).

that shouldn't be hard. actually, being that ps is forth, once you 
code the functions you need it's almost a 1:1 translation

saw that in one forth book.

James is getting into Forth, and I was just looking at some old notes 
I made on ForthR (play on "further"), where the machine primitives 
are actually a little REBOL VM/emulator, rather than ASM for a specific 
chip. Easier to get started, though not real Forth.

I have the figforth assembly code for the 6502  ... so you could 
run fig forth on your 6502 emulator ?

about proposals, currently we have only one atom operation to control 
advance in the serie: [skip].
We could had some other atom operations, like DROP,SWAP,ROT,DUP.
(any reference to FORTH language are intentional)

don't ask me an usage, it's only because i'm currently working on 
a FORTH engine

Then make actions for data to go to JSON, XML, XHTML, back and forth 
to a database,....

Chuck Moore uses color extensively in his color forth .. to replace 
other types of syntactic markup.

Looking at the new WHILE keyword and I was quite baffled by Carl's 
use of it in his latest blog example. Then I read the docs and it 
didn't get much better:

- WHILE is a variant of ANY
- ANY stops, if input does not change
- WHILE doesn't stop, even if input does not change

What does "input does not change" mean?

Is it about changing the parse series length during parse?

Is it actively moving the parse index back or forth using special 
commands?

Is it normal progression of parse index with each cycle of WHILE 
or ANY?

Is it alteration of the parse series content while maintaining length 
during parse?

I don't see it. One of the authors later wrote a portable Forth, 
so JForth is probably not very portable

The runtime portion of a Forth is extremely small, so if you can 
get that to compile, you're basically there

That compilation is done by the compiler. I doubt they have a lot 
of assember in it. But strong point is integration with amiga-apis 
AFAIK, i guess without it its just a forth.

What compiler? A C compiler, or some sort of Forth compiler?

forth-compiler.

If you want this, you should look at the portable Forth that one 
of the authors did

Anyway, it's full of forth source so that could be useful if someone 
else ports another forth over.

forth-compilers are not that complex, mostly "look word up, copy 
some bytes". Except of the professional ones which do register-optimizing 
and tricks.

the forth interpreter is tiny ...

well, Phil Burk did release his portable forth with source ... so 
that's the way to go I guess.
http://www.softsynth.com/pforth/

Taygeta has a native forth tcp/ip stack.

then forth would make really sense.

Should have used Forth :)

I've been playing with Kubuntu on and off for a month or so. Sometimes, 
after updates to the system, something breaks.

I would like to know what is the best way of backing up and restoring 
the system.
I think the best way might be to copy partitions back and forth.
I have a few LiveCDs like the System Rescue CD.
What do you guys do ?

off topic question - in Rebol you have contexts in which words are 
hidden.  In forth you have vocabularies in which you define your 
lexicons.  But in forth it is much easier to switch to using a different 
vocabulary by changing the current vocabulary.  In Rebol you have 
to specify the context to use a word from within that context.  Would 
it make sense to implement such a feature in Rebol?

So, modules would be like forth vocabularies ?

Forth vocabularies are heaps of word definitions (code and data).

It has been too long since I used Forth to know precisely!

but here is more control about what you use from other modules. if 
you search "forth" in big systems, thats 1k words. here we can say 
"want only drop dup swap".

Requesting Opinions.  Being a crusty old forther, I really really 
miss the immersive nature of the block editor environment.  Coding 
in forth meant never leaving forth.  Editor, debugger, disk drivers 
etc... all forth commands.  No need to ever have the brain exit forth 
mode.  Now that Rebol is my language of the future, I kinda pine 
for the past.  The wonder and beauty of Rebol keeps being interrupted 
by decisions on what to use to edit that last little bit of script. 
 Notepad, Crimson Editor, Rebol editor? A small annoyance but it 
still disrupts the brain from getting to streaming mode.  So now 
to the question.  My first crack at a forth block editor dialect 
failed miserably.  Dialects need to be LOADable for parse to function. 
 Editing source code makes for unloadable situations.  Do I just 
give up on it and learn to live in the third millenium?  Write a 
utility that doesn't use dialects (which seems to unRebol the solution)? 
 I thought I'd ask you guys, just in case there is a light shining 
in front of me that I can't see.  Thanks in advance.

forth editors used to access the hard drive sectors directly.  You 
want to do that?

Well, I've never gone Forth, and I'm not sure what a block editor 
is, but maybe you can benefit from some console commands. I almost 
always use Crimson Editor. I have an EDIT command which launches 
Crimson Editor, and I navigate the filesystem in the rebol console 
using dir-utils.r, which supplies unix-like filesystem commands; 
CD, LS, MV etc.
http://anton.wildit.net.au/rebol/os/windows/edit.r
http://anton.wildit.net.au/rebol/library/dir-utils.r

Sorry for the confusion here.  A forth "block" editor, uses a 1K 
chunk of disk as 16 lines of 64 characters.  There are forth words 
for the editor e.g.  9 LIST ( list block 9)     3 T ( Highlight line 
3)  P newword: ( n - n) DUP . ;   ( place the text "newword: ..." 
to end of command line onto line 3.  What you get is an editor that 
uses the same language that you are programming in.  Immersive.

Sorry Technically Inaccurate Typo.  newword: DUP . ;  would not compile 
in forth.  : newword DUP . ;  is correct.  Long Live Rebol.

Gregg wrote (in group Rebol vs Scheme):

I would *love* to see mini-primers on language design for Lisp, Forth, 
Logo, etc. in REBOL.

I've taken the first step for a BASIC dialect:

do http://www.fys.ku.dk/~niclasen/rebol/basic.r

It only knows a few commands so far: auto list new old
And these statements: end goto print rem run
And these functions: cos sin

Very cool John. Now, let me throw another thought into the mix, just 
for fun. 


If you were to write a language interpreter long ago, you would do 
it in a low level language like ASM or, later, C. In those languages 
you didn't have high level constructs like we have in REBOL. Certain 
languages have very specific models; consider Lisp and Forth, each 
has a few core definitions and the rest of the language it built 
on those. Lisp has lists, Forth has blocks, etc. 

With REBOL, we can do things in many ways. 


1) Leverage all REBOL has to offer. For example, how hard would it 
be to write a simple Lisp system if you (basically) use blocks for 
lists and supply a few standard Lisp functions? Is eval'ing a Lisp 
paren/list different than DOing a REBOL block?


2) Write lower level code, simulating how you would have to write 
a language using something like C or ASM. You could go as far as 
writing a simple virtual machine with its own set of ops.


3) Write dialects that are designed for building specific kinds of 
languages, showing the core concepts of languages, where they're 
similar, and where they differ; tools for teaching language design. 

I think all of those approaches have something to offer.

http://maschenwerk.de/foerthchen/


This guy has written a forth in javascript ... guess it's doable 
in Rebol

Comments, hmmm.  You've done an awesome job John.  I learned Z-80 
assembler back on my TRS-80 before I did much BASIC.  When they finally 
got a computer class in my high school for ninth graders, I was already 
in grade 12 and laughed at the BASIC.  So, instead of having me whining 
and whinging all class, I got to write a student database program 
in assembler for my electronics teacher on the Commodore PET.  Never 
been a fan of BASIC, but what you've done can only attract a larger 
REBOL audience so well done.  If you can make it compatible enough 
to run old DOS frogger.bas you may have a demo that gains worldwide 
attention.


Technically, back to your point, (having sadly only glossed over 
your codebase), what if you tricked the "line" internals say with 
pair! or decimal! keeping your own sub-lines invisible to the user?


And if you start up a Forth dialect...I'm in.   Or at least will 
show a keener interest watching a guru at work   :)

Thanks for the input! I thought about something similar, having a 
sub-pointer as you speak of. It could work. But I got the feeling, 
it'll be a better design, if it's done like the original, using an 
internal format with byte-code for the keywords. I have to judge, 
how much work it is.


I'm interested in Greggs original ideas, which got me going with 
this, to implement different languages. I'll consider Forth as the 
next one.

Forth has a very (untouchable actually) immersive feel to it.  As 
long as you avoid working with the sad sad current trend of text 
file forth, everything you do in Forth is Forth.  Editor commands...Forth, 
disk management Forth, debugger Forth, locate and cross reference, 
Forth.  Anyway I'm still questing for a REBOL enviroment that allows 
that immersive feel.  No brain switching to Editor, back to console 
command brain, then another brain switch to file manager, bobloblaw. 
 Mondo powerful when you can keep your brain in one mode for a full 
eight hours.  Even building Forth was Forth.  I do kinda miss it, 
but only for semimental reasons.  REBOL is just too cool to think 
about going back.

What is a good Forth version as a reference system? ANS Forth? I 
also need a place to look, where the language is explained in a clear 
and short form.

http://www.retroforth.org/
http://www.colorforth.com/cf.html
http://www.xs4all.nl/~thebeez/4tH/4thide.htm
http://maschenwerk.de/foerthchen/

http://www.fig-uk.org/byof.htm
http://www.complang.tuwien.ac.at/forth/threaded-code.html

http://www.amresearch.com/starting_forth/
http://thinking-forth.sourceforge.net/
http://www.ultratechnology.com/1xforth.htm

http://c2.com/cgi/wiki?ForthLanguage

I have a lot more links here as well, but the best reference may 
be Brian, since he was a real live Forth user. I also have a couple 
books on my shelf, but...

Leo Brodie's books, Starting Forth and Thinking Forth, are the seminal 
works on the language.

You beat me to it Gregg.  Starting Forth by Leo Brodie.  It includes 
the old school (and really the only reason to use Forth) block editor. 
 Without the block editor Forth is pretty much just another language, 
with it (and after getting used to EDLIN style editing), you get 
the immersive holy grail.  Thinking Forth is quite a bit more cerebral, 
but I know it's been made available in PDF, but I found this...

http://home.iae.nl/users/mhx/sf.htmlso far.

I never got into Forth more than playing around, but I *love* the 
idea of the immersive experience. REBOL is that in many ways for 
me, because I can think about so many things using REBOL as a context. 
I think the idea of dialects could lead us to domain specific environments 
that are like Forth, in that they are highly focused and immersive.

Forth Inc will send you a copy of of Swiift   http://www.forth.com
 it has a block editor, but they've moved away from supporting it 
so they could 'do Windows'...a pity.  And wait...did I say Forth 
was "just another language"?  Where did THAT come from?   Long live 
REBOL.  :)

If I had to quickly pick an order;  REBOL, Forth, SNOBOL, Lisp.  
If I was told I HAD to do it in a class based object oriented language 
I'd probably pick SmallTalk ... no ... I'd probably just leave.  
To be honest, I've rarley seen a DSL that didn't require a programmer 
to script it anyway, so... I find the whole thing kind of moot.  
Moot is the wrong word.  A non-coder MIGHT be able to VID up a GUI 
but I doubt it would do much...or by the time they were done, the 
non-coder would have unknowningly become a coder.  I've not seen 
a DSL I'd turn over to Bob the manager to write progams in.  Even 
languages written to be specific; Erlang for telephony, Forth for 
telescopes, are still programmer languages. REBOL comes soooo close 
to being a data language that humans can use...but unfortunately 
nope;  Programmers required.  The magic all happens when you can 
build up layers, and stand on the shoulders of giants.  Something 
hardware engineers have been doing since day 1...programmers might 
learn by day 32'767 if we get lucky.  No doubt our smartest programmers 
will be fussing with strings 50 years from now with the same basic 
problems and mind sets faced 50 years ago.

...and so forth.

Stevee: good catch, the commented version is not in sync with the 
decompiled version (as I said, day 1 of this, lots of back and forth). 
 If you run unmush you get:

angular is a js library which interprets special tags, attributes 
and element values in the dom and sets up an event handler system 
behind the scenes which keeps model objects in sync w the dom content 
(back and forth)

This is totally fun.  I made new icons for an application and put 
them in with Resource Hacker (suggested by the documentation), but 
the icons change back and forth between mine and REBOLs based when 
I change the name of the .exe file.  Any explanation

we want to compile it to a forth-like processor

I know of some where you can have overlays, and preload the transparencies 
and do switching back and forth between multiple cameras, and slides 
with transition effects. Only that is cost about USD$400.

i did this kind of realtime coding once. i wrote a forth vm in awk 
at the #[forth-:-irc-:-freenode-:-net]. what i missed those times was a simple 
cooperative editor. it can b imagined as a whiteboard but there is 
only 1 "painting" tool is available, a cursor for writing text. (i 
was at the end of a 33.6kbps modemline those times, so i havent dared 
to dream about video :)

For example:



Find | Select | Pick | First | Second | Third | Forth | Fifth | and 
Sixth are all really the same command:


If you picture a master command with lots of settings (refinements) 
and even some conditional code (if refinement set, do x).

denismx, when I've taught REBOL to people, even people who are already 
familiar with other programming languages, it has been helpful to 
make the distinction between the REBOL language and the dialect engines.


REBOL is really a data model and related syntax, and a bundle of 
library functions that manipulate data in this model. A dialect is 
really a semantic model for interpreting this data, like what people 
think of as a language in real life. A dialect engine is a set of 
library functions that think of the data in the same way - I know 
this sounds anthropomorphic, but it makes it easier to explain REBOL 
if you think of the different dialect engines as entities that are 
acting on a set of commands you are giving them. You can even use 
role playing to demonstrate this, having one of your students act 
out the part. It also helps to name each of these models after the 
main function that implements them - otherwise people might not get 
the distinction between them and REBOL as a whole.


There are some functions that only deal with the REBOL data model 
and don't really do anything with the data other than translate it 
from or to some concrete syntax. It is best to group these functions 
by the syntax they implement - the group that implements what people 
normally think of as the REBOL syntax is LOAD, SAVE and MOLD.


When teaching REBOL dialects I usually start with what I call the 
DO engine, what people normally think of as the REBOL language. DO 
is a stack machine like Forth, but it uses a prefix syntax to make 
it easier to use (by making DO dialect code more resemble that in 
other programming languages). DO also does a simple swapping hack 
to implement inline operators, which you will have to demonstrate 
so that your students will understand DO's operator precedence or 
lack thereof. DO always works on REBOL data: If you pass it a string 
or file that contains REBOL syntax code, DO will call LOAD to convert 
it to REBOL data - this is an important distinction to make so that 
your students can distinguish between the data and the processor 
of that data. There are many functions that depend on DO to interpret 
their blocks of "code", such as IF, WHILE, FOR, etc. It is important 
to note that these are just functions, not "syntax". DO's only syntax 
is the predefined operators that DO swaps (these are effectively 
keywords because of how the swap is implemented), the word/set-word/get-word 
difference, the interpretation of paths and the precedence of parens. 
Everything else is a function.


There is also the PARSE engine, a rule-based recursive-decent parser 
with limited backtracking, that implements three dialects (simple 
parse, string parse and block parse). These dialects actually have 
keywords, as well as an entirely different execution model. Also, 
there is the View engine, which implements the LAYOUT and DRAW dialects.


Refering to these engines as state machines isn't helpful, because 
the distinctions between their execution models, or whether they 
even have execution models, is important for distinguishing between 
them. You need to use the higher-level terms like stack machine, 
composition engine and such.

I hope this helps!

Don't forget Forth in the heritage list! Lisp/Logo and Forth are 
key design ancestors, for lists/blocks and words, respectively.

So, the main things I think of as far as basic concepts are:


1) Everything is data; sometimes that data is evaluated and things 
happen.


2) Everything lives in blocks; there are series operations that you 
need to understand in order to manipulate them.

3) Everything is data.


4) Words are very important; not only knowing when they are evaluated 
and other technical details, but also how you choose them so they 
work together well.

5) Everything is data.

There are about 270 in View but the op! are duplicates of some natives, 
and some natives are for efficiency and can be rewritten using the 
other native words. I guess I like looking at Rebol as a Forth language 
with very good and standard I/O support.

I expect languages like REBOL and forth that expand their own dictionaries 
are not as compact as Python.

It's something I learned from Forth .. math is always faster than 
logic.

Pekr, that would mean Forth :)

Bernd Paysan once wrote a regexp compiling to jitted forth. 10* faster 
than the usual c-interpreter.

Right. I once talked with an astronomer working in Lund, Sweden. 
He told me about the software, they use. It's mostly based in code 
written in the 70'ies (in FORTH, if I remember correctly). It's good, 
well-tested software of course, but the user interfaces are terrible, 
often just a command-line. It could be interesting doing modern versions 
of some of that software using REBOL. But the scientists have to 
be 100% sure, the output is correct and the same as they get from 
the software, they use now. If the right function libraries were 
developed in REBOL (rebcode), I think scientists could be a good 
user-base (developer-base) for the REBOL language.

Geomol, they are probably using a domain specific language to drive 
their telescopes ... something forth pioneered.

They also use Forth to control the robotic arms on the space shuttles.

jfyi i use forth regulary for writing pic microcontrolers applications 
(small ones usually)

Not compilable - thats no showstopper for bootstrap. Both forth and 
squeak can do it. Needs restrictions while bootstrapping, but is 
possible. Should be possible in rebol too.

Also even though Forth and Smalltalk are dinamic languages they don't 
have CFG. So the problems is not dynamicity.

Thats what forth does with meta-compilers and squeak does with slang. 
Ugly, so a pretty good motive to do most in meazzines :)

Since finding REBOL, I have thought it would be a nearly ideal tool 
to teach language and interpreter design and development, because 
you can do so at a very high level. I think Lisp, Forth, and Logo 
would be a great place to start, but there is no reason I know of 
that would prevent us from doing Smalltalk, Erlang, Icon, and others. 
I would LOVE to see that happen.

Yes, compilation must be done on block-level, and preferably after 
the block has already been interpret. to find function-boundaries. 
but self could go half as fast as c, and hotspot even faster. while 
switching back and forth between compiled and interpreted code.

Yes, the compilable dialect would have different semantics than the 
DO dialect but could look superficially the same, and execute a lot 
of the same code (not mine, of course). We have done this before 
in the R1 to R2 transition when we switched from a Scheme-like engine 
to a Forth-like engine without changing the syntax (except for getting 
rid of ELSE). I already have some ideas about how to do this - it's 
on my to-do list.

There would be 2 things you would have to give up in a compilable 
dialect of REBOL, if you want it to be worth it:

- Code blocks that aren't statically determinable at function creation 
time (unlike your example above, which could be partially evaluated)

- Functions that could be edited in place, or hot-patched (already 
gone in R3)

If you don't give these up you would be adding compilation overhead. 
Admittedly, Java isn't the right language to emulate here - Forth 
or other stack languages would be better, as they are closer to the 
REBOL execution model and compiled Forth can be drastically faster 
than the best Java code.

Forth vs Java: well maybe it was very true 10 years ago, but since 
then, the gap is closing with some great  improvements in compilation 
like Java's Hotspot VM.

That's why I mentioned "other stack languages". There has been a 
lot of research in that camp too - they just name their languages 
other names than Forth. I think that some of the research in type-inferenced 
stack languages will eventually make Java and .NET faster too.

I look at this problem from two views.  wanting a forth style block 
editor and wanting to let a construction boss sit at home and edit 
his own data blocks.  The forth style CLI just needs strings...any 
string including something like  p [   putting an open bracket on 
a line by itself.  This can be done with string parsing and a dialect 
pass, but hey.  The other issue is a lot deeper.  I want the boss 
to type in $1,000,000 and not have to call me when load kakks and 
(when I'm not careful enough) breaking a script.

(as a regular REBOLer) I've thought about doing the PS thing, because 
I hoped it would help printing support (and OSX uses DisplayPS, right? 
NeXT did too.). I also thought it would be a cool example, because 
of REBOL's Forth heritage that is very PS like (though I think someone 
once said that PS was *not* based on Forth..whatever). 


It shouldn't be too tough--I even have a couple PS book on my shelf 
if people need something looked up--but, like Pekr, I doubt the general 
practical usefulness for the average REBOL app user without a "full 
stack" of PS tools. That doesn't matter if you want it for yourself 
though, or we can bundle things into a distro for those who want 
it.

it sounds very much like my RE, except my RE does not have that ability 
to move around freely in the structure, and you have to cross relate 
manually. no "traversing" back and forth. you can't start in the 
"middle" of the tree.

this is my final function, I removed the rounding as it created a 
lot of noise in position, (not the fault of the round function but 
the act or rounding itself, would snap the position back and forth 
while dragging)


I also use the vector's length using an hypothenuse formula (similar 
to distance), cause your previous example did not properly scale 
to the vector's maximum size.


I also added support for supplying a negative value for 'AT argument 
so that it actually offsets from the end, which is very usefull.

vlength: func [v] [v: v * v square-root v/x + v/y]

between: func [
	{compute the specified point on the line}
 	start [pair!]
	end [pair!]
	at [decimal! integer!]
	/local vector points 
] [
	; solve "degenerate case" first
	if equal? start end [return start]
	vector: end - start	 
	if integer? at [
		; convert AT to decimal
		at: at / (to-integer vlength vector)
	]
	if negative? at [
		at: 1 + at
	]
	

 start + to-pair reduce [to-integer vector/x * at to-integer vector/y 
 * at] 
]

The problem is not the twice, it's that it keeps going. I do the 
reload to let it continue and it does, back and forth forever.

Hi Paul - yes, I've been lurking via html :)  Off topic:  I dabbled 
a bit with the Windows API and have a simple working webcam viewer, 
and also a working remote video client that produces usable video 
from simple image refreshes.  I need to explore the audio api to 
understand how to capture and pass audio frames across the net - 
I've got plenty of code from other languages - just need  to convert 
all those api calls to Rebol and see if there are any performance 
issues, but I suspect that a very simple point-to-point app like 
that could work in Rebol2.  To make it practical for real use, there'd 
need to be a little server/repeater app to pass data back and forth 
between clients that are behind routers.  Not so crazy difficult, 
I don't think...