Thanks Jesse,
this kind of elaboration is what I really need to see into the
fundamental thinking of Factor since I'm myself written actual Factor
code less than implemented it. :)
I think I could create an alternative stack view for the playground
(and for the tutorial which I think is maybe even more crucial).
The listener could have visually truncated boxes for elements other
than the top three element and hovering over them would show whole
element as string. E.g.
[...] [ .. ] [ .. ] "foo" { 2 4 } [ 5 * ] | input |
^
_____________
| { 1 2 3 } |
_____________
- Henrik
On Sat, Mar 27, 2010 at 5:28 PM, Jesse Rusak <fac...@jesserusak.com> wrote:
> Hi All,
>
> I particularly like the vertical visual representation of the stack. In
> fact I think it is crucial. A stack is after all a "stack" and not some
> other structure.
>
> I see your point here - the name "stack" is evocative of a vertical
> orientation. Of course, the data structure itself doesn't have an innate
> orientation. I don't want to argue about something so subjective, but
> perhaps let me flesh out why thinking of Factor code as having a horizontal
> stack works for me, in the hopes that it helps someone else think about
> Factor code:
> When I was first learning to read and write Factor (the first concatenative
> language I've learned) I was visualizing a vertical stack. I was thinking of
> things as being on the "top" of the stack or "the next one below the top"
> and so on, based on the usual notion of a stack. All Factor code, though,
> shows items on the stack in a left-to-right manner. For example, stack
> effects show ( a b -- c ). When first trying to understand a word's effect,
> I kept having to remind myself whether the top of the stack was on the left
> or right. Having a horizontal orientation in code and a vertical one in my
> head was extra mental effort.
> When I started to focus less on a vertical stack and more on the idea of
> concatenating words, this became much easier for me. When looking at a word
> ": foo ( a b -- c ) swap / ;", I could imagine that when we call "1 2 foo",
> we instead evaluate "1 2 swap /". As we evaluate this we can imagine: (with
> | representing the top of the stack)
> | 1 2 swap /
> 1 | 2 swap / ! literals just "move over"
> 1 2 | swap /
> 2 1 | / ! we can visually see this right from swap's effect ( x y -- y x )
> 2 |
> That is, since Factor code shows stack effects and word bodies in a
> left-to-right manner, I found it easiest to keep them that way. Especially
> with combinators like over ( x y -- x y x ), I find it begs to be read as
> though the second x on the right-hand side has been stuck on to the right
> end of the stack.
> On a side note: when Factor shows a data stack in the listener, it does it
> with the top of the stack at the bottom.
> Well, I hope that helps someone learning Factor.
> - Jesse
> ------------------------------------------------------------------------------
> Download Intel® Parallel Studio Eval
> Try the new software tools for yourself. Speed compiling, find bugs
> proactively, and fine-tune applications for parallel performance.
> See why Intel Parallel Studio got high marks during beta.
> http://p.sf.net/sfu/intel-sw-dev
> _______________________________________________
> Factor-talk mailing list
> Factor-talk@lists.sourceforge.net
> https://lists.sourceforge.net/lists/listinfo/factor-talk
>
>
------------------------------------------------------------------------------
Download Intel® Parallel Studio Eval
Try the new software tools for yourself. Speed compiling, find bugs
proactively, and fine-tune applications for parallel performance.
See why Intel Parallel Studio got high marks during beta.
http://p.sf.net/sfu/intel-sw-dev
_______________________________________________
Factor-talk mailing list
Factor-talk@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/factor-talk
