[antlr-interest] Creating extension libraries for a DSL

[Cliff Hudson]

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