profile
viewpoint
If you are wondering where the data of this site comes from, please visit https://api.github.com/users/mrkkrp/events. GitMemory does not store any data, but only uses NGINX to cache data for a period of time. The idea behind GitMemory is simply to give users a better reading experience.
Mark Karpov mrkkrp @tweag Paris, France https://markkarpov.com Software engineer at @tweag

commercialhaskell/stack 3550

The Haskell Tool Stack

matsievskiysv/vimish-fold 225

Vim-like text folding for Emacs

commercialhaskell/path 114

Typed filepath

libre-man/unix-opts 79

Unix-style command line options parser

mmark-md/mmark 75

Strict markdown processor for writers

mrkkrp/ace-popup-menu 64

Replace GUI popup menu in Emacs with something more efficient

mrkkrp/char-menu 19

Create a menu for fast insertion of arbitrary symbols

cbaggers/mk-string-metrics 17

Calculate various string metrics efficiently in Common Lisp (Damerau-Levenshtein, Hamming, Jaro, Jaro-Winkler, Levenshtein, etc.)

mrkkrp/avy-menu 14

An Avy-powered popup menu

mmark-md/mmark-ext 10

Commonly useful extensions for the MMark markdown processor

pull request commentUnkindPartition/temporary

Add mkTempFileName, fixes #10

No, I think it would be very useful. The utility is not the same as complexity.

The trick with the temporary directory was non-obvious to me, and if I needed a temporary file name, I'd probably end up with a solution similar to @hasufell's. By providing this function, we solve a real problem that users have and save them from inventing broken solutions.

hasufell

comment created time in 5 hours

release ocaml-community/utop

2.8.0

released time in 6 hours

startedgmarpons/asciidoc-hs

started time in 6 hours

startedakabe/ocaml-jupyter

started time in 11 hours

pull request commenttweag/ormolu

Simplify p_conDecl GADT rendering by using p_hsType

Thanks!

expipiplus1

comment created time in 13 hours

pull request commentUnkindPartition/temporary

Add mkTempFileName, fixes #10

I like the idea of creating a temporary directory and returning a file from there. @Fuuzetsu would you be ok with putting that logic into mkTempFileName (and documenting that that's what it's doing)?

I could but it'd just be something like

temporaryFileName :: FilePath -> String -> IO FilePath
temporaryFileName dir template = combine <$> createTempDirectory dir template <*> "predetermined_filename"

Seems of questionable utility in the library, no?

hasufell

comment created time in 15 hours

issue closedtweag/ormolu

Placement of comma for lists, records, tuples, function type signatures...

TLDR It is unreasonable to start putting commas at the end of lines.

There was a ticket already on this topic that was about making this configurable in #497

In this ticket, however, I am not proposing making ormolu configurable. This issue is about changing the default, because current formatting choice is vastly worse than what the defacto Haskell style is.

Of course, my personal preference plays a role in me opening this ticket, but I will put it aside and will show facts instead.

I have looked at arguments in the blogpost in favor of comma placement at the end rather that at the beginning:

Multiline pattern matching

While this popular formatting choice works in expressions, it’s a parse error if used in a pattern, because everything in a multiline pattern should be more indented than the opening parenthesis.

Multiline pattern matching in case statements is rather uncommon, especially when compared with popular formatting choice. I even had to google it in order to see what it actually means.

For anyone reading this here is an example. These two will parse:

bar :: Num a => [a] -> a
bar [ x
    , y
    , z
    ] = x + y + z
baz :: Num a => [a] -> a
baz xs =
  case xs of
    [ x,
      y,
      z ] -> x + y + z

But this will not:

baz :: Num a => [a] -> a
baz xs =
  case xs of
    [ x
    , y
    , z ] -> x + y + z

For the curious here is a ghc issue that tries to improve the error message about it. IMHO it would be better to fix ghc to support such syntax, rather than use it as an argument to change formatting style.

