This is just a thought, not a serious interest at this point. Since Groovy
targets the JVM and is supposedly a superset of Java, to some extent, it
adds additional flexibility to the programmer-centric methodology by
allowing easy use of optional types, followed by normal static types in
Java, and finally using types in ATS for the most rigor, all while using
the JVM. But – aside from those wanting to target the JVM – is this
really worth it, or does it make better sense to just do co-programming in
ATS and a completely dynamically typed language? I hope to get some actual
experience with ATS co-programming soon, probably with Perl, so maybe I’ll
have a better sense then.
I’m aware that currently there is no code generator for Java. I don’t know
if a code-generator for Groovy would be the right way to go for efficiency
reasons, but if it isn’t much different, it seems like that might be
preferable.
The caveat is, I don’t know to what extent Groovy is really a superset of
Java, so I don’t know if by supporting Groovy code generation you could
also claim to have Java support.
I think it makes a lot of sense to target Groovy (instead of Java).
I prefer targeting untyped languages in general as it means no need
to fight typechecking in the targeted language.
I am willing to implement atscc2groovy if someone can promise me
to use it to do a (small) project.
PS: By the way, targeting clojure makes a lot of sense, too :)On Tuesday, December 2, 2014 6:49:16 PM UTC-5, Brandon Barker wrote:
This is just a thought, not a serious interest at this point. Since Groovy
targets the JVM and is supposedly a superset of Java, to some extent, it
adds additional flexibility to the programmer-centric methodology by
allowing easy use of optional types, followed by normal static types in
Java, and finally using types in ATS for the most rigor, all while using
the JVM. But – aside from those wanting to target the JVM – is this
really worth it, or does it make better sense to just do co-programming in
ATS and a completely dynamically typed language? I hope to get some actual
experience with ATS co-programming soon, probably with Perl, so maybe I’ll
have a better sense then.
I’m aware that currently there is no code generator for Java. I don’t know
if a code-generator for Groovy would be the right way to go for efficiency
reasons, but if it isn’t much different, it seems like that might be
preferable.
The caveat is, I don’t know to what extent Groovy is really a superset of
Java, so I don’t know if by supporting Groovy code generation you could
also claim to have Java support.
Last year.On Thursday, December 4, 2014 3:31:30 AM UTC-5, gmhwxi wrote:
I had a brief encounter with Groovy last.
I think it makes a lot of sense to target Groovy (instead of Java).
I prefer targeting untyped languages in general as it means no need
to fight typechecking in the targeted language.
I am willing to implement atscc2groovy if someone can promise me
to use it to do a (small) project.
PS: By the way, targeting clojure makes a lot of sense, too
On Tuesday, December 2, 2014 6:49:16 PM UTC-5, Brandon Barker wrote:
This is just a thought, not a serious interest at this point. Since
Groovy targets the JVM and is supposedly a superset of Java, to some
extent, it adds additional flexibility to the programmer-centric
methodology by allowing easy use of optional types, followed by normal
static types in Java, and finally using types in ATS for the most rigor,
all while using the JVM. But – aside from those wanting to target the JVM
– is this really worth it, or does it make better sense to just do
co-programming in ATS and a completely dynamically typed language? I hope
to get some actual experience with ATS co-programming soon, probably with
Perl, so maybe I’ll have a better sense then.
I’m aware that currently there is no code generator for Java. I don’t
know if a code-generator for Groovy would be the right way to go for
efficiency reasons, but if it isn’t much different, it seems like that
might be preferable.
The caveat is, I don’t know to what extent Groovy is really a superset of
Java, so I don’t know if by supporting Groovy code generation you could
also claim to have Java support.
I think it makes a lot of sense to target Groovy (instead of Java).
I prefer targeting untyped languages in general as it means no need
to fight typechecking in the targeted language.
I am willing to implement atscc2groovy if someone can promise me
to use it to do a (small) project.
My current goal is to practice doing GUI programming in Java or Groovy
(don’t care which, the main issue is getting used to GUIs, and Groovy may
be simpler for this due to being more concise).
As an example app using co-programming, I was thinking of keeping the GUI
in Groovy (at least for now) to avoid having to model the API (SWT) in ATS,
especially since some people may like Swing more (I might be one of them…
packaging swt libs for different platforms is a bit annoying using java
build systems). The underlying logic could be a simple calculator in ATS,
ported from the existing calculator demo. I do not know if that is of
sufficient interest, but in principle it could be a good template for many
GUI apps.
Otherwise, I plan to just use JNI, which is fine for me as well for this
purpose. Sorry I don’t have anything more interesting at the moment. I have
an existing (closed-source) app involving cattle simulation in Java, but
that is not my baby, so it is too early to say if I could use it there.
PS: By the way, targeting clojure makes a lot of sense, too
Yes, I can imagine that would make porting to other lisp-like platforms
rather easy as well. I haven’t looked at it much though, and am less sure
if it makes as much sense for co-programming, but I don’t have any specific
reservations; I just know it is quite easy to mix in Java-like code in
Groovy. It doesn’t seem to fare well here: http://benchmarksgame.alioth.debian.org/u32/clojure.php Unfortunately
Groovy is not an option.
This is just a thought, not a serious interest at this point. Since
Groovy targets the JVM and is supposedly a superset of Java, to some
extent, it adds additional flexibility to the programmer-centric
methodology by allowing easy use of optional types, followed by normal
static types in Java, and finally using types in ATS for the most rigor,
all while using the JVM. But – aside from those wanting to target the JVM
– is this really worth it, or does it make better sense to just do
co-programming in ATS and a completely dynamically typed language? I hope
to get some actual experience with ATS co-programming soon, probably with
Perl, so maybe I’ll have a better sense then.
I’m aware that currently there is no code generator for Java. I don’t
know if a code-generator for Groovy would be the right way to go for
efficiency reasons, but if it isn’t much different, it seems like that
might be preferable.
The caveat is, I don’t know to what extent Groovy is really a superset of
Java, so I don’t know if by supporting Groovy code generation you could
also claim to have Java support.
