faq.html (30365B)
1 <!DOCTYPE HTML PUBLIC "-//W3C//DTD HTML 4.0 Transitional//EN" "http://www.w3.org/TR/1998/REC-html40-19980424/loose.dtd"> 2 <html lang="en"> 3 <head> 4 <meta http-equiv="Content-Type" content="text/html; charset=utf-8"> 5 <title>PicoLisp FAQ</title> 6 <link rel="stylesheet" href="doc.css" type="text/css"> 7 </head> 8 <body> 9 <a href="mailto:abu@software-lab.de">abu@software-lab.de</a> 10 11 <p align=right> 12 <i>Monk: "If I have nothing in my mind, what shall I do?"</i><br> 13 <i>Joshu: "Throw it out."</i><br> 14 <i>Monk: "But if there is nothing, how can I throw it out?"</i><br> 15 <i>Joshu: "Well, then carry it out."</i><br> 16 <i>(Zen koan)</i><br> 17 18 <h1>PicoLisp Frequently Asked Questions</h1> 19 20 <p align=right>(c) Software Lab. Alexander Burger 21 22 <p><ul> 23 <li><a href="#yet">Why did you write yet another Lisp?</a> 24 <li><a href="#who">Who can use PicoLisp?</a> 25 <li><a href="#advantages">What are the advantages over other Lisp systems?</a> 26 <li><a href="#performance">How is the performance compared to other Lisp systems?</a> 27 <li><a href="#interpreted">What means "interpreted"?</a> 28 <li><a href="#compiler">Is there (or will be in the future) a compiler available?</a> 29 <li><a href="#portable">Is it portable?</a> 30 <li><a href="#webServer">Is PicoLisp a web server?</a> 31 <li><a href="#lambda">I cannot find the LAMBDA keyword in PicoLisp</a> 32 <li><a href="#dynamic">Why do you use dynamic variable binding?</a> 33 <li><a href="#problems">Are there no problems caused by dynamic binding?</a> 34 <li><a href="#closures">But with dynamic binding I cannot implement closures!</a> 35 <li><a href="#macros">Do you have macros?</a> 36 <li><a href="#strings">Why are there no strings?</a> 37 <li><a href="#arrays">What about arrays?</a> 38 <li><a href="#floats">How to do floating point arithmetics?</a> 39 <li><a href="#bind">What happens when I locally bind a symbol which has a function definition?</a> 40 <li><a href="#hardware">Would it make sense to build PicoLisp in hardware?</a> 41 <li><a href="#segfault">I get a segfault if I ...</a> 42 <li><a href="#ask">Where can I ask questions?</a> 43 </ul> 44 45 <p><hr> 46 <h2><a name="yet">Why did you write yet another Lisp?</a></h2> 47 48 <p>Because other Lisps are not the way I'd like them to be. They concentrate on 49 efficient compilation, and lost the one-to-one relationship of language and 50 virtual machine of an interpreted system, gave up power and flexibility, and 51 impose unnecessary limitations on the freedom of the programmer. Other reasons 52 are the case-insensitivity and complexity of current Lisp systems. 53 54 55 <p><hr> 56 <h2><a name="who">Who can use PicoLisp?</a></h2> 57 58 <p>PicoLisp is for programmers who want to control their programming 59 environment, at all levels, from the application domain down to the bare metal. 60 Who want use a transparent and simple - yet universal - programming model, and 61 want to know exactly what is going on. This is an aspect influenced by 62 <code>Forth</code>. 63 64 <p>It does <i>not</i> pretend to be easy to learn. There are already plenty of 65 languages that do so. It is not for people who don't care what's under the hood, 66 who just want to get their application running. They are better served with some 67 standard, "safe" black-box, which may be easier to learn, and which allegedly 68 better protects them from their own mistakes. 69 70 71 <p><hr> 72 <h2><a name="advantages">What are the advantages over other Lisp systems?</a></h2> 73 74 <h3>Simplicity</h3> 75 <p>PicoLisp is easy to understand and adapt. There is no compiler enforcing 76 special rules, and the interpreter is simple and straightforward. There are only 77 three data types: Numbers, symbols and lists ("LISP" means "List-, Integer- and 78 Symbol Processing" after all ;-). The memory footprint is minimal, and the 79 tarball size of the whole system is just a few hundred kilobytes. 80 81 <h3>A Clear Model</h3> 82 <p>Most other systems define the language, and leave it up to the implementation 83 to follow the specifications. Therefore, language designers try to be as 84 abstract and general as possible, leaving many questions and ambiguities to the 85 users of the language. 86 87 <p>PicoLisp does the opposite. Initially, only the single-cell data structure 88 was defined, and then the structure of numbers, symbols and lists as they are 89 composed of these cells. Everything else in the whole system follows from these 90 axioms. This is documented in the chapter about the <a href="ref.html#vm">The 91 PicoLisp Machine</a> in the reference manual. 92 93 <h3>Orthogonality</h3> 94 <p>There is only one symbolic data type, no distinction (confusion) between 95 symbols, strings, variables, special variables and identifiers. 96 97 <p>Most data-manipulation functions operate on the values of symbols as well as 98 the CARs of cons pairs: 99 100 <pre><code> 101 : (let (N 7 L (7 7 7)) (inc 'N) (inc (cdr L)) (cons N L)) 102 -> (8 7 8 7) 103 </code></pre> 104 105 <p>There is only a single functional type, no "special forms". As there is no 106 compiler, functions can be used instead of macros. No special "syntax" 107 constructs are needed. This allows a completely orthogonal use of functions. For 108 example, most other Lisps do not allow calls like 109 110 <pre><code> 111 : (mapcar if '(T NIL T NIL) '(1 2 3 4) '(5 6 7 8)) 112 -> (1 6 3 8) 113 </code></pre> 114 115 <p>PicoLisp has no such restrictions. It favors the principle of "Least 116 Astonishment". 117 118 <h3>Object System</h3> 119 <p>The OOP system is very powerful, because it is fully dynamic, yet extremely 120 simple: 121 122 <p><ul> 123 <li>In other systems you have to statically declare "slots". In PicoLisp, 124 classes and objects are completely dynamic, they are created and extended at 125 runtime. "Slots" don't even exist at creation time. They spring into existence 126 purely dynamically. You can add any new property or any new method to any single 127 object, at any time, regardless of its class. 128 129 <li>The multiple inheritance is such that not only classes can have several 130 superclasses, but each individual object can be of more than one class. 131 132 <li>Prefix classes can surgically change the inheritance tree for any class or 133 object. They behave like Mixins in this regard. 134 135 <li>Fine-control of inheritance in methods with <code><a 136 href="refS.html#super">super</a></code> and <code><a 137 href="refE.html#extra">extra</a></code>. 138 139 </ul> 140 141 <h3>Pragmatism</h3> 142 <p>PicoLisp has many practical features not found in other Lisp dialects. Among 143 them are: 144 145 <p><ul> 146 <li>Auto-quoting of lists when the CAR is a number. Instead of <code>'(1 2 147 3)</code> you can just write <code>(1 2 3)</code>. This is possible because a 148 number never makes sense as a function name, and has to be checked at runtime 149 anyway. 150 151 <li>The <code><a href="refQ.html#quote">quote</a></code> function returns all 152 unevaluated arguments, instead of just the first one. This is both faster 153 (<code>quote</code> does not have to take the CAR of its argument list) and 154 smaller (a single cell instead of two). For example, <code>'A</code> expands to 155 <code>(quote . A)</code> and <code>'(A B C)</code> expands to <code>(quote A B 156 C)</code>. 157 158 <li>The symbol <code><a href="ref.html#atres">@</a></code> is automatically 159 maintained as a local variable, and set implicitly in certain flow- and 160 logic-functions. This makes it often unnecessary to allocate and assign local 161 variables. 162 163 <li><a href="tut.html#funio">Functional I/O</a> is more convenient than 164 explicitly passing around file descriptors. 165 166 <li>A well-defined <a href="ref.html#cmp">ordinal relationship</a> between 167 arbitrary data types facilitates generalized comparing and sorting. 168 169 <li>Uniform handling of <code>var</code> locations (i.e. values of symbols and 170 CARs of cons pairs). 171 172 <li>The universality and usefulness of symbol properties is enforced and 173 extended with implicit and explicit bindings of the symbol <code><a 174 href="refT.html#This">This</a></code> in combination with the access functions 175 <code><a href="ref_.html#=:">=:</a></code>, <code><a 176 href="ref_.html#:">:</a></code> and <code><a href="ref_.html#::">::</a></code>. 177 178 <li>A very convenient list-building machinery, using the <code><a 179 href="refL.html#link">link</a></code>, <code><a 180 href="refY.html#yoke">yoke</a></code>, <code><a 181 href="refC.html#chain">chain</a></code> and <code><a 182 href="refM.html#made">made</a></code> functions in the <code><a 183 href="refM.html#make">make</a></code> environment. 184 185 <li>The syntax of often-used functions is kept non-verbose. For example, instead 186 of <code>(let ((A 1) (B 2) C 3) ..)</code> you write <code>(let (A 1 B 2 C 3) 187 ..)</code>, or just <code>(let A 1 ..)</code> if there is only a single 188 variable. 189 190 <li>The use of the hash (<code>#</code>) as a comment character is more adequate 191 today, and allows a clean hash-bang (<code>#!</code>) syntax for stand-alone 192 scripts. 193 194 <li>The interpreter is <a href="ref.html#invoc">invoked</a> with a simple and 195 flexible syntax, where command line arguments are either files to be interpreted 196 or functions to be directly executed. With that, many tasks can be performed 197 without writing a separate <a href="tut.html#script">script</a>. 198 199 <li>A sophisticated system of interprocess communication, file locking and 200 synchronization allows multi-user access to database applications. 201 202 <li>A Prolog interpreter is tightly integrated into the language. Prolog 203 clauses can call Lisp expressions and vice versa, and a self-adjusting 204 depth-first search predicate <code>select</code> can be used in database 205 queries. 206 207 </ul> 208 209 <h3>Persistent Symbols</h3> 210 <p>Database objects ("external" symbols) are a primary data type in PicoLisp. 211 They look like normal symbols to the programmer, but are managed in the database 212 (fetched from, and stored to) automatically by the system. Symbol manipulation 213 functions like <code>set</code>, <code>put</code> or <code>get</code>, the 214 garbage collector, and other parts of the interpreter know about them. 215 216 <h3>Application Server</h3> 217 <p>It is a stand-alone system (it does not depend on external programs like 218 Apache or MySQL) and it provides a "live" user interface on the client side, 219 with an application server session for each connected client. The GUI layout and 220 behavior are described with S-expressions, generated dynamically at runtime, and 221 interact directly with the database structures. 222 223 <h3>Localization</h3> 224 <p>Internal exclusive and full use of UTF-8 encoding, and self-translating <a 225 href="ref.html#transient-io">transient symbols</a> (strings), make it easy to 226 write country- and language-independent applications. 227 228 229 <p><hr> 230 <h2><a name="performance">How is the performance compared to other Lisp systems?</a></h2> 231 232 <p>Despite the fact that PicoLisp is an interpreted-only system, the performance 233 is quite good. Typical Lisp programs operating on list data structures are 234 executed in (interpreted) PicoLisp at about the same speed as in (compiled) 235 CMUCL, and about two or three times faster than in CLisp or Scheme48. Programs 236 with lots of numeric calculations, however, may be slower on a 32-bit system, 237 due to PicoLisp's somewhat inefficient implementation of numbers. The 64-bit 238 version improved on that. 239 240 <p>But in practice, speed was never a problem, even with the first versions of 241 PicoLisp in 1988 on a Mac II with a 12 MHz CPU. And certain things are cleaner 242 and easier to do in plain <code>C</code> or <code>asm</code> anyway. It is very 243 easy to write <code>C</code> functions in PicoLisp, either in the kernel, as 244 shared object libraries, or even inline in the Lisp code. 245 246 <p>PicoLisp is very space-effective. Other Lisp systems reserve heap space twice 247 as much as needed, or use rather large internal structures to store cells and 248 symbols. Each cell or minimal symbol in PicoLisp consists of only two pointers. 249 No additional tags are stored, because they are implied in the pointer 250 encodings. No gaps remain in the heap during allocation, as there are only 251 objects of a single size. As a result, consing and garbage collection are very 252 fast, and overall performance benefits from a better cache efficiency. Heap and 253 stack grow automatically, and are limited only by hardware and operating system 254 constraints. 255 256 257 <p><hr> 258 <h2><a name="interpreted">What means "interpreted"?</a></h2> 259 260 <p>It means to directly execute Lisp data as program code. No transformation to 261 another representation of the code (e.g. compilation), and no structural 262 modifications of these data, takes place. 263 264 <p>Lisp data are the "real" things, like numbers, symbols and lists, which can 265 be directly handled by the system. They are <i>not</i> the textual 266 representation of these structures (which is outside the Lisp realm and taken 267 care of the <code><a href="refR.html#read">read</a></code>ing and <code><a 268 href="refP.html#print">print</a></code>ing interfaces). 269 270 <p>The following example builds a function and immediately calls it with two 271 arguments: 272 273 <pre><code> 274 : ((list (list 'X 'Y) (list '* 'X 'Y)) 3 4) 275 -> 12 276 </code></pre> 277 278 <p>Note that no time is wasted to build up a lexical environment. Variable 279 bindings take place dynamically during interpretation. 280 281 <p>A PicoLisp function is able to inspect or modify itself while it is running 282 (though this is rarely done in application programming). The following function 283 modifies itself by incrementing the '0' in its body: 284 285 <pre><code> 286 (de incMe () 287 (do 8 288 (printsp 0) 289 (inc (cdadr (cdadr incMe))) ) ) 290 291 : (incMe) 292 0 1 2 3 4 5 6 7 -> 8 293 : (incMe) 294 8 9 10 11 12 13 14 15 -> 16 295 </code></pre> 296 297 <p>Only an interpreted Lisp can fully support such "Equivalence of Code and 298 Data". If executable pieces of data are used frequently, like in PicoLisp's 299 dynamically generated GUI, a fast interpreter is preferable over any compiler. 300 301 302 <p><hr> 303 <h2><a name="compiler">Is there (or will be in the future) a compiler available?</a></h2> 304 305 <p>No. That would contradict the idea of PicoLisp's simple virtual machine 306 structure. A compiler transforms it to another (physical) machine, with the 307 result that many assumptions about the machine's behavior won't hold any more. 308 Besides that, PicoLisp primitive functions evaluate their arguments 309 independently and are not suited for being called from compiled code. Finally, 310 the gain in execution speed would probably not be worth the effort. Typical 311 PicoLisp applications often use single-pass code which is loaded, executed and 312 thrown away; a process that would be considerably slowed down by compilation. 313 314 315 <p><hr> 316 <h2><a name="portable">Is it portable?</a></h2> 317 318 <p>Yes and No. Though we wrote and tested PicoLisp originally only on Linux, it 319 now also runs on FreeBSD, Mac OS X (Darwin), Cygwin/Win32, and probably other 320 POSIX systems. The first versions were even fully portable between DOS, SCO-Unix 321 and Macintosh systems. But today we have Linux. Linux itself is very portable, 322 and you can get access to a Linux system almost everywhere. So why bother? 323 324 <p>The GUI is completely platform independent (Browser), and in the times of 325 Internet an application <u>server</u> does not really need to be portable. 326 327 328 <p><hr> 329 <h2><a name="webServer">Is PicoLisp a web server?</a></h2> 330 331 <p>Not really, but it evolved a great deal into that direction. 332 333 <p>Historically it was the other way round: We had a plain X11 GUI for our 334 applications, and needed something platform independent. The solution was 335 obvious: Browsers are installed virtually everywhere. So we developed a protocol 336 which persuades a browser to function as a GUI front-end to our applications. 337 This is much simpler than to develop a full-blown web server. 338 339 340 <p><hr> 341 <h2><a name="lambda">I cannot find the LAMBDA keyword in PicoLisp</a></h2> 342 343 <p>Because it isn't there. The reason is that it is redundant; it is equivalent 344 to the <code>quote</code> function in any aspect, because there's no distinction 345 between code and data in PicoLisp, and <code>quote</code> returns the whole 346 (unevaluated) argument list. If you insist on it, you can define your own 347 <code>lambda</code>: 348 349 <pre><code> 350 : (def 'lambda quote) 351 -> lambda 352 : ((lambda (X Y) (+ X Y)) 3 4) 353 -> 7 354 : (mapcar (lambda (X) (+ 1 X)) '(1 2 3 4 5)) 355 -> (2 3 4 5 6) 356 </code></pre> 357 358 359 <p><hr> 360 <h2><a name="dynamic">Why do you use dynamic variable binding?</a></h2> 361 362 <p>Dynamic binding is very powerful, because there is only one single, 363 dynamically changing environment active all the time. This makes it possible 364 (e.g. for program snippets, interspersed with application data and/or passed 365 over the network) to access the whole application context, freely, yet in a 366 dynamically controlled manner. And (shallow) dynamic binding is the fastest 367 method for a Lisp interpreter. 368 369 <p>Lexical binding is more limited by definition, because each environment is 370 deliberately restricted to the visible (textual) static scope within its 371 establishing form. Therefore, most Lisps with lexical binding introduce "special 372 variables" to support dynamic binding as well, and constructs like 373 <code>labels</code> to extend the scope of variables beyond a single function. 374 375 <p>In PicoLisp, function definitions are normal symbol values. They can be 376 dynamically rebound like other variables. As a useful real-world example, take 377 this little gem: 378 379 <pre><code> 380 (de recur recurse 381 (run (cdr recurse)) ) 382 </code></pre> 383 384 <p>It implements anonymous recursion, by defining <code>recur</code> statically 385 and <code>recurse</code> dynamically. Usually it is very cumbersome to think up 386 a name for a function (like the following one) which is used only in a single 387 place. But with <code>recur</code> and <code>recurse</code> you can simply 388 write: 389 390 <pre><code> 391 : (mapcar 392 '((N) 393 (recur (N) 394 (if (=0 N) 395 1 396 (* N (recurse (- N 1))) ) ) ) 397 (1 2 3 4 5 6 7 8) ) 398 -> (1 2 6 24 120 720 5040 40320) 399 </code></pre> 400 401 <p>Needless to say, the call to <code>recurse</code> does not have to reside in 402 the same function as the corresponding <code>recur</code>. Can you implement 403 anonymous recursion so elegantly with lexical binding? 404 405 406 <p><hr> 407 <h2><a name="problems">Are there no problems caused by dynamic binding?</a></h2> 408 409 <p>You mean the <i>funarg</i> problem, or problems that arise when a variable 410 might be bound to <i>itself</i>? For that reason we have a convention in 411 PicoLisp to use <a href="ref.html#transient-io">transient symbols</a> (instead 412 of internal symbols) 413 414 <ol> 415 416 <li>for all parameters and locals, when functional arguments or executable lists 417 are passed through the current dynamic bindings 418 419 <li>for a parameter or local, when that symbol might possibly be (directly or 420 indirectly) bound to itself, and the bound symbol's value is accessed in the 421 dynamic context 422 423 </ol> 424 425 <p>This is a form of lexical <i>scoping</i> - though we still have dynamic 426 <i>binding</i> - of symbols, similar to the <code>static</code> keyword in 427 <code>C</code>. 428 429 <p>In fact, these problems are a real threat, and may lead to mysterious bugs 430 (other Lisps have similar problems, e.g. with symbol capture in macros). They 431 can be avoided, however, when the above conventions are observed. As an example, 432 consider a function which doubles the value in a variable: 433 434 <pre><code> 435 (de double (Var) 436 (set Var (* 2 (val Var))) ) 437 </code></pre> 438 439 <p>This works fine, as long as we call it as <code>(double 'X)</code>, but will 440 break if we call it as <code>(double 'Var)</code>. Therefore, the correct 441 implementation of <code>double</code> should be: 442 443 <pre><code> 444 (de double ("Var") 445 (set "Var" (* 2 (val "Var"))) ) 446 </code></pre> 447 448 <p>If <code>double</code> is defined that way in a separate source file, and/or 449 isolated via the <code><a href="ref_.html#====">====</a></code> function, then 450 the symbol <code><u>Var</u></code> is locked into a private lexical context 451 and cannot conflict with other symbols. 452 453 <p>Admittedly, there are two disadvantages with this solution: 454 455 <ol> 456 457 <li>The rules for when to use transient symbols are a bit complicated. Though it 458 is safe to use them even when not necessary, it will take more space then and be 459 more difficult to debug. 460 461 <li>The string-like syntax of transient symbols as variables may look strange to 462 alumni of other languages. 463 464 </ol> 465 466 Fortunately, these pitfalls do not occur so very often, and seem more likely in 467 utilities than in production code, so that they can be easily encapsulated. 468 469 470 <p><hr> 471 <h2><a name="closures">But with dynamic binding I cannot implement closures!</a></h2> 472 473 <p>This is not true. Closures are a matter of scope, not of binding. 474 475 <p>For a closure it is necessary to build and maintain a separate environment. 476 In a system with lexical bindings, this has to be done at <i>each</i> function 477 call, and for compiled code it is the most efficient strategy anyway, because it 478 is done once by the compiler, and can then be accessed as stack frames at 479 runtime. 480 481 <p>For an interpreter, however, this is quite an overhead. So it should not be 482 done automatically at each and every function invocation, but only if needed. 483 484 <p>You have several options in PicoLisp. For simple cases, you can take 485 advantage of the static scope of <a href="ref.html#transient-io">transient 486 symbols</a>. For the general case, PicoLisp has built-in functions like <code><a 487 href="refB.html#bind">bind</a></code> or <code><a 488 href="refJ.html#job">job</a></code>, which dynamically manage statically scoped 489 environments. 490 491 <p>Environments are first-class objects in PicoLisp, more flexible than 492 hard-coded closures, because they can be created and manipulated independently 493 from the code. 494 495 <p>As an example, consider a currying function: 496 497 <pre><code> 498 (de curry Args 499 (list (car Args) 500 (list 'list 501 (lit (cadr Args)) 502 (list 'cons ''job 503 (list 'cons 504 (list 'lit (list 'env (lit (car Args)))) 505 (lit (cddr Args)) ) ) ) ) ) 506 </code></pre> 507 508 <p>When called, it returns a function-building function which may be applied to 509 some argument: 510 511 <pre><code> 512 : ((curry (X) (N) (* X N)) 3) 513 -> ((N) (job '((X . 3)) (* X N))) 514 </code></pre> 515 516 <p>or used as: 517 518 <pre><code> 519 : (((curry (X) (N) (* X N)) 3) 4) 520 -> 12 521 </code></pre> 522 523 <p>In other cases, you are free to choose a shorter and faster solution. If (as 524 in the example above) the curried argument is known to be immutable: 525 526 <pre><code> 527 (de curry Args 528 (list 529 (cadr Args) 530 (list 'fill 531 (lit (cons (car Args) (cddr Args))) 532 (lit (cadr Args)) ) ) ) 533 </code></pre> 534 535 <p>Then the function built above will just be: 536 537 <pre><code> 538 : ((curry (X) (N) (* X N)) 3) 539 -> ((X) (* X 3)) 540 </code></pre> 541 542 <p>In that case, the "environment build-up" is reduced by a simple (lexical) 543 constant substitution with zero runtime overhead. 544 545 <p>Note that the actual <code><a href="refC.html#curry">curry</a></code> 546 function is simpler and more pragmatic. It combines both strategies (to use 547 <code>job</code>, or to substitute), deciding at runtime what kind of function 548 to build. 549 550 551 <p><hr> 552 <h2><a name="macros">Do you have macros?</a></h2> 553 554 <p>Yes, there is a macro mechanism in PicoLisp, to build and immediately execute 555 a list of expressions. But it is seldom used. Macros are a kludge. Most things 556 where you need macros in other Lisps are directly expressible as functions in 557 PicoLisp, which (as opposed to macros) can be applied, passed around, and 558 debugged. 559 560 <p>For example, Common Lisp's <code>DO*</code> macro, written as a function: 561 562 <pre><code> 563 (de do* "Args" 564 (bind (mapcar car (car "Args")) 565 (for "A" (car "Args") 566 (set (car "A") (eval (cadr "A"))) ) 567 (until (eval (caadr "Args")) 568 (run (cddr "Args")) 569 (for "A" (car "Args") 570 (and (cddr "A") (set (car "A") (run @))) ) ) 571 (run (cdadr "Args")) ) ) 572 </code></pre> 573 574 575 <p><hr> 576 <h2><a name="strings">Why are there no strings?</a></h2> 577 578 <p>Because PicoLisp has something better: <a 579 href="ref.html#transient-io">Transient symbols</a>. They look and behave like 580 strings in any respect, but are nevertheless true symbols, with a value and a 581 property list. 582 583 <p>This leads to interesting opportunities. The value, for example, can point to 584 other data that represent the string's translation. This is used extensively for 585 localization. When a program calls 586 587 <pre><code> 588 (prinl "Good morning!") 589 </code></pre> 590 591 <p>then changing the value of the symbol <code>"Good morning!"</code> to its 592 translation will change the program's output at runtime. 593 594 <p>Transient symbols are also quite memory-conservative. As they are stored in 595 normal heap cells, no additional overhead for memory management is induced. The 596 cell holds the symbol's value in its CDR, and the tail in its CAR. If the string 597 is not longer than 7 bytes, it fits (on the 64-bit version) completely into the 598 tail, and a single cell suffices. Up to 15 bytes take up two cells, 23 bytes 599 three etc., so that long strings are not very efficient (needing twice the 600 memory on the average), but this disadvantage is made up by simplicity and 601 uniformity. And lots of extremely long strings are not the common case, as they 602 are split up anyway during processing, and stored as plain byte sequences in 603 external files and databases. 604 605 <p>Because transient symbols are temporarily interned (while <code><a 606 href="refL.html#load">load</a></code>ing the current source file), they are 607 shared within the same source and occupy that space only once, even if they 608 occur multiple times within the same file. 609 610 611 <p><hr> 612 <h2><a name="arrays">What about arrays?</a></h2> 613 614 <p>PicoLisp has no array or vector data type. Instead, lists must be used for 615 any type of sequentially arranged data. 616 617 <p>We believe that arrays are usually overrated. Textbook wisdom tells that they 618 have a constant access time O(1) when the index is known. Many other operations 619 like splits or insertions are rather expensive. Access with a known (numeric) 620 index is not really typical for Lisp, and even then the advantage of an array is 621 significant only if it is relatively long. Holding lots of data in long arrays, 622 however, smells quite like a program design error, and we suspect that often 623 more structured representations like trees or interconnected objects would be 624 better. 625 626 <p>In practice, most arrays are rather short, or the program can be designed in 627 such a way that long arrays (or at least an indexed access) are avoided. 628 629 <p>Using lists, on the other hand, has advantages. We have so many concerted 630 functions that uniformly operate on lists. There is no separate data type that 631 has to be handled by the interpreter, garbage collector, I/O, database and so 632 on. Lists can be made circular. And lists don't cause memory fragmentation. 633 634 635 <p><hr> 636 <h2><a name="floats">How to do floating point arithmetics?</a></h2> 637 638 <p>PicoLisp does not support real floating point numbers. You can do all kinds 639 of floating point calculations by calling existing library functions via 640 <code><a href="refN.html#native">native</a></code>, inline-C code, and/or by 641 loading the "@lib/math.l" library. 642 643 <p>But PicoLisp has something even (arguably) better: Scaled <a 644 href="ref.html#num-io">fixpoint numbers</a>, with unlimited precision. 645 646 <p>The reasons for this design decision are manifold. Floating point numbers 647 smack of imperfection, they don't give "exact" results, have limited precision 648 and range, and require an extra data type. It is hard to understand what really 649 goes on (How many digits of precision do we have today? Are perhaps 10-byte 650 floats used for intermediate results? How does rounding behave?). 651 652 <p>For fixpoint support, the system must handle just integer arithmetics, I/O 653 and string conversions. The rest is under programmer's control and 654 responsibility (the essence of PicoLisp). 655 656 <p>Carefully scaled fixpoint calculations can do anything floating points can 657 do. 658 659 660 <p><hr> 661 <h2><a name="bind">What happens when I locally bind a symbol which has a function definition?</a></h2> 662 663 <p>That's not a good idea. The next time that function gets executed within the 664 dynamic context the system may crash. Therefore we have a convention to use an 665 upper case first letter for locally bound symbols: 666 667 <pre><code> 668 (de findCar (Car List) 669 (when (member Car (cdr List)) 670 (list Car (car List)) ) ) 671 </code></pre> 672 673 ;-) 674 675 676 <p><hr> 677 <h2><a name="hardware">Would it make sense to build PicoLisp in hardware?</a></h2> 678 679 <p>At least it should be interesting. It would be a machine executing list 680 (tree) structures instead of linear instruction sequences. "Instruction 681 prefetch" would look down the CAR- and CDR-chains, and perhaps need only a 682 single cache for both data and instructions. 683 684 <p>Primitive functions like <code>set</code>, <code>val</code>, <code>if</code> 685 and <code>while</code>, which are written in <code>C</code> or assembly language 686 now, would be implemented in microcode. Plus a few I/O functions for hardware 687 access. <code>EVAL</code> itself would be a microcode subroutine. 688 689 <p>Only a single heap and a single stack is needed. They grow towards each 690 other, and cause garbage collection if they get too close. Heap compaction is 691 trivial due to the single cell size. 692 693 <p>There would be no assembly-language. The lowest level (above the hardware and 694 microcode levels) are s-expressions: The machine language is <i>Lisp</i>. 695 696 697 <p><hr> 698 <h2><a name="segfault">I get a segfault if I ...</a></h2> 699 700 <p>It is easy to produce a segfault in PicoLisp. Just set a symbol to a value 701 which is not a function, and call it: 702 703 <pre><code> 704 : (setq foo 1) 705 -> 1 706 : (foo) 707 Segmentation fault 708 </code></pre> 709 710 There is another <a href="ref.html#codePointer">example</a> in the <a 711 href="ref.html#ev">Evaluation</a> section of the reference manual. 712 713 <p>PicoLisp is a pragmatic language. It doesn't check at runtime for all 714 possible error conditions which won't occur during normal usage. Such errors are 715 usually detected quickly at the first test run, and checking for them after that 716 would just produce runtime overhead. 717 718 <p>Catching the segmentation violation and bus fault signals is also not a good 719 idea, because the Lisp heap is most probably be damaged afterwards, possibly 720 creating further havoc if execution continues. 721 722 <p>It is recommended to inspect the code periodically with <code><a 723 href="refL.html#lint">lint</a></code>. It will detect many potential errors. 724 And, most of these errors are avoided by following the PicoLisp <a 725 href="ref.html#conv">naming conventions</a>. 726 727 728 <p><hr> 729 <h2><a name="ask">Where can I ask questions?</a></h2> 730 731 <p>The best place is the <a 732 href="mailto:picolisp@software-lab.de?subject=Subscribe">PicoLisp Mailing 733 List</a> (see also <a 734 href="http://www.mail-archive.com/picolisp@software-lab.de/">The Mail 735 Archive</a> and <a 736 href="http://dir.gmane.org/gmane.lisp.picolisp.general">Gmane.org</a>), or the 737 IRC <a href="irc://irc.freenode.net/picolisp">#picolisp</a> channel on 738 FreeNode.net. 739 740 </body> 741 </html>