|Subject:||Re: [Gm2] equality, inequality tests and structured types|
|Date:||Thu, 05 Feb 2009 20:43:40 +0100|
|User-agent:||Thunderbird 18.104.22.168 (Macintosh/20081209)|
Iztok Kobal wrote:
Not necessarily.I would agree with Thomas. And Gaius, we have already had some talk about opaque types implementation some time ago and I remember sending you some samples of opaque types usage in ISO library code from StonyBrook M2 and GardensPoint M2. Please consider also theese since I would suppose they had done their business according to standard.
That's not quite correct. We are talking here only about (in)equality tests between two opaque variables of the same type. Of course is there any comparison among different opaque types completely out of question. Would be against all the fundamental type checking philosophy of Modula-2. Moreover, comparing opaque variables has nothing to do with the hidden objects they represent. Therfore also nothing with the memory allocation needs of those hidden objects. In an OOP context I'd say, the comparison serves only the purpose to check whether the instantiation of the hidden object is the same or not.I do not really remember what was all about back then. Yet, the outcome was that the "problem" with opaque types is that their storage size is unknown in compile time for other modules since their implementation is hidden so some kind of generalization is needed - maybe considering them as being of size ADDRESS. And second, by no means can they be compared between each other since each and every of them represents different type.
All variables of type COMPLEX, since of the same type, are again in principle compatible. Whether ISO calls for (in)equality tests is not clear to me, since I am not familiar enough with ISO Modula-2. It would be logical but I could also imagine implementation restrictions, since comparison of COMPLEX is more than just the traditional, one register based equality test. But sure it could be done.As for COMPLEX, I would consider it as GM2 extension, atomic type, so direct comparission could be allowed between two variables of COMPLEX, including possibility to pass and return them to/from procedures. The implementation of type conversions via VAL() is yet to be considered - I suppose you already had implemented some kind of solution.
Regards, Iztok Breeden, Thomas (tmb) wrote:Gaius Mulley wrote: although interestingly (unless opaque types are covered the statement (a) - which I doubt) it disallows opaque and ADDRESS parameter compatibility. [This can be easily turned on/off via -fiso, -fpim2, -fpim3 and -fpim4 options] Andreas Fischlin <address@hidden> writes: I'm no sure I quite get what you are saying here. I believe the statement a) is quite appropriate. Indeed, I would expect this compatibility to be given in any good Modula-2 implementation. However, I see no reference there to opaque types. Do yo then mean what would be needed is another statement in the ISO standard, one that would cover also compatibility questions of opaque types in the case of variable proc parameters?Gaius Mulley wrote: oops - I was wrong (a) does imply opaque types - as I've found that the ISO standard says:"2. An opaque type may be redeclared as the address type, since the address type is also a pointer type.I spent some time this weekend pouring over the ISO document trying to determine if I could really allow a statement like this in a client module importing an Opaque. VAR c :TheImportedOpaque; BEGIN c := NIL; and I couldn't. The standard makes it clear that an Opaque type is not a pointer type except within the Impl module which elaborates the Opaque type as POINTER TO x or ADDRESS. It even states that baldly, though I don't have the paragraph at hand. Number 2. above is simply pointing out that ADDRESS is a pointer type and can be used by the Opaque types IMPLEMENTATION module to define it within its module only. So, it looks to me that for strict ISO conformability, an Opaque cannot be used in expressions or assignments or parameter substitution w/r/t pointers and ADDRESS without a coercion, except again, within the implementation module for that Opaque, as in Andreas' example, except via CAST() for ISO. But I do wish that ISO had made an exception for assigning NIL to Opaques, since without it you either have to initialize Opaques either by providing an init proc for the client to call, or having him use ovar := CAST(TheImportedOpaque, NIL), which might even be dubious under ISO :) regards, Tom _______________________________________________ gm2 mailing list address@hidden http://lists.nongnu.org/mailman/listinfo/gm2_______________________________________________ gm2 mailing list address@hidden http://lists.nongnu.org/mailman/listinfo/gm2
________________________________________________________________________ ETH Zurich Prof. Dr. Andreas Fischlin Systems Ecology - Institute of Integrative Biology CHN E 21.1 Universitaetstrasse 16 8092 Zurich SWITZERLAND address@hidden www.sysecol.ethz.ch +41 44 633-6090 phone +41 44 633-1136 fax Make it as simple as possible, but distrust it! ________________________________________________________________________
|[Prev in Thread]||Current Thread||[Next in Thread]|