DLR Limits on Language Implementation

Nov 20, 2013 at 11:56 AM
Hi everybody,

I'm newbie here in programming language implementation. I would like to know limits of DLR while being used for language implementation. I have a specific question which asked on stackoverflow, but no answer yet. So I wanted to open this discussion to figure out what is beyond DLR.
Coordinator
Nov 20, 2013 at 7:33 PM

Hi, roodya. I'm including your text from your post here to merge:

"Typed" so that the correct method can be selected based on method signature and the compiler can do some sort of type-safety (Not necessarily 100%) as well. And "dynamic" so that every variable can change its type runtime. Now my question is that is it possible to implement this kind of language by using DLR.

Since all DLR languages (about which I heard) are dynamic and also they don't have access modifiers (public, protected, etc), I'm thinking whether DLR is a good platform that the language can be built on. Any answer/suggestion/comment is highly appreciated. Thanks in advance.

Considering the interoperability with .NET, my question is that is it possible to implement such language by using DLR? And how much effort does it need? Is there any other better option?

You can use the DLR for this. Enforcing types is your choice in what code you emit (that is, what Expression Trees you generate, which can be statically typed). The DLR should give you some lift to make it easier. Please see the overview paper and the Sympl example, docs on the codeplex docs page.

Cheers,

Bill

Nov 21, 2013 at 2:12 AM
Thank you Bill,
I would like to know more on access modifiers, such as private, protected, and public. Is it easy enough to implement a language with such access modifiers on DLR? As I can see, implementing a language with public members is easy and straightforward. How about more complex member? Apart from access modifier and type, what if I have to add a new attribute with each member? Is it possible to implement this kind of semantic on DLR?
Nov 21, 2013 at 6:02 PM
It's certainly possible, since IronRuby supports public/protected/private. Whether you do it as part of the compilation process or do the checks at runtime is up to you, depending on how "static" your language is. The dynamic way to do it would be to emit an expression tree that checks any attributes of the member when it is accessed and then allows or disallows as appropriate.
Marked as answer by roodya on 11/23/2013 at 12:48 AM
Coordinator
Nov 21, 2013 at 6:37 PM

I like Jeff's answer, but I'll weigh in on your use of "easy". :-). The DLR gives you a lot of lift for many common implementation needs, BUT building a full language is a lot of work, period. the more features, the more work :-). If you look at ironpython or ironruby sources, there is a lot of code to fully implement those languages vs. the comparatively very little code to just get up something as simple and Sympl (that, while cute, is far from a fully useful language :-)).

Cheers,

Bill

Nov 23, 2013 at 8:47 AM
Thanks @jdhardy and @billchi. I got it. Based on what you said, I assume that it's possible to check more attributes rather than access control during binding process. Lets say we want to specify whether the variable (the receiver) is aliased or not. Am I right?