World: r3wp

Gabriele, you have my support on the UI separation. I agree it's 
important and think it's good news you got it through. Your original 
design document on it was brilliant

It has always been a mystery to me how REBOL is the best language 
for abstraction, yet almost all its applications are a mishmash of 
layers that should have been separated out

It must be an effect of the throw-away coding model and the focus 
on individual developers. It doesn't scale to responsibility delegation 
in the way Chris says

Like R3 is introducing a programming-in-the-large model, VID3 needs 
a designing-in-the-large model

I'll +1 on Kaj's remarks.  I'd like to see Gabriele be allowed to 
apply some genius to VID3 then drag the rest (most) of us up to where 
we should be.  Chris and Henrik and Robert and Maarten et al will 
then produce all the cool code we've come to expect, but from a higher 
view point and perhaps from a slightly different slant than we are 
used to. imho.  And I do hope that VID3 work will be as shareable 
as the best of the library functions, umm, we don't really have yet. 
 :)

There is potential for R3 to have access to last console expression 
results.  Any suggested names?

>> 2 + 3
== 5
>> 3 * result  ; where result is some new REBOL function.
== 15


I'm a forther so I suggested  .  (dot), but Carl hinted he has been 
waiting for the perfect use of that symbol.  Is this it?  Looking 
for a good name for last-console-result.  Of course my example is 
trvial, it'd be more useful for longer expression and save on a  
temp:  while working the console.  For me, I'd prefer something short, 
easy to type (avoiding shift if possible) and having some meaning. 
 That may exclude . as dot is really forther common speak and would 
be meaningless to many.  I want to push for this feature as I'm continually 
up arrowing and adding temp: to test expressions.

$_

I'd go for that one too, but it's an Invalid money!  It would require 
a special hook in the scanner.

lcr ... for last-console-result ??  If something like . would be 
acceptable then I'm sure an acronymn could be used.

;-)

Well, _$ then? Sendsa nice signal to newbies

that is also an invalid money!

_&

as in whatever canme before & what follows

the use of . means we could use .. for second last, and ... for third 
last ad infinitum :)

well, that would make for a lot of hard to read code :-)

heh:
 . + .. + ... * .. + ...
reminds me of a certain very annoying language :)

I think actually there should be a limit to how far you can go back, 
otherwise one might encourage people to make hard to read code.

skip stack -37 ; hard to debug

Hmmm,  I'd love a 'get-stack and 'restore-stack. Who needs continuations....

(and serializable)

I'm not sure this will be last-expression-result.  I think it will 
be restricted to last-console-result.  afaik.  But a short-cut for 
last-expression-result could make for more codie looking code.  :)

I don't think it would make a difference if it were in console or 
in code. I think that being able to go one result back in code would 
be highly useful, but it should be done in a readable way.

a word like 'previous could do that

I think to browse console results interactively, use something like 
the stack of HP calculators.

or: system/console/last (or whatever the appropriate R3 equivelent 
is)

last system/console/history

ah, that is not the same ... you don't want to obtain expression, 
but a result ....

then it needs to be really assigned to some some word in system/console 
object ...

>> probe system/console
make object! [
    history: ["probe system/console"]
    keys: none
    prompt: ">> "
    result: "== "
    escape: "(escape)"
    busy: "|/-\"
    tab-size: 4
    break: true
]

pity result word is already taken for the string ....

maybe history could be two dimension block - pair of values - result, 
expression, or something like that ...

This isn't quite the same either (the last line could evaluate differently):

>> 'result

== result

>> res: do second system/console/history

== result

All good ideas gentlemen.  For the way I work (lazy and forgetful) 
I'd prefer not to have to type system/console/last-result if we can 
convice Carl to make it nice and short like  recent  or  answer  
or ans or just  or anything along the six or less character typing 
range.  Plus if there is no shift-key involved, that'd be a bonus 
(meaning if we pick a symbol to suggest, I'd prefer backtick over 
tilde)

I think I'd prefer something that's easily readable, rather than 
a symbol - so 'lastres (for Last Result) is my suggestion

con, conres

Kinda joking, but not,  last-evaluated-expression  lee  Has a sheltered 
feel to it and is a wine-makers word.  And then we could pay homage 
to The Bare Naked Ladies and call R3, Gordon.  :)

But I'll stop joking...this will be a very handy feature and doesn't 
deserve me clownin' around.  These are all good ideas.  And I think 
the fact of showing interest may move it closer to reality in R3. 
 Right now it is just a suggestion that got the nod of being possible.

Izkata I agree about readability.  A symbol may suffer abusive 'coding' 
practice if it ends up being last-expression and not just last-console-expression 
and then people do use the feature in scripts.

If we can have access to an evaluation stack, let's name is stack... 
something.

And then we can pick at the stack like forth

who cares about readability

As long as it's only _console_ I don't care about readybility. If 
it ends up in code, I do care much. I wouldn't like rebol to become 
the second perl ... 

Actually, if it ends up to be only the last console expression, I'd 
vote for something like 'last-console-expression . This is Rebol, 
after all, so you can always add sometthing like:
.: :last-console-expression
to your user.r

:)  My concern for readability would be avoiding REBOL code starting 
to look like perl, where you have to decipher while reading.  Coded 
code is fine for things like C, J and R but REBOL has a very nice 
quality of being grok'ed at a glance.  Losing that would be sad. 
 ICarii said it best already ... let's not go there.  So I'd almost 
like to restrict the new feature to last-console-expression just 
so we don't go overboard with short-cut expressions in scripts.  
Thinking along those lines, perhaps system/console/last-result would 
be fine.  Developers could add .: or `: or ~: to personalize for 
console work.  Then again, system/console/last-result wouldn't want 
to be set for evey expression.  Just when needed, so it'd have to 
be an action, not a data set.


Ingo;  Wow.  As I was typing...you were echoing the same thoughts.

Right, I was thinking about what you said about system/console/last-result, 
too, but was too lazy to add it to my post ;-)

Well, REBOL is all block/series based .... and series is a "queue" 
of values. I would like to have stack of values (block of values), 
series, which we can pick-up from, sort, move, remove - no ackward 
one only value!

then define your function as you wish. Via pick, select, whatever, 
call it whatever you like .....

Petr; A lot of this comes down to what is going to cost the REBOL 
evaluator.  I don't know, but have a feeling that a lot of intermediate 
results are discarded.  Could be wrong.  But if so, I wouldn't push 
for anything that will slow down current execution speed.  If the 
values are there on a stack today, great.  But II'd guess that only 
the last may easily (and zero cost to current run-time) accessible. 
 And with some fancy expressions, what goes on the stack in what 
order may be optimized differently than reading code left to right. 
 I'll ask while pointing out the interest that has been shown here 
by the group.  If coders want a pickable list of expressions today 
we have reduce and friends.  I'm more aiming to get at the last result 
from the console as I'm always forgetting to put a var: in front 
of test code, especially code tthat returns an object! that I'd like 
to probe.

I was kidding of course about readability - don't want Rebol to become 
write only like Forth :)

I guess we need to know what we can get before we start naming things.