Mercurial > hg > BCS
comparison CR_preface.txt @ 28:b741a43258af
merge
| author | Henry S Thompson <ht@inf.ed.ac.uk> |
|---|---|
| date | Sat, 02 Nov 2024 22:18:57 +0000 |
| parents | 7688b405c09f |
| children | b23d34ac6765 |
comparison
equal
deleted
inserted
replaced
| 27:3113ddaf1829 | 28:b741a43258af |
|---|---|
| 148 [What about Phi vs. Psi, 'full [?] procedural consequence'] | 148 [What about Phi vs. Psi, 'full [?] procedural consequence'] |
| 149 | 149 |
| 150 If you are interested in _real_ semantics, ... what's a poor boy to | 150 If you are interested in _real_ semantics, ... what's a poor boy to |
| 151 do? | 151 do? |
| 152 | 152 |
| 153 | 153 Semantical issues are non-the-less still in the drivers seat---we are |
| 154 happy when (+ 2 3) yields 5 because of are awareness of them. | |
| 154 | 155 |
| 156 Tracing the fate of those issues, and the vocabulary, are stories that | |
| 157 need told. | |
| 158 | |
| 159 "Things have changed and now we do things differently." What's | |
| 160 changed and how is it different? | |
| 161 | |
| 162 Answer - the SDK would [be wanted to] track reference relations, not | |
| 163 just implementation relations. But that's so complicated that it | |
| 164 couldn't possibly work. Suppose you're defining a type [theta], a | |
| 165 vector type accessible via theta and rho or x and y. Setting x and | |
| 166 rho contstrains. Compiler can ignore this, and just keep one or the | |
| 167 other, but the type system should 'know' the relationship of both, and | |
| 168 could therefore track a lot more about a program using vectors than it | |
| 169 does at the moment. | |
| 170 | |
| 171 [HST poses a story about astronomers and air traffic controllers?] | |
| 172 | |
| 173 Problem solving is not the motiviation, articulating what is the case | |
| 174 is, to say what's true. | |
| 175 | |
| 176 The effect of PSI is everything that happens, and the PHI relations | |
| 177 are what matters. All constraints, norms, requirements are expressed | |
| 178 in terms of PHI stuff. | |
| 179 | |
| 180 What does this book say that requirements engineering etc. haven't | |
| 181 already | |
| 182 | |
| 183 [HST what about program correctness, specification languages ? etc.] | |
| 184 | |
| 185 [Chapter 7?] | |
| 155 ------------ | 186 ------------ |
| 156 Foundations of/Philosophy of Computation | 187 Foundations of/Philosophy of Computation |
| 157 | 188 |
| 158 Lisp was 'broken', 2-Lisp was a flawed attempt to fix it, 3-Lisp takes | 189 Lisp was 'broken', 2-Lisp was a flawed attempt to fix it, 3-Lisp takes |
| 159 us in to new territory. | 190 us in to new territory. |
| 160 | 191 |
| 161 Don't think you have to be a specialist to read this book. | 192 Don't think you have to be a specialist to read this book. |
| 162 | 193 |
| 163 Effective vs non-Effective is actually new: at the book boundaries, | 194 Effective vs non-Effective is actually new: at the book boundaries, |
| 164 project onto the effective [?] | 195 project onto the effective [? - it's not that everything is |
| 196 term-rewriting, it's more like ]. | |
| 165 | 197 |
| 166 | 198 |
| 167 | 199 |