Front Page All Articles Recent Changes Random Article

Contents

Concatenative language

  • ACL
  • Ait
  • Aocla
  • Breeze
  • Callisto
  • Cat
  • Cognate
  • colorForth
  • Concata
  • CoSy
  • Deque
  • DSSP
  • dt
  • Elymas
  • Enchilada
  • ETAC
  • F
  • Factor
  • Fiveth
  • Forth
  • Fourth
  • Freelang
  • Gershwin
  • hex
  • iNet
  • Joy
  • Joy of Postfix App
  • kcats
  • Kitten
  • lang5
  • Listack
  • LSE64
  • Lviv
  • Meow5
  • min
  • Mirth
  • mjoy
  • Mlatu
  • Ode
  • OForth
  • Om
  • Onyx
  • Plorth
  • Popr
  • Porth
  • PostScript
  • Prowl
  • Quest32
  • Quackery
  • r3
  • Raven
  • Retro
  • RPL
  • SPL
  • Staapl
  • Stabel
  • Tal
  • Titan
  • Trith
  • Uiua
  • Worst
  • xs
  • XY
  • 5th
  • 8th

Concatenative topics

  • Compilers
  • Interpreters
  • Type systems
  • Object systems
  • Quotations
  • Variables
  • Garbage collection
  • Example programs

Concatenative meta

  • People
  • Communities

Other languages

  • APL
  • C++
  • Erlang
  • FP trivia
  • Haskell
  • Io
  • Java
  • JavaScript
  • Lisp
  • ML
  • Oberon
  • RPL
  • Self
  • Slate
  • Smalltalk

Meta

  • Search
  • Farkup wiki format
  • Etiquette
  • Sandbox

Factor/Metacircularity

(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

Latest Revisions Edit

All content is © 2008-2024 by its respective authors. By adding content to this wiki, you agree to release it under the BSD license.