Some sort of simpl dsl / language / etc for making classes/enums/etc?

Thrift, Protobuf have intermediate "languages" for authoring classes / etc that then get translated to other languages.

Yin / etc has mentioned this as a possibility for simpl. I agree that it's worth doing. I think in general, the "language" should probably get interpreted into a set of enum/class/field descriptors (which in turn get handed to the simpl translator apis... this way we seperate the concerns nicely and don't have to rewrite translator code if we change up the language / add more frmats for that language.)

In what way should this language be implemented? Should we roll our own? Aim for similar syntax to thrift / protobuf? Implement it like MMD is implemented now (as some intermediate representation that gets de/serialized from the user's input?)

There's some room for discussion here. Care to weigh in? @rhema @quyin @amwebb @andruidk

[andru1d]

these are called "interface definition language"s. i believe the mother of
systems w idls is corba.

the mmd syntax is obviously the easiest to implement. if you think that the
more typical PL like declaration is nicer because people are more used to
it, and its worth the hassles of implementation, then i don't mind. it
doesn't float my boat, personally, mind you.

note that not requiring external IDL is a great benefit of simpl when you
are using java or c# (languages with annotations and reflection!), as it
enables you to start coding in that language, and thus to develop and test
data structures and algorithms in the same place.

of course, when you are not using one of these languages, that advantage is
turned into a disadvantage. this is when you want a simpl idl.

andruid

On Sun, Feb 3, 2013 at 3:09 AM, Tom White notifications@github.com wrote:

Thrift, Protobuf have intermediate "languages" for authoring classes / etc
that then get translated to other languages.

Yin / etc has mentioned this as a possibility for simpl. I agree that it's
worth doing. I think in general, the "language" should probably get
interpreted into a set of enum/class/field descriptors (which in turn get
handed to the simpl translator apis... this way we seperate the concerns
nicely and don't have to rewrite translator code if we change up the
language / add more frmats for that language.)

In what way should this language be implemented? Should we roll our own?
Aim for similar syntax to thrift / protobuf? Implement it like MMD is
implemented now (as some intermediate representation that gets
de/serialized from the user's input?)

There's some room for discussion here. Care to weigh in? @rhemahttps://github.com/rhema
@quyin https://github.com/quyin @amwebb https://github.com/amwebb
@andruidk https://github.com/andruidk

—
Reply to this email directly or view it on GitHubhttps://github.com//issues/59.

andruid kerne, ph.d.
director, interface ecology lab
associate professor, department of computer science and engineering
texas a&m university 979.862.3684 fax
college station, tx 77843-3112 http://ecologylab.net

http://facebook.com/ecologylab

Interfaces are the multidimensional border zones through which the
interdependent relationships of people, activities, codes, components,
and systems are constituted. Interface ecology investigates the
dynamic interactions of media, cultures, and disciplines that
flow through interfaces.

[quyin]

I like the general idea of an IDL, but I don't feel that it is very useful
to make it protobuf / thrift compatible unless we want to enable data
exchange with protobuf / thrift.

on the other hand, some day we might want to be able to exchange data with
protobuf / thrift. so this can actually be a good thing.

it seems that it depends on where we position ourselves and in which
direction we are heading to ...

Best Regards,
Yin Qu (屈垠)

On Thu, Feb 7, 2013 at 6:46 AM, Andruid Kerne notifications@github.comwrote:

these are called "interface definition language"s. i believe the mother of
systems w idls is corba.

the mmd syntax is obviously the easiest to implement. if you think that
the
more typical PL like declaration is nicer because people are more used to
it, and its worth the hassles of implementation, then i don't mind. it
doesn't float my boat, personally, mind you.

note that not requiring external IDL is a great benefit of simpl when you
are using java or c# (languages with annotations and reflection!), as it
enables you to start coding in that language, and thus to develop and test
data structures and algorithms in the same place.

of course, when you are not using one of these languages, that advantage
is
turned into a disadvantage. this is when you want a simpl idl.

andruid

On Sun, Feb 3, 2013 at 3:09 AM, Tom White notifications@github.com
wrote:

Thrift, Protobuf have intermediate "languages" for authoring classes /
etc
that then get translated to other languages.

Yin / etc has mentioned this as a possibility for simpl. I agree that
it's
worth doing. I think in general, the "language" should probably get
interpreted into a set of enum/class/field descriptors (which in turn
get
handed to the simpl translator apis... this way we seperate the concerns
nicely and don't have to rewrite translator code if we change up the
language / add more frmats for that language.)

In what way should this language be implemented? Should we roll our own?
Aim for similar syntax to thrift / protobuf? Implement it like MMD is
implemented now (as some intermediate representation that gets
de/serialized from the user's input?)

There's some room for discussion here. Care to weigh in? @rhema<
https://github.com/rhema>
@quyin https://github.com/quyin @amwebb https://github.com/amwebb
@andruidk https://github.com/andruidk

—
Reply to this email directly or view it on GitHub<
https://github.com/ecologylab/simplJava/issues/59>.

andruid kerne, ph.d.
director, interface ecology lab
associate professor, department of computer science and engineering
texas a&m university 979.862.3684 fax
college station, tx 77843-3112 http://ecologylab.net

http://facebook.com/ecologylab

Interfaces are the multidimensional border zones through which the
interdependent relationships of people, activities, codes, components,
and systems are constituted. Interface ecology investigates the
dynamic interactions of media, cultures, and disciplines that
flow through interfaces.

—
Reply to this email directly or view it on GitHubhttps://github.com//issues/59#issuecomment-13234359.

I'm not arguing for making the idl compatible w thrift and protobuf. The discussion is whether or not we should have such an idl.

I agree w andruid that a non-simpl backed idl would be unfavorable insofar as it is extra work, however an idl that looks like thrifts or protobufs may be possible to back w simpl given the new direction for de/serialization.

This is not PRI zero , we can think about it more. Etc.

Sent from my Windows Phone

---

From: quyinmailto:notifications@github.com
Sent: ‎2/‎7/‎2013 3:05 PM
To: ecologylab/simplJavamailto:simplJava@noreply.github.com
Cc: Tom Whitemailto:Tom.White@outlook.com
Subject: Re: [simplJava] Some sort of simpl dsl / language / etc for making classes/enums/etc? (#59)

I like the general idea of an IDL, but I don't feel that it is very useful
to make it protobuf / thrift compatible unless we want to enable data
exchange with protobuf / thrift.

on the other hand, some day we might want to be able to exchange data with
protobuf / thrift. so this can actually be a good thing.

it seems that it depends on where we position ourselves and in which
direction we are heading to ...

Best Regards,
Yin Qu (屈垠)

On Thu, Feb 7, 2013 at 6:46 AM, Andruid Kerne notifications@github.comwrote:

these are called "interface definition language"s. i believe the mother of
systems w idls is corba.

the mmd syntax is obviously the easiest to implement. if you think that
the
more typical PL like declaration is nicer because people are more used to
it, and its worth the hassles of implementation, then i don't mind. it
doesn't float my boat, personally, mind you.

note that not requiring external IDL is a great benefit of simpl when you
are using java or c# (languages with annotations and reflection!), as it
enables you to start coding in that language, and thus to develop and test
data structures and algorithms in the same place.

of course, when you are not using one of these languages, that advantage
is
turned into a disadvantage. this is when you want a simpl idl.

andruid

On Sun, Feb 3, 2013 at 3:09 AM, Tom White notifications@github.com
wrote:

Thrift, Protobuf have intermediate "languages" for authoring classes /
etc
that then get translated to other languages.

Yin / etc has mentioned this as a possibility for simpl. I agree that
it's
worth doing. I think in general, the "language" should probably get
interpreted into a set of enum/class/field descriptors (which in turn
get
handed to the simpl translator apis... this way we seperate the concerns
nicely and don't have to rewrite translator code if we change up the
language / add more frmats for that language.)

In what way should this language be implemented? Should we roll our own?
Aim for similar syntax to thrift / protobuf? Implement it like MMD is
implemented now (as some intermediate representation that gets
de/serialized from the user's input?)

There's some room for discussion here. Care to weigh in? @rhema<
https://github.com/rhema>
@quyin https://github.com/quyin @amwebb https://github.com/amwebb
@andruidk https://github.com/andruidk

—
Reply to this email directly or view it on GitHub<
https://github.com/ecologylab/simplJava/issues/59>.

andruid kerne, ph.d.
director, interface ecology lab
associate professor, department of computer science and engineering
texas a&m university 979.862.3684 fax
college station, tx 77843-3112 http://ecologylab.net

http://facebook.com/ecologylab

Interfaces are the multidimensional border zones through which the
interdependent relationships of people, activities, codes, components,
and systems are constituted. Interface ecology investigates the
dynamic interactions of media, cultures, and disciplines that
flow through interfaces.

—
Reply to this email directly or view it on GitHubhttps://github.com//issues/59#issuecomment-13234359.

---

Reply to this email directly or view it on GitHub:
#59 (comment)

I'm going to assign this to you, @AndrewKoons. This isn't a work item that you should work on RIGHT THIS SECOND, but it's certainly worth thinking about very seriously / incubating on.