Euphoria
Ticket #322:
Interpreter is not trying to use the correct function.
-
Reported by
SDPringle
Nov 05, 2010
In the following program, there are three functions called 'get' in three different included files. Two take two arguments and the first takes only one. One call in particular to 'get' is qualified (has the namespace) and in this namespace is a 'get' that takes two arguments. and we try to call the two argument one but instead the parser tells me that 'get' requires just one argument.
link to the code
Details
1. Comment by jeremy
Nov 05, 2010
It would be very helpful to include short code in the ticket that shows the bug, not links to your website.
2. Comment by mattlewis
Nov 05, 2010
Although an actual link would be useful, too. This ticket has...neither!
3. Comment by SDPringle
Nov 05, 2010
http://shawnpringle.webs.com/software.htm . The same place you went a few days ago.
4. Comment by jeremy
Nov 05, 2010
What about people viewing this ticket who didn't view your ticket a few days ago? Further, I don't remember what ticket I viewed a few days ago or what the link was. Not being mean but more detailed bug reports and short examples of the bug right here in the ticket is the proper way to write bug reports. It will allow them to be fixed w/o all this interaction which is just slowing everyone down.
5. Comment by mattlewis
Nov 05, 2010
Shawn, a ticket shouldn't magically refer to other tickets.
6. Comment by mattlewis
Nov 05, 2010
Also, once again, you didn't include all of your code. How hard is this?
7. Comment by jimcbrown
Nov 05, 2010
As usual, I've cobbled together the code as best I could and included a runme.sh (this time in sm/runme.sh). See http://malcom.unkmar.com/lostsouls/322r.zip - under Linux, I am fully able to reproduce the problem with this.
8. Comment by mattlewis
Nov 05, 2010
Yes, I'm seeing it too. It shouldn't be this difficult.
9. Comment by SDPringle
Nov 05, 2010
setting status to accepted, and milestone 4.0rc1
10. Comment by mattlewis
Nov 05, 2010
The parser is finding the global get() from the 311 std library.
11. Comment by jimcbrown
Nov 05, 2010
Why is this ticket assigned to the Binder? WTF
12. Comment by mattlewis
Nov 05, 2010
Changing the category to language, since this is about how symbols are resolved, regardless of the mode of execution.
13. Comment by mattlewis
Nov 05, 2010
We were immediately resolving globals that were indirectly included (i.e., not directly or publicly included), which lead to premature resolution (in this case, from the legacy standard library).
Indirectly included globals are now not fully resolved until the end, when we resolve globals not included.
14. Comment by eumario
Nov 05, 2010
I can confirm, that this is not fixed, as of Revision 3870, as resolution of namespaced tagged routines are being ignored, when a local routine is defined of same name. Namespace should have priority over local. See http://repos.ruby-im.net/ooeu/file/f3b3d1c680c4/lib/backend/objectspace.e, Line 67 is calling the Class:get_attributes(), but Euphoria is actually calling get_attributes defined in objectspace.e at line 162.
15. Comment by eumario
Nov 05, 2010
Correct URL for previous comment: http://repos.ruby-im.net/ooeu/file/febed1c680c4/lib/backend/objectspace.e
16. Comment by jimcbrown
Nov 05, 2010
I think that's a different bug, with a different cause. The bug here was caused by a global in a different file overriding a qualified (namespace'd) public in a third file.
Your case, you have a local (well public and namespaced, but declared later in the same file) that overrides a qualified public.
17. Comment by jimcbrown
Nov 05, 2010
You can reproduce with just two files:
-- t.e
namespace t
include g.e
puts(1, "expecting g:x to be called here\n")
puts(1, g:x())
public function x()
return "t:x was called\n"
end function
-- g.e
namespace g
include t.e
public function x()
return "g:x was called\n"
end function
then run eui g.e
Note that the two files must include each other, or the bug won't happen. Also note that g.e must be seen by the parse tree before t.e, or the bug won't happen.
18. Comment by mattlewis
Nov 06, 2010
The qualified public issue found by eumario should be fixed now.
19. Comment by eumario
Nov 08, 2010
I have confirmed that this bug is fixed, and working properly now.
GitHub