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 <[email protected]> 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 <[email protected]> > 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 <[email protected]> > 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 <[email protected]> > >> 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 <[email protected]> > >> > 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 > >> > > >> > > > > > > List: http://www.antlr.org/mailman/listinfo/antlr-interest Unsubscribe: http://www.antlr.org/mailman/options/antlr-interest/your-email-address -- You received this message because you are subscribed to the Google Groups "il-antlr-interest" group. To post to this group, send email to [email protected]. To unsubscribe from this group, send email to [email protected]. For more options, visit this group at http://groups.google.com/group/il-antlr-interest?hl=en.
