[antlr-interest] Creating extension libraries for a DSL

[Andreas Stefik]

It's possible we could do it that way, but I've avoided it. We're
using the Java target for our DSL, so a direct C wrapper would
probably require that we tap everything through Java, then through
JNI. So if we supported a straight C wrapper, it might be a little
complicated making it work with our DSL in terms of the way we make
users create their custom libraries. I suppose we could allow a
wrapper into and out of Java directly, which would probably get us
most of the way there, as users can then do whatever they want in JNI
anyway, but this still seems pretty messy. Perhaps a CORBA-like
middle-ware architecture? I guess most languages don't really do that
for this sort of thing ...

Hmm,

Stefik





On Sat, Apr 3, 2010 at 9:57 AM, Cliff Hudson <cliff.s.hudson at gmail.com> wrote:
> Well, it seems reasonable then to ask the question as to whether you
> *should* provide any additional bridge beyond those mechanisms which already
> exist.  What you are talking about is a driver layer in this case.  People
> who write such things are almost universally going to do so in C, or such
> libraries for these devices or similar ones are likely to exist (when we did
> mobile phone development for instance, drivers for most pieces of hardware
> were already available, and for those bits where there were none, we write
> the drivers in C or C++ anyhow.)  In that case, just providing a way to call
> into external executable code was the only thing the language needs to do,
> as well as being able to marshal arguments back and forth between the
> calling and called bits of code.
> Given the simplicity of working with a C target language and its commonality
> of usage, why not just go with that?  Everyone understands it.
>
> On Sat, Apr 3, 2010 at 6:53 AM, Andreas Stefik <stefika at gmail.com> wrote:
>>
>> Cliff,
>>
>> I'm not asking how to make abstractions or functions, or "how to look
>> at other languages and figure it out myself." No matter the
>> abstraction mechanisms you have in place (and we have a bunch of them
>> in our language), for you to complete certain kinds of operations you
>> need some kind of a low level bridge that can ultimately tell new, or
>> unique, pieces of hardware to physically do something. For example, if
>> a user wanted to add in a MIDI controller in our language, or a sound
>> library, or to tap into an ethernet controller, or some unique piece
>> of hardware we haven't considered, that simply would not exist unless
>> we had a low level bridge, which they could then tie into both the
>> hardware and our language, and then ultimately build abstractions
>> around in our language (e.g., a wrapper to a JNI library, as I stated
>> before).
>>
>> There's lots of ways to approach it. LUA has an interesting approach.
>> Java uses JNI, while C allows you to embed assembly directly if
>> desired. I'm curious what more modern approaches folks take.
>>
>> Stefik
>>
>> On Fri, Apr 2, 2010 at 9:29 PM, Cliff Hudson <cliff.s.hudson at gmail.com>
>> wrote:
>> > Have you looked at other languages and seen a pattern you like?  You
>> > could
>> > then follow that pattern.  Typically adding extensions as keywords would
>> > be,
>> > well, basically something no one does at this point.  Assuming you
>> > support
>> > the concept of a function call, then having otherwise unresolved
>> > functions
>> > go through a resolution system which, say, looks at a list of declared
>> > imports and figures out if the function is in one of them is a
>> > well-understood pattern.
>> >
>> > On Fri, Apr 2, 2010 at 8:32 AM, Andreas Stefik <stefika at gmail.com>
>> > wrote:
>> >>
>> >> Hey folks,
>> >>
>> >> Our development team here is nearly complete with a DSL that we've
>> >> designed and are hoping to ship the first open-source version in July
>> >> or so. Right now, we parse down to the ANTLR Java target and are
>> >> preparing for the version past this release, which I think needs to
>> >> include some extension libraries for the language. For example, while
>> >> our DSL can do all of the typical language things (e.g., if
>> >> statements, looping), there are no APIs or libraries for doing file
>> >> IO, connecting to hardware, network programming, or other such things.
>> >>
>> >> Does this community have any experience adding in these sorts of
>> >> features, as in, suggestions as for what kind of approach we should
>> >> take? For example, we could allow something like a Java Native
>> >> Interface, that would allow a developer to connect in utilities that
>> >> allow things like File access. Or, we could allow custom native
>> >> functions for low level things, like a file keyword, but that doesn't
>> >> sound very flexible or extensible.
>> >>
>> >> Any general suggestions on an appropriate approach to take?
>> >>
>> >> Stefik
>> >>
>> >> List: http://www.antlr.org/mailman/listinfo/antlr-interest
>> >> Unsubscribe:
>> >> http://www.antlr.org/mailman/options/antlr-interest/your-email-address
>> >
>> >
>
>