Redistributable Scheme tutorial, Environments, OO
Dimitrios Souflis
Recently, I have turned to Scheme as a scripting language
for my company's SQL Server. I'm certain that many of our
users, accustomed to PL/SQL, Javascript etc. will not be
familiar with Scheme, or even Lisp in general. Is there a
free and small introduction to Scheme, same in spirit (and
size) to the "Gentle Introduction to Haskell", that we could
redistribute (or point to)?
Then, some questions on environments:
R5RS defines functions that return 'environment specifiers',
used in conjunction with 2-arg EVAL. Is the omission of an
appropriate predicate (e.g. environment?) deliberate, in that
envirionment specifiers are not types of their own?
In my TinySCHEME (extension of MiniSCHEME, see my homepage)
I have introduced a "(current-environment)" function that
returns the environment _at the nesting level of the call_. I have
found it handy for constructing packages easily
(package <definitions>) => (apply (lambda ()
<definitions>
(current-environment))
Has any implementation provided such a primitive? Is it an outrageous
addition to Scheme?
I have also found environments seductively rich to express single
inheritance OO hierarchies. Instead of the YASOS motivating idea
that "objects are closures", I have found much expressibility
in the idea that "objects and classes are environments", with
the inclusion relationship between environments being the ISA
relationship between classes (and instances). I find it semantically
cleaner (and "Schemer") than ad-hoc mechanisms for object orientation.
The lexer of TinySCHEME recognizes the construction <qualifier>:<symbol>
and
transforms it in the following manner (T is the transformation
function):
T(<qualifier>:<symbol>) = (*colon-hook* T(<symbol>) <qualifier>)
where <qualifier> is a symbol not containing any colons.
As the definition is recursive, qualifiers can be nested.
The user can define his own *colon-hook*, to handle qualified names.
By default *colon-hook* is defined as EVAL, so that qualifiers must
denote environments.
Using this functionality, class and instance fields and
methods are accessible with familiar notation:
class1:somefield
(class1:somemethod 67 21)
(define instance1 (class1:new 23 41))
instance1:somefield
(instance1:somemethod 36)
(instance1:super:somemethod 45 32)
(class1:super:+ 2 3)
Inside methods, no special notation is needed to access members,
providing the same kind of ease like the familiar C++ defaulting
to "this->".
Of course, this mechanism is of little practical value. Sometimes,
though, it is useful to have a semantically clean foundation on
which one can hardwire optimized mechanisms that don't change the
semantics but make some features affordable.
You are welcome to comment on the text:
<http://www.altera.gr/dsouflis/oo.txt>
--
Dimitrios Souflis dsou...@altera.gr
Altera Ltd. http://www.altera.gr/dsouflis
*** If Hungarian is so great, dwhy vdo aits nproponents
*** dnot vuse nit ain atheir nemail?
Ray Dillinger
> Then, some questions on environments:
> R5RS defines functions that return 'environment specifiers',
> used in conjunction with 2-arg EVAL. Is the omission of an
> appropriate predicate (e.g. environment?) deliberate, in that
> envirionment specifiers are not types of their own?
The standard does not require environments to be first-class
types. In particular, they cannot be stored as values, returned
from (other) functions, passed as arguments to user-defined
functions, etc.
The fact that some implementations provide these facilities
should in no way be mistaken for the standard requiring them.
And, FWIW, the implementations that provide these facilities
usually also provide an (environment?) predicate.
Bear
Keith Wright
> Dimitrios Souflis wrote:
>
> > Then, some questions on environments:
> > R5RS defines functions that return 'environment specifiers',
> > used in conjunction with 2-arg EVAL. Is the omission of an
> > appropriate predicate (e.g. environment?) deliberate, in that
> > envirionment specifiers are not types of their own?
>
> The standard does not require environments to be first-class
> types. In particular, they cannot be stored as values, returned
> from (other) functions, passed as arguments to user-defined
> functions, etc.
Whoa! Where do you get that? Section 6.5 says:
"[the] envirionment-specifier must be a value returned by one of
the three procedures defined below".
I see nothing that suggests that these are not ordinary values
returned by ordinary procedures.
--
--Keith
This mail message sent by GNU emacs and Linux.
Food, Shelter, Source code.
Ray Dillinger
Keith Wright wrote:
>
> Ray Dillinger <be...@sonic.net> writes:
> > The standard does not require environments to be first-class
> > types. In particular, they cannot be stored as values, returned
> > from (other) functions, passed as arguments to user-defined
> > functions, etc.
> Whoa! Where do you get that? Section 6.5 says:
> "[the] envirionment-specifier must be a value returned by one of
> the three procedures defined below".
> I see nothing that suggests that these are not ordinary values
> returned by ordinary procedures.
here's a quote from the proposal returned from the snowbird
meeting, which r5rs was developed from.
///////////////////////////////////////////////////////////
// Rozas explains: "The proposal does not imply the
// existence or support of first-class environments, although
// it is compatible with them. The proposal only requires a
// way of associating tags with a finite set of distinguished
// environments which the implementations can maintain
// implicitly (without reification).
// "`Pascal-like' implementations can support both
// null-environment and scheme-report-environment since the
// environments specified by the return values of these
// procedures need not share any bindings with the current
// program. A version of eval that supports these but not
// interaction-environment can be written portably, but can
// better be written by the implementor, since it can share
// code with the default evaluator or compiler."
// Here "Pascal-like" refers to implementations that
// are restricted to static compilation and linking. Because
// an eval that doesn't support interaction-environment can be
// written entirely in the scheme langauge described by the
// rest of the report, it raises no troublesome questions
// about its formal semantics.
////////////////////////////////////////////////////////////
The text of the report, which was published in LISP
pointers, 4th quarter 1992, can be found on the web at
http://www.sonic.net/~bear/scheme/june92.txt .
(though I may move it somewhere else and link it into my
scheme page in the near future...)
That quote, indicating that they are "not first class", implies
to me that the functions that "return" an environment are not
**NECESSARILY** returning a value which can be stored in any
variable, passed on the stack, etc. This impression is deepened
by the fact that environments are immutable.
Environments being immutable implies that there is no actual
need to pass the environment to another place -- you can simply
pass the environment-specifier function (and possibly its
argument)instead.
I have long thought that this is a defect in R5RS, or at least
a whopping huge missed opportunity. If Environments were first
class and mutable, then we would have our long-awaited standard
module system, for those who desire it. In fact, all existing
module systems could easily be implemented in terms of first-class
mutable environments.
Ray Dillinger
Dimitrios Souflis
> a whopping huge missed opportunity. If Environments were first
> class and mutable, then we would have our long-awaited standard
> module system, for those who desire it. In fact, all existing
> module systems could easily be implemented in terms of first-class
> mutable environments.
I second that thought. I used first-class environments in my
TinyScheme scripting language, because it was so easy it was a
shame not to. Since you are attracted to the idea of mutable
environments, perhaps you'd like to take a look at some thoughts
of mine for expressing OO semantics in Scheme via environments,
instead of in an ad-hoc manner.
<http://www.altera.gr/dsouflis/oo.txt>
--
Dimitrios Souflis dsou...@altera.gr
Altera Ltd. http://www.altera.gr/dsouflis
*** Reality is what refuses to dissapear when you stop believing
*** in it (VALIS, Philip K. Dick)
Max Hailperin
From: Ray Dillinger <be...@sonic.net>
... here's a quote from the proposal returned from the snowbird
meeting, which r5rs was developed from.
///////////////////////////////////////////////////////////
// Rozas explains: "The proposal does not imply the
// existence or support of first-class environments, although
// it is compatible with them. The proposal only requires a
// way of associating tags with a finite set of distinguished
// environments which the implementations can maintain
// implicitly (without reification). ...
That quote, indicating that they are "not first class", implies
to me that the functions that "return" an environment are not
**NECESSARILY** returning a value which can be stored in any
variable, passed on the stack, etc. ...
The quote, contrary to what you say, does not indicate that they are
"not first class." Rather, it indicates that they need not be
"first-class environments." I wasn't at Snowbird, but taking the
whole thing in context I think you are making a mistake to focus on
the adjective "first-class" rather than the noun "environments." When
Rozas says that "the proposal does not imply the existence or support
of first-class environments," I am 99.99% sure he is not saying that
the value returned need not be first-class, but rather he is saying
that they need not be *environments* as that term had previously been
understood.
-Max Hailperin
Associate Professor of Computer Science
Gustavus Adolphus College
800 W. College Ave.
St. Peter, MN 56082
USA
http://www.gustavus.edu/~max/
Guillermo 'Bill' J. Rozas
> The quote, contrary to what you say, does not indicate that they are
> "not first class." Rather, it indicates that they need not be
> "first-class environments." I wasn't at Snowbird, but taking the
> whole thing in context I think you are making a mistake to focus on
> the adjective "first-class" rather than the noun "environments." When
> Rozas says that "the proposal does not imply the existence or support
> of first-class environments," I am 99.99% sure he is not saying that
> the value returned need not be first-class, but rather he is saying
> that they need not be *environments* as that term had previously been
> understood.
Thanks Max. You are correct.
Among the Scheme report authors (and surrounding "groupies" -- no
pejorative connotation intended), the phrase "first-class
environments" is not the sum of "first-class" plus "enviroments".
"First-class environments" is meant as something like what MIT Scheme
has which goes far beyond what R5RS has. Among other things it
specifies ways of creating new environments by reification [the
special forms (the-environment) and (make-environment ...)], and a
procedural interface to query, access, and mutate existing
environments. Furthermore the mutation of such environments affects
procedures closed in them, a feature that several authors consider
very objectionable for aesthetic and implementation reasons that have
long been debated.
The environment specifiers returned by the suitable procedures in R5RS
and taken by EVAL as a second argument are first-class values. They
can be passed around, stored in data structures and closures, etc.
However, they lack the other features that would make them into
"first-class environments".
The distinction is similar to that between "first-class procedures" in
Scheme and ML, and first-class procedures in C. In some sense (I've
always disliked the standard definition of "first-class") the
procedures in C are first-class. However, they are certainly nowhere
near as powerful and useful as the "first-class procedures" in Scheme.
It is the extra "features" in Scheme and ML that make them really
stand out. Similarly it is the extra features of environements in MIT
Scheme and other dialects that make "first-class environments" stand
out and make some people like them and some hate them.
The R5RS EVAL and environment specifiers are a compromise between
those who profoundly dislike first-class environments and want a
restricted EVAL, and those who can not accept/understand EVAL without
a second argument that is an environment.
BTW, if memory serves, this proposal was not discussed at Snowbird in
1988, but in Palo Alto in 1992. Just a minor nit to the original
poster.
Rob Warnock
+---------------
| The environment specifiers returned by the suitable procedures in R5RS
| and taken by EVAL as a second argument are first-class values. They
| can be passed around, stored in data structures and closures, etc.
|
| However, they lack the other features that would make them into
| "first-class environments".
So, for example, if an implementation chose to do the following
(with the understanding that "eval" would "do the right thing"
when passed one of the indicated values), that would satisfy R5RS?
(define *magic-env-flag* (list '*magic-env-flag*))
(define (null-environment vers)
(if (= vers 5)
(cons *magic-env-flag* 0)
(error "bad env version" vers)))
(define (scheme-report-environment vers)
(if (= vers 5)
(cons *magic-env-flag* 1)
(error "bad env version" vers)))
(define (interaction-environment)
(cons *magic-env-flag* 2))
-Rob
-----
Rob Warnock, 7L-551 rp...@sgi.com http://reality.sgi.com/rpw3/
Silicon Graphics, Inc. Phone: 650-933-1673
2011 N. Shoreline Blvd. FAX: none (temp)
Mountain View, CA 94043 PP-ASEL-IA