summaryrefslogtreecommitdiff
diff options
context:
space:
mode:
authorMatthias Andreas Benkard <matthias@benkard.de>2008-08-11 19:03:47 +0200
committerMatthias Andreas Benkard <matthias@benkard.de>2008-08-11 19:03:47 +0200
commit0e5c25802c9d069a290555629f35f93091839b09 (patch)
tree1e6f47c0a521527c37ee7a8a59b1c313ee7dd232
parent97dc73d800d9528e1b832b2668fe8040a1d49145 (diff)
New journal entry.
-rw-r--r--JOURNAL78
1 files changed, 58 insertions, 20 deletions
diff --git a/JOURNAL b/JOURNAL
index 84a6bd4..cf0c8d2 100644
--- a/JOURNAL
+++ b/JOURNAL
@@ -3,7 +3,7 @@
#title Toilet Lisp Development Diary
#desc Random news and stuff about just another random pet project
-; Time-stamp: <2008-08-06 11:36:21 mulk>
+; Time-stamp: <2008-08-11 02:35:35 mulk>
;
; C-c i t insert-time-stamp
; C-c C-t muse-project-publish-this-file
@@ -18,6 +18,44 @@ Context: [[http://matthias.benkard.de/toilet][The Toilet Lisp Project]].
----
+* 2008-08-11, 02:09:21 CEST
+
+** Function Calling, 2nd Take
+
+More thoughts:
+
+ - Fat pointers are =MLKClosure= instances. =(funcall x a b c)= is compiled
+ into:
+
+ <example>
+ %tmp1 = x->code
+ %tmp2 = x->closure_data_pointer
+ tail call %tmp1 (%tmp2, a, b, c)
+ </example>
+
+ Of course, the =code= and =closure_data_pointer= ivar offsets have to be
+ known in advance, but that should be doable.
+
+ - Contrary to what I said earlier, I now think it should be possible to
+ not always require the use of varargs. Simply accept one more
+ argument than we really expect, then look for the end-of-arguments
+ marker in the supplied arguments. If it's there, determine whether
+ it's in an expected place (i.e. not at a position that a required
+ argument was expected at), if not, signal an error.
+
+ - It should also be possible to skip argument list checking entirely,
+ either by providing another thread-local flag or by putting the same
+ =BasicBlock= into two different functions so that there are two entry
+ points (a safe one and an unsafe one).
+
+ - **lambda** is just as dumb as **flet**: Neither operator causes an =MLKClosure=
+ object to be created at runtime. Both yield two values upon
+ compilation: a =Value*= that contains the closure data value at runtime
+ (i.e. the first argument of the function to call) and a code pointer.
+ Now, where do =MLKClosure= objects come from, then? Easy: **function** is
+ the one that creates them from all that information.
+
+
* 2008-08-06, 11:08:30 CEST
** Function Calling
@@ -116,27 +154,27 @@ proto-name) to become a Lisp compiler for the Étoilé runtime (and maybe
Mac OS X as well, but that's of a lower priority) with the following
features:
- * A proper subset of ANSI Common Lisp, with an eye towards full ANSI
+ - A proper subset of ANSI Common Lisp, with an eye towards full ANSI
compliance in the far future.
- * CFFI support.
- * Lexical **and** dynamic scoping.
- * Integration with the Étoilé object system.
- * DEFMACRO.
- * Hygienic macros by way of Explicit Renaming and Syntactic Closures.
- * Read macros. (?)
- * TAGBODY and GO. (?)
- * CATCH and THROW. (?)
- * Places (that is, SETF).
- * A package system.
- * Arrays and hash tables compatible with their Common Lisp counterparts,
+ - CFFI support.
+ - Lexical **and** dynamic scoping.
+ - Integration with the Étoilé object system.
+ - DEFMACRO.
+ - Hygienic macros by way of Explicit Renaming and Syntactic Closures.
+ - Read macros. (?)
+ - TAGBODY and GO. (?)
+ - CATCH and THROW. (?)
+ - Places (that is, SETF).
+ - A package system.
+ - Arrays and hash tables compatible with their Common Lisp counterparts,
but based on the Étoilé/GNUstep ones.
- * Direct compilation to Étoilé runtime code (as with Étoilé Smalltalk).
- * A REPL.
- * Conditions and restarts.
- * Multiple namespaces.
- * Bignums and rationals.
- * JIT and explicit compilation (COMPILE) via LLVM. (?)
- * Optional static typing with Cells-based/Hindley-Milner/whatever type
+ - Direct compilation to Étoilé runtime code (as with Étoilé Smalltalk).
+ - A REPL.
+ - Conditions and restarts.
+ - Multiple namespaces.
+ - Bignums and rationals.
+ - JIT and explicit compilation (COMPILE) via LLVM. (?)
+ - Optional static typing with Cells-based/Hindley-Milner/whatever type
inference. (?)
Well, that's what I'm dreaming of. At least now you have something new