[Bug 1073] New: readData data type problem
https://bugzilla.mcs.anl.gov/swift/show_bug.cgi?id=1073 Summary: readData data type problem Product: Swift Version: 0.94 Platform: PC OS/Version: Mac OS Status: ASSIGNED Severity: normal Priority: P2 Component: SwiftScript language AssignedTo: [email protected] ReportedBy: [email protected] file seedfile<"output/seed.dat">; # Dynamically generated bias for simulation ensemble seedfile = genseed(genseed_prog, 1); # int s = @toInt(readData(seedfile)); tracef("Generated seed=%i\n", readData(seedfile)); yields: Could not start execution Failed to convert .swiftx to .kml for p6.swift Not typed properly: <variable>swift#callintermediate</variable> -- Configure bugmail: https://bugzilla.mcs.anl.gov/swift/userprefs.cgi?tab=email ------- You are receiving this mail because: ------- You are watching all bug changes.
https://bugzilla.mcs.anl.gov/swift/show_bug.cgi?id=1073 --- Comment #1 from Mihael Hategan <[email protected]> 2013-08-25 13:30:35 --- Hmm. I think there is a deeper problem there. readData does not have a static return type. It is inferred by looking at the lvalue. So when you have: int v; v = readData(...); It's obvious that readData should return an int and a check is made a run-time to make sure that is the case (or at least I hope that check is made). In the case of an expression, the type that readData should return cannot be clearly inferred, since multiple types may be valid in the expression term where readData appears. For example: sum = readData(f1) + readData(f2); Here, the terms can be either ints, or floats, or strings, some combinations being valid, some not. I propose that a different error message be printed in this case: "Cannot infer function return type for 'readData' at x.swift, line y. Assign the result from 'readData' to a variable instead of using it directly in an expression." That's pretty easy to do. An alternative would be to support type casting in such situations: sum = (int) readData(f1) + (int) readData(f2); I am not sure if the parser already supports this, so it might be easy or hard to add. -- Configure bugmail: https://bugzilla.mcs.anl.gov/swift/userprefs.cgi?tab=email ------- You are receiving this mail because: ------- You are watching all bug changes.
https://bugzilla.mcs.anl.gov/swift/show_bug.cgi?id=1073 --- Comment #2 from Michael Wilde <[email protected]> 2013-08-25 17:55:20 --- I think casting needs more thought. For now, I think we can instead used extractInt() and extractFloat() in cases like the one reported in this ticket. (I was going to suggest creating readInt() etc, when I realized they were already partly there in the form of extractInt() and extractFloat()). Can we reliably infer when an array should be returned from these? And return the "cannot infer error" you suggest below when readData()'s return cant be unambiguously inferred? Alternatively: if we extend Swift's type conversion primitives (and ideally unify those of /K and /T: http://www.mcs.anl.gov/exm/local/guides/swift.html#_type_conversion and http://www.swift-lang.org/guides/trunk/userguide/userguide.html#_toint etc) then can we safely do toFloat(readData(f)) instead of the casts? -- Configure bugmail: https://bugzilla.mcs.anl.gov/swift/userprefs.cgi?tab=email ------- You are receiving this mail because: ------- You are watching all bug changes.
https://bugzilla.mcs.anl.gov/swift/show_bug.cgi?id=1073 --- Comment #3 from Mihael Hategan <[email protected]> 2013-08-25 18:47:09 --- Using inference as much as possible and if that fails throwing an error is my plan. toFloat(readData()) does not, by itself, solve the problem, since it only covers one type. There is no to<someUserDefinedType>, so I do think that the right solution is eventually inference as much as possible and casting if that fails. Java does something similar when you call a polymorphic method with a null parameter or when you have both m(Object) and m(Object...) methods (although in the later case it is only a warning). Example: void m(Integer i){...} void m(Double i){...} m(null); // compilation fails m((Integer) null); // compilation succeeds I don't see a difference in what can be achieved with the Swift/T primitives vs. the Swift/K primitives. It is pretty sad that Swift/T has different primitives there. -- Configure bugmail: https://bugzilla.mcs.anl.gov/swift/userprefs.cgi?tab=email ------- You are receiving this mail because: ------- You are watching all bug changes.
https://bugzilla.mcs.anl.gov/swift/show_bug.cgi?id=1073 Mihael Hategan <[email protected]> changed: What |Removed |Added ---------------------------------------------------------------------------- Status|ASSIGNED |RESOLVED Resolution| |FIXED --- Comment #4 from Mihael Hategan <[email protected]> 2013-08-26 02:33:56 --- A preliminary fix is in SVN. It could use some improvements, but readData (or other (void *) returning procs) will work if: - it's assigned directly: int j = readData(...); - it is an actual argument to a function or procedure whose respective formal argument is a non-wildcard type*: (int r) fn(int i) {...} fn(readData(...)); (*) only built-in procs/functions can have parameters with wildcard types. These are things like toString(x), where x can be an expression of any type. -- Configure bugmail: https://bugzilla.mcs.anl.gov/swift/userprefs.cgi?tab=email ------- You are receiving this mail because: ------- You are watching all bug changes.
participants (1)
-
bugzilla-daemon＠mcs.anl.gov