Home     |     .Net Programming    |     cSharp Home    |     Sql Server Home    |     Javascript / Client Side Development     |     Ajax Programming

Ruby on Rails Development     |     Perl Programming     |     C Programming Language     |     C++ Programming     |     IT Jobs

Python Programming Language     |     Laptop Suggestions?    |     TCL Scripting     |     Fortran Programming     |     Scheme Programming Language


 
 
Cervo Technologies
The Right Source to Outsource

MS Dynamics CRM 3.0

Scheme Programming Language

why set-car! and set-cdr! can be propagated like regular functions while set! can't?


hi

Why set-car and set-cdr can be propagated like regular functions while
set! can't? I can't figure this one out. (I'm rewriting all my
functions into using only set-car!)  This is sorta funny.

dillog@gmail.com wrote:
> Why set-car and set-cdr can be propagated like regular functions while
> set! can't? I can't figure this one out. (I'm rewriting all my
> functions into using only set-car!)  This is sorta funny.

In ancient LISP there was a function called SET, which was just
an ordinary function. Therefore, you had to quote its first argument:

(SET (QUOTE FOO) 1)

Because you had to quote the first argument in about 99% of all
applications of SET, it evolved into a special form that quoted the
first argument automatically:

(SETQ FOO 1)

SETQ cannot be a function, because functions are applied to the
/values/ of their arguments, so if SETQ was a function,

(LET ((FOO 0)) (SETQ FOO 1))

would be equal to

(LET ((FOO 0)) (SETQ 0 1))

which would be wrong.

SET! is Scheme's counterpart of SETQ.

SET-CAR! and SET-CDR!, on the other hand, have pairs as their first
arguments, so they do not have to be special forms. If they /would/
work like SET!, this would be rather confusing, because

