[HN Gopher] Experience with an Uncommon Lisp (1986) [pdf]
___________________________________________________________________
Experience with an Uncommon Lisp (1986) [pdf]
Author : mepian
Score : 81 points
Date : 2024-03-18 01:26 UTC (21 hours ago)
(HTM) web link (dl.acm.org)
(TXT) w3m dump (dl.acm.org)
| andsoitis wrote:
| _When our development process began, there was ferment in the
| Lisp community. One of the more important events relat- ing to
| the design of the new IBM Research Lisp system was the
| publication of the Bobrow and Wegbreit paper [Bobrow and Wegbreit
| 1973] proposing a new control structure, the spaghetti stack. We
| immediately seized on the elegance and flexibilityof this idea._
|
| _A key component of this model of computation was the con- cept
| of the saved state, a data object which captured both the set of
| current variable bindings (the environment) and the current call
| chain and point of execution (the control). We have used saved
| states (state descriptors) extensively, both as a form of
| continuation and as a component of closures._
| antonvs wrote:
| > there was ferment in the Lisp community.
|
| This is the same as saying "the Lisp community existed."
| lisper wrote:
| No, it is saying that the community was coming up with a lot
| of remarkably good ideas.
| jksmith wrote:
| An elegant weapon for a more civilized age without the C
| language legacy.
| fargle wrote:
| that's like saying the 18th century was more "civilized"
| because we settled squabbles with dueling pistols. people
| are still people and we are just about as civilized today
| as we ever were. which isn't saying much.
|
| the analogy holds for programming languages as well as it
| does for anything else involving people.
| jksmith wrote:
| Just a fanciful quote with some license. But one might
| argue the defn of civilization as applied to general
| programming with so much of it being commodity
| programming these days. Additionally, I believe an
| argument could be made that the long-term tyranny of the
| C bubble has actually retarded the advancement of the
| art.
| MonkeyClub wrote:
| I think GP missed the reference, https://xkcd.com/297
| digdugdirk wrote:
| That sounds really interesting, in a way I cannot begin to
| comprehend.
|
| Can someone please translate into more common vernacular?
| JimmyRuska wrote:
| Sounds like an implementation for how to managing scopes
| using stack frames with some state machine like elements to
| it
| volemo wrote:
| > Can someone please translate into more common vernacular?
|
| If I were to read that, it'd be common lisp. :D
| rurban wrote:
| setjmp/longjmp if the states were not on the stack. (of
| course nobody would be so crazy to actually use longjmp, just
| properly save the stack state: env and control)
|
| if jumping back into inner states (i.e. out of control
| stacks), the stack frame needs to be preserved also. as in
| call/cc later.
| ustad wrote:
| Could not find the actual paper but the figures look cool:
| https://www.semanticscholar.org/paper/A-model-and-stack-impl...
| mainland wrote:
| Here is a copy of what looks to be the original report:
| <https://wellcomecollection.org/works/seuuc6a5>
|
| Here is a link to the version published with the ACM:
| <https://dl.acm.org/doi/10.1145/362375.362379>
| _delirium wrote:
| Is that kind of like a reified version of Scheme's call/cc?
| pmcjones wrote:
| More on YKTLISP (and its predecessor) here:
|
| https://www.softwarepreservation.org/projects/LISP/ibm_lisp_...
| lispm wrote:
| Looks like this was an application: YES/MVS
| https://cdn.aaai.org/AAAI/1984/AAAI84-032.pdf
|
| About Lispedit: https://dl.acm.org/doi/10.1145/1006142.1006164
| pmcjones wrote:
| Thanks; I added citations for both of those.
| lispm wrote:
| "https://dl.acm.org/doi/pdf/10.1145/1006147.1006176" "LEVEL
| LANGUAGE DEBUGGING WITH A COMPILER" -> about LispEdit
| pmcjones wrote:
| Thanks again; added that (and fixed up previous edit fat-
| fingering).
| pjmlp wrote:
| Love the technical stuff on the paper related to compiler
| implementation, inline Assembly and debugging capabilities.
___________________________________________________________________
(page generated 2024-03-18 23:02 UTC)