Experience with an Uncommon Lisp (1986) [pdf](dl.acm.org)
dl.acm.org
Experience with an Uncommon Lisp (1986) [pdf]
https://dl.acm.org/doi/pdf/10.1145/319838.319849
24 comments
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
About Lispedit: https://dl.acm.org/doi/10.1145/1006142.1006164
Thanks; I added citations for both of those.
"https://dl.acm.org/doi/pdf/10.1145/1006147.1006176" "LEVEL LANGUAGE DEBUGGING WITH A COMPILER" -> about LispEdit
Thanks again; added that (and fixed up previous edit fat-fingering).
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.
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.
Could not find the actual paper but the figures look cool:
https://www.semanticscholar.org/paper/A-model-and-stack-impl...
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>
Here is a link to the version published with the ACM: <https://dl.acm.org/doi/10.1145/362375.362379>
Is that kind of like a reified version of Scheme's call/cc?
That sounds really interesting, in a way I cannot begin to comprehend.
Can someone please translate into more common vernacular?
Can someone please translate into more common vernacular?
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.
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.
Sounds like an implementation for how to managing scopes using stack frames with some state machine like elements to it
> Can someone please translate into more common vernacular?
If I were to read that, it’d be common lisp. :D
If I were to read that, it’d be common lisp. :D
> there was ferment in the Lisp community.
This is the same as saying "the Lisp community existed."
This is the same as saying "the Lisp community existed."
No, it is saying that the community was coming up with a lot of remarkably good ideas.
The point is that the Lisp community was always in some sort of ferment. The number of Lisps that were developed alone is testament to that.
An elegant weapon for a more civilized age without the C language legacy.
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.
the analogy holds for programming languages as well as it does for anything else involving people.
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.
Love the technical stuff on the paper related to compiler implementation, inline Assembly and debugging capabilities.
https://www.softwarepreservation.org/projects/LISP/ibm_lisp_...