[LLVMdev] Dynamic Type Lookup ...

Frank White frankwhite1003 at gmail.com
Thu Apr 25 07:21:33 PDT 2013


Thanks for your feedback David....

Yes, the intention is to support duck-typing.  In my code example,

a.attrB1 = 5            .... is probably more accurately stated as .....
a. attr1.attrB1 = 5


Certainly this would be an unsafe call because we would not know that attrB1
is an attribute of attr1 until runtime.  I believe this type of call is
valid in a language like Python.

Are there any references out there that would help me implement something
like this?

thanks,
frank





On Thu, Apr 25, 2013 at 4:16 AM, David Chisnall <David.Chisnall at cl.cam.ac.uk
> wrote:

> On 24 Apr 2013, at 23:13, Frank White <frankwhite1003 at gmail.com> wrote:
>
> > Hello everyone, I would like to implement functionality something like
> the following in my sample language.....
> >
>
> {snipped not very informative C++ pseudocode.}
>
>
> > I assume that I will need:
> >
> > - some type of runtime lookup table to store the class structure of
> Class A and B.
>
> That depends on your type system, which isn't clear from your language
> snippets.  Are you doing static type inference?  If so, this only needs to
> be stored in the AST, if not then you will need run-time type information.
>
> Does your language support duck typing?  If so, then you will need some
> form of dynamic lookup in a runtime library, if not then you will be able
> to just generate vtables and jump to constant offsets into them.
>
> > - some way of encoding and storing an object's attribute type information
>
> Yes, if your language exposes these.
>
> > - a means of retrieving this information at runtime so that in the event
> that an object's attribute is itself an object, attributes from the latter
> can be accessed as well.
>
> Correct.
>
> > I have looked at the LLVM API but didn't see any straightforward way to
> do this.
>
> Correct.  These are highly dependent on your object model and your ABI.
>  For example, Clang supports Objective-C with two Apple and three GNU-like
> Objective-C runtimes.  This includes four (I think, possibly more now) ways
> of representing class structures and at least four ways of doing message
> sending.
>
> You choice is to either define a new object model and ABI, or follow the
> approach of LanguageKit and reuse an existing one (in our case, the GNUstep
> Objective-C runtime).  These choices are orthogonal to your choice to use
> LLVM for code generation.
>
> David
>
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.llvm.org/pipermail/llvm-dev/attachments/20130425/657acacf/attachment.html>


More information about the llvm-dev mailing list