Skip to main content

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index] [List Home]
Re: [mdt-ocl.dev] Question regarding operations on UnlimitedNatur al taking UnlimitedNatural argument

Hi Axel

The problem might be simpler.

There is no concrete syntax that can ever parse as an Integer!

-ve numbers are specified as unary negate expressions of positive numbers.

+ve number are UnlimitedNatural.

If you parse right it might not then go wrong, but you then have to worry about when '*' is treated consistently. Sometimes it's a distinct non-java.lang.Number and othertimes its a pragmatic -1.

'Reliably' is not possible until you localize stdlib declaration (4 places), analyzer location, analyzer checking, evaluation checking, evaluation dispatch, and another couple.

    Ed



On 19/04/2011 08:25, Axel Uhl wrote:
Aside from the 3.0 vs. 3 issue particularly in collections and the polymorphic collection operation lookup that doesn't work as expected, I think I got the invalid/null stuff under control using Laurent's tests. After commenting the collections tests with a FIXME where inherited operation specs are not found, and after commenting the 3.0 vs. 3 issues, also with a FIXME, I have only 9 failures left which all have to do with UnlimitedNatural. Those, however, are nasty particularly because the Integer-defined operations are not resolved for an UnlimitedInteger. So if we parsed non-negative integer literals as UnlimitedNaturalLiteral we'd currently mess things up as 1.+(-1) wouldn't be resolved because -1 is not an UnlimitedNatural, 1 is, and we have UnlimitedNatural::+(UnlimitedNatural), and Integer::+(Integer) is not found.

I'm inclined to at least for the special case of UnlimitedNatural introduce the superclass lookup in AbstractTypeChecker.findOperationMatching. This would solve the nasty UnlimitedNatural issue reliably, I think. I'll give it a try.

Best,
-- Axel

On 4/18/2011 4:30 PM, Willink, Ed wrote:
HI Axel

It's not easy. - I gave up.

The mature parser was written before UnlimitedNatural was properly
identified. I think only '*' is parsed as unlimited natural, although all
non-negative integers should be.

1.oclIsTypeOf(UnlimitedNatural) = true.

'*' really is a mess, requiring conversion to invalid when assigned to
Integer variable.

I have raised an OMG issue suggesting that +infinity, at least, exist for
all numerics.

------------------------------

I suggest that you try to bound your ambition to correct the mature code.

My intention was to do just 1% of the fixes and move on to the pivot for the
100%.

You may well be able to do 50%, perhaps even 75%, but is that really worth
it?

    Regards

        Ed

-----Original Message-----
From: mdt-ocl.dev-bounces@xxxxxxxxxxx
[mailto:mdt-ocl.dev-bounces@xxxxxxxxxxx] On Behalf Of Axel Uhl
Sent: 18 April 2011 15:22
To: MDT OCL mailing list
Subject: [mdt-ocl.dev] Question regarding operations on
UnlimitedNatural taking UnlimitedNatural argument

Hi,

there are operations defined on UnlimitedNatural in the 2.3
spec which
as argument take an UnlimitedNatural (e.g., div, mod, max,
min and the
comparison operations). The current parser creates IntegerLiteralExp
expressions for non-negative integer literals such as 0, 1, ...

This leads to a glitch for expressions such as

    *.div(1)

because * parses to an UnlimitedNaturalLiteralExp, 1 parses to an
IntegerLiteralExp, Integer does not conform to UnlimitedNatural and
hence the operation UnlimitedNatural::div(UnlimitedNatural) is not
applicable.

Now, Integer::div(Integer) would be applicable, but it's not
clear to me
whether these operations should be visible for the specialization
UnlimitedNatural. What's your take on this?

Currently, the "mature" implementation for Ecore gives up on any
expression of this sort, and I wonder whether and how to fix it.

Best,
-- Axel
_______________________________________________
mdt-ocl.dev mailing list
mdt-ocl.dev@xxxxxxxxxxx
https://dev.eclipse.org/mailman/listinfo/mdt-ocl.dev


Please consider the environment before printing a hard copy of this
e-mail.

The information contained in this e-mail is confidential. It is intended
only for the stated addressee(s) and access to it by any other person is
unauthorised. If you are not an addressee, you must not disclose, copy,
circulate or in any other way use or rely on the information contained in
this e-mail. Such unauthorised use may be unlawful. If you have received
this e-mail in error, please inform us immediately on +44 (0)118 986 8601
and delete it and all copies from your system.

Thales Research and Technology (UK) Limited. A company registered in
England and Wales. Registered Office: 2 Dashwood Lang Road, The Bourne
Business Park, Addlestone, Weybridge, Surrey KT15 2NX. Registered Number:
774298

Thales UK Limited. A company registered in England and Wales. Registered
Office: 2 Dashwood Lang Road, The Bourne Business Park, Addlestone,
Weybridge, Surrey KT15 2NX. Registered Number: 868273
_______________________________________________
mdt-ocl.dev mailing list
mdt-ocl.dev@xxxxxxxxxxx
https://dev.eclipse.org/mailman/listinfo/mdt-ocl.dev


_______________________________________________
mdt-ocl.dev mailing list
mdt-ocl.dev@xxxxxxxxxxx
https://dev.eclipse.org/mailman/listinfo/mdt-ocl.dev


-----
No virus found in this message.
Checked by AVG - www.avg.com
Version: 10.0.1209 / Virus Database: 1500/3582 - Release Date: 04/18/11





Back to the top