On Thursday 11 January 2007 21:52, Chris Double wrote:
> > In the system I changed it so "foo" is used as the variable.
> Isn't using a symbol the right thing though? Using a string means you
> can get clashes with any other file that uses the same string name as
> a variable.
Chris,
Wow, you have a good point! I hadn't thought about this.
The reason I wanted to move away from symbols is that it's easy to clash with
existing things like word names and tuple names. Clashing with tuple names
hasn't caused a problem for me yet, but it seems weird.
So about using strings for variables. On the one hand, protection of the
variable will happen via explicit scoping setup by the programmer. I'll have
to look at places where I've used VAR: in my code to see if string based ones
would cause a problem.
Hmm. It's probably better to stick with symbols. :-)
: foo ( a b c -- ) [ >c >b >a
...
] with-scope ;
That is one usage pattern that is common for me, with the following
characteristics: 1 - foo is not recursive; 2 - the only references to the
variables a, b, and c, happen via the a> b> and c> words directly in the body
of foo. That is, we aren't setting them for the sake of words called in the
body of foo which reference a, b, or c, taking advantage of dynamic scope.
That is a very nice clean pattern. String based variables would work well for
this kind of usage.
The problem is with words which reference variables and expect their value to
be set in a way that dynamic scope is utilized.
I think the simple foo pattern above is close to the model of Scheme.
Moreover, if the words used in the body of foo stick to using >>foo (the set*
version which searches up the namestack) then you get even closer to Scheme.
One area where modeling the Scheme way breaks down is when you make foo
recursive:
: foo ( a b c -- ) [ >c >b >a
... foo ...
] with-scope ;
Each time it recurs you add a level to the namestack! Scheme implementations
are supposed to be smart enough to run foo in bounded memory as long as the
foo is a tail call. If you know that the call to foo is a tail call, you can
do this:
: foo ( a b c -- ) [ (foo) ] with-scope
: (foo) ( a b c -- ) >c >b >a
... (foo) ...
;
Neato. So the scope is established by foo and things run bounded via (foo).
What about situations like this:
(define (a x y z)
...
(b) ; tail call
...)
(define (b x y z)
...
(c) ; tail call
...)
(define (c x y z)
...
(a) ; tail call
...)
Scheme is expected to run that chain in bounded space too. How about the
Factor version?
If entry to that set of functions only happens via a then:
: a ( x y z -- ) [ (a) ] with-scope
: (a) ( x y z -- ) >z >y >x ... (b) ... ;
: (b) ( x y z -- ) >z >y >x ... (c) ... ;
: (c) ( x y z -- ) >z >y >x ... (a) ... ;
I wonder if that is an accurate enough modeling of the Scheme idiom.
What about internal defines?
(define (foo)
(define (a) ...)
(define (b) ...)
(define (c) ...)
(list (a) (b) (c)))
: foo ( -- ) [
[ ... ] >a
[ ... ] >b
[ ... ] >c
#a #b #c 3array
] with-scope ;
Does that one hold up?
Factor is a language that can support different programming styles. Besides
applying Factor to practical problems, I think it is up to the community to
explore the power of Factor. If I'm not being a stack purist then it's OK
because there aren't any language police. Actually there are language police
out there but they are powerless. I hope nobody interprets my suggestions as
wanting to impose new idioms on others. We're all here because we're open
minded enough to use Factor. It would be ironic to wear straightjackets now
that we've come all this way. :-)
So let's get on with the use and abuse of Factor. :-D
Ed
-------------------------------------------------------------------------
Take Surveys. Earn Cash. Influence the Future of IT
Join SourceForge.net's Techsay panel and you'll get the chance to share your
opinions on IT & business topics through brief surveys - and earn cash
http://www.techsay.com/default.php?page=join.php&p=sourceforge&CID=DEVDEV
_______________________________________________
Factor-talk mailing list
Factor-talk@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/factor-talk
