YC wrote:

> I've heard that Scheme
> doesn't keep variables on the stack, but want to verify.

The explanation is a little involved. First the
concept of call stack. Consider:

   (define (f x) (g (+ x 1))
   (define (g y) (h (+ y 2))
   (define (h z) (+ x 3))
   (f 0)

Conceptually f calls g, which calls h. So we have
a stack of functions calls here. In most languages
the conceptually call stack is implemented as an
actual stack.

That strategy can't be used naïvely with Scheme.
due to call-with-current-continuation. The
problem is that call/cc allows a function to
return more than once - and thus conceptually
you get a call *tree* instead of a call stack.

In a simple Scheme implementations the tree is
represented as (you guessed it) a tree stored
in the normal garbage collected heap.

However it is possible to use a stack to store the
current branch of the call tree and then do
some trickery when control transfers to another
branch [actually a little trickery is needed prior
to this too].

In short, you can't say "Scheme doesn't keep variables
on the stack" because some implementations do and
others don't-

The canonical [I believe] reference is:

   "Three Implementation Models for Scheme"
   by R. Kent Dybvig.

It is very well-written and explains everything
in detail. See especially chapter 3 and 4.

--
Jens Axel Søgaard

_________________________________________________
  For list-related administrative tasks:
   http://list.cs.brown.edu/mailman/listinfo/plt-scheme

On 5/31/07, YC <yinso.chen-Re5JQEeQqe8AvxtiuMwx3w@public.gmane.org> wrote:
> > Am I inferring correctly that you are saying closure consumes a constant
> > factor of memory over struct, but otherwise doesn't necessarily hold onto
> > unnecessarily references from the stack?

> Right.

> > Any other way besides closure & struct to create opaque compound value
> > objects?

> The way we think of it: all compound values are structs at one level
> or another. You just may or may not have access to the inspector to
> see the fields. So ... no. :)

> At Thu, 31 May 2007 16:31:28 -0700, YC wrote:
> > While it's unclear for me what model PLT Scheme uses for structs - Robby
> > alluded to that closures is only a constant factor over struct from memory
> > consumption.

> I think that constant factor should be between 0 and 1 pointer,
> depending on whether the closure refers to top-level bindings or module
> top-level bindings (other than things that are built into MzScheme, in
> which case the reference is inlined instead of kept in the closure).

> Otherwise, a closure has a pointer to its code, and a struct has a
> pointer to it's type descriptor, so those balance; each field and
> captured bindings take the same amount of space.

I think it's ignorance.

When I was doing Python programming, I saw newcomers work with the Python
DBI and almost always not use prepared statements but rather string
concatenate.  That's what their teacher told them to do.  And even people
who should know better can propagate this problem.  Here's one example:

     http://mail.python.org/pipermail/tutor/2003-April/022010.html

I saw the same thing with many Java programmers: I rarely saw use of
prepareStatement(), and even when I saw people using it, the code would
completely miss the point of prepareStatement(); I'd see code like:

     stmt = conn.prepareStatement("insert into article (title) values ('" +
                                  title + "')");
     stmt.executeQuery();

which made me laugh and cry at the same time.



I'm very glad that Hans's SQLID interface includes support for prepared
statements.  I would like to see it highlighted more vividly in the
documentation.  As it is, it's just a quick mention in:

http://www.elemental-programming.org/sqli.html#_code__sqli_query_sqli_handle_query___args____boolean__code_

as a set of optional arguments passed to the "query" method.
_________________________________________________
  For list-related administrative tasks:
   http://list.cs.brown.edu/mailman/listinfo/plt-scheme