(let ((p '(0 . 1))) (set-car! p '2))

would be equal to

(let ((p '(0 . 1))) (set-car! (quote p) '2))

--
Nils M Holm <n m h @ t 3 x . o r g> -- http://t3x.org/nmh/

On Apr 3, 6:56 am, Nils M Holm <before-2007-07@online.de> wrote:

> (let ((p '(0 . 1))) (set-car! p '2))

This should be
  (let ((p (cons 0 1))) (set-car! p '2))

Aziz,,,

Abdulaziz Ghuloum <aghul@gmail.com> wrote:
> On Apr 3, 6:56 am, Nils M Holm <before-2007-07@online.de> wrote:
> > (let ((p '(0 . 1))) (set-car! p '2))

> This should be
>   (let ((p (cons 0 1))) (set-car! p '2))

Oops, yes.

--
Nils M Holm <n m h @ t 3 x . o r g> -- http://t3x.org/nmh/

Nils M Holm <before-2007-07@online.de> writes:

I would not disagree with any of this, though I would point out that
the "evolution" of SET into SETQ happened more quickly than the word
"evovled" might suggest.

However, I would add an explanation of why Scheme contains only an
analog of SETQ and not of SET.  This is a good example of where a
programming language designer can make programmers' lives easier by
providing them with less flexibility.

With SET, you gain the ability to assign a new value to a variable
where the variable being assigned is determined at runtime.  Consider,
for exampple

(SET (READ) 17)

in which the variable's name is read in from the keyboard.

This makes it extremely difficult to reason about a program, whether
the reasoning is being done by a human reading the program or by a
computer interpreting or compiling it.  Consider also that the above
use of SET could be in the code of some procedure, perhaps one that
isn't immediately apparent.  The net result is that you have to assume
that any variable could change values at almost any time. By contrast,
with Scheme's set!, and the use of lexical scoping, it is easy to tell
whether a variable truly can vary or not.  If there is no (set! x ...)
within the scope of x, then you know for sure that x's value remains
constant.

<dillog@gmail.com> wrote:
> hi

> Why set-car and set-cdr can be propagated like regular functions while
> set! can't? I can't figure this one out. (I'm rewriting all my
> functions into using only set-car!)  This is sorta funny.

(set! x y)

The variable x evaluates to a location. The variable y evaluates to the
contents of a location.

(set-car! x y)

The variable x evaluates to the contents of a location.

Is the reason set! cannot be a procedure because in Scheme procedures are
applied to values not locations? (In Scheme, a location is not an expressed
value.)

Here are three ways to represent assignment. I've been wondering why set!
and ref are new productions of the grammar whereas the others - cell,
contents, setcell, deref, setref - are primitives.

(set! <identifier> <expression>)

- - - - - - - - - -

(cell <expression>) ;=> reference
(contents <reference>) ;=> value
(setcell <reference> <expression>)

- - - - - - - - - -

(ref <identifier>) ;=> reference
(deref <reference>) ;=> value
(setref <reference> <expression>)

"Marlene Miller" <marlenemil@worldnet.att.net> writes:
> ...
> (set! x y)

> The variable x evaluates to a location. The variable y evaluates to the
> contents of a location.

My only quibble here is with your use of "evaluates to."  This phrase
should refer to one specific function from expressions to expressed
values.  If the variable x were evaluated, it would evaluate to the
contents of a location.  But it isn't evaluated.  Instead a different
function is applied to it, mapping it into a location.

> ...
> Is the reason set! cannot be a procedure because in Scheme procedures are
> applied to values not locations? (In Scheme, a location is not an expressed
> value.)

Yes.  In a language like ML, where locations are first-class values,
or a language like Fortran, which uses pass-by-reference (i.e.,
procedures applied to locations), there would be no problem with set!
being a procedure.  (Of course, in Fortran you would need a different
procedure for each type, but that is a detail.) -max

I think you already answered this yourself in your first post of the
day.  If set! or ref were a procedure, then the <identifier> would be
evaluated, which would be the wrong thing to do with it.  -max

"Max Hailperin" wrote:
> "Marlene Miller" writes:

> > ...
> > (set! x y)

> > The variable x evaluates to a location. The variable y evaluates to the
> > contents of a location.

> My only quibble here is with your use of "evaluates to."  This phrase
> should refer to one specific function from expressions to expressed
> values.  If the variable x were evaluated, it would evaluate to the
> contents of a location.  But it isn't evaluated.  Instead a different
> function is applied to it, mapping it into a location.

Oh my :-(. I see what I said was wrong. The environment function is applied
to x. y is evaluated. Just as they show in EoPL and say in the R5RS.

- - - - - - - -

> This phrase
> should refer to one specific function from expressions to expressed
> values.

Hmm. I am not sure what this says. The semantic function from expressions to
their meanings? The phrase (set! x y) should refer to this function?
"evaluates to" violates this?

This time I was the one being sloppy.  Your "Oh my" paragraph above
indicates that you nonetheless got what I was trying to say.

You are right to think that "evaluates to" has something to do with
the semantic meaning function.  Let us ignore continuations for the
sake of simplicity.  Then my sloppiness consisted of my willingness to
accept a phrase like "the name y evaluates to 17" as though there were
some function that took you directly from the name to the value.
Really all that is meaningful is "the name y evaluates to 17 provided
that y is bound to a location containing 17."  This latter claim is an
informal statement about the meaning function: that if you apply the
meaning function to the name y, apply the result to an environment
that binds the name y to some location, let us call it L, and apply
the result to a store that maps L to 17, you will get a pair
containing the value 17 and some store.  (The store happens to be the
same as the original, but the "evaluates to" claim doesn't say that.)

Because we chase down that whole path from the name y to the value 17,
we can say we "evaluated" y (i.e., turned it into a value), but
because we don't do the same with the name x, we ought not call what
we do with x "evaluation" -- a lesson that you apparently had already
recognized back up at "Oh my". -max

On Apr 4, 5:28 am, Max Hailperin <m@gustavus.edu> wrote:

> "Marlene Miller" <marlenemil@worldnet.att.net> writes:
> > ...
> > (set! x y)

> > The variable x evaluates to a location. The variable y evaluates to the
> > contents of a location.

> My only quibble here is with your use of "evaluates to."  This phrase
> should refer to one specific function from expressions to expressed
> values.  If the variable x were evaluated, it would evaluate to the
> contents of a location.  But it isn't evaluated.  Instead a different
> function is applied to it, mapping it into a location.

Whoa!  If the phrase `evaluates to' gives you the jitters, what
about `a different function is applied to it'?!  I know what you
mean, but a newbie might get a horribly wrong idea here.

How about ``X isn't evaluated.  The interpreter treats SET!
specially by changing what X refers to.''

I was going to say `changing the contents of the location that
X refers to', but I think that is an implementation detail.  A real
interpreter or compiler may have several locations associated
with X or it may have none at all.  All it is required to do
is ensure that future evaluations of X return the new value.

"Max Hailperin" wrote:
> Your "Oh my" paragraph above
> indicates that you nonetheless got what I was trying to say.

Yes. I thought about how set! is implemented in EoPL.

(define eval-expression
  (lambda (exp env)
    (cases expression exp
...
      (var-exp (id) (apply-env env id))
...
      (varassign-exp (id rhs-exp)
                     (begin
                       (setref! (apply-env-ref env id)
                                (eval-expression rhs-exp env))
                       1))
      )))

eval-expression *evaluates* the expressions (set! x y) and y. Whereas
apply-env-ref is applied to x. eval-expression never sees x.

Suppose the abstract syntax for set! is

<expression> ::= set! <variable> <expression>

or if you like,

(define-datatype expression expression?
  (set! (var symbol?)
       (exp expression?)))

The syntax of the set! phrase is defined in terms of the syntax of two
subphrases.

Even though <variable> is a subphrase of the abstract syntax, we know
<variable> is not evaluated. Does this *sort of* describe how <variable>
fits into a semantic equation for set!? In particular, not [[var]].

[[set! <var> <exp>]] env store0 =

...   env <var> ...    [[<exp]]   ...   store1

In other words, <var> is part of the stuff that makes of the composition,
such as + here.

[[e1 + e2]] sigma0 = [[e1]] sigma + [[e2]] sigma

"Marlene Miller" wrote:

Revised. I can do a little bit better. Metavariables, not sets.

> [[set! <var> <exp>]] env store0 =

> ...   env <var> ...    [[<exp]]   ...   store1

[[set! v e]] env store0 =

 ... env v   ...   [[e]]   ... store1

<dillog@gmail.com> wrote:
> hi

> Why set-car and set-cdr can be propagated like regular functions while
> set! can't? I can't figure this one out. (I'm rewriting all my
> functions into using only set-car!)  This is sorta funny.

(let ((x 0) (y 1))
  (set! x y))

Step 1:
(((lambda (x)
    (lambda (y)
      (set! x y))) 0) 1)

Step 2:
((lambda (y)
   (set! L1 y))) 1)

Store={<L1,0>}

Step 3:
(set! L1 L2)

Store={<L1,0>,<L2,1>}

Step 4:
(set! L1 1)

Store={<L1,0>,<L2,1>}

Step 5:
void

Store={<L1,1>,<L2,1>}

Assignment corresponds to changing the value of the slot in memory named L1.

Could I get away with saying step i reduces to step i + 1?

Add to del.icio.us | Digg this | Stumble it | Powered by Megasolutions Inc