Trailing comma is now supported by ghc

module Foo 
  ( foo,
    bar,
  ) where

vs

module Foo 
  ( foo
  , bar
  ) where

Did you notice that we also add trailing commas where possible, for example, in export lists? Our ability to do this comes from a relatively new feature in Haskell—it helps with Ormolu’s goal of achieving minimal diffs too. If we try to remember where leading commas come from, Johan Tibell’s style guide comes to mind. The author said later:

"[…] I designed [Haskell style guide] to work with the lack of support for a trailing comma. If we supported a trailing comma my style guide would probably be different."

There you have it: GHC supports a trailing comma now, so it’s not unreasonable to start putting commas at the end of lines.

That argument works for exports only and we do lack trailing comma support, so Johan Tibell's design is still valid.

Coming from other languages

This style is also more familiar to programmers who come to Haskell from other languages.

I think this is the worst argument of all. We don't need to change the style that people used for decades just because other languages do it and new people are accustomed to it. Haskell is unique in many aspects and many of those aspects is what makes it very powerful.

Negative affects of comma placement

I really don't think that above arguments are strong enough to enforce the same style in all other places affected by that decision:

  • lists
  • records
  • tuples
  • derivation clauses
  • function class constraint list
  • super class constraints list

If we did have the ability to place trailing comma at the end of all of these, then it probably would not be such a big deal, just as Johan Tibell said. Because then the only downside is that we have to type an extra symbol per line and possibly adjust our eyes a bit. However trailing comma is not possible and it is unlikely that ghc will ever change that. It'll definitely never be adjusted for tuples, since trailing comma in tuples implies TupleSections.

The downside of this style without support for a trailing comma is significant IMHO, because it has a very negative impact on the git diff. Here are two sample diffs:

+++ b/haskell/ormolu-trailing-comma/classic.hs
@@ -8,6 +8,7 @@ lists =
   [ "It is often lists do not fit into a single line."
   , "We need to format them in a readable fashion"
   , "without compromising functionality."
+  , "Placement of commas at the end increases git diffs!"
   ]
 
 data Record =
@@ -15,6 +16,7 @@ data Record =
     { records :: String
     , are :: Bool
     , no :: Bool
+    , exception :: SomeException
     }
 
 myRecord :: Record
@@ -23,6 +25,7 @@ myRecord =
     { records = "Records are also suscpetible to trailing comma problem"
     , are = True
     , no = False
+    , exception = toException StackOverflow
     }
 
 
@@ -32,9 +35,11 @@ tuples ::
      ( String
      , String
      , VeryLongTypeNameThatCausesForTupleiInTheTypeSignatureToWrapAroundTooAmIRight
+     , Bool
      )
 tuples =
   ( "It is less common for tuples to not fit into a single line."
   , "However it does still happen"
   , AmIRight
+  , True
   )
+++ b/haskell/ormolu-trailing-comma/ormolu.hs
@@ -7,13 +7,15 @@ lists :: [String]
 lists =
   [ "It is often that lists do not fit into a single line.",
     "We need to format them in a readable fashion",
-    "without compromising functionality."
+    "without compromising functionality.",
+    "Placement of commas at the end increases git diffs!"
   ]
 
 data Record = Record
   { records :: String,
     are :: Bool,
-    no :: Bool
+    no :: Bool,
+    exception :: SomeException
   }
 
 myRecord :: Record
@@ -21,7 +23,8 @@ myRecord =
   Record
     { records = "Records are aslo suscpetible to trailing comma problem",
       are = True,
-      no = False
+      no = False,
+      exception = toException StackOverflow
     }
 
 data VeryLongTypeNameThatCausesForTupleiInTheTypeSignatureToWrapAroundTooAmIRight = AmIRight
@@ -29,10 +32,12 @@ data VeryLongTypeNameThatCausesForTupleiInTheTypeSignatureToWrapAroundTooAmIRigh
 tuples ::
   ( String,
     String,
-    VeryLongTypeNameThatCausesForTupleiInTheTypeSignatureToWrapAroundTooAmIRight
+    VeryLongTypeNameThatCausesForTupleiInTheTypeSignatureToWrapAroundTooAmIRight,
+    Bool
   )
 tuples =
   ( "It is less common for tuples to not fit into a single line.",
     "However it does still happen",
-    AmIRight
+    AmIRight,
+    True
   )

We clearly get one unnecessary line of diff for every place where we append an element at the end.

closed time in 16 hours

lehins

issue commenttweag/ormolu

Placement of comma for lists, records, tuples, function type signatures...

In this kind of discussion no argument of ultimate convincing power is possible

If I only knew that I would not bother wasting my time on this. I'll make sure not to make that mistake twice.

The simplest reason why this is not going to change is that it would cause a lot of reformatting in existing projects, which we do not want.

If I understand you correctly, you are saying that whatever wrong decisions you have made about formatting style will never be fixed. Moreover, without lack of configuration users don't even have a choice of opting in for a fix, they are simply stuck with those bad decisions. Does not seems like a good policy/design decision to me. But hey, who am I to complain at free software. I wish you all the luck with this project.

lehins

comment created time in 16 hours

issue commenttweag/ormolu

Layout is sometimes indented less than the line of the layout trigger

I don't recall the exact original input. Obviously x was a much longer pattern (hence the newline), and the case branches were indented further. Something like this:

foo | Some (Really Long (Pattern x) Goes Here) <-
      someOther really long expression goes here = case x of
        5 -> True
        _ -> False
cdsmith

comment created time in 19 hours

issue closedUnkindPartition/temporary

Functions for getting temporary filenames/directories (without creating them)?

All the functions in this package already create said files/directories. This might not be desired, e.g. when the temp filename is the destination of an atomic move operation.

closed time in a day

hasufell

pull request commentUnkindPartition/temporary

Add mkTempFileName, fixes #10

Ok, after reading the subsequent discussion, I have to side with @Fuuzetsu. Sorry @hasufell for prematurely asking you to prepare a PR.

By the way, the unix.stackexchange answer you reference is concerned with mktemp(1), while Mateusz was arguing against mktemp(3).

I like the idea of creating a temporary directory and returning a file from there. @Fuuzetsu would you be ok with putting that logic into mkTempFileName (and documenting that that's what it's doing)?

hasufell

comment created time in a day

push eventtweag/linear-constraints

Csongor Kiss

commit sha 68ff69a76685650d2dd8d99ca7324b808801a57b

Move sidenotes out of figure (fix compile)

view details

push time in a day

starteddinosaure/cri

started time in a day

starteddinosaure/cri

started time in a day

issue commenttweag/ormolu

DISABLED ormolu remove empty lines

I expect that ORMOLU_DISABLE can fully disable ormolu, but it continues removing empty lines.

@ryukzak Note that there is an exception regarding the indentation level in the regions where formatting is disabled. See #601.

ryukzak

comment created time in a day

PR opened tweag/ormolu

cutting out disabled regions

This is meant to close #673 and close #708.

The idea is to cut out the disabled regions in the preprocessing, and paste them back in the postprocessing, instead of commenting them out.

When cutting out the disabled regions we reduce the indentation in each of them. The disabling and enabling markers bounding the region are not cut out (they are not treated as a part of the disabled region), but only normalized. Ormolu then finds the right indentation level for the disabling marker, treating it like a normal comment. In the postprocessing we paste the disabled regions back between the markers. The indentation level of a region is adjusted basing on the indentation level of the disabling marker.

I admit that the whole solution is somewhat hacky (but so is the current one). The pasting will go wrong if a new {- ORMOLU_DISABLE -} line somehow appears in the code as a result of formatting, or if an existing one disappears. I have not found a case when this may happen, but perhaps there should be an explicit error in postprocessing when the number of cut-out disabled regions does not match the number of {- ORMOLU_DISABLE -} markers.

The readability of the cutting/pasting code can probably be improved, and there are possibly some other details to be tweaked, but I'd love to get some feedback first.

+184 -89

0 comment

18 changed files

pr created time in a day

release mirage/repr

0.4.0

released time in 2 days

release mirage/repr

0.4.0

released time in 2 days

issue commenttweag/ormolu

Don't add a blank line between kind signatures and types

Looks like it. I guess I have an ormolu from before that patch. Thanks!

cdsmith

comment created time in 2 days

issue closedtweag/ormolu

Don't add a blank line between kind signatures and types

Ormolu insists on adding a blank line between a kind signature and the corresponding type declaration. This is inconsistent with functions, where it doesn't add a line after the type declaration. I'd like it to omit that line for kind signatures, too.

closed time in 2 days

cdsmith

issue openedtweag/terraform-nixos

Pass arguments to nixos_config derivation

Is your feature request related to a problem? Please describe. I want to parameterize my NixOS config based on some resource attributes (i.e. aws_instance.xxx.public_dns), but this module doesn't have a good way to pass inputs to the configuration.

Describe the solution you'd like

  • This module should provide an extra argument for derivation parameters, i.e. derivation_args or similar.
  • The NixOS configuration file should be a function (i.e. { myAddress }: ...) when arguments are passed.
  • The derivation should rebuild and redeploy every time input changes cause a different output.

Describe alternatives you've considered It gets really annoying to use a raw string instead of a .nix file, especially when I need string interpolation, so I want to keep it in a separate file.

Additional context I made a really primitive branch that does this here. I can then do extra_eval_args = [ "--arg" "configArgs" "..." ]; but the inputs don't update on subsequent runs of terraform plan. Changes to the configuration are detected and applied correctly, but with an old value of configArgs that doesn't apply anymore. This is probably because I'm using Terraform string interpolation in the argument, and I want it to reevaluate when the result of interpolation changes.

created time in 2 days

startedandorp/IdrisExtSTGCodegen

started time in 2 days

Pull request review commentUnkindPartition/temporary

Add mkTempFileName, fixes #10

 mkPrivateDir s = System.Posix.createDirectory s 0o700 -- "/home/feuerbach" getCanonicalTemporaryDirectory :: IO FilePath getCanonicalTemporaryDirectory = getTemporaryDirectory >>= canonicalizePath+++-- | Make a temporary file or directory name in the given directory, similar to unix 'mktemp'.+-- This does not create a file.+--+-- Note that this might be subject to race conditions. Only use this on secure directories.+mkTempFileName :: FilePath   -- ^ directory in which to test for available random filenames+               -> String     -- ^ File name template. If the template is \"foo.ext\" then+                             -- the created file will be \"fooXXX.ext\" where XXX is some+                             -- random number. Note that this should not contain any path+                             -- separator characters.+               -> IO FilePath+mkTempFileName tmp_dir template

You didn't really read what I said.

The function in base has the same randomization trick. So if you create a million files and forget to clean them up, there's a chance the next process will hang, because it's iterating through a million already existing files.

Wrt the security thing: WE ALREADY ESTABLISHED THAT IT'S ONLY REASONABLE IN A SECURE DIRECTORY.

hasufell

comment created time in 2 days

issue commentUnkindPartition/temporary

Functions for getting temporary filenames/directories (without creating them)?

Don't babysit users.

I'm not trying to. I'm trying to not add stuff to the API that's broken majority of the time.

The only babysitting happening is addition of this basically trivial function for no good reason.

The filesystem is a shared resource, half of the functions in directory are non-atomic. base can leak file handles etc etc.

"Other things are broken so let's make it even worse"?

hasufell

comment created time in 3 days

pull request commentUnkindPartition/temporary

Add mkTempFileName, fixes #10

I'm completely -1 of adding a function to a library that's obviously broken if used without great care: I don't see the point of adding a landmine to the API for something as easy to implement in a separate library or program as this.

Maybe @UnkindPartition disagrees though.

hasufell

comment created time in 3 days

Pull request review commentUnkindPartition/temporary

Add mkTempFileName, fixes #10

 mkPrivateDir s = System.Posix.createDirectory s 0o700 -- "/home/feuerbach" getCanonicalTemporaryDirectory :: IO FilePath getCanonicalTemporaryDirectory = getTemporaryDirectory >>= canonicalizePath+++-- | Make a temporary file or directory name in the given directory, similar to unix 'mktemp'.+-- This does not create a file.+--+-- Note that this might be subject to race conditions. Only use this on secure directories.+mkTempFileName :: FilePath   -- ^ directory in which to test for available random filenames+               -> String     -- ^ File name template. If the template is \"foo.ext\" then+                             -- the created file will be \"fooXXX.ext\" where XXX is some+                             -- random number. Note that this should not contain any path+                             -- separator characters.+               -> IO FilePath+mkTempFileName tmp_dir template+  | any isPathSeparator template+  = failIO $ "mkTempFileName: Template string must not contain path separator characters: " ++ template+  | otherwise = find' 0 (splitExtension template)+ where+  find' :: Int -> (String, String) -> IO FilePath+  find' c (prefix, suffix)+    | c >= max_tries = failIO "mkTempFileName: too many attempts of finding unique filename" +    | otherwise = do+        rs <- rand_string+        let filename = prefix ++ rs ++ suffix+            filepath = tmp_dir </> filename+        doesPathExist filepath >>= \case+          False -> pure filepath+          True -> find' (c + 1) (prefix, suffix)++  max_tries = 10++-- build large digit-alike number+rand_string :: IO String

This is temporary, not base. base does a lot of awful things such as proliferation of String or the whole implicit text decoding/encoding business: I don't see how that makes it OK to put bad things in every other library too.

Regardless, as mentioned in the other comment, there's nothing wrong fundamentally with this function on its own but it can only be used safely if the caller meets some about the usage.

Your caller does not do this.

hasufell

comment created time in 3 days

Pull request review commentUnkindPartition/temporary

Add mkTempFileName, fixes #10

 mkPrivateDir s = System.Posix.createDirectory s 0o700 -- "/home/feuerbach" getCanonicalTemporaryDirectory :: IO FilePath getCanonicalTemporaryDirectory = getTemporaryDirectory >>= canonicalizePath+++-- | Make a temporary file or directory name in the given directory, similar to unix 'mktemp'.+-- This does not create a file.+--+-- Note that this might be subject to race conditions. Only use this on secure directories.+mkTempFileName :: FilePath   -- ^ directory in which to test for available random filenames+               -> String     -- ^ File name template. If the template is \"foo.ext\" then+                             -- the created file will be \"fooXXX.ext\" where XXX is some+                             -- random number. Note that this should not contain any path+                             -- separator characters.+               -> IO FilePath+mkTempFileName tmp_dir template

So the current implementation has exactly the same behavior, so you could file a bug against base.

No, not at all.

The difference between openTempFile and what you have here is this:

-- With some exceptions (see below), the file will be created securely
-- in the sense that an attacker should not be able to cause
-- openTempFile to overwrite another file on the filesystem using your
-- credentials, by putting symbolic links (on Unix) in the place where
-- the temporary file is to be created.  On Unix the @O_CREAT@ and
-- @O_EXCL@ flags are used to prevent this attack, but note that
-- @O_EXCL@ is sometimes not supported on NFS filesystems, so if you
-- rely on this behaviour it is best to use local filesystems only.

What you're proposing here just rolls a dice and gives you a random filename that it randomly checked for existence of on the filesystem. What's in base is easy to use as part of programs without some strange unintended security hole. What you're proposing is adding something inherently broken to a very popular library with bunch of caveats in the docs.

hasufell

comment created time in 3 days