<!DOCTYPE html><html><head><title></title><style type="text/css">p.MsoNormal,p.MsoNoSpacing{margin:0}</style></head><body><div>Re: Platform support: I have access to Windows, Linux, and Mac machines, so i can run a quick test if need be. (My current development environment is on a Mac, so i'd need to set up a fresh environment on my Windows and Linux machines.) My assumption is the the EXCL flag being enabled by these modes is part of the basic support for the POSIX open() call - even the MSVC C standard library includes it as part of its emulated open(). It would of course be important to verify this by running the code.<br></div><div><br></div><div>Re: Names: I want to reiterate that the names in my branch were sketches. I did a quick survey of a handful of programming languages just now to see is there was any existing consensus. Rust and .NET call the behavior "create new" in their enumerations. The docs for Python and Ruby call the flag "exclusive create" or "exclusive access", reflecting the name of the underlying C flag. This seems to tell me that my initial suggestion of "no overwrite" doesn't really match up; i'd like to offer another suggestion of WriteCreateNewMode and ReadWriteCreateNewMode.<br></div><div><br></div><div>No worries about the slow reply! I've been there, so it's totally understandable.<br></div><div><br></div><div>-grey<br></div><div><br></div><div>On Tue, Mar 31, 2020, at 4:15 PM, Carter Schonwald wrote:<br></div><blockquote type="cite" id="qt"><div><div dir="auto">One really important question is what modes are actually promised by actual file systems on every posix or otherwise supported platforms . Table stakes is code should work well on every tier 1 platform and tier 2 as well <br></div><div dir="auto"><br></div><div dir="auto">And it’s been pointed out to me that this is part of the Haskell report so whatever final design is done needs to be excellent <br></div></div><div dir="auto"><br></div><div dir="auto">Meta aside : on and off I sometimes wonder what the world would be like if file systems weren’t stuck in posix minima tar pits (heck an Mvcc with transactions file system would rock). But that’s unrelated to improving the world we have. Do either way this at least starts a discussion about what we can do better today !<br></div><div dir="auto"><br></div><div dir="auto">Pardon the slow reply, I think everyone everywhere is having a very strange start to spring. <br></div><div dir="auto"><br></div><div dir="auto">Be well and look forward to improving bits and pieces of how we deal with files on computers ;) <br></div><div dir="auto"><br></div><div dir="auto">-Carter <br></div><div><div><br></div><div class="qt-gmail_quote"><div dir="ltr" class="qt-gmail_attr">On Tue, Mar 31, 2020 at 5:51 PM Carter Schonwald <<a href="mailto:carter.schonwald@gmail.com">carter.schonwald@gmail.com</a>> wrote:<br></div><blockquote class="qt-gmail_quote" style="margin-top:0px;margin-right:0px;margin-bottom:0px;margin-left:0.8ex;border-left-color:rgb(204, 204, 204);border-left-style:solid;border-left-width:1px;padding-left:1ex;"><div><div dir="auto">At least naively, this seems like a really good idea. <br></div></div><div dir="auto"><br></div><div dir="auto">1) do folks who have more experience across the range of supported platforms have any opinions about these additional semantics ?<br></div><div dir="auto"><br></div><div dir="auto">2) are these names suitably descriptive / unambiguous and or otherwise widely used / discoverable ? <br></div><div><div><div><br></div><div class="qt-gmail_quote"><div dir="ltr" class="qt-gmail_attr">On Mon, Mar 30, 2020 at 12:22 PM Grey Mitchell <<a href="mailto:grey@quietmisdreavus.net" target="_blank">grey@quietmisdreavus.net</a>> wrote:<br></div><blockquote class="qt-gmail_quote" style="margin-top:0px;margin-right:0px;margin-bottom:0px;margin-left:0.8ex;border-left-color:rgb(204, 204, 204);border-left-style:solid;border-left-width:1px;padding-left:1ex;"><div>The current behavior for System.IO.openFile will either truncate an existing<br></div><div> file (with WriteMode) or append new content to the end (with AppendMode).<br></div><div> However, there's another behavior that's available from the underlying API:<br></div><div> signal an error when the file already exists. I poked around at the code and i<br></div><div> think that with a couple extra variants of IOMode, this behavior could be added<br></div><div> with a relatively small patch.<br></div><div> <br></div><div> I have a branch pushed where i added this behavior:<br></div><div> <a href="https://gitlab.haskell.org/QuietMisdreavus/ghc/-/commit/1ff18d4d3fc63f42c371f4046ab07405299c6755" rel="noreferrer" target="_blank">https://gitlab.haskell.org/QuietMisdreavus/ghc/-/commit/1ff18d4d3fc63f42c371f4046ab07405299c6755</a><br></div><div> <br></div><div> I'm a relative newcomer to contributing to GHC or the base library, so if i'm<br></div><div> missing something in my patch please let me know. Specifically, i would like to<br></div><div> know is there's a place i can add a test for this behavior. I'm also open to<br></div><div> changing the names of the new IOModes - this was just something i wrote in to<br></div><div> get something working.<br></div><div> <br></div><div> Looking forward to working with maintainers to get this added!<br></div><div> <br></div><div> Thanks,<br></div><div> Grey Mitchell (@QuietMisdreavus)<br></div><div> _______________________________________________<br></div><div> Libraries mailing list<br></div><div> <a href="mailto:Libraries@haskell.org" target="_blank">Libraries@haskell.org</a><br></div><div> <a href="http://mail.haskell.org/cgi-bin/mailman/listinfo/libraries" rel="noreferrer" target="_blank">http://mail.haskell.org/cgi-bin/mailman/listinfo/libraries</a><br></div></blockquote></div></div></div></blockquote></div></div></blockquote><div><br></div><div id="sig101514696"><div>Thanks,</div><div>Grey</div></div><div><br></div></body></html>