Concatenative topics
Concatenative meta
Other languages
Meta
(22/10)[08:36:11] <prunedtree> also, something that I didn't mention
(22/10)[08:39:07] <prunedtree> for subjective dispatch, I think a good way to optimize is to customize any sufficiently low level method (even non-generic ones) to the 'VM sealed' access
(22/10)[08:39:31] <prunedtree> If you remember the concept, it's very similar to sealing in dylan, but with dynamic extent
(22/10)[08:39:59] <prunedtree> so we can seal any low level stuff even if it use any generic library (like sequences) without the need to seal the library itself
(22/10)[08:40:48] jeffz` is now known as jeffz
(22/10)[08:42:03] <prunedtree> in essence, I don't think it would require much complexity (to optimize the most generic case, that is the 'VM sealed' and 'unrestricted' access controls)
(22/10)[08:43:11] <prunedtree> it would allow anyone to add subjective dispatch on, say, +, so that in a dynamic context all additions are logged
(22/10)[08:43:31] <prunedtree> without hurting the performance of any method that is in the two most common cases
(22/10)[08:45:30] <prunedtree> In essence it doesn't matter if access control is quite expensive when you use it. it's a very very usefull semantic for hacks (like trying to make stuff work together quickly), debugging and sandboxing
(22/10)[08:46:28] <prunedtree> of course in the 'VM sealed' case we would expect it to be extremely fast. but that would be a very large subset of the 'unrestricted' case (all primitives and base datastructures would be available)
(22/10)[08:47:26] <prunedtree> in fact, the 'sealed' mode might be applicable to more areas than metacircularity, like speed critical sections
(22/10)[08:48:28] <prunedtree> I believe dynamic extent gives you a much more pratical sealing than class/word sealing
(22/10)[08:48:30] <slava> so klein was written in a subset of self?
(22/10)[08:48:39] <prunedtree> nope. full self lol
(22/10)[08:48:47] <slava> how did that work
(22/10)[08:49:05] <prunedtree> how would it not work ? any system can be made metacircular
(22/10)[08:49:42] <prunedtree> the only reason I want sealing with dynamic extent is for performance (in order to make a metacircular Factor VM something practical, not academic) not correctness
(22/10)[08:50:31] <prunedtree> the additional bonus is that it's a great help to avoid unintended performance regressions or bugs
(22/10)[08:52:05] <prunedtree> slava : one you have a metacircular compiler to native code you have the most important part of the puzzle
(22/10)[08:52:16] <prunedtree> in fact most of Klein was a Self compiler in Self
(22/10)[08:53:22] <prunedtree> the most tricky part for HLLs is the 'runtime'
(22/10)[08:53:48] <prunedtree> for Self, there are three parts: primitives, dispatch, GC (tell me if I forget something)
(22/10)[08:54:27] <prunedtree> the most low level primitives (intrinsics) produce native code in the compiler. all other ones can be written in the HLL
(22/10)[08:55:14] <prunedtree> dispatch simply needs to be written in a way that doesn't do any dispatching (to avoid infinite recursion)
(22/10)[08:55:44] <prunedtree> ironically, metacircularity is all about breaking the cycle :)
(22/10)[08:56:29] <prunedtree> dispatch is probably the least HLL piece of code of the system (in Self). but it's very very short so it's not really a problem
(22/10)[08:57:45] <prunedtree> in GC you have two issues: reclaiming more garbage that you create (for correctness, scavenging trivially solves this - it leaves you with potentially horrible performance though)
(22/10)[08:59:05] <prunedtree> and be carefull when you GC the stuff the GC touches. this is actually trivial when you write a concurrent GC, as you have to be carefull about anything you touch (the GC thread can be considered a mutator like all others)
(22/10)[09:01:11] <prunedtree> what is interressing (to me at least) is that it's clear that it's not as difficult to write a high performance metacircular VM. I will admit it doesn't give you suddenly immense comfort vs C:
(22/10)[09:01:28] <slava> prunedtree: you should put this type of stuff in the wiki
This revision created on Wed, 22 Oct 2008 07:12:51 by prunedtree