Disadvantages of building a compiler and library on top of a specific memory management scheme

[Marco Leise]

Am Fri, 07 Feb 2014 21:05:47 +0000
schrieb "Frustrated" <c1514843 at drdrb.com>:

> On Friday, 7 February 2014 at 13:36:12 UTC, Németh Péter wrote:
> >
> >> It would be more of an abstract type. Something special 
> >> template
> >> aggregate that the compiler accesses to get code to "hook" in 
> >> to
> >> the memory management parts of  the code the compiler needs, 
> >> but
> >> has delegated specifics to the "user".
> >
> > It's intresting idea for me.
> > If we mark a variable with a property, that how that memory is 
> > allocated then we got an marked AST node. And based on that 
> > mark we can perform AST manipulation during compile time. So if 
> > we marked a variable with ARC, then refcount decrease will 
> > injected during scope exit. If we mark a variable with GC, 
> > nothing will happen. We shoul allocate a separate memory area 
> > to refcounts, so that an RC variable can remain a pointer. 
> > These are just thoughts, nothing real proposal here... this is 
> > on my mind now..
> 
> Well, if one is providing hooks and provides the appropriate
> hooks then whatever strategy is used defines how it deals with it
> all.
> 
> 
> Basically the idea is to export the memory management work to
> external user code so it can be easily changed. In this case, for
> the most part, the compiler will not know that reference counting
> is be used(since it might not be) but scope hooks(or callbacks)
> need to be used where reference counting would need them.

Can we just copy Rust already?

Do you realize that you'll still need to have type
constructors for your allocation schemes?

  A foo() {
      A a = new!myAlloc A();
      return a;
  }

  void main() {
      A a = foo();
      // All we know is we have a reference to A.
      // We need a type ctor to know we need to deallocate it
      // with myAlloc.scopeDesctructor.
  }

-- 
Marco