-
Notifications
You must be signed in to change notification settings - Fork 387
Refactor string functions, rewrite tests #2235
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
Refactor string functions, rewrite tests #2235
Conversation
You need to add the test to |
libs/base/Data/String.idr
Outdated
unlines [""] = "\n" | ||
unlines = join "\n" |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
All patterns in pattern matching must have the same count of arguments they are matching at, so you'd better to have unlines ss = join "\n" ss
for the second line.
Anyway, this implementation is not equivalent to the current unlines
implementation. For example, unlines ["", ""]
now gives "\n\n"
, your implementation gives "\n"
.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Just to further the point made in the above comment, here's a reference to when the semantics of lines/unlines were most recently changed: #1585
That is, the current semantics were intentional instead of accidental so we should honor them in the changes made in this PR. That might make the suggestion of using join
less obvious of a win, at least for unlines, though I wish I'd thought to mention that on the open GitHub ticket in the first place.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Should unlines be written to use join
? I ended up writing the following which doesn't include join so I'm considering reverting this specific change since it won't be any different to the original code.
Idris2/libs/base/Data/String.idr
Lines 147 to 149 in 5433275
unlines : List String -> String | |
unlines [] = "" | |
unlines (x::xs) = (x ++ "\n") ++ (unlines xs) |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Since the function isn't publicly exported and it is transformed to fastUnlines
at runtime, I suppose it's neither here nor there whether it unpacks and runs on characters or not. I think I slightly prefer your new approach personally.
libs/base/Data/String.idr
Outdated
@@ -1,5 +1,6 @@ | |||
module Data.String | |||
|
|||
import Data.String.Extra |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
This looks like a dependency of base
to contrib
which should not be. I think it's better to move join
function from contrib
to base
for that case.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Big +1 from me on moving join
from contrib to base.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Idris2/libs/base/Data/String.idr
Lines 41 to 52 in 5433275
||| Remove the first `n` characters from a string. Returns the empty string if | |
||| the input string is too short. | |
public export | |
drop : (n : Nat) -> (input : String) -> String | |
drop n str = substr n (length str) str | |
||| Concatenate the strings from a `Foldable` containing strings, separated by | |
||| the given string. | |
public export | |
join : (sep : String) -> Foldable t => (xs : t String) -> String | |
join sep xs = drop (length sep) | |
(foldl (\acc, x => acc ++ sep ++ x) "" xs) |
How's this?
You've gone a different direction with your test file -- making a single file and name spacing it by folder in a way that reminds me of unit tests instead of sequentially increasing test folders. Your approach to the rename both makes sense to me and at the same time makes me wonder if it forces an awkward middle ground between the golden testing we have today and the unit testing we would ideally want for a module in the base library but cannot have yet because our test harness only supports golden. So, I'm on the fence about the file renames and relocation within the test folders, but aside from that (as noted above by @Z-snails) , you'll need to add the test to the Main file in the test harness for it to be picked up (it isn't running right now). |
Right now you've got some build failures in the compiler where you've added functions to Data.String that were previously added to the compiler's internal Libraries.Data.String.Extra. We can't remove the definitions from Libraries.Data.String.Extra until after the next release because the compiler depends on base and needs to be able to build against the previous version of base (before you added those functions to base). This is awkward, but not uncommon when working in the compiler codebase. You should be able to add After the next release, that workaround can be removed (as is done in another currently open PR for a similar reason: #2230). |
I'm immediately thinking the circumstance is different here and the compiler should I think complain if you try to hide the version you're adding now before it's available in the previous version of base. You'll probably need to use the second approach I mentioned of fully qualifying the calls to Libraries.Data.String.Extra. |
@@ -63,19 +63,19 @@ drop n str = substr n (length str) str | |||
||| the input string is too short. | |||
public export | |||
dropLast : (n : Nat) -> (input : String) -> String | |||
dropLast n str = reverse (drop n (reverse str)) | |||
dropLast n str = reverse (Libraries.Data.String.Extra.drop n (reverse str)) |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Sorry my previous comment was unclear. This fully qualified call change is necessary inside the compiler codebase but in contrib (this file), there won't be ambiguity -- more importantly, the Libraries.Data.String.Extra
module is not accessible from contrib.
In short, just revert the changes to this file.
20718fd
to
2c9bf24
Compare
Is this dead? Should I revive the effort in a different PR? |
Given that this has gone stale for quite a while I'm going to close this. If someone else wants to try again, feel free (@ProofOfKeags) |
Resolves #2172