It changes
(a b c d (1 2 |3 4) ha ha ha)
into
|(1 2 (a b c d 3 4 ha ha ha))
What is the use for that transformation?
Also just a quick add regarding practical use, you may like to check the minute 1:40 of this tutorial:
http://emacsrocks.com/e14.html
calling M-? with the cursor on the opening of do-something broadens the scope of the let, from this:
(defun my-other-command ()
(when (and (this-predicate)
(that-predicate))
(let ((v (calculate-v))
(x (calculate-x)))
(do-something)
(do-some-more)
(do-a-third-thing))))
directly to this:
(defun my-other-command ()
(let ((v (calculate-v))
(x (calculate-x)))
(when (and (this-predicate)
(that-predicate))
(do-something)
(do-some-more)
(do-a-third-thing))))
cheers!
Andres
Strictly speaking, it's used for reversing the nesting of an inner expression.
As an example:
(let [foo bar] (if a b| c))
becomes
(if a b (let [foo bar]| c))
As for use case, I've never had a practical use for it specifically, but it's a nice building block for a larger macro
To add to Nirk's answer
For smartparens users, M-x sp-prefix-save-excursion M-x sp-convolute-sexp changes
(let [foo bar] (if a b| c))
and
(let [foo bar] (if a b |c))
into
(if a b (let [foo bar] |c))
For paredit users, M-x paredit-convolute-sexp changes
(let [foo bar] (if a b| c))
and
(let [foo bar] (if a b |c))
into
|(if a b(let [foo bar] c))
and
|(if a b (let [foo bar] c))
For those who uses neither, you can still use the convolute commands if you include
(require 'paredit)
(require 'smartparens)
in the init file and those two lines alone do NOT set up your Emacs to use paredit mode or smartparens mode and so all is well. If you install the paredit package from a package archive, the autoloads file may or may not set up Emacs to use paredit mode, and paredit has no Customize interface. If you install smartparens package, whatever the autoloads file does, you can use Customize interface to set smartparens-global-mode to nil, if its default is not nil (default is nil though for now).
Most examples have shown narrowing scope, but I expect you'd most likely use this if you realized you had a let form inside an if and realized you needed those bindings in the other branch of the if form as well.
Let's say you're a troll and you've found a delicious-looking thief.
(defn eat-hobbit [hobbit]
(if (is-cooked? hobbit)
(eat! hobbit)
(let [is-fat (< too-greasy (:fat-content hobbit))]
(if is-fat
(eat! (deep-fry hobbit))
(eat! (saute hobbit))))))
You realize you should probably be making better health choices and not just eat every hobbit you come across, cooked or not, so you decide to decide whether or not to eat the hobbit in the first place based on how fatty it is. You need to know is-fat before you decide to eat! So, you want to elevate that let. Put the cursor after the binding vector in (let [is-fat ...] and M-? (and clean up whitespace with M-j M-q):
(defn eat-hobbit [hobbit]
(let [is-fat (< too-greasy (:fat-content hobbit))]
(if (is-cooked? hobbit)
(eat! hobbit)
(if is-fat
(eat! (deep-fry hobbit))
(eat! (saute hobbit))))))
You're not DONE making better food choices yet, but now the binding is in the right scope to make better decisions.
Let's try it again. We should really ask if the hobbit is fat first, so put the cursor after (if is-fat and M-? (and cleanup with M-j M-q again):
(defn eat-hobbit [hobbit]
(let [is-fat (< too-greasy (:fat-content hobbit))]
(if is-fat
(if (is-cooked? hobbit)
(eat! hobbit)
(eat! (deep-fry hobbit))
(eat! (saute hobbit))))))
Hmm. That's not quite VALID yet—there's an extra form in the if—but it's very close to where we want to be. At this point, we can easily use the more common bindings of paredit to barf, transpose, and/or kill the extra form in the if, depending on how sincere we are in our intentions towards healthy eating. We could also splice the two if forms together for brevity.
Related
If you evaluate (list-tail '(1 2) 3) at guile scheme. You will get an exception.
It would be smarter to have an '() as answer.
Overall why do we haven't closure property with respect to cdr combinator? What complications may arise?
Examples to make my point clearer
Now (cdr (cdr (cdr '(1 2))) -> raise-exception
Should be (cdr (cdr (cdr ... (cdr '(1 2))...))) -> ()
Then we would automatically have properly working list-tail
(define (list-tail list n)
(if (= n 0)
list
(list-tail (cdr list) (- n 1)))
Group-by then could be written elegantly and exceptionless
(define (group-by list-arg n)
(if (null? list-arg)
'()
(cons (list-head n) (list-tail n))))
The historic answer is that:
Originally, the Lisp 1 and 1.5 languages created by John MacCarthy did not allow (CDR NIL). The CDR function required a cons cell argument.
The idea that it would be convenient for (CDR NIL) to just return NIL came from a dialect called Interlisp (but may have been present elsewhere).
In the 1960's, there was another major dialect of Lisp called MacLisp (two decades before the Apple Mac, unrelated).
According to The Evolution of Lisp by Peter Gabriel and Guy Steele, some MacLisp people held a pow-wow with Interlisp people in 1974:
In 1974, about a dozen persons attended a meeting at MIT between the MacLisp and Interlisp implementors, including Warren Teitelman, Alice Hartley, Jon L White, Jeff Golden, and Guy Steele. There was some hope of finding substantial common ground, but the meeting actually served to illustrate the great chasm separating the two groups, in everything from implementation details to overall design philosophy. [...] In the end only a trivial exchange of features resulted from “the great MacLisp/Interlisp summit”: MacLisp adopted from Interlisp the behavior (CAR NIL) → NIL and (CDR NIL) → NIL, and Interlisp adopted the concept
of a read table.
Both Interlisp and MacLisp are ancestral dialects to Common Lisp, which also has the forgiving car and cdr.
Further remarks are made in the above paper on this matter, begining with:
The adoption of the Interlisp treatment of NIL was not received with universal warmth.
You can see from this fifty, sixty years ago, Lisp people were already divided into camps, and didn't agree on everything. Whether the car of an empty list should just yield the empty list, or error out is a very old issue.
Ashwin Ram, presently director of AI at Google, put in his own opinion in favor of forgiving cdr in 1986, when he composed this poem.
It still remains a divisive issue that is a matter of opinion.
It is undeniable that the flexible car, cdr and their derivatives can help you "code golf" list processing code.
It's also true that such code-golfed code sometimes handles only happy cases without error checking, which can cause problems in some circumstances.
For instance, some list that is assumed to always have three items is subject to (caddr list) to get the third item. But, due to some bug, it has only two. Now the code just ran off with the nil value, which may cause a problem somewhwere else. For instance, suppose the value is expected to be a string, and in some totally different function elsewhere, nil is passed to some API that needs a string and blows up. Now you're hunting through the code to discover where this nil came from.
People who write Lisp interpreters or compilers that rely on the forgiving destructuring performed by car and cdr end up producing something that accepts bad syntax silently.
For instance
(defun interpret-if (form env)
(let ((test (car form))
(then (cadr form))
(else (caddr form)))
(if (interpret-expr test env)
(interpret-expr then env)
(interpret-expr else env))))
This is actually a very nice example for discussing both sides of the issue.
On the one hand, the code is succinct, and nicely supports the optional else clause: the user of this interpreter can do:
(if (> x y)
(print "x is greater than y"))
In interpret-if, the else variable will pull out a nil, and that will get handed off to (eval expr else env) where it just evaluates to nil, and everything is cool; the optionality of else was obtained from free thanks to caddr not complaining.
On the other hand, the interpreter doesn't diagnose this:
(if) ;; no arguments at all
or this:
(if (> x y)) ;; spec says "then" is required, but no error!
However, all these issues have nice solutions and ways of working that don't require tightening up the list accessor functions, so that we can resort to the succinct coding when we need to. For instance, the interpreter could use pattern matching of some kind, like Common Lisp's rudimentary destructuring-bind:
(defun interpret-if (form env)
(destructuring-bind (test then &optional else) form
(if (interpret-expr test env)
(interpret-expr then env)
(interpret-expr else env))))
destructuring-bind has strict checking. It generates code with car, caddr and other functions under the hood, but also error checking code. The list (1 2 3) will not be destructured by the pattern (a b).
You have to look at the entire language and how it is used and what else is in it.
Introducing forgiving car and cdr into Scheme might give you less mileage than you think. There is another issue, which is that the only Boolean false value in Scheme is #f. The empty list () in Scheme is not false.
Therefore, even if car is forgiving, code like this cannot work.
Suppose the third element of a list is always a number, or else it doesn't exist. In Lisp, we can do this to default to zero:
(or (third list) 0)
for that to work in Scheme in the default 0 case, (third list) would have to return the Boolean false value #f.
A plausible approach might be to have different default values for car and cdr:
(car ()) -> #f
(cdr ()) -> ()
However, that is rather arbitrary: it works in some circumstances, but fails in situations like:
;; if list has more than two items ...
(if (cddr list) ...)
If cddr returns () by default, then that is always true, and so the test is useless. Different defaulting for car and cdr would probably be more error prone than common defaulting.
In Lisp, the forgiving list accessors work in a synergistic way with the empty list being false, which is why once upon a time I was quite surprised to learn that the forgiving list accessors came in fairly late into the game.
Early Scheme was implemented as a project written in Lisp, and therefore to interoperate smoothly with the host language, it used the same convention: () being NIL being the empty list and false. This was eventually changed, and so if you're wishing to have that back, you're asking for Scheme to revert a many-decades-old decision which is next to impossible now.
Object-oriented programming weighs in on this also. The fact that (car nil) does something instead of failing is an instance of the Null Object Pattern, which is something useful and good. We can express this in the Common Lisp object system, in which it practically disappears:
Suppose we had a car function which blows up on non-conses. We could write a generic function kar which doesn't, like this:
;; generic fun
(defgeneric kar (obj))
;; method specialization for cons class: delegate to car.
(defmethod kar ((obj cons))
(car obj))
;; specialization for null class:
(defmethod kar ((obj null))) ;; return nil
;; catch all specialization for any type
(defmethod kar ((obj t))
:oops)
Test:
[1]> (kar nil)
NIL
[2]> (kar '(a . b))
A
[3]> (kar "string")
:OOPS
In CLOS, the class null is that class whose only instance is the object nil. When a method parameter specializes to null, that method is only eligible when the argument for that parameter nil.
The class t is the superclass of everything: the top of the type spindle. (There is a bottom of the type spindle also, the class named nil, which contains no instances and is a subclass of everything.)
Specializing methods on null lets us catch method calls with nil parameters. Thanks to CLOS multiple dispatch, these can be thus handled in any parameter position. Because of that, and null being a class, the Null Object Pattern disappears in CLOS.
If you're debating Lisp with OOP people, you can present (car nil) can be spoken about as being the Null Object pattern.
The inconvenience of explicit null handling is recognized in numerous newer programming languages.
A common feature nowadays is to have null safe object access. For instance
foo.bar
might blow up if foo is null. So the given language provides
foo?.bar
or similar, which will only dereference .bar if foo isn't nil, otherwise the expression yields nil.
When languages add foo?.bar, they do not throw away foo.bar, or make foo.bar behave like foo?.bar. Sometimes you want the error (foo being nil is a programming error you want to catch in testing) and sometimes you want the default.
Sometimes you want the default, so you can collapse multiple levels of default and catch an error:
if (foo?.bar?.xyzzy?.fun() == nil) {
// we coudn't have fun(); handle it
// this was because either foo was nil, or else bar was nil,
// or else xyzzy was nil, or else fun() returned nil.
} else {
// happy case
}
cdr is only allowed on pairs. When you reach the end of the list, the value is (), which is not a pair, so you get an error.
You can check for this in your list-tail procedure to allow it to be more permissive.
(define (list-tail list n)
(if (or (= n 0) (not (pair? list)))
list
(list-tail (cdr list) (- n 1)))
Using (not (pair? list)) will also allow it to work for improper lists like (1 2 . 3). It will keep returning 3 for any n >= 2.
"You will get an exception."
This is a problem with many core libraries, and not just Scheme. Take Haskell's core library:
tail [1] -- []
tail [] -- error
head [1] -- 1
head [] -- error
As you know, the technical name for a function like this is a Partial Function. It is a function that doesn't work for some inputs, leading to errors.
So, yes, you can define your own version. One thing, though - what should be returned in the end condition? Should (list-tail '(1 2) 3) return () or should it return 0? If I'm trying to get a value to add to another number, then 0 would be appropriate. If I'm using cons to gather values then () would be appropriate. I guess that's why the function is left as partial.
"Right. I was interested why scheme was designed that way, without car/cdr closure property. Is it feature or just design flaw. It's more like scheme is less consistent than Common Lisp, rather strict."
Common Lisp returns NIL when it runs out of list:
(car '(1)) ; 1
(car '()) ; NIL
(cdr '(1)) ; 1
(cdr '()) ; NIL
In this case you would have to test for NIL, and if you wanted a zero instead make the replacement.
Why Scheme didn't have this is due to its minimalistic design. The report was so under-specified you could do pointer arithmetic and just let the program segfault since any faulty scheme code was deemed not scheme and pigs could fly. Later reports, like R7RS, requires much more error checking since it is required to signal errors in many situations where just undefined behavior would be OK in early reports.
With today's Scheme we can easily create car and cdr that does what you want:
#!r7rs
(define-library
(sylwester pair-accessors)
(export car cdr)
(import (rename (scheme base) (car base:car) (cdr base:cdr))
(except (scheme base) (car cdr)))
(begin
(define (car v)
(if (pair? v)
(base:car v)
'()))
(define (cdr v)
(if (pair? v)
(base:cdr v)
'()))))
So in your library or program you just import (scheme) (or (scheme base)) without car and cdr and also import (sylwester pair-accessors) and you're in business. Alternatively you can make a (scheme base) or (scheme) that replaces all accessors with you own safe ones using a macro to produce them all.
The only thing you cannot do is inject your version of car/cdr into already defined libraries since that would require some late binding or monkey-patching, but that isn't supported by the language. I'm fascinated by these things and would love to make a OO-scheme where you can augment standard procedures with some CLOS-ish late binding where all core functions under the hood are indeed methods so that you can define your own objects and accessors and that standard libraries and user libraries created for normal pairs would just work out of the box for your new data structures that has pair like features.
Suppose I have a list of arguments args and a macro/syntax f that takes a variable number of arguments. How do I apply f to args? Apparently apply doesn't work here.
For example, suppose I have a list of values bs and I want to know if they're all true, so I try (apply and bs) but I get the error "and: bad syntax". The workaround I came up with is (eval `(and . ,bs)) but I'm wondering if there is some standard way to achieve this sort of thing.
Update
A bunch of possible duplicates have been suggested, but most of them are just about the and example. This suggested question seems to be the same as mine, but the answer there is not very helpful: it basically says "don't do this!".
So maybe the point is that in practice this "apply + macro" question only comes up for macros like and and or, and there is no useful general question? I certainly ran into this issue with and, and don't have much Scheme experience, certainly no other examples of this phenomenon.
This is an XY problem. Macros are part of the syntax of the language: they're not functions and you can't apply them to arguments. Conceptually, macros are like functions which map source code to other source code, and which are called at compile time, not run time: trying to use them at run time is a category error. (In Common Lisp macros are, quite literally, functions which map source code to other source code: in Scheme I'm not quite so clear about that).
So if you have a list and you want to know if all its elements are true, you call a function on the list to do that.
It's easy to write such a function:
(define (all-true? things)
(cond [(null? things)
#t]
[(first things)
(all-true? (rest things))]
[else #f]))
However Racket provides a more general function: andmap: (andmap identity things) will either return false if one of things is not true, or it will return the value of the last thing in the list (or #t if the list is empty). (andmap (lambda (x) (and (integer? x) (even? x))) ...) will tell you if all the elements in a list are even integers, for instance.
There is also every which comes from SRFI 1 and which you can use in Racket after (require srfi/1). It is mostly (exactly?) the same as andmap.
One thing people sometimes try to do (and which you seem to be tempted to do) is to use eval. It may not be immediately clear how awful the eval 'solution; is. It is awful because
it doesn't, in fact, work at all;
insofar as it does work it prevents any kind of compilation and optimisation;
last but not least, it's a pathway to code injection attacks.
Let's see how bad it is. Start with this:
> (let ([args '(#t #t #f)])
(eval `(and ,#args)))
#f
OK, that looks good, right? Well, what if I have a list which is (a a a b): none of the elements in that are false, so, let's try that:
> (let ([args '(a a b)])
(eval `(and ,#args)))
; a: undefined;
; cannot reference an identifier before its definition
Oh, well, can I fix that?
> (let ([args '(a a b)]
[a 1] [b 2])
(eval `(and ,#args)))
; a: undefined;
; cannot reference an identifier before its definition
No, I can't. To make that work, I'd need this:
> (define a 1)
> (define b 2)
> (let ([args '(a a b)])
(eval `(and ,#args)))
2
or this
> (let ([args '('a 'a 'b)])
(eval `(and ,#args)))
'b
Yes, those are quotes inside the quoted list.
So that's horrible: the only two cases it's going to work for is where everything is either defined at the top level as eval has no access to the lexical scope where it is called, or a literal within the object which may already be a literal as it is here, because everything is now getting evaluated twice.
So that's just horrible. To make things worse, eval evaluates Scheme source code. So forget about compiling, performance, or any of that good stuff: it's all gone (maybe if you have a JIT compiler, maybe it might not be so awful).
Oh, yes, and eval evaluates Scheme source code, and it evaluates all of it.
So I have this convenient list:
(define args
'((begin (delete-all-my-files)
(publish-all-my-passwords-on-the-internet)
(give-all-my-money-to-tfb)
#t)
(launch-all-the-nuclear-missiles)))
It's just a list of lists of symbols and #t, right? So
> (eval `(and #,args)
; Error: you are not authorized to launch all the missiles
; (but all your files are gone, your passwords are now public,
; and tfb thanks you for your kind donation of all your money)
Oops.
It would be nice to be able to say, if I have a list that I want to check some property of that doing so would not send all my money to some person on the internet. Indeed, it would be nice to know that checking the property of the list would simply halt, at all. But if I use eval I can't know that: checking that every element of the list is (evaluates to) true may simply never terminate, or may launch nuclear weapons, and I can generally never know in advance whether it will terminate, or whether it will launch nuclear weapons. That's an ... undesirable property.
At the very least I would need to do something like this to heavily restrict what can appear in the list:
(define (safely-and-list l)
(for ([e (in-list l)])
(unless
(or (number? e)
(boolean? e))
(error 'safely-and-list "bad list")))
(eval `(and ,#l)))
But ... wait: I've just checked every element of the list: why didn't I just, you know, check they were all true then?
This is why eval is never the right solution for this problem. The thing eval is the right solution for is, well, evaluating Scheme. If you want to write some program that reads user input and evaluates, it, well, eval is good for that:
(define (repl (exit 'exit))
(display "feed me> ")
(flush-output)
(let ([r (read)])
(unless (eqv? r exit)
(writeln (eval r))
(repl exit))))
But if you think you want to apply a macro to some arguments then you almost certainly have an XY problem: you want to do something else, and you likely don't understand macros.
I'm triying to use when in Scheme but i dont know why at the last element of my list appears .#void>.
Here is my code
(define (genlist x y)
(when
(< x y)
(cons x (genlist (+ x 1) y))))
And this is my output =>
(2 3 4 5 6 7 8 9 . #void>)
We use when when we need to write an if without an else part, and/or when we need to write more than one expression inside the if. Only the last expression's value gets returned, hence we use it mostly for the side effects. To understand it better, in Racket this:
(when <condition>
<exp1>
<exp2>
<exp3>)
Is equivalent to this:
(if <condition>
(begin
<exp1>
<exp2>
<exp3>)
(void)) ; implementation-dependent
The same considerations apply to unless, except that the condition is surrounded with a (not ...).
The source of your problems (and the reason why it's a code smell to have an if without an else) is that your code is not handling the case when (>= x y). Ask yourself, what should you do in that case? Simple, return an empty list! that's the base case of the recursion that's missing from your code.
You would need to use (if (< x y) (cons ...) '()) to produce a proper list.
when (and it's counterpart unless) is mostly for doing side effects (like printing something out) in a context where the result is not used.
e.g. (when debug-mode? (print "got here"))
when is an one armed ifs with implicit begin. The following examples are the same:
(if (any odd? lst)
(begin
(set! some-binding #t)
(display "Found an odd element")))
(when (any odd? lst)
(set! some-binding #t)
(display "Found an odd element"))
And you can use unless instead of using not in the predicate:
(if (not (any odd? lst))
(set! some-binding #f))
(unless (any odd? lst)
(set! some-binding #f))
Peter Norvig made a nice book about Lisp style and in it he addresses this:
Be as specific as your data abstractions warrant, but no more.
if for two-branch expression
when, unless for one-branch statement
and, or for boolean value only
cond for multi-branch statement or expression
So while you can write all your logic using if it will not be the easiest code to read. Other might use the term principle of least surprise. Even though the book is for Common Lisp much of it can be used in Scheme as well. It's a good read if you want to program any lisp dialect professionaly.
For when and unless this is applies much better to Scheme as you have no idea what an implementation might return in the event the predicate evaluates to #f while in CL you could abuse when since it's destined to return nil in such cases.
In you code you are trying to return something and letting the implementation choose what should happen when the predicate failes is what causes the #<void>. When the return matter you should always use two armed if:
(if test-expression
then-expression
else-expression)
Note there is no else keyword.
I've been studying Scheme recently and come across a function that is defined in the following way:
(define remove!
(let ((null? null?)
(cdr cdr)
(eq? eq?))
(lambda ... function that uses null?, cdr, eq? ...)
What is the purpose of binding null? to null? or cdr to cdr, when these are built in functions that are available in a function definition without a let block?
In plain R5RS Scheme, there is no module system -- only the toplevel. Furthermore, the mentality is that everything can be modified, so you can "customize" the language any way you want. But without a module system this does not work well. For example, I write
(define (sub1 x) (- x 1))
in a library which you load -- and now you can redefine -:
(define - +) ; either this
(set! - +) ; or this
and now you unintentionally broke my library which relied on sub1 decrementing its input by one, and as a result your windows go up when you drag them down, or whatever.
The only way around this, which is used by several libraries, is to "grab" the relevant definition of the subtraction function, before someone can modify it:
(define sub1 (let ((- -)) (lambda (x) (- x 1))))
Now things will work "more fine", since you cannot modify the meaning of my sub1 function by changing -. (Except... if you modify it before you load my library...)
Anyway, as a result of this (and if you know that the - is the original one when the library is loaded), some compilers will detect this and see that the - call is always going to be the actual subtraction function, and therefore they will inline calls to it (and inlining a call to - can eventually result in assembly code for subtracting two numbers, so this is a big speed boost). But like I said in the above comment, this is more coincidental to the actual reason above.
Finally, R6RS (and several scheme implementations before that) has fixed this and added a library system, so there's no use for this trick: the sub1 code is safe as long as other code in its library is not redefining - in some way, and the compiler can safely optimize code based on this. No need for clever tricks.
That's a speed optimization. Local variable access is usually faster than global variables.
How can I pass a variable by reference in scheme?
An example of the functionality I want:
(define foo
(lambda (&x)
(set! x 5)))
(define y 2)
(foo y)
(display y) ;outputs: 5
Also, is there a way to return by reference?
See http://community.schemewiki.org/?scheme-faq-language question "Is there a way to emulate call-by-reference?".
In general I think that fights against scheme's functional nature so probably there is a better way to structure the program to make it more scheme-like.
Like Jari said, usually you want to avoid passing by reference in Scheme as it suggests that you're abusing side effects.
If you want to, though, you can enclose anything you want to pass by reference in a cons box.
(cons 5 (void))
will produce a box containing 5. If you pass this box to a procedure that changes the 5 to a 6, your original box will also contain a 6. Of course, you have to remember to cons and car when appropriate.
Chez Scheme (and possibly other implementations) has a procedure called box (and its companions box? and unbox) specifically for this boxing/unboxing nonsense: http://www.scheme.com/csug8/objects.html#./objects:s43
You can use a macro:
scheme#(guile-user)> (define-macro (foo var)`(set! ,var 5))
scheme#(guile-user)> (define y 2)
scheme#(guile-user)> (foo y)
scheme#(guile-user)> (display y)(newline)
5
lambda!
(define (foo getx setx)
(setx (+ (getx) 5)))
(define y 2)
(display y)(newline)
(foo
(lambda () y)
(lambda (val) (set! y val)))
(display y)(newline)
Jari is right it is somewhat unscheme-like to pass by reference, at least with variables. However the behavior you want is used, and often encouraged, all the time in a more scheme like way by using closures. Pages 181 and 182(google books) in the seasoned scheme do a better job then I can of explaining it.
Here is a reference that gives a macro that allows you to use a c like syntax to 'pass by reference.' Olegs site is a gold mine for interesting reads so make sure to book mark it if you have not already.
http://okmij.org/ftp/Scheme/pointer-as-closure.txt
You can affect an outer context from within a function defined in that outer context, which gives you the affect of pass by reference variables, i.e. functions with side effects.
(define (outer-function)
(define referenced-var 0)
(define (fun-affects-outer-context) (set! referenced-var 12) (void))
;...
(fun-affects-outer-context)
(display referenced-var)
)
(outer-function) ; displays 12
This solution limits the scope of the side effects.
Otherwise there is (define x (box 5)), (unbox x), etc. as mentioned in a subcomment by Eli, which is the same as the cons solution suggested by erjiang.
You probably have use too much of C, PHP or whatever.
In scheme you don't want to do stuff like pass-by-*.
Understand first what scope mean and how the different implementation behave (in particular try to figure out what is the difference between LISP and Scheme).
By essence a purely functional programming language do not have side effect. Consequently it mean that pass-by-ref is not a functional concept.