Euphoria
Ticket #413:
Qualify Std Library
-
Reported by
mattlewis
Nov 19, 2010
In light of ticket:343, we should qualify all/most/a lot of the standard library, since that will greatly improve the euphoria experience.
Details
1. Comment by mattlewis
Nov 21, 2010
std/sequence.e has been scrubbed. Also, it was needlessly including std/math.e and std/types.e.
2. Comment by mattlewis
Nov 21, 2010
sort.e was fine.
search.e is fixed.
3. Comment by DerekParnell
Nov 21, 2010
I'm doing some work on map.e right now so I'll do the qualifications for that file.
4. Comment by DerekParnell
Nov 22, 2010
Is there any advantage to using the "eu:" namespace to speed up resolution?
5. Comment by SDPringle
Nov 22, 2010
It is easy to miss things when doing this. I let the parser check the files by making copies of the standard library and changing the default namespace in them and including these copies.
namespace machine
public include std/memconst.e
public include std/copymemconst.e
ifdef SAFE then
public include std/safe.e as memory
elsedef
public include std/memory.e as memory
end ifdef
include std/dll.e
include std/copydll.e
include std/error.e
include std/copyerror.e
include std/types.e
include std/copytypes.e
6. Comment by jeremy
Nov 26, 2010
Do we have a list of ones yet to do? Maybe if the ticket detail comment contained a list, we could mark them off as we go.
7. Comment by DerekParnell
Nov 26, 2010
I'm just about finished doing map.e.
I'm a bit concerned about the apparent requirement that use "public include std/types.e" in search.e and filesys.e.
8. Comment by mattlewis
Nov 26, 2010
The "public include" is because we're using NO_ROUTINE_ID as a default argument.
The default arguments are parsed as code from the place where they are called. So if the file calling the function didn't already include types.e, it can't see NO_ROUTINE_ID.
By using this here, you're requiring that users of the file also use types.e, hence the "public include".
9. Comment by jeremy
Nov 26, 2010
This goes against every coding rule I know, but I wonder if it wouldn't be better to know the value of NO_ROUTINE_ID and place that as the default parameter in the function, as to not require public include type....
i.e.
public function abc(xyz, def, abc={-9,-8,-7,-1})
10. Comment by DerekParnell
Nov 26, 2010
Oh, I understand why it is being used, but it still concerns me that we are force to do it this way. I'd much rather we didn't need to do it.
11. Comment by mattlewis
Nov 26, 2010
What's the downside to the public include?
In any case, rather than hard coding a magic number, I'd rather create a constant in the file that uses it, but initialize it to the value of NO_ROUTINE_ID. That way, consumers only need to see the file, but the value stays consistent.
Also, using a default like that requires the construction of the sequence for each call, which, of course, has performance implications.
12. Comment by jeremy
Nov 26, 2010
public include? Nothing is wrong with it when you need it, but to need it for this case, I agree with Derek. Including files increments the visible symbols, thus more chance for collision and needing for qualifying calls. Does it also slow down the parsing of the given file since it has to resolve where method ABC came from?
You are right about a constant initialized via the include being better than a sequence, d'oh! Much better.
13. Comment by mattlewis
Nov 26, 2010
types.e doesn't include anything else, so it will be fully parsed as soon as it's included. Since NO_ROUTINE_ID is qualified, it should be resolved immediately.
I understand, of course, that additional visible names can lead to additional conflicts. The current solution is to not require the consumer of your code to rely on other parts of your library.
In theory, we could change the way recorded tokens are parsed. I don't fully understand that part of the code (CChris wrote it initially), so I couldn't guess at how difficult it would be to make those changes. But I suspect it would be difficult, and I'm not sure it would be any better than the current method.
14. Comment by jeremy
Nov 26, 2010
Is there a list of files yet to do?
15. Comment by ne1uno
Nov 26, 2010
if some user needs NO_ROUTINE_ID they include std/types.e
there is no known requirement they would need it. the use is internal. the public include is not necessary.
constant NO_ROUTINE_ID is used rather than the old default of -1 so an invalid routine_id would not pass silently as a choice to use a default compare or whatever.
16. Comment by ne1uno
Nov 26, 2010
I didn't intend to skip over the default argument aspect Matt discovered. transfer to a local constant sounds like the way to go. this kind of implementation detail should really be documented in the performance or internal part of the docs.
17. Comment by mattlewis
Dec 01, 2010
All of the std directory should be done (with the exception of map.e, which Derek is working). I've also done net/common.e, but no other files in subdirectories.
18. Comment by DerekParnell
Dec 01, 2010
Matt, just repeating my earlier question, does using the "eu:" namespace help parsing speed?
19. Comment by mattlewis
Dec 01, 2010
Sorry, no, that should not speed it up, since SC_PREDEF generally gets precedence.
20. Comment by jimcbrown
Dec 02, 2010
I finished up std/win32 and the ones in std/net that weren't already qualified.
Only stuff that's left is euphoria/tokenize.e and euphoria/syncolor.e and std/map.e
21. Comment by jeremy
Dec 03, 2010
Looking through map.e, I only found one or two places that were not already qualified, thus it's done and that was the last that needed qualified. Thus, this ticket is complete.
22. Comment by ne1uno
Dec 21, 2010
I don't find this ticket in the release notes? this seems to have been responsible for a huge improvement in startup speed.
23. Comment by jeremy
Dec 21, 2010
See: hg:euphoria/rev/534b8fa82bf3
changeset: 4317:534b8fa82bf3 tag: tip user: Jeremy Cowgar <jeremy@cowgar.com> date: Tue Dec 21 04:57:22 2010 -0500 files: docs/release/4.0.0.rc2.txt description: Added reference to ticket 413 in 4.0.0.RC2 release notes.
GitHub