Skip to content

Commit f44fea4

Browse files
masintermasinter
committed
deploy: d35eb88 
1 parent c4379f9 commit f44fea4

File tree

2 files changed

+89
-38
lines changed

2 files changed

+89
-38
lines changed

‎data/bibliography.json

+77-22
Original file line numberDiff line numberDiff line change
@@ -22852,7 +22852,7 @@
2285222852
]
2285322853
},
2285422854
"key": "HNE2HXZ8",
22855-
"version": 7257,
22855+
"version": 7259,
2285622856
"itemType": "journalArticle",
2285722857
"creators": [
2285822858
{
@@ -22879,10 +22879,10 @@
2287922879
"extra": "",
2288022880
"tags": [
2288122881
{
22882-
"tag": "should this be in here?"
22882+
"tag": "Reviewed by SHFT - UofA (Eleanor Young)"
2288322883
},
2288422884
{
22885-
"tag": "sz"
22885+
"tag": "should this be in here?"
2288622886
}
2288722887
],
2288822888
"collections": [
@@ -22892,7 +22892,7 @@
2289222892
"dc:replaces": "http://zotero.org/groups/2914042/items/ASDUNVUX"
2289322893
},
2289422894
"dateAdded": "2021-04-25T19:54:45Z",
22895-
"dateModified": "2024-09-02T02:26:29Z"
22895+
"dateModified": "2024-09-02T03:50:10Z"
2289622896
},
2289722897
{
2289822898
"target": "GLIMJDIW",
@@ -24110,6 +24110,7 @@
2411024110
"publisher-place": "USA",
2411124111
"page": "409–426",
2411224112
"event-place": "USA",
24113+
"abstract": "In this chapter, some of the events of LISP development are protocolled. Step by step, the implementers became independent of McCarthy. In 1962 the internal drive was stronger than McCarthy's proposals. The results are somehow ambiguous.",
2411324114
"ISBN": "978-0-12-450010-5",
2411424115
"author": [
2411524116
{
@@ -24136,7 +24137,7 @@
2413624137
]
2413724138
},
2413824139
"key": "JEBHSFXU",
24139-
"version": 2154,
24140+
"version": 7273,
2414024141
"itemType": "bookSection",
2414124142
"creators": [
2414224143
{
@@ -24166,15 +24167,27 @@
2416624167
"extra": "",
2416724168
"tags": [
2416824169
{
24169-
"tag": "sz"
24170+
"tag": "LISP"
24171+
},
24172+
{
24173+
"tag": "Programming Languages"
24174+
},
24175+
{
24176+
"tag": "Reviewed by SHFT - UofA (Eleanor Young)"
24177+
},
24178+
{
24179+
"tag": "early programming"
24180+
},
24181+
{
24182+
"tag": "list processing"
2417024183
}
2417124184
],
2417224185
"collections": [
2417324186
"MV55NAER"
2417424187
],
2417524188
"relations": {},
2417624189
"dateAdded": "2021-06-02T17:31:32Z",
24177-
"dateModified": "2021-07-26T02:24:15Z"
24190+
"dateModified": "2024-09-02T04:09:04Z"
2417824191
},
2417924192
{
2418024193
"target": "KXVS2RBT",
@@ -25633,7 +25646,7 @@
2563325646
]
2563425647
},
2563525648
"key": "9IIYFLFK",
25636-
"version": 2047,
25649+
"version": 7277,
2563725650
"itemType": "journalArticle",
2563825651
"creators": [
2563925652
{
@@ -25659,15 +25672,21 @@
2565925672
"extra": "",
2566025673
"tags": [
2566125674
{
25662-
"tag": "sz"
25675+
"tag": "LISP"
25676+
},
25677+
{
25678+
"tag": "Reviewed by SHFT - UofA (Eleanor Young)"
25679+
},
25680+
{
25681+
"tag": "computer-aided design"
2566325682
}
2566425683
],
2566525684
"collections": [
2566625685
"MV55NAER"
2566725686
],
2566825687
"relations": {},
2566925688
"dateAdded": "2021-06-02T17:55:44Z",
25670-
"dateModified": "2021-06-02T17:56:09Z"
25689+
"dateModified": "2024-09-02T04:10:11Z"
2567125690
},
2567225691
{
2567325692
"target": "JSW29WAW",
@@ -25711,7 +25730,7 @@
2571125730
]
2571225731
},
2571325732
"key": "JSW29WAW",
25714-
"version": 1998,
25733+
"version": 7287,
2571525734
"itemType": "journalArticle",
2571625735
"creators": [
2571725736
{
@@ -25743,15 +25762,30 @@
2574325762
"extra": "",
2574425763
"tags": [
2574525764
{
25746-
"tag": "sz"
25765+
"tag": "Interlisp"
25766+
},
25767+
{
25768+
"tag": "LISP"
25769+
},
25770+
{
25771+
"tag": "Programming Languages"
25772+
},
25773+
{
25774+
"tag": "Reviewed by SHFT - UofA (Eleanor Young)"
25775+
},
25776+
{
25777+
"tag": "history"
25778+
},
25779+
{
25780+
"tag": "overview"
2574725781
}
2574825782
],
2574925783
"collections": [
2575025784
"MV55NAER"
2575125785
],
2575225786
"relations": {},
2575325787
"dateAdded": "2021-06-02T17:33:20Z",
25754-
"dateModified": "2021-06-02T17:34:16Z"
25788+
"dateModified": "2024-09-02T04:16:08Z"
2575525789
}
2575625790
],
2575725791
"1994": [
@@ -26866,7 +26900,7 @@
2686626900
]
2686726901
},
2686826902
"key": "HFRDQ97U",
26869-
"version": 1892,
26903+
"version": 7293,
2687026904
"itemType": "journalArticle",
2687126905
"creators": [
2687226906
{
@@ -26893,7 +26927,16 @@
2689326927
"extra": "",
2689426928
"tags": [
2689526929
{
26896-
"tag": "sz"
26930+
"tag": "Common Lisp"
26931+
},
26932+
{
26933+
"tag": "LISP"
26934+
},
26935+
{
26936+
"tag": "Reviewed by SHFT - UofA (Eleanor Young)"
26937+
},
26938+
{
26939+
"tag": "compilers"
2689726940
}
2689826941
],
2689926942
"collections": [
@@ -26902,7 +26945,7 @@
2690226945
],
2690326946
"relations": {},
2690426947
"dateAdded": "2021-04-25T19:54:39Z",
26905-
"dateModified": "2021-06-03T19:16:47Z"
26948+
"dateModified": "2024-09-02T04:22:45Z"
2690626949
},
2690726950
{
2690826951
"target": "5WCSNA4L",
@@ -26913,7 +26956,7 @@
2691326956
"page": "15-24",
2691426957
"volume": "VIII",
2691526958
"issue": "2",
26916-
"abstract": "We consider the impact of introducing the future construct to the multiple value facility in Lisp (Common Lisp and Scheme). A natural way to accommodate this problem is by modifying the implementation of futures so that one future object returns (or resolves to) multiple values instead of one. We first show how a such straightforward modification fails to maintain the crucial characteristic of futures, namely that inserting futures in a functional program does not alter the the result of the computation. A straightforward modification may result in wrong number of values. We then present two methods which we call the mv-context method and the mv-p flag method to overcome this problem. Both of these methods have been tested in TOP-1 Common Lisp, an implementation of a parallel Common Lisp on the TOP-1 multiprocessor workstation. To our knowledge, this problem has never been analyzed nor solved in an implementation of parallel Lisp. We also present the technique of\nfuture chain elimination\nwhich avoids creation of unnecessary futures and processes at run-time, which was inspired by this solution.",
26959+
"abstract": "We consider the impact of introducing the future construct to the multiple value facility in Lisp (Common Lisp and Scheme). A natural way to accommodate this problem is by modifying the implementation of futures so that one future object returns (or resolves to) multiple values instead of one. We first show how a such straightforward modification fails to maintain the crucial characteristic of futures, namely that inserting futures in a functional program does not alter the the result of the computation. A straightforward modification may result in wrong number of values. We then present two methods which we call the mv-context method and the mv-p flag method to overcome this problem. Both of these methods have been tested in TOP-1 Common Lisp, an implementation of a parallel Common Lisp on the TOP-1 multiprocessor workstation. To our knowledge, this problem has never been analyzed nor solved in an implementation of parallel Lisp. We also present the technique of future chain elimination which avoids creation of unnecessary futures and processes at run-time, which was inspired by this solution.",
2691726960
"DOI": "10.1145/224133.224135",
2691826961
"journalAbbreviation": "SIGPLAN Lisp Pointers",
2691926962
"language": "en",
@@ -26946,7 +26989,7 @@
2694626989
]
2694726990
},
2694826991
"key": "5WCSNA4L",
26949-
"version": 1320,
26992+
"version": 7305,
2695026993
"itemType": "journalArticle",
2695126994
"creators": [
2695226995
{
@@ -26977,6 +27020,12 @@
2697727020
"rights": "",
2697827021
"extra": "",
2697927022
"tags": [
27023+
{
27024+
"tag": "Common Lisp"
27025+
},
27026+
{
27027+
"tag": "LISP"
27028+
},
2698027029
{
2698127030
"tag": "sz"
2698227031
}
@@ -26988,7 +27037,7 @@
2698827037
"dc:replaces": "http://zotero.org/groups/2914042/items/YFSCXZRI"
2698927038
},
2699027039
"dateAdded": "2021-04-25T19:54:47Z",
26991-
"dateModified": "2021-05-29T20:37:55Z"
27040+
"dateModified": "2024-09-02T06:05:33Z"
2699227041
},
2699327042
{
2699427043
"target": "QHTE5I6X",
@@ -27028,7 +27077,7 @@
2702827077
]
2702927078
},
2703027079
"key": "QHTE5I6X",
27031-
"version": 1790,
27080+
"version": 7299,
2703227081
"itemType": "journalArticle",
2703327082
"creators": [
2703427083
{
@@ -27055,7 +27104,13 @@
2705527104
"extra": "",
2705627105
"tags": [
2705727106
{
27058-
"tag": "sz"
27107+
"tag": "LISP"
27108+
},
27109+
{
27110+
"tag": "Programming Languages"
27111+
},
27112+
{
27113+
"tag": "Reviewed by SHFT - UofA (Eleanor Young)"
2705927114
}
2706027115
],
2706127116
"collections": [
@@ -27065,7 +27120,7 @@
2706527120
"dc:replaces": "http://zotero.org/groups/2914042/items/H5UXX97B"
2706627121
},
2706727122
"dateAdded": "2021-04-25T19:54:47Z",
27068-
"dateModified": "2021-06-02T18:33:42Z"
27123+
"dateModified": "2024-09-02T04:29:19Z"
2706927124
},
2707027125
{
2707127126
"target": "A52363YK",

‎history/bibliography/index.html

+12-16
Original file line numberDiff line numberDiff line change
@@ -18,7 +18,7 @@
1818
<meta itemprop="name" content="Bibliography">
1919
<meta itemprop="description" content="Interlisp Bibliography (This bibliography is kept in sync with our Zotero collection Library.
2020
Reference 1959 LISP: a programming system for symbolic manipulations McCarthy, John AAA LISP (for LISt Processor) is a programming system for the IBM 704 being developed by the Artificial Intelligence Group at MIT. We are developing it in order to program the Advice Taker which is to be a system for instructing a machine in a combination of declarative and imperative sentences.">
21-
<meta itemprop="wordCount" content="52080">
21+
<meta itemprop="wordCount" content="52117">
2222
<meta name="twitter:card" content="summary">
2323
<meta name="twitter:title" content="Bibliography">
2424
<meta name="twitter:description" content="Interlisp Bibliography (This bibliography is kept in sync with our Zotero collection Library.
@@ -8052,9 +8052,17 @@ <h2 id="interlisp-bibliography">Interlisp Bibliography</h2>
80528052
<div class="authors">
80538053
Stoyan, Herbert
80548054
</div>
8055+
<button type="button" class="abstractExpander left" id="A9296070_JEBHSFXU">AAA</button>
80558056

8056-
8057-
</td>
8057+
<br><div class="abstractContent" id="A9296070_JEBHSFXU_Abs">
8058+
8059+
8060+
8061+
8062+
In this chapter, some of the events of LISP development are protocolled. Step by step, the implementers became independent of McCarthy. In 1962 the internal drive was stronger than McCarthy&#39;s proposals. The results are somehow ambiguous.
8063+
8064+
8065+
</div></td>
80588066
</tr>
80598067

80608068
<tr>
@@ -8687,19 +8695,7 @@ <h2 id="interlisp-bibliography">Interlisp Bibliography</h2>
86878695

86888696

86898697

8690-
We consider the impact of introducing the future construct to the multiple value facility in Lisp (Common Lisp and Scheme). A natural way to accommodate this problem is by modifying the implementation of futures so that one future object returns (or resolves to) multiple values instead of one. We first show how a such straightforward modification fails to maintain the crucial characteristic of futures, namely that inserting futures in a functional program does not alter the the result of the computation. A straightforward modification may result in wrong number of values. We then present two methods which we call the mv-context method and the mv-p flag method to overcome this problem. Both of these methods have been tested in TOP-1 Common Lisp, an implementation of a parallel Common Lisp on the TOP-1 multiprocessor workstation. To our knowledge, this problem has never been analyzed nor solved in an implementation of parallel Lisp. We also present the technique of
8691-
8692-
8693-
8694-
<br>
8695-
8696-
future chain elimination
8697-
8698-
8699-
8700-
<br>
8701-
8702-
which avoids creation of unnecessary futures and processes at run-time, which was inspired by this solution.
8698+
We consider the impact of introducing the future construct to the multiple value facility in Lisp (Common Lisp and Scheme). A natural way to accommodate this problem is by modifying the implementation of futures so that one future object returns (or resolves to) multiple values instead of one. We first show how a such straightforward modification fails to maintain the crucial characteristic of futures, namely that inserting futures in a functional program does not alter the the result of the computation. A straightforward modification may result in wrong number of values. We then present two methods which we call the mv-context method and the mv-p flag method to overcome this problem. Both of these methods have been tested in TOP-1 Common Lisp, an implementation of a parallel Common Lisp on the TOP-1 multiprocessor workstation. To our knowledge, this problem has never been analyzed nor solved in an implementation of parallel Lisp. We also present the technique of future chain elimination which avoids creation of unnecessary futures and processes at run-time, which was inspired by this solution.
87038699

87048700

87058701
</div></td>

0 commit comments

Comments
 (0)