►
Description
In this meeting, Alan Dipert told about Common Lisp in a talk tailored for the Clojure crowd.
Moderator: Daniel Szmulewicz
Background and abstract:
https://clojureverse.org/t/scicloj-public-meeting-common-lisp-for-the-curious-clojurian/
Slides:
http://bit.ly/scicloj-common-lisp-slides
Text chat:
http://bit.ly/scicloj-common-lisp-chat
A
A
My
name
is
danielle
and-
and
I'm
I
was
asked
to
moderate
this
talk,
so
I'm
so
happy
to
that
danielle
switzky
reached
out
to
me
and
that
I
get
to
do
that
because
I
know
alan
from
way
back.
If
I
can
say
that
I
remember
allen's
work
when
we
were.
I
was
doubling
in
closure
and
he
came
up
with
a
very
ambitious
front-end
framework
called
hotline,
and
we
will
see
what
was
impressive
about.
It
was
that
it
was
based
on
a
completely
different
architectural
principle
that
we
were
used
to.
A
You
hear
about
him
and
it's
about
in
the
context
of,
and
that
is
that
is.
That
is
what
I
like
about
alan.
It's
that
it's
not
it's,
not
it's
not
just
about
one
community,
one
language,
this
this
this
this
you
know
polyglotism.
If
I
may
say
you
know
the
ability
to
to
learn
multiple
languages
and
juggle
with
the
languages.
A
So
that
is
one
thing,
but
the
other
thing
is
that
alan
also
is
going
to
talk
about
a
project
which
is
in
a
yet
another
language
common
list,
although
it's
the
same
family
of
languages.
But
the
question
now
is
the
about
the
audience.
We
would
like
to
know
two
things
and
please
use
the
chat
to
to
answer
the
the
question
the
first.
A
A
10
years
professionally,
seven
years,
six
years,
six
years,
20
70.,
so
we
have,
I
would
say
three
years
six
times
and
everybody
is
kind
of
okay.
We
have
a
okay
allen.
Your
audience
is
made
of
experienced
developers
which
maybe
shouldn't
be
too
surprising,
because
this
is
not
the
kind
of
meetup
you
stumble
upon
if
you
start,
but
anyway
now
we
know
and
then
the
second
question
is:
what
is
your
daily
driver
in
terms
of
language
because
we
have?
A
Maybe
we
have
certainly
closure
people
which
are
recognized,
but
we
might
might
have
commonly
people
and
we
might
have
people
who
write
in
other
languages
as
well.
So
maybe
everybody
can
type
in
what
kind
of
programming
language
they
use
as
a
daily
driver,
and
the
question
is
just
the
daily
driver
because
you
might
know
multiple
languages,
but
what?
What
is
the
the
main?
Your
main
language
that
you
use?
Okay,
nice,
nice?
We
have
ruby,
we
have,
we
have
c
plus
plus
we
have
kotlin.
A
B
A
B
Niskin
is
here
on
the
call,
so
that's
the
reason
I
have
to
be
honest
about
it.
He
and
I
designed
all
those
things
together
so
but
yes
thank
you
so
much
for
the
opportunity
to
come
here
and
speak,
and
I
was
telling
the
daniels
before
the
call
preparing
for
things
like
this
is
always
really
fun,
because
you
know
I'm
sure
you've
heard
it
said.
The
act
of
writing
is
kind
of
a
vehicle
for
thought
and
for
honing
your
thoughts
and
every
time
I
have
an
opportunity
to
introspect
and
crystallize
and
share.
B
A
B
B
B
B
Yeah.
So
daniel
has
done
a
fantastic
job
of
biographying
me,
but
I
can
fill
in
some
gaps
and
paint
the
picture
a
little
more.
I
think
this
is
important
because
and
I'll
get
elaborate
more
on
this,
but
I
don't
think
you
can
understand
things
in
the
world
without
understanding
why
they
matter
to
other
people
and
to
do
that,
you
have
to
know
a
little
bit
about
the
other
people,
and
you
know
it
understand
where
they're
coming
from
a
little
bit.
So
that's
my
goal
here,
so
I've
been
using
closure
since
2009.
B
I
learned
it
when
I
was
a
student
and
I
had
the
enthusiasm
of
the
new
convert
big
time
because
it
seemed
like
closure
was
the
end-all
be-all
and
I
couldn't
believe
people
were
using
java.
That
was
ridiculous
and
preposterous,
and
there
was
no
way
I
was
going
to
do
anything
except
closure
and
as
foolish
as
that
perspective,
was
it
turned
out
to
pay
pretty
huge
dividends
for
my
career
and
for
my
friend's
circles
and
everything
because
going
all
in
on
something
is
valuable.
You
know
you
make
these
lifelong
friends
and
connections.
B
You
are
exposed
to
ideas
that
you
can
use
to
compare
other
ideas
to
later,
and
I
know
anyone
who's
learned
closure
pretty
much
compares
anything.
Anybody
tells
them
about
to
closure
right.
I
mean
it's
like
okay.
What
doesn't
this
do?
That
closure
does
better
is
kind
of
like
after
you
know,
closure
that's
kind
of
the
standard
you
hold
at
least
I
did
for
a
while
and
tempered
somewhat
there
but
yeah.
B
I
was
you
know
heavily
invested
in
the
language,
the
community
and
then
added
participated
in
the
creation
of
new
tools
and
infrastructure
and
libraries
and
stuff
around
2016.
I
made
a
career
change.
It
seemed
like
there
was
an
opportunity
for
me
to
apply
the
skills
and
the
knowledge
I'd
accumulated
in
the
closure
community
in
a
new
context
in
the
r
world
and
more
broadly,
in
scientific
computing,
and
I
think
this
is
this
is
a
trend,
the
concept
of
data
scientists,
the
concept
of
scientific
computing.
B
I
remember
when
I
was
in
college
scientific
computing
meant
like
grid
computing
with
c
and
mpi
and
stuff
like
that,
and
I
vaguely
was
aware
that
this
was
going
on.
I
never
participated
in
it,
but
I
think
since
then,
the
concept
of
data
science
has
opened
up
significantly
to
the
point
where
we
have
a
category
of
person
who
is
a
new
programmer?
Who
needs
to
explore
data
and
that's
interesting,
because
I
think
that's
pretty
much
the
same
kind
of
person
as
someone
who's
using
a
dynamic
language
for
the
first
time
programmer
or
not.
B
You
know
it's
all
about
working
your
way
through
dad
data,
finding
patterns,
defining
patterns,
carrying
yourself
to
new
levels
of
understanding
of
the
data
filling
in
the
gaps
with
abstractions
and
so
on.
So
this
this
little
period
in
my
life,
when
I
was
doing
r
and
javascript
and
immersed
in
the
data
science
world
was
really
interesting
and
my
experience
with
closure
paid
off
there.
B
I
think
it's
closure
math
ad,
or
something
like
that.
Like
there's
a
java,
static
method,
underneath
closures
plus
and
if
you
can
replace
the
function,
call
to
plus
with
a
direct
call
to
the
java
static
method.
Without
any
variatic
arguments,
then
you
get
a
slight
performance
improvement
and
when
I
was
studying,
I've
never
seen
anything
like
this
before.
B
B
B
So
for
me
this
is
a
hobby
and
by
that
same
token,
I'm
not
an
expert
at
common
list,
I'm
if
I'm
closest
to
being
something
like
an
expert
in
closure,
but
I
cannot
claim
to
be
an
expert
in
common
lists,
but
I
think
lack
of
real
production.
Experience
is
probably
what
keeps
me
from
that,
but
maybe
in
the
future,
it'll
be
something
I'll
be
able
to
pursue.
It's
certainly
an
aspiration
for
the
moment
I
am
still
a
closure
programmer.
B
B
B
I
think
it's
good
and
I
like
it
and
I'm
marginally
obsessed
with
it
it's
funny,
because
my
interest
in
this
has
really
confused
and
surprised
a
lot
of
my
friends
in
the
closure
community
and
even
in
the
art
community,
like
what
what
do
you
see
in
this?
So
some
of
the
time
I'm
looking
at
this
stuff,
I
think-
maybe
maybe
I'm
just
going
crazy,
like
maybe
I
have
a
brain
tumor
or
something
like
that.
B
But
you
know
I
don't
have
any
other
symptoms,
so
I
think
it
really
is
just
it's
interesting,
so
I
hope
to
convey
why
why
I
think
it's
history
and
interesting-
and
this
is
the
introspection
that
I
mentioned
earlier-
that
I
that
I
did
that
I
haven't
done.
Is
I've
known
I've
been
afflicted
with
this
like
obsession,
but
I
haven't
really
thought
about
why
I'm
so
interested,
and
so
I
hope
to
share
that.
The
other
thing
is
context.
I
think
I
mentioned
you
know
if
you
want
to
understand
an
idea.
B
B
B
So
you
hear
a
lot
of
different
versions
of
why
common
lisp
is
good
and
you
hear
common
lisp
explained
in
a
lot
of
different
ways,
but
the
people
who
originally
designed
it
are
more
or
less
out
of
the
public
sphere.
They're
retired,
you
know
playing
it
playing
it's
low,
so
you
don't
hear
much
about
what
motivated
the
people
originally
to
make
it.
B
B
Daniel
mentioned
earlier
that
you
know
I'm
polyamorous
or
poly
poly
polytheistic
polylingual,
I'm
down
for
all
these
ideas.
I
have
recognized
great
personal
benefit
from
investing
heavily
in
one
thing,
which
I
did
with
closure
for
like
10
years,
but
I
think
there's
also
tremendous
benefit
in
recognizing
that
it's
possible
to
like
multiple
things.
At
the
same
time-
and
you
know
we
don't
have
to
be
fully
invested
and.
A
B
Think
this
is
a
message
more
for
junior
people
and
my
former
self.
I
don't
think
anyone
here
probably
is,
would
disagree
with
this.
So
yeah.
Both
closure
and
common
list
can
exist
at
the
same
time
and
both
be
amazing
at
the
same
time,
and
we
can,
we
can
have,
you
know,
recognize
and
realize
great
benefits
from
holding
both
in
our
heads
at
the
same
time
and
maybe
even
switching
between
them
when
it's
convenient
okay.
B
So
why
are
we
here?
Why
am
I
why?
Why
is
this
meeting
worth
your
time?
And
I
think
it's
because
common
lisp
is
not
going
anywhere.
It
is
going
to
wait
for
you
for
the
rest
of
your
life
to
learn
without
changing
and
that's
because
it's
a
standard,
it's
already
agreed
upon
it's
in
the
books.
You
know
they
there's
a
thing:
there's
a
plate.
B
B
And
still
it
has
value,
and
I
think
that's
because
the
fundamental
problems
of
programming
have
not
changed.
Since
people
started
programming,
the
human
brain
hasn't
changed
the
user
interface,
the
you
know,
the
human
computer
interface
hasn't
changed.
We
still
have
keyboards
symbols,
letters
we
use
natural
language
in
identifiers,
we
can
more.
You
know
it's
not
like.
People
now
can
hold
more
ideas
in
their
head
at
the
same
time
as
people
in
1981.
B
So
there's
value
there
clearly
the
other
interesting
thing
about
it
compared
to
most
other
language,
implementations
and
design
initiatives
is
the
amount.
The
sheer
amount
of
experience
that
went
into
this
thing.
Usually
people
when
people
from
closure
or
even
the
scheme
community
talk
about
common
lisp.
They
sneer
at
the
legacy.
B
You
know
the
the
problem
of
backward
compatibility,
but
the
flip
side
of
that
the
benefit
of
a
legacy
is
that
everything
there
was
put
in
for
a
reason
at
some
point,
so
it
might
bother
you
now
that
the
interfaces
aren't
perfectly
uniform
but
who's
to
say
that
your
perfectly
uniform
interface
won't
be
corrupted
in
the
future.
When
you
decide
to
use
it
and
considering
that
all
of
the
problems
are
the
same,
it
seems
to
me
unlikely
that
you're
never
going
to
have
to
corrupt
whatever
idea
you
have
for
abstraction
now
in
the
future.
B
So
why
not
just
start
with
the
set
of
corruptions
from
prehistory
and
build
up
from
there,
knowing
full
well
with
your
eyes
open
that
these
are
compromises
and
that
just
hindsight
doesn't
free
you
from
having
to
make
compromises
so
and
yeah.
I
think
it's
interesting.
I
don't
I'm
not
sure
people
come
together.
I'm
not
aware
of
any
more
recent
examples
of
people
with
this
depth
of
programming
experience
coming
together
from
such
wide
parts
of
the
programming
world
to
make
something
and
to
pour
their
experience
and
their
interests
into
something.
B
So
I
think
commonlist
was
singular
as
an
artifact
yeah,
so
dldr
commonlist
is
a
great
thing
to
learn
because
it's
not
going
anywhere.
It's
not
going
to
change
whatever
you
learn
about
commonlist
today
and
this
meeting
is
going
to
be
applicable
in
10
years.
Whatever
code
you
write
is
probably
going
to
work
and
that's
what
circling
back
to
me
and
my
interest,
my
obsession
like
when
I
first
got
back
into
common
list
in
2016.
B
This
is
an
email
from
the
original.
I
believe
it's
the
original
multi-institution
design
mailing
list,
so
there
were
people
from
mit
stanford
symbolics,
all
the
major
players
of
the
early
80s
and
they
were
on
an
email
list
and
they
discussed
fundamental
design
problems
and
we
have
visibility
into
those
discussions.
Some
of
the
discussions
are
kind
of
contentious
some
some
of
a
lot
of
the
times
they're.
Referring
to
meetings
they
had
in
person,
and
so
you
don't
get
the
full
picture,
but
it's
nevertheless,
it's
a
window
like
here's,
an
example
that
I
pulled
up.
B
This
is
an
email
from
somebody
at
mit
about
they're
talking
about
commonless
language,
probably
the
first
edition,
which
was
it's
like
a
1200
page
book.
That
was
a
draft
of
the
specification
that
guy
still
put
together
in,
I
think,
1981
or
82,
and
that
book
circulated
around
at
these
different
institutions
and
they
would
read
it
and
think
about
it
and
prototype
things,
and
then
they
would
communicate
to
each
other
on
this
mailing
list.
So
this
guy's,
asking
about
the
thing
for
making
a
hash
table,
takes
a
test.
B
Keyword
argument
and
one
of
the
equality
comparators
is
is
missing.
You
know
why
is
that
it
seems
like
it
should
be
in
there,
and
so
people
respond
to
him
separately.
There
is
this
thing
called
the
hyperspec
which
I
mentioned,
which
is
a
hyperlinked
documentation
of
everything,
more
or
less
everything
in
common
list,
so
anything
that's
named
in
common
lisp
has
represented
somewhere
in
the
hyperspec.
B
B
So
this
this
basically
is
like
a
javadoc
for
lisp,
and
you
can
see
why
that
is
you
get
your
arguments,
your
return
value,
your
description
and
then
a
little
bit
of
high
level
overview.
But
the
interesting
thing
is
that
these
javadoc
things
link
to
design
issues
and
represented
in
the
set
of
design
issues
is
a
reference
to
the
problem
we
saw
from
the
design
mailing
list,
which
is
they
had
like
a
committee
discussion
about
which
equality
constructs
hash
tables
should
support.
B
B
B
B
Java
interval
java
interrupt
that's
huge,
but
I
think
the
killer
feature
is
rich
hickey
and
the
reason
I
say
that
is
because
rich
hickey,
yes,
he
made
a
language.
Yes,
he
put
all
these
features
together,
but
there's
a
consistent
philosophy
behind
the
language
and,
most
importantly,
rich
makes
it
very
clear
up
front.
Why
he's
doing
what
he's
doing
so
when
anyone
comes
to
closure?
B
They're
not
looking
at
individual
features,
they're
connecting
with
this
person
and
his
story
and
his
needs
and
his
philosophy
and
once
you're
holding
that
in
your
head,
then
all
the
features
and
stuff
in
closure
fall
out
naturally
like
you
can
understand
his
perspective
and
why
he
made
the
decisions
he
did
and
that
empowers
you
to
really
design
closure
for
yourself
in
a
way.
That
also
is,
I
think,
rare
generally,
when
people
are
promoting
technology,
they
talk
about
specific
features
or,
if
you're
lucky
they'll
talk
about.
B
You
know
stories
like
user
stories
or
case
analysis.
What
do
they
call
that
case
studies,
but
you
don't
really
get
a
holistic
fundamental
view.
Part
of
that
is
because
it's
really
rare
for
for
large
intellectual
artifacts
in
computing
to
be
really
designed
by
one
person.
That's
pretty
rare.
Even
you
know
most
most
things
are
designed
by
small
groups
of
people,
but
this
really
is
a
one
person
thing,
and
so
because
it's
a
one
person
thing,
you
have
unprecedented
visibility
into.
Why
and
I
think
it's
great
I
I'm
this.
B
This
was
new
to
me
like
I,
when
I,
when
I
learned
closure.
This
was
very
compelling
to
me
because
it
seemed
like
I
had
to
learn
java.
Just
because
that's
what
everybody
learned
and
if
I
wanted
to
do
stuff
on
linux,
I
had
to
learn
c
because
that's
what
everybody
does,
but
neither
of
those
things
came
with
this
deep
philosophical,
historical
background
and
so
that
I
was.
I
was
almost
shocked
by
this
I'm
giddy
and
I
think
all
these
things
are
still
on
youtube,
and
this
is
a
great
reason
to
to
use
closure
today.
B
So
yeah,
you
know
rich,
is
big
on
on
rationale
and
and
doing
things
with
intent
and
in
an
open
source
project.
This
is
critical
because
the
intent
messages
to
people
whether
or
not
they
want
to
have
anything
to
do
with
your
thing
whether
they
want
to
help
you
you
know,
are
you
in
alignment
with
what
they
want?
B
If
you
don't
have
this
rationale,
then
you
get
pull
requests
that
you
have
to
shut
down,
which
makes
everybody
feel
bad.
So
it's
better
to
say
what
you're
going
for
and
let
people
come
to
you
rather
than
not
say
what
you're
going
for,
and
people
come
to
you
with
ideas
that
aren't
in
alignment
with
your
own,
and
you
know
for
himself.
B
I
know
richard
this
for
himself.
This
is
this:
is
the
outcome
of
years
of
his
own
thinking
and
research,
and
it's
great
and
lisp?
Doesn't
their
common
lisp
doesn't
have
a
document
like
this
like
there
isn't
a
common
lisp
rationale
document
part
of
that
is
because
there
is
no
single
person
who
could
have
written
it.
B
The
other
part
of
it
is
a
lot
of
their
rationale
was
implied
to
themselves
at
the
time.
So
you
can
piece
something
like
this
together
for
yourself.
If
you
do
the
research
and
you
can
find
it
in
the
emails
and
the
hyperspec
and
the
issues
list,
but
it's
not
all
in
one
place
like
this,
but
I
think
this
is
very
powerful.
B
All
right
the
champion,
so
that's
where
I
introduce
myself,
I'm
the
champion,
I'm
the
hero
of
this
talk,
I'm
the
person,
who's,
who's,
distilling,
all
the
context
for
you
all
and
I'm
certainly
joking.
There
is
no
such
person,
but
there
is
room
for
such
a
person
to
pretend
to
be
such
a
person,
which
is
what
I'm
doing
now.
B
Well.
This
slide
is
mangled,
so
a
little
light
criticism
of
closure
is
in
order.
I
still
use
in
love
closure,
but
one
of
the
things
in
the
rationale
is
emphasis
on
functional
programming,
which
I
think
anyone
here
would
agree
is
a
good
thing,
but
there
is
no
free
lunch.
You
know
every
every
design
decision
comes
with
a
set
of
trade-offs
and
in
one
interview,
rich
described
closure
as
a
programming
language
that
inhabits
a
place
in
the
set
of
possible
designs
that
he
really
likes
and
wants
to
be
in.
B
The
idea
that
you
could
describe
things
as
data
was
really
empowering,
but,
as
I
doubled
down
on
that
approach
and
continued
in
my
career,
I
realized
well,
if
even
if
you
put
data
together,
you
still
have
to
interpret
it
somehow
and
you're
going
to
need
code
to
do
that,
and
sometimes
the
kind
of
interpreter
you're
going
to
write,
looks
suspiciously
like
a
lisp
interpreter.
Hiccup
is
an
example
of
this.
It's
like
this
is
kind
of
like
a
lisp
and
a
lisp
at
first.
B
B
So
it's
all
a
set
of
trade-offs.
Overall,
though
I
mean
I'm
still
really
grateful
for
the
spot
on
the
design
space
that
closure
inhabits
here,
because
it
is
unique
and
it
is
very,
very
powerful,
like
it
really
it's
very
easy
to
make
things
that
are
likely
to
work
on
the
first
try
and
are
just
conceptually
nice.
It
feels
nice.
So
that's
it
for
the
light
criticism.
B
B
B
B
If
you
ran
it
just
by
itself,
which
made
it
clear
that
jits
could
be
could
do
could
add
value
regardless,
like
even
at
the
machine
code
level
like
the
concept
of
tracing
and
hot
reloading
and
stuff,
or
you
know,
moving
code
motion
and
all
that
stuff
like
there
was
value
there.
Even
the
machine
level
and
that
kind
of
smarts
is
moving
further
into
the
computer
as
we
see
with
apple's
m1
chip.
B
The
other
trade-off
with
jits,
which
was
true
even
15
years
ago.
Is
they
make
it
harder
to
reason
about
the
performance
envelope
of
a
particular
function,
because
something
that
to
you
might
seem
intuitively
fast
might
actually
have
a
non
like
a
non-local
effect
of
making
something
else
that
you
thought
would
be
fast
slow
because
it
gets
kicked
out
of
cash.
For
example,
the
code
trace
gets
kicked
out
of
cash
because
your
thing
now
dominates
in
some
way
that
intrigues
the
jit.
B
So
again,
I
think
this
is
something
that
is
a
trade-off
for
most
people
using
java.
It
provides
more
benefits
than
problems,
but
if
you're
really
interested
in
reliable
performance
envelope
like
you
really
need
to
make
sure
that
this
function
runs
the
same
speed
every
time
and
there's
various
applications
that
need
that,
then
java
and
jits
are
not
necessarily
the
right
thing.
For
you
platform
on
platform
issues,
I
think
this
is
this
is
still
true,
which
is,
if
you
have
different
platforms,
with
different
memory
models
like,
for
example.
B
If
on
what
one
platform
you
have
strings
are
immutable
and
another
platform
strings
are
immutable
or
you
know,
there's
32
bits
and
a
float
or
there's
32
bits
in
a
integer
here,
64
bits
and
an
integer
here
you
know
you
can
see
how
that
complicates
fitting
one
thing
to
the
other
thing
or
setting
one
thing.
On
top
of
the
other
thing,
you
can
imagine
how
there's
inefficiencies
that
creep
in
there,
because
you
have
to
coerce
and
copy
and
do
stuff
to
make
it
all
match
up
right.
B
B
Oh
yeah,
I'm
I'm
not
sure.
If
there's
a
closure
script
rationale,
I
actually,
if
you
go
to
the
first,
commit
enclosure,
script,
there's
a
an
org
file.
The
original
closure
script
read
me:
there's
a
bulleted
list.
Foreclosure
script,
that's
similar
to
the
one
for
closure,
but
I
don't
know
if
it's
I
don't
know.
If
that's
on
the
closure
script
website.
C
B
So
right,
this
is,
this
is
the
big
difference.
Really
closure
is
two
things:
the
compiler
and
the
runtime
built
on
a
really
pretty
deep
stack
of
other
stuff,
and
this
was
a
this
is
a
tactical
decision.
Now
you
can
imagine
you're
a
person
you're
a
single
person.
You
can
only
be
awake
for
so
many
hours
in
the
day.
You
can
only
type
so
fast,
but
you
want
to
make
a
new
programming
language.
Are
you
going
to
define
a
new
kind
of
computer
and
operating
system
to
make
that
happen?
B
B
B
So
the
platform
aspect
for
him
just
in
terms
of
his
time
available
to
engineer
stuff,
certainly
was
really
really
key.
I
should
say
also
I
I
do
you
know.
I
have
worked
with
rich
and
I
have
a
personal
connection
to
him,
but
I
don't
speak
for
him
on
any
of
these
things
and
I'm
going
based
really
only
on
information
that
he's
made
public
or
written
about
or
spoken
about,
but
which
with
which
he
may
now
disagree.
So
again,
I
don't.
I
am
not
rich
hickey.
B
B
And
the
operating
system
was
in
some
cases,
written
almost
entirely
in
lisp,
so
even
that
boundary
is
not
really
very
easy.
You
know
or
obvious
lisp
the
idea
you
can
use
to
describe
a
whole
computer
and
where
you
want
the
fun
the
foundational
stuff
of
the
computer
to
end
and
list
to
begin
is
kind
of
a
design
design
decision,
but
commonlist
was
not
architected
to
take
on
the
problems
of
the
operating
system,
so
some
things
are
absent
from
the
spec
and
are
provided
by
third
parties
or
implementations.
B
Now
threads
is
one
of
those
c
interop
cffi
is
another
one,
that's
platform
dependent,
but
you
know
it's
been
20
years,
so
I'll.
Even
a
lot
of
these
platform
dependent
things
have
converged
on
something
like
a
standard
that
works
across
platforms
like
the
thread
standard
board.
There's
a
library
called
bordeaux
threads,
but
nowadays
most
implementations
provide
their
own
native
version
and
they
all
interoperate
and
people
in
the
community
take
interoperation
between
different
implementations
pretty
seriously
so
yeah.
It's
a
different
thing.
B
B
B
If
you
are,
then
you're
probably
going
to
come
to
the
same
conclusions
as
they
did
about
what's
necessary
and
unnecessary
if
you're,
not
then
you're
going
to
feel
like
this
thing
is
in
your
way,
certainly
when
rich
designed
closure,
he
felt
this
way
about
java.
He
thought
you
know
this.
Is
these
the
the
people
who
design
java
their
priorities
are
all
wrong?
I
don't
want
to
program
in
this
way
and
I'm
at
odds
with
this
way
of
programming,
so
I'm
going
to
find
my
own
way
well.
B
So
a
lot
of
decisions
from
top
to
bottom
are
already
are
made
for
you
already,
but
in
common
list
you
have
more
room
to
make
your
own
decisions.
You
have
more
leverage
more
rope
to
hang
yourself
a
lot
more
rope
as
an
example
of
that
commonlist
does
not
explicitly
does
not
have
offer
a
concept
of
general
equality,
and
that's
intentional.
The
downside
of
it
is
that
there's
like
half
a
dozen
or
more
equality
operators
and
they
work
on
all
different
types.
B
A
B
Any
choice
you
make
about
how
to
do
that
is
going
to
suggest
or
imply
other
constraints
on
the
system,
and
so
in
the
interest
of
making
as
many
things
possible
in
common
lisp
as
they
can.
They
decided
not
to
make
a
decision
about
this,
and
what
this
means
is
that
if
you
want
something
like
closure
style,
immutable
structures
with
general
equality,
you're
going
to
have
to
make
it
yourself
or
use
library.
B
And
this
goes
back
to
the
tension
of
platform
versus
language
on
top
of
a
platform.
This
is
commonlist,
taking
a
stand
as
a
platform
and
saying
we're
not
going
to
approach
this
we're
going
to
leave
this
to
the
users
and
contrast
with
closures
generally
quality
operator
equal,
which
you
can
pretty
much
use
intuitively
in
any
context
where
you
situation,
demands
equality.
B
But
there
are
a
few
costs
associated
with
this
convenience.
You
need
the
fourth
one
is:
maybe
the
the
meatiest
one,
which
is
you
know
you
can
extend
quality
quality
to
your
own
new
objects.
But
when
you
do
that,
you
need
to
mutate
the
list
of
equality,
comparator
functions
inside
closure
itself,
and
that's
what
you're
doing
that's
effectively,
what
you're
doing
when
you're
extending
an
interface
in
java
or
if
you're,
extending
a
protocol
enclosure.
B
Oh
yeah
yeah
henry
baker,
yeah
yep
yeah,
so
in
some
of
his
early
talks,
rich
references
egal-
and
this
is
henry
baker's
attempt
to
who's
another
original
mit
list
person
to
bring
some
sanity
to
common
lisps
equality
operations
because
he,
he
also
was
disgusted
by
the
proliferation
of
equality
functions,
and
he
had
an
idea
about
how
to
make
a
better
one
or
at
least
a
more
comprehensive
one.
But
there
are
trade-offs
associated
with
his
approach.
B
So
yeah,
you
know
the
nice
thing
about
these
abstractions
is
they
change
the
economy
of
using
them
and
it's
either
to
your
advantage
or
your
detriment,
depending
on
what
you're
trying
to
do,
and
if
you're
trying
to
write
a
hot,
you
know
new
parrot,
numeric
type
loop
or
doing
scientific
computing,
then-
and
you
know,
you're
always
going
to
be
working
with
a
particular.
You
know
signed
integer
or
whatever.
B
Then
this
may
get
in
your
way
more
than
it
helps
you.
Maybe
I
mean
again
it's
it's
contextual.
So
if
I
were
to
like
sum
up
the
conceptual
abstraction
differences
between
closure,
I
would
say
in
common
list.
I
think
you
know
closure
is
like
this
tightly
integrated,
beautifully,
designed
internally
consistent
view
of
how
to
program
and
in
particular
how
to
program
on
a
platform
like
java
or
javascript
common
lisp.
B
It
evolved
over
a
long
period
of
time.
It
has
amazing
ideas
in
it.
Those
ideas
are
not
especially
artfully
connected,
but
where
their
connections
dissatisfy,
you
can
at
least
go
find
out.
Why
there's
always
a
place
to
figure
out?
Why,
like
what
experience
led
to
this?
What
was
the
discussion
behind
this?
B
What
is
this
like?
Why
are
you
looking
at
this
and
yeah?
So
it
has
a
weird,
weird
vibe,
it's
old-timey,
but
it's
lovable
endearing
and
again
will
never
change
so,
whatever
time
you
spend
learning
it,
it's
going
to
pay
a
dividend
on
the
long,
the
long
tail,
so
I've
got
a
list
of
things
that
I
am
interested
in
of
late.
I
think
by
far
the
one
I'm
most
excited
about
is
this
project
which
I'll
see
if
I
can
open
it
up.
B
B
So
everything
about
this
guy
and
his
projects,
I'm
super
into
usually
there's
an
irc
channel
on
free
node.
It's
the
sickle
channel,
where
you
can
follow
what
he's
doing
he
checks
in
every
morning
and
he
says
good
morning,
everyone.
This
is
what
I'm
working
on
today.
So
you
have
like
it's
it's
kind
of
exciting.
B
B
B
So
what
you
end
up
with
and
what
he
has
is
a
set
of
libraries
that
sum
up
to
an
implementation,
they're
just
all
beautifully
written
and
his
implementation
of
one
of
commonless
standard
macros.
The
loop
macro
is
what
got
me
into
sickle
originally.
So
I
can't
I
can't
recommend
his
stuff
or
things
related
to
this
project
enough.
B
For
sure,
like
maybe
even
the
next
couple
years,
so
that's
fun,
jackal
is
my.
I
mean
certainly
in
comparison
to
sickle
hobby
pet
thing.
I
don't
work
on
this
every
day.
I
don't
even
work
on
it
every
week.
It's
a
long
term
bet
and
a
lot
of
it
is
educational
for
me,
but
this
is
an
attempt
to
bring
the
common
lisp
platform
at
least
parts
of
it
to
javascript
and
to
think
about
those
platform.
B
Impedance
issues
that
I
mentioned
having
to
do
with
lining
up
the
data
types
and
lining
up
the
abstractions
and
use
cases,
and
so
on,
and
so
there's
a
paper
that
I
wrote
about
that
that
that
illuminates
that-
and
I
still
I
still
poke
at
that.
Most
recently,
I've
been
working
on
multiple
value
return
support
to
be
efficient
in
there,
which
is
the
thing
I'll
talk
about
and
yeah.
I
think
I'll
leave
these
other
things
for
you
to
explore.
B
One
thing
I
will
emphasize-
or
one
thing
I'll
highlight-
is
peter
norvig,
so
peter
norvig,
long
time,
whisper
and
also
lisp's,
most
famous
defector,
probably
because
he
famously
switched
from
after
doing
decades
of
common
lisp
and
ai.
For
ai
research
to
using
python-
and
I
think
that
confused
and
saddened
many
people
in
this
community,
but
if
you
click
on
this
video
he's
interviewed
on
a
podcast,
I
think
two
years
ago
and
he
gets
into
why
he
did
that,
and
he
has
a
very
nuanced
perspective
and
he's
a
really
smart
guy.
B
So
any
opportunity
to
watch
him
speak
about
lisp
or
anything
else.
Is
you
know,
I
recommend
I
think,
I'm
at
a
good
place
to
stop.
This
is
the
end
of
my
slides.
My
plan
was
to
give
you
these
slides
to
give
you
some
background,
and
then
we
can.
Whatever
time
we
have,
we
can
use
for
discussion
or
questions,
or
I
can
do
little
demos
of
things.
A
A
A
A
C
I
can,
I
can
just
ask
it
live
if
you
want
yeah
sure,
yes,
yeah
yeah,
I
I
actually
I
I
I
think
it's
you
made
a
great
introduction,
because
one
thing
where
I
also
wrote
it's
a
great
slide
where
you
could
see
a
calmness
which
more
or
less
takes
the
whole
stack
from
bare
metal
to
space
or
you
can.
You
can
work
on
on
the
in
lisp
yeah
you're
still
in
this,
but
you
can
work
on
the
nitty-gritty,
compiler
details
where
you
get.
C
C
B
But
I'm
certainly
aware
of
it
is
the
rebel
situation
in
these
two
things
I
I
should
have
had
a
slide
for
this.
It's
an
important
point,
which
is
both
of
these
languages
are
very
rebel
focused,
and
what
I
mean
by
that
is
everything
about
the
language,
supports,
interactive
development
and
everything
about
compilation
and
delivery.
B
The
trade-off
here
is
rich
has
spoken
to
this
point
in
hacker
news,
threats
about
single
pass
versus
multi-pass
and
so
lisp
compilers
have
always
been
single
pass
in
the
sense
that
you
feed
the
top
level
forms
in
and
you
accumulate
a
lisp
image
inside
the
computer.
So
what
you're
doing
is
you're
contributing
code
to
a
stable
identity,
which
is
the
lisp
image,
and
you
have
certain
assurances
like
if
loading
a
top-level
form
fails,
your
image
isn't
corrupt,
for
example.
So
it's
like
a
transaction
so
both
of.
B
Have
that
in
common-
and
this
is
different
from
languages
in
the
scheme-
tradition
which
have
broadly
speaking-
and
this
is
a
generalization
that
I'm
not
a
scheme
expert,
so
feel
free
to
correct
me.
But
one
of
the
things
that
you
have
in
common
lisp
enclosure
are
first
class
packages
or
name
spaces,
so
that
lisp
image
you're
building
up
it's
introspectible
and
there
are
well
there
are.
You
know,
public
entry
points
into
the
database
of
information
contained
in
the
lisp
image
and
that's
accessible
from
the
reppl
using
various
functions
for
looking
at
documentation.
B
B
If
you
it
would
be
like,
if
you
throw
an
exception
in
java
and
instead
of
the
stack,
unwinding
and
you're
seeing
a
stack
trace,
execution
can
actually
be
suspended
in
common
lisp,
and
you
can
have
a
reply
at
the
place
where
the
exception
was
thrown.
So
you
can
inspect
local
variables.
You
can
write
new
code
that
gets
run
in
that
same
stack
context.
B
Which
is
pretty
cool,
it's
pretty
cool
and
it's,
I
think
it's
still
unique
among
languages.
Closure
does
not
have
that.
You
know
we
have
java
stacked.
We
have
java
exception
semantics
and
java
stack
traces,
and
at
one
point
when
I
was
learning
common
list,
I
reflected
on
why
I
didn't
really
even
once.
I
knew
about
the
common
lisp
way,
why
I
didn't
miss
it
in
closure,
and
the
best
I
could
come
to
an
explanation
was
the
most
of
the
closure
programs.
B
B
I
wasn't
even
born
when
people
are
programming
this
way,
but
my
perception
is
that
one
thing
that
has
changed
about
the
kinds
of
programming
most
people
do
is
that
we
generally
have
databases
now
for
managing
transactional
data,
but
that
hasn't
always
been
the
case
and
when
common
lisp
first
came
into
existence,
it
was
really
important
to
be
able
to
do
that
kind
of
very,
very
surgical
debugging,
because
you
might
lose
data.
If
you
didn't
have
an
opportunity
to
do
it
right,
then-
and
actually
you
can
see
this
in
action,
there's
a
youtube.
B
B
D
Maybe
I'll
just
offer
a
comment
adam,
I
think,
on
your
last
slide,
you
had
a
list
of
things
that
you
might
talk
about.
One
was
the
symbols
and
the
and
the
package
system
when
I
so
so.
I
had
a
background
in
common
lisp
when
I
was
learning
closure
and
I
found
the
way
symbols
worked
in
closure
to
be.
I
guess
I
came
in
with
a
bunch
of
assumptions
that
just
went
weren't
true
and
I
it
took
me
a
while
to
really
understand
how
how
common
this
sorry,
how
closure
symbols
worked.
D
B
Yes,
two
thoughts.
So
first
of
all,
I
don't
know
about
you
all,
but
when
I
was
learning
closure,
the
ns
macro
took
me
a
really
long
time
to
become
comfortable
with,
and
I
think
I
was
thinking
of
it
like
you
know:
python's
import,
syntax.
I
took
the
syntax
for
the
thing
which
you
know
as
you
learn
lisp.
You
realize
that
the
syntax
is
the
front
end
for
the
thing
and
if
you
really
want
to
understand
the
thing
you
have
to
go
beneath
the
syntax
but
yeah.
B
And
I
think,
based
on
what
I've
read
about
the
common
list
package
system,
I
think
there
are
a
lot
of
the
same.
At
least
people
who
are
learning
seem
to
have
some
of
the
same
problems,
but
anyway,
that's
that's
sort
of
neither
here
nor
there
that
doesn't
address
your
question
exactly
yeah
the
big
difference.
B
B
So
you
can
establish
a
mapping
between
a
packet
between
a
symbol
that
doesn't
have
a
package
and
a
package,
and
you
can
install
that
in
your
package
if
that
makes
sense,
but
the
symbols
themselves
are
not
installed
in
particular
packages.
The
the
package
environment
is
not
mutated
by
the
reader
and
that,
if
in
the
closure
rationale,
I
think
this
is
actually
mentioned
specifically
rich
says
something
to
be
effective.
I
don't
like
that.
The
reader
necessitates
mutation
because
you
know
he
believes
strongly
in
data
and
he
believes
strongly
in
the
idea
that
data
should
be
require.
B
Follow-On
thought
is
that
mutation
is
contextual,
because
if
you
have
a
functional
programming,
language
and
you're
doing
a
bunch
of
mutation
inside
a
function
and
nobody
outside
of
the
function
knows
then
do
we
really
care
and
closure.
That
idea
is
delivered
with
transients,
but
I
think
it
illustrates
a
more
broad
point
which
is
you
know.
Mutation
is
just
a
matter
of
perspective
because
when
you
run
a
program,
you're
mutating
the
call
stack,
you're
mutating
pixels
on
the
screen.
B
B
A
A
A
B
B
But
you
know
there's
a
lot
of
dimensions
of
interpretation
in
the
programming
language,
obviously,
and
if
you
add
other
types
of
atomic
values,
you
know
atoms
to
this
discussion,
then
for
me,
this
point
becomes
less
important.
So,
for
example,
is
closure
a
list
one?
Let's
think
about
this.
What
does
a
symbol
mean?
B
A
lot
of
people
pass
that
a
keyword
to
indicate
you
know
to
identify
the
condition
or
the
exception
they're
throwing
so
anytime
people
use
those
identifiers,
they've
created
their
own
global
naming
scheme
with
their
own
interpretat.
You
know
their
own
semantics
there,
so
that's
kind
of
a
dimension
of
naming
there
is
the.
B
There
is
the
namespace
of
reader
macros
enclosure,
they're
data
literals,
but
any
package
that
you
load
into
the
classpath
enclosure
has
it
can
provide
a
datareaders.clj
file
which
will
automatically
get
executed
and
contribute
a
data
literal
syntax
to
closure
and
those
have
an
opportunity
to
conflict.
So
I
think
we're
at
a
lisp
four
now.
B
So
my
point
with
this
is
that,
in
my
view
now
this
is
actually
a
really
small
and
maybe
even
not
very
important
distinction
between
these
two
things,
because
the
same
is
true
for
common
lisp.
If
you
go
and
catalog
all
the
different
things
that
can
be
named
globally
or
interfere
with
each
other
at
a
global
level,
it's
a
lot
of
stuff
and
I'm
not
sure
you
can
get
away
from
having
a
lot
of
stuff.
I
think
you're
just
going
to
have
a
lot
of
stuff.
B
For
my
part,
I
I
think
it.
The
lisp2
thing
contributes
to
the
old-timey
feel
which
I
enjoy.
I
haven't
written
enough
lisp
code
to
leverage
any
of
the
purported
benefits.
I
don't
think,
but
it
certainly
I
don't
in
the
little
list
code
I've
written
it.
I
don't
feel
like
it's
gotten
in
my
way,
but
that
that
is
just
my
opinion.
A
Right,
which
is
interesting
because
I
I
can-
I
can
testify
myself
that
the
same
way
that
you
were
drawn
to
common
lisp
in
in
this
kind
of
oh
this
looks
interesting.
Let's
have
a
closer
look
at
it.
I
I
have
this
kind
of
hobby,
where
I
study
scheme,
implementations
or
at
least
try
to
follow,
what's
happening
in
the
skin
world
and
trying
trying
some
implementations
on
and
trying
to
understand
how
it
works
and
understanding
the
standard
systems.
A
Serif
is
and
stuff
like
that,
and
in
that
respect,
the
the
the
major
maybe
difference
except,
of
course
the
least
is
two
thing:
is
that
scheme
is
evolving
because
the
standard
itself,
it
is
also
a
standard
like
common
list,
but
it's
another
that
is
that
is
that
has
revisions
and
which
is
ongoing
with
the
committee.
That
is
being
so.
Maybe
maybe
you
want
to
to
address
this
this
aspect,
just
just
just
a
thought
like
scheme
is
going
to
change
commonly,
is
not
so
that's
interesting
right.
B
Well,
it's
interesting
and
strictly
speaking,
is
true,
but
I
think
the
implementations
of
common
lisp
have
continued
to
evolve
and
because
of
the
culture
of
platform
interop
the
culture
rather
of
implementation,
interop
like,
for
example,
there's
a
there's
a
fairly
recent
feature
in
a
common
list
called
package,
local
nicknames
and
that's
enclosure.
We've
had
that
from
the
beginning
and
that's
the
ability
to
give
pac
namespaces
aliases.
B
B
But
in
practice
like
you,
can
pretty
much
count
on
an
existing,
and
you
know
that's
at
odds
with
the
spirit
of
the
standard,
because
that
is
strictly
speaking,
that
is
not
conformant,
you
know
or
not,
or
rather
not.
There
there's
particular
terms
that
people
in
commonlist
use
when
they
refer
to
different
features
and
whether
or
not
they're
implementation,
dependent
or
conformant,
but
that
adds
gray
area,
to
say
the
least.
You
know
it
complicates
the
situation,
but
another
other
thing
that
comes
to
mind
is
there's
a
there.
B
Well,
there
are
a
few
things:
there's
a
sequence
of
protocol
in
a
you,
know:
non-standard,
but
universally
supported
sequence
protocol
in
common
lisp,
so
which
is
to
say
that
yeah
street,
strictly
speaking,
common
list
for
standard,
is
unlikely
to
change
anytime
soon.
But
there
is
movement,
there
is
activity,
and
you
know
the
culture
is
what
makes
it
tolerable
to
me.
It's
not
like
other
languages
where
they're
changing,
or
packages
or
libraries,
where
they're
changing
fundamental
things
on
on
a
whim.
A
D
Hi
yeah,
so
it's
tough
to
remember
a
little
bit
because
it's
about
it's
coming
up
for
10
years
ago.
I
suppose
I'm
trying
to
think
if
I
can
say
an
interesting
intelligence.
I
think
it
probably
took
me
a
good
while
maybe
it's
probably
a
gradual
thing,
but
there
were
definitely
things
I
tripped
up
on
and
and-
and
I
mentioned
the
thing
with-
with
symbols
and
and
packages.
D
Now
I'd
have
to
think
to
kind
of
tie
that
back
into
to
what
we
were
talking
about
earlier,
but
I
think
I
think
when,
when
you
get
the
thing
with
the
symbols
being
interned
at
read
time,
I
think
I'd
really
have
to
think
about
this.
But
I
think
that
draws
you
into
getting
that's
one
of
the
things
that
makes
it
harder
to
write
hygienic
macros
in
common
lips.
I
think
and
so
closure's
approach.
B
Yes,
second
speak
to
that
relationship,
cool
again,
yeah,
it's!
It
is
a
really
complicated
part
of
both
languages.
So
I
could
be
wrong
but
yeah
in
common
list.
There
is
a
function
and
syntax
for
making
what
they
call
uninterned
symbols
and
so
like
the
gen
sim
function
in
common
list
returns.
One
of
these
and
that's
a
that,
gives
you
an
object,
that
is
a
symbol
type
with
a
distinct
name
and
a
distinct
identity.
B
So
it's
not
eq
or
identical
question
mark
to
any
any
other
symbol
in
the
system.
If
once
you
get
it
back
from
gen
sim,
and
so
those
identifiers
can
be
used
in
code
that
you're
generating
in
a
macro
for
things
like
the
name
of
something
in
a
let
binding
and
that's
the
I
think-
maybe
that's
what
you
might
be
getting
at
simon,
because
that's
because
that
thing
does
not
inhabit
a
package
regardless
of
the
package.
B
In
effect,
when
the
macro
is
called
the
identity
of
that
symbol
is
guaranteed
not
to
conflict
with
the
identity
of
any
symbols,
either
in
the
caller's
package
or
anywhere
else
in
the
in
the
system.
And
we
don't.
We
don't
need
to
go
out
of
our
way
to
do
that
in
closure,
because
the
symbols
naturally
are
uninterned.
C
C
If
you
have
this
one,
then
it's
both
the
operators
and
the
values
and
they're
all
in
the
name
name,
space,
the
variables
and
the
and
the
operators
are
all
in
the
name,
same
name
space.
So,
for
example,
you
can't
suppose
a
much
more
possibility
for
conflict
yeah,
and
so
you
need
to
to
to
be
very
careful
about
gendering
anything
and
so
what?
C
Then
there
there's
the
autogensen
so
there's
this
is
automatically
expanded
to
a
gent
name.
So
in
effect,
there's
a
little
number
yeah
increasing
number
it
attached
to
it.
So
it's
always
a
different
symbol,
and
you
get
all
this
hygiene
from
that.
So
it's
it's
much
easier
and
closer
to
write
a
really
hygienic
macro
yeah.
So
so
you
get
all
this
accidental
shadowing
out
of
the
out
of
the
way
and
in
communism
you
have
to
be
a
bit
more
explicit
about
it
yeah.
C
My
keys
function
is
gone
and
that's
something
that
took
me
up
and
when
I
came
to
closure
it
was
always:
oh,
I
can't
use
keys,
it's
it's
a
function
in
the
in
the
chord
yeah.
I
can't
I
can't
use
ends
because
it's
it's
a
operator
in
core.
It's
I
want
to
destruction,
numbers
n
and
ends.
Oh
damn
wells,
no,
you
can't
say
vowels,
you
have
to
say:
values
is
okay.
Yeah
values
is
okay,
yeah,
so
it's
it's.
C
I
I
feel
more
restricted
by
it
being
a
lisp
one.
On
the
other
hand,
it's
of
course
always
this
thing.
This
funny
thing
about:
okay,
if
I
use
higher
order
functions
and
I
want
to
pass
a
function,
then
I
have
to
reference
it
from
the
function
here.
So
I
have
to
put
this
hash
science
quote
before
it
to
pass
it
and
it's
always
a
bit
more
hassle
a
bit
more.
A
Didn't
know
the
point
that
for
me
in
terms
aesthetically
high
order
functions,
and
at
least
one
is
just
this
is
just
elegance
embodied
for
me.
I
mean
to
be
able
to
say
you
know
map
and
then
the
name
of
the
function
and
your
collection,
that's
without
going
through
the
to
this
yeah.
But
that's
that's,
maybe
just
an
aesthetic
point
and
really
not
not
really
important.
F
B
A
B
Okay,
so
I
don't
use
list
books
myself
for
anything
I'll,
occasionally
open
it
up
to
poke
around
test
things
out,
but
I'm
glad
that
it
exists
and
what
it
is
is
it
is
a
commercial
lisp,
implementation
and
ide
and
someday.
I
will
buy
a
license
to
it
because
I
think
it's
neat
and
I
want
to
support
the
work,
but
the
license
costs
like
three
thousand
dollars,
and
I
want
other
things
first.
So
it's
not
going
to
happen
anytime
soon,
but
you
can
download
this
thing
for
free
and
run
it.
B
B
You
know
ui
support
for
the
stuff
in
common
list,
so
we
can
do
you
know
I've
got
a
what's
called
a
listener
over
here.
A
listener
is
a
is
a
term
you'll
see
used
in
the
common
list
world
to
refer
to
a
rebel,
but
usually
the
kinds
of
rebels
you
can
expect
in
common
lists
are
more
featureful
than
what
we're
used
to
in
the
closure
world
and
I
think
that's
just
again
part
of
being
the
platform.
B
B
B
B
B
B
B
B
B
This
is
back
to
a
big,
significant
difference
in
syntax,
which
is
in
closure.
You
can
attach
metadata
to
almost
any
cl
anything.
That's
readable,
there's
some
subtlety
there
into
whether
the
metadata
is
copied.
If
you
add
something
to
that
like
there's
a
concept
of
losing
metadata
enclosure
like
if
you
have
a
vector
with
metadata
on
it,
and
then
you
conjure
something
onto
that
vector
is
the
vector.
A
B
There
is
no
general
metadata
thing,
there's
not
syntax
for
it,
but
symbols
are
mutable
in
the
sense
that
they
carry
a
property
list
which
is
a
set
of
associations
between
other
symbols
and
values,
and
they
also
have
what
are
traditionally
called
the
function
and
value
cells,
and
these
are
basically
slots
or
fields
on
the
symbol
that
can
either
carry
a
value
at
some
in
some
environment
or
a
function
value
and
by
default.
If
you
just
refer
to
a
symbol
without
any
qualification,
it's
the
value
cell
that
is
going
to
be
accessed,
and
so
that's
effectively.
B
How
lisp
ii
is
implemented
is
its
admission
of
the
symbol
as
a
mutable
container,
and
then
it's
the
admission
of
a
syntactic
default
to
interpret
occurrences
of
symbols
as
accesses
of
their
values
and
not
necessarily
accesses
of
their
function,
values
right.
So
in
this
function
we
have
this
parameter
list
lexically.
It
takes
the
value
of
the
parameter.
That's
activated
on
the
stack
when
it's
activated
on
the
stack
and
then
so
now
list
is
a
variable.
But
look
on
this.
I
don't
have
line
numbers
here.
B
B
B
So
you
can
see
these
two
return,
the
same
object,
and
that's
because
this
hash
quote
is
a
reader
macro
that
basically
expands
to
this.
You
can
think
of
it
as
expanding
to
that
yep.
So
this
occurrence
of
list
is
not
a
function.
Call
we
could
say
that's
the
symbol
appears
in
value
position.
Maybe,
but
you
could
say
whether
or
not
we're
accessing
the
symbol
or
the
function
is.
You
know,
syntactically,
dependent
and
lexically
dependent.
B
B
So
there's
a
lot
of
ways
to
do
this
and
they're
all
different
variations
of.
You
know
this
general
idea
that
we
have
a
symbol
that
can
have
multiple
meanings
and
there
are
different
contexts
in
which
the
meanings
will
be
inferred
automatically,
and
but
we
also
have
tools
to
make
explicit
references
to
aspects
of
this
symbol.
B
So
yeah
I
mean
not
very
savory
honestly
from
a
closure
perspective
like
these
are
all
the
details
that
closure
helps
us
avoid,
but
at
the
same
time
there
is
some
value
in
them
existing
because
you
have
you
have
more
flexibility
along
certain
certain
dimensions.
Foremost
among
them.
Is
this
lac
the
fact
that
this
function
variable
does
not
shadow
the
list
function
and
so
honestly,
like
I'm
kind
of
refreshed
because,
like
in
closure,
you
know
you
do
things
like
you
have
to
make
you
have
to
you
know
you
don't
want
to.
A
B
B
B
B
In
lisp
they
refer
to
the
set
of
functions
and
symbols
relevant
to
some
concept,
as
that
concept's
dictionary,
which
I
like.
So
this
is
the
packages
dictionary
and
you
can
see,
there's
a
set
of
symbols
and
each
symbol
is
defined
either
by
its
function,
whether
it's
a
function,
a
class
macro
variable.
B
B
B
Normally,
in
a
programming
language,
there's
conceptually
a
register
that
a
return
value
is
put
into
and
a
normal
programming
language
maintains
one
such
register,
but
common
lisp
exposes
some
performance
related
features,
and
one
of
them
is
this
idea
that
a
function
can
return
multiple
values
and
it's
based
on
the
observation
that
a
function
can
box
up
multiple
values
into
a
list,
for
example
or
vector
enclosures
case.
But
that
means
that
you
need
to
allocate
a
fresh
vector.
That's
immediately
going
to
be
thrown
away
by
the
consumer.
It's
going
to
be
destructured
and
then
gc'd.
B
So
if
you
just
have,
if
you
have
a
concept
of
multiple
values,
then
you
can
maintain
a
set
of
registers
say
like
a
hundred
and
instead
of
allocating
a
new
vector
when
somebody
wants
to
return
multiple
things,
you
just
return
a
special
value.
That
indicates
there
are
multiple
values
involved
and
then
you
could
pass
like
an
offset
into
the
registers
or
something,
but
at
the
end
of
the
day,
there's
no
allocation
happening
necessarily
so
no
pressure
on
the
gc
no
allocation
and
the
caller
has
very
fast
access
to
the
values
returned.
B
This
is
somewhat
famously
not
in
closure.
Closure
doesn't
have
multiple
values.
Probably
the
biggest
reason
is
because
java
doesn't
have
multiple
values
and
you
can
imagine
how
crazy
that
would
be
to
try
and
do,
but
closure
actually
defended
his
decision,
but
richie
defended
his
decision
in
a
separate
way.
B
In
practice,
at
least
that
was
rich's
argument,
but
anyway,
in
case
rich
is
wrong.
We
have
multiple
values
in
common
lisp
and
which
is
what
we're
seeing
here
so
find
symbols
returning
two
values,
symbol
plus
and
then
inherited,
which
is
a
keyword.
That
means
it's
present
in
the
package
as
an
in.
Oh,
yes,
it's
inherited
through
use
package.
B
B
A
B
In
common
enclosure,
we
have
lazy
sequences,
we
have
recursion,
we
have
the
loop
recur
construct
for
doing
iteration
and
those
are
all
functional
in
the
sense
that
they
don't
imply,
or
they
don't
necessitate
mutation
of
anything.
So
you
don't
need
to
name
something
in
order
to
mutate
it
so
that
you
can
add
something
to
it.
Lupercur
is
is
like
probably,
closure
is
most.
A
B
B
Yeah,
so
I
think
I
it's
not
clear
to
me
exactly
what's
going
on
here,
but
there's
multiple
keywords
supported
in
loop,
four
creates
the
bounds
of
an
iteration,
and
then,
when
is
a
conditional
inside
the
body
do
lets.
You
do
a
side
effect
at
that
point
in
the
iteration
and
then
collect
will
contribute
a
value
to
an
implicit
set
of
or
an
implicit
list
of
values.
You're
accumulating.
B
B
You
there
is
the
value
of
this
deliver
is,
is
this
doesn't
rely
on
any
runtime
abstractions,
so
there's
no
need
for
a
lazy
sequence.
Abstraction
loop
expands
into
the
lowest
level
possible
common
lisp
code
like
basically
go
to
is
what
it
expands
into:
go:
to's
with
mutating
and
cutters
and
stuff
like
that.
B
So
it's
high
level
in
the
sense
that
it
gives
you
a
high
level
language
to
work
with
that
looks
pretty
much
like
python
or
something,
but
it's
low
level
in
the
sense
that
it
produces
code.
That
depends
on
only
commonly
lowest
level,
runtime
affordances
and
that's
a
trade-off.
Obviously
you
know
this
doesn't
participate
in
a
system
of
runtime
constructs
or
distractions.
B
The
way
sequences
enclosure
do
but
at
the
same
time
you're
not
paying
for
such
a
system,
so
yeah
just
kind
of
conceptually
interesting
thing
that
occupies
a
point
in
a
design
space
that
I
don't
think
we
use
or
are
supposed
to
use
enclosure,
because
we
have
lazy
sequences
and
recursion
and
so
forth.
If
that
makes
sense,.
B
Well,
I
I
enjoyed
working
with
r
and
I
think
r
is
I
mean
by
mccarthy's
definition.
R
is
a
lisp,
I
mean
it
is
written
in
data
structures
that
you
have
accessible
at
runtime
and
it's
an
online
compiler
and
everything
I
think
r.
So
I
did
not
find
myself
getting
obsessed
with
it.
The
way
that
I
am
obsessed
with
common
lisp,
I
don't
know
why
that
is.
I
don't
know
if
it's,
because
I'm
just
immune
to
being
obsessed
with
things
that
are
popular,
I
I
don't
know
I.
B
B
B
There
is
a
very
interesting
thing
about
r
that
is
unique
to
r
among
lisps
and
among
all
languages
that
I've
ever
known,
which
is
that
r
has
f
expressions
fespers,
so
r
is
a
call
by
need
language
and
lazy
evaluation
and
ours.
So
you
know,
common
lisp
has
first
class
a
lot
of
things
that
come
unless
our
first
class,
but
one
thing,
that's
not
for
first
class
is
the
lexical
environment,
which
is
that
inside
a
function,
you
don't
have
access
to
that
function's
lexical
scope.
B
B
You
can
do
the
moral
equivalent
of
after
that
function
has
been
defined,
go
in
there
mutate
its
environ
internal
environment,
which
you
know
again
pretty
egregious
from
the
closure
functional
perspective.
I
think
that's
possible,
but
it
also
gives
you
a
level
of
meta
programming
capability.
That
is,
I
think,
unparalleled
except
by
other
lips,
so
very,
very
interesting
language,
and
I
think
you
know
the
the
reason
that
f
expert
thing
did
exist
in
lisps
for
decades
before
common
list,
and
I
think
it
was
thrown
out
for
performance
reasons.
B
Long
before
common
list
came
to
be
standardized,
but
one
thing
that
this
is
kind
of.
Another
observation
I
have
is
that
there's
a
concept
of
computer
performance
and
there's
a
concept
of
human
performance
and
it's
okay
for
something
to
have
very
poor
computer
performance
if
it
unlocks
some
kind
of
human
performance.
Because,
yes,
our
relatives
are
things
kind
of
slow
because
of
this
first
class
environments
thing,
but
you
can
use
it
to
make
a
really
nice
dsl
on
top
of
something
that's
written
in
c
plus,
for
example.
B
So
it
gives
you
a
testbed
in
which
to
prototype,
constructs
and
semantics
that
are
valuable
to
people
and
then
later,
if
at
all,
you
have
a
layer
on
which
you
can
make
those
things
more
efficient,
and
it
makes
me
regret
that
not
adding
r
to
my
little
platform
and
abstraction
level
chart
like
that's
sort
of
a
bar
chart.
Really,
you
know
r
sits
even
higher
than
closure,
maybe
on
the
on
or
well
I
guess
it's
a
it's
complicated.
B
I
have
to
think
about
that
more,
but
it
too
offers
semantic
affordances
at
a
very
high
level,
and
there
are
trade-offs
with
the
ones
it
does
offer,
and
it
occupies
a
unique,
like
closure
occupies
a
point
in
the
design
space
that
has
benefits
for
people
who
do
a
certain
kind
of
thing
or
like
a
certain
kind
of
thing,
yeah.
I
still
really
like
it,
and
I
I
enjoyed
the
process
of
learning
it.
It
also
it
also
light.
Closure
is
significantly
influenced
by
common
lisp,
which
is.