Feature request: Fragment support

[tomokinakamaru]

Feature request: Fragment support

[tomokinakamaru]

Thank you for the request :)

Notation

I prefer the first notation $FOO = ...; without enforcing ALL_CAPS. I would also give ALL_CAPS names to fragments, but it can be a convention like in Java.

but that feels "fake" to me because none of the three keywords really do what they do in Java here - and it's really long-winded.

Agree, I also feel redundant because Silverchain does not provide public or non-final fragments.

However, for consistency, we should then definitely consider having keywords elsewhere in AG, for example class GroupLoader { } and rule MyReturnValue Method1() Method2();.

Adding keywords elsewhere definitely makes every part easy to understand, so we should work on it. However, we first need to discuss the grammar of AG in another issue; There are many points that we need to fix, since the current grammar is based on what I have designed long time ago before Silverchain focuses on the Java API generation :(

Fragment in Fragment

To reduce the repetition of an expression as much as possible, I think Silverchain should allow its users to put $FRAGMENT in the right hand side of a fragment statement (e.g. $FOO = method() $BAR;).

I am planning to implement the imperative interpretation of fragment statements, which does not allow forward references:

$FOOS_AND_BARS = foo()+ $BARS ; // <- Forward reference, error
$BARS = bar()+ ;

This way of interpretation is the same as the one used in the field declaration in Java.

For consistency with the class declaration, we can alternatively implement the declarative interpretation, which does allow forward references:

$FOOS_AND_BARS = foo()+ $BARS ; // <- No problem
$BARS = bar()+ ;

This way is less restrictive, but I think it's freedom that Silverchain users do not need. Furthermore, Silverchain needs to check the dependencies among fragments before code generation, to avoid infinite loop of fragment expansion. (Silverchain should throw an error before expanding $FOO and $BAR in $FOO = method()+ $BAR; $BAR = method()+ $FOO;.)

To summarize, I would like to hear your opinion on the following:

• Should Silverchain support fragment-in-fragment?

• Should Silverchain interpret fragment statements imperatively?

(My answer is YES for both)

[bannmann]

Should Silverchain support fragment-in-fragment?

Sure! Come to think of it, I think it's both useful and will simply be expected by developers.

Should Silverchain interpret fragment statements imperatively?

Yes. I see no need for the freedom granted by declarative interpretation either.

[bannmann]

However, we first need to discuss the grammar of AG in another issue

I'd love to do that!

Depending on the type of discussion, we could also take it to https://gitter.im/ which may be more suited for back-and-forth style conversations. However, so far our explain - ask questions - get opinions loop seems to work fine here :-)

[bannmann]

@tomokinakamaru, I found your commit 9e06d00 on feature/fragment and took the liberty of testing it with my code. The fragments feature works flawlessly; I was able to eliminate all redundancies.

[tomokinakamaru]

@bannmann Sorry for my late reply, it took long to update documents (#67) because I am not good at writing documents :(

Thank you for testing the fragment feature! I was going to ask you :) I will merge the branch feature/fragment.

---

[Gitter]
We can move to Gitter! It seems nice for back-and-forth style conversations though I have never used Gitter before. (If Gitter does not fit, we can move back here.) Anyway, I will create a community on Gitter later :)