Re: [Jastadd] Feature request: avoiding list rewrites when unnecessary

From: Jesper qvist <jesper.oqvist_at_cs.lth.se>
Date: Mon, 22 Oct 2012 13:32:33 +0200

Hello Jesper,

Could you provide more context for that code example? Why is a not
final? Is that code within a rewrite method?

/Jesper

On 10/22/2012 11:41 AM, Jesper Mattsson wrote:
>
> Hi all
>
> Given a list X*, both getXList() and addX() will trigger a rewrite of
> each child in the list. As far as I can tell, this is because a rewite
> can be declared for a specific list that returns a list of elements,
> that will then be inlined into the original list. I can see that the
> general behavior of List must keep these rewrites of all its children,
> even though they are only needed in special cases. However, since
> those cases can be detected at compile time, it should be possible to
> generate a use of getChildNoTransform() to get the list unless the
> rewrite of the list is needed.
>
> Or am I missing some case where rewriting the entire list is needed?
>
> One example where the list rewrites can create problems is:
>
> AST:
>
> A ::= B* /*... etc */;
>
> And A is created by the code:
>
> A a = new A();
>
> for (BCreator b : getBCreators())
>
> a.addB(b.createB());
>
> // ... fill in the rest of A
>
> This approach seems very reasonable to the user, and is useful when
> there are subclasses that share some of that code, but not all. This
> will, however, create two problems:
>
> 1.Since the A node isn't final yet, the B list won't be final either.
> Thus each call to addB() will trigger a rewrite of the list, and in
> turn an attempt to rewrite each child already in the list. This will
> have an O(n^2 ) complexity, which for us have proven significant for
> large models.
>
> 2.If B has a rewrite that uses inherited attributes that are not
> defined on A, then this code will crash with a NullPointerException.
>
> Of course a simple solution is to use addBNoTransform() instead, but I
> feel that that this encourages users to routinely use the NoTransform
> versions of these methods -- a habit that strikes me as potentially
> harmful.
>
> Jesper
>
> *Jesper MATTSSON, MSc*
>
> Software Developer & IT Administrator
>
> Phone direct: +46 73 324 5909
>
> Email: jesper.mattsson_at_modelon.com <mailto:jesper.mattsson_at_modelon.com>
>
>
> Description: Description: Modelon_2011_Gradient_RGB_400
>
> ------------------------------------------------------------------------
>
> Modelon AB
> Ideon Science Park
> SE-223 70 Lund, Sweden
>
>
>
> Phone: +46 46 286 2200
> Fax: +46 46 286 2201
>
>
>
>
> Web: http://www.modelon.com <http://www.modelon.com/>
>
> This email and any attachments are intended solely for the use of the
> individual or entity to whom it is addressed and may be confidential
> and/or privileged. If you are not one of the named recipients or have
> received this email in error, (i) you should not read, disclose, or
> copy it, (ii) please notify sender of your receipt by reply email and
> delete this email and all attachments, (iii) Modelon does not accept
> or assume any liability or responsibility for any use of or reliance
> on this email.
>
>
> _______________________________________________
> JastAdd mailing list
> JastAdd_at_cs.lth.se
> https://mail1.cs.lth.se/cgi-bin/mailman/listinfo/jastadd
Received on Mon Oct 22 2012 - 13:32:11 CEST

This archive was generated by hypermail 2.3.0 : Wed Apr 16 2014 - 17:19:06 CEST