[antlr-interest] Creating extension libraries for a DSL

[Cliff Hudson]

Ahh, well yes, if your runtime remains Java, then I can see why you'd be
reluctant to just go with a direct native code interface.  Is it necessary
or especially desirable to stick with the Java target?  Or is the JNI really
that cumbersome?  I'm more of a .Net person, and I guess we have a similar
issue, where we would have to either require the extension to use COM or do
LoadLibrary and PInvoke.

On Sat, Apr 3, 2010 at 10:39 AM, Andreas Stefik <stefika at gmail.com> wrote:

> 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
> >> >
> >> >
> >
> >
>