[
Date Prev][
Date Next][
Thread Prev][
Thread Next][
Date Index][
Thread Index]
[
List Home]
Re: [m2t-dev] [backend] bugs and thoughts
|
Arno,
Coments below
Arno Haase a écrit :
Laurent,
First of all, let me apologize, this will be a lengthy mail :D.
not at all - quite the contrary, I found it pretty concise and to the
point.
1) I found the IfExpression you have defined in the backend for the
control flow. But there isn't any cases such as "an if with no else"
(I think such use cases could be handled by creating an "if" with an
LiteralExpression containing an empty String as the else, but it
would be better to have the backend perform this transparently) or
"if - else if - else". What is the expected way to implement this
last use case? An "if" with another "if" as the statement when false?
Or simply using a SwitchExpression that seems to present the right
behavior?
The backend is thoroughly functional - there are no statements but
only expressions, which by definition always return a value. So an "if
without else" makes no sense in this paradigm.
The SequenceExpression serves the purpose of "executing" several
expressions one after another, statement-like. It treats all
expressions except the last as "statements", i.e. it discards their
return values and executes them only to have their side effects.
Ok, didn't understand the purpose of the SequenceExpression correctly
(hence point 3). As for the "if - else if - else" case, I think the
correct way of implementing it is indeed to create IfExpression with
another IfExpression as the "else".
2) This might be the most annoying one I have faced since so hard to
track down : When using a CompositeTypeSystem, getting functions from
a java file through MiddleEnd#getFunctions() fails in NPE with the
root being the first line of JavaBeansType#init() :
- _superTypes = Collections.singleton
(ts.getRootTypesystem().findType (_javaClass.getSuperclass()));
It so happens that one of the java class as no superClasses, thus
_javaClass.getSuperclass() returning null and the execution failing
later on. I have had to completely comment out all of the lines of
CompositeTypeSystem that references the field _javaBeansTypesystem in
order to get rid of the error (I do not need the java beans types for
my use case ... why didn't you create a typeSystem for java beans as
you did for EMF, one that can be registered if needed and that isn't
used otherwise).
I do not understand this yet, but it vaguely sounds as if you are
using things differently from the way I intended them to be used. If
you send some code or explain some more, I will be happy to look into
it and advise you.
The reason why the Java type system is built-in is that Java is the
only language to actually implement "native" functions, and it is used
internally. This may not be necessary at some time in the future - but
that should be transparent, and there should be no situation when it
actually gets in the way - at least that's what I hope and intend ;-)
Sorry, seems my explanation wasn't clear enough. Here is a very small
unit test case that should throw the exception I mentionned. Note that
no exception is thrown when we do not register the EMFTypeSystem ... and
yet it is no longer thrown when the java beans typesystem is commented
out. As I said earlier, this exception was a hell to track down in order
to be able to carry on my testing. As a side note, you might need to
take a look at the patch I attached on bugzilla
https://bugs.eclipse.org/bugs/show_bug.cgi?id=225565 for this snippet
not to fail before even executing this far.
public class MiddleendTest extends TestCase {
public void testFailure() {
final CompositeTypesystem typeSystem = new CompositeTypesystem();
typeSystem.register(new EmfTypesystem());
final MiddleEnd middleEnd = MiddleEndFactory.create(typeSystem,
null);
/*
* We have no middle end registered for "xfdg" files, this isn't
an issue here since failure happens before we
* even search for a middle end while registering types.
*/
final FunctionDefContext functionContext =
middleEnd.getFunctions("void.xfdg");
}
}
3) You have defined a SequenceExpression that is described on the
wiki ( http://wiki.eclipse.org/M2TBackend ) as being "the subsequent
execution of several expressions"... yet I am puzzled by its
implementation :
protected Object evaluateInternal(ExecutionContext ctx) {
Object result = null;
for (ExpressionBase e: _inner)
result = e.evaluate(ctx);
return result;
}
The only result we'll get ... is the result of the very last
statement's evaluation since "result" is overriden by each new
evaluation. Is that how it is intended? If yes, is there an
expression that has been defined to allow us to have the backend
execute a sequence of expressions (let's say two LiteralExpression)
and get the result of both evaluations? The use case I have is
similar to (forgive the errors, I've never used xpand :D) :
«DEFINE function FOR uml::Element-»
«IF name != null-»
Element : «name»
Element type : «eClass»
«ENDIF»
And I would like to define the backend expressions needed : an
IfExpression with a condition, but what can I use as the "then part"
of this IF if not a SequenceExpression?
In the example you included, the then part is about concatenating the
results of several expressions into a single string. This is done
using a system library function - look into the Xpand middleend
implementation which does just this. This is *not* a situation for a
SequenceExpression.
(woops) indeed, this can be handled with String concatenation, which
solves my problem. Your answer to 1) highlighted the accurate purpose of
the SequenceExpression.
4) On to the Type System. You have provided us the way of defining
new BackendTypeSystem through the CompositeTypeSystem#register()
method. In the same fashion, you provided us with a way of defining
new BackendType and to tell that such or such BackendType is
assignment compatible with another through
BackendType#isAssignableFrom(). This is perfect ... but what if I
tell that RandomType is assignment-compatible with String? The
backend will fail to invoke functions defined with parameter of type
"RandomType" with a String parameter since it doesn't know how to
convert from String to Random.
We then need a way to provide our own converters, the same way you
did with the JavaBuiltinConverterFactory. What I did for now is
"hack" my way through by adding a method "addConverter" to the
JavaBuiltinConverterFactory and providing it with as key the Class on
which the converter applies, and as value the converter itself
(extending JavaBuiltinConverter). This doesn't seem like a solution
that could be applied since all types that need conversion are not
mandatory java.
I think type conversion should be handled by the BackendTypeSystem
itself when we provide it. Maybe we could discuss this a little
further? This truly is a blocking issue if we decide to use the
backend for our project (hence the "hack" I implemented to carry on
my tests). Except if I deeply misunderstood something (which can be
the case :p).
You are right, there is currently no way to register implicit type
conversions. It is a powerful feature, and I somewhat like the idea of
adding it, but it is extremely complex to integrate in a conceptually
clean way.
What you want is different from the JavaBuiltin stuff. The JavaBuiltin
stuff works only at the fringes of the system, i.e. when Java
functions are called, becasue there are several integer types in Java
but they are all represented by java.lang.Long in the backend.
Yes, what I did is but a mere hack to allow me to carry on my testing, I
am totally aware that this cannot be the good solution. As for the
example you give, I am happy you brang that out since it is involved in
a bug I was going to send you. I'll elaborate later in this mail.
You on the other hand probably want implicit type conversions for
function calls inside the backend (with conversions when a Java
function is called only as a special case), right?
yup, that's it.
Would you view such assignment compatibility as a part of a type
definition, introducing static dependencies between the types? Or
would you see it as something introduced by a certain compilation
unit, giving it a limited scope?
I must admit I don't get your last suggestion quite well. As for the
first, this seems promising, something like a "convert" method on the
interface BackendType which would allow us to tell the backend how to
effectively convert objects of a given type to (and from) ours would
likely be enough for most conversion needs.
5) Each of the Expressions provided by the backend need a "SourcePos"
object which seems to hold information on the source template and the
line number where we are located. Is this intended for debugguing
purposes? I couldn't find documentation on these.
SourcePos is a placeholder to support debugging, logging etc. - it is
currently largely transparent to the backend, and we will see what
information exactly is needed for this purpose.
6) Last but not least, some languages define functions with varargs.
This can happen in M2T languages (Acceleo comes in mind) as well as
in programming languages (Java 5 and function defined as "public void
varargs(Object... args)"). How are these dealed with by the backend?
Or if they are not, is there even plans to support such feature?
varargs are at the level of the concrete syntax, not of the backend.
If you want varargs, just add a List parameter in the backend and
transform accordingly.
5) and 6), thanks for the clarifications.
That's all there is for this mail, hope you are not sleeping or in
need of an aspirin by now ;) .
Oh, not at all. I am really glad for your feedback - it helps making
the backend meaningful for several languages, and your different way
of thinking and requirements are really interesting.
Have fun
- Arno
I'll now elaborate a little more on the bug I mentionned for 4). I have
faced problems with most of my function since polymorphic resolution
simply fails because of the type conversion the backend does. Let's say
I have defined a function "/public Object getElementAt(List, int)/" and,
perchance, there is an other function going by the same name in the
context, which signature is "/public Object getElementAt(List, long)/"
... what is called if I try to invoke something like a "/new
InvocationOnWhateverExpression("getElementAt", [Collection, Integer],
true, sourcePos)/"? Well it will be the function defined with a long! In
fact the very first will never get called since integer are converted to
long.
Worse yet, if I define a new "/getElementAt/" function with a type that
is assignment compatible from Integer ... it will be called instead with
an integer parameter. The underlying purpose of this argument is ... we
truly **need** the backend to define BackendTypes for each java
primitive for it to be usable. I can give an even worse example : try
and invoke the syslib's function "operatorPlus" with two integer ... and
the backend will end up invoking String concatenation on them, thus "1 +
1" resulting in "11".
I wound up defining an IntegerType, the syslib's functions for it as
well as modifying the LongType to allow assignment-compatibility from
Integer on it so that I could test the backend further... this will
obviously be a blocking issue for us, is there any plans from your side
to create the missing primitives (int, float, char, ...)? I think this
would also maker the JavaBuiltinConverterFactory obsolete.
I was also wondering ... is there a specific bugzilla for the backend? I
have created https://bugs.eclipse.org/bugs/show_bug.cgi?id=225565 on
eclipse bugzilla for Modeling / M2T / core. Should I create new bugs on
the xpand component instead?
Thanks for your time.
Laurent Goubet
Obeo
begin:vcard
fn:Laurent Goubet
n:Goubet;Laurent
org:<a href="http://www.obeo.fr/">Obeo</a>
email;internet:laurent.goubet@xxxxxxx
url:http://www.obeo.fr
version:2.1
end:vcard