The Artima Developer Community
Sponsored Link

Weblogs Forum
(Re-)Introducing the Heron Programming Language

19 replies on 2 pages. Most recent reply: Mar 16, 2010 1:47 PM by John Zabroski

Welcome Guest
  Sign In

Go back to the topic listing  Back to Topic List Click to reply to this topic  Reply to this Topic Click to search messages in this forum  Search Forum Click for a threaded view of the topic  Threaded View   
Previous Topic   Next Topic
Flat View: This topic has 19 replies on 2 pages [ « | 1 2 ]
Achilleas Margaritis

Posts: 674
Nickname: achilleas
Registered: Feb, 2005

Re: (Re-)Introducing the Heron Programming Language Posted: Mar 11, 2010 2:43 AM
Reply to this message Reply
Advertisement
> Instead of answering individual questions, allow me to
> mention an article on reflection in C++, written by a very
> smart fellow Achilleas Margaritis:
> http://www.codeproject.com/KB/library/libreflection.aspx
>
> Are you saying that macros CLASS, PROPERTY, METHOD, etc.
> don't result in any overhead in code size - even if
> reflection is never even actually used?

My reflection library is a add on library in an existing programming language. It is not the optimal solution for reflection, and certainly not the approach to take for native reflection support.

My belief is that reflection has no cost at all when supported natively by a programming language. Reflection data can exist separately from the rest of the code.

So, could you please answer the questions I asked you previously? I am truly curious as to what I am missing.

Nemanja Trifunovic

Posts: 172
Nickname: ntrif
Registered: Jun, 2004

Re: (Re-)Introducing the Heron Programming Language Posted: Mar 11, 2010 1:13 PM
Reply to this message Reply
1) Even for introspection, the type data needs to be present and it will affect the size of the executable. I don't know if it can be kept separatelly - do you know a language which supports such option?

2) Affecting optimization is still a concern. Unused methods cannot be optimized away because they might be called dynamically.

3) To enable emitting code at run-time, basically a compiler needs to be embedded with the executable.

I hope I answered your questions.

Achilleas Margaritis

Posts: 674
Nickname: achilleas
Registered: Feb, 2005

Re: (Re-)Introducing the Heron Programming Language Posted: Mar 12, 2010 9:28 AM
Reply to this message Reply
Thank you for the replies.

> 1) Even for introspection, the type data needs to be
> present and it will affect the size of the executable. I
> don't know if it can be kept separatelly - do you know a
> language which supports such option?

I do not know such a language, but I do not think it is difficult to do. A compiler could create two modules for each source code file: one with the actual code, and one with the metadata. If the client code uses reflection, then it should also link with the metadata module. The metadata are always different symbols from the actual code.

>
> 2) Affecting optimization is still a concern. Unused
> methods cannot be optimized away because they might be
> called dynamically.

For dynamically linked libraries, this problem does not exist, because the compiler does not optimize anything away, since the libraries are loaded dynamically.

For statically linked libraries, and for source code, the problem can be solved by optionally marking symbols not eligible for reflection, including whole classes and modules.

>
> 3) To enable emitting code at run-time, basically a
> compiler needs to be embedded with the executable.
>
> I hope I answered your questions.

The compiler can exist as a module which is linked only if used.

Anything else I am missing? so far, I don't see reflection being a problem for a system language, given the choice to avoid it if not desired, just like garbage collection.

John Zabroski

Posts: 272
Nickname: zbo
Registered: Jan, 2007

Re: (Re-)Introducing the Heron Programming Language Posted: Mar 16, 2010 1:45 PM
Reply to this message Reply
> Thank you for the replies.
>
> > 1) Even for introspection, the type data needs to be
> > present and it will affect the size of the executable.
> I
> > don't know if it can be kept separatelly - do you know
> a
> > language which supports such option?
>
> I do not know such a language, but I do not think it is
> difficult to do. A compiler could create two modules for
> each source code file: one with the actual code, and one
> with the metadata. If the client code uses reflection,
> then it should also link with the metadata module. The
> metadata are always different symbols from the actual
> code.

As usual, your intuition is not too far off, Achilleas!

The actual solution must be more object-oriented. You should only get a reference to the code module from an object that governs access to both the code module and metadata module. This is different from how things are done in .NET. IMHO, as a consequence, it significantly complicates the design of various subsystems such as the Profiling API, which must maintain shadow stacks in order to properly trace tail calls - evil voodoo!

> >
> > 2) Affecting optimization is still a concern. Unused
> > methods cannot be optimized away because they might be
> > called dynamically.
>
> For dynamically linked libraries, this problem does not
> exist, because the compiler does not optimize anything
> away, since the libraries are loaded dynamically.

Correct. Dynamic linking literally means dynamic linking. If a bytecoded method does not need to be JIT'ed, it will not be. Only JIT-cache what you need to, due to memory pressure. However, some JIT's have a hard time recognizing that a piece of JIT-cached code will never be used again, ever.

> For statically linked libraries, and for source code, the
> problem can be solved by optionally marking symbols not
> eligible for reflection, including whole classes and
> modules.
>
> >
> > 3) To enable emitting code at run-time, basically a
> > compiler needs to be embedded with the executable.
> >
> > I hope I answered your questions.
>
> The compiler can exist as a module which is linked only if
> used.
>
> Anything else I am missing? so far, I don't see reflection
> being a problem for a system language, given the choice to
> avoid it if not desired, just like garbage collection.

You should read papers by Greg Morrissett. He created a typed assembly language that supported reflection.

Also, there is a difference between procedural introspection and procedural intercession (which is more general than what Reflection.Emit allows, since this involves advanced code marshaling services for thread-safe, memory-safe code-update-in-place). Recently, Andrej Filinski has been doing some exciting work in category on monadic reflection, too. You may also want to check out the recently proposed language ARCHON, which has some interesting thoughts on reflection.

But, IMHO, the coolest reflective system devised so far is Alessandro Warth and Ian Piumarta's OMeta PEG parser: it is so mischievously ingenius.

John Zabroski

Posts: 272
Nickname: zbo
Registered: Jan, 2007

Re: (Re-)Introducing the Heron Programming Language Posted: Mar 16, 2010 1:47 PM
Reply to this message Reply
Just to be clear, memory-safety implies supporting this service at the same level of abstraction as the garbage collector.

Flat View: This topic has 19 replies on 2 pages [ « | 1  2 ]
Topic: Setting Multiple Inheritance Straight Previous Topic   Next Topic Topic: A Golf Ball to the Forehead

Sponsored Links



Google
  Web Artima.com   

Copyright © 1996-2019 Artima, Inc. All Rights Reserved. - Privacy Policy - Terms of Use