Lisplog

Blogging in Lisp

Search

Feed Aggregator

Rendered on Wed, 20 Mar 2019 11:31:52 GMT  newer latest older 
Next udpate: Wed, 20 Mar 2019 12:00:00 GMT feeds

ContaSystemer AS current stats and thank you the community

via Elm Discourse - Latest posts by @akoppela Andrey Koppel on Wed, 20 Mar 2019 10:30:00 GMT

The same question our manager asked me :wink: We had a talk with @stil4m (the author of elm-analyse) and as I remember a way to extend elm-analyse with custom rules may come in the future release. But if it’s interesting for the community we can open source it. I’ll open a separate thread for that.

ContaSystemer AS current stats and thank you the community

via Elm Discourse - Latest posts by @razze Kolja Lampe on Wed, 20 Mar 2019 09:43:15 GMT

I’m not sure what others think, but any reason your not open sourcing this?

Proposal: Alternative Syntax for the Built-in Typeclasses

via Elm Discourse - Latest posts by @pdamoc Peter Damoc on Wed, 20 Mar 2019 08:45:46 GMT

There is a section in the guide that describes these constrained type variables. No magic syntax. Just 4 constrained type variables that make working with core functionality easier than it would be without them.

This is a highly complex topic where changes to the language have dramatic consequences that need to be taken into account. It is such a big change that it turns Elm into another language. Support for type clases is one of the very first issues created for Elm and if you search the old archives you can find a lot of discussions about this topic, not all of them pleasant.

The relationship between current Elm and Elm+typeclasses is similar to the relationship between C and C++ and C++ is not C with Just™ a small added feature.

Module design: When to use a pipeline and when to fold a list?

via Elm Discourse - Latest posts by @pdamoc Peter Damoc on Wed, 20 Mar 2019 08:09:54 GMT

Code is a liability and the semantics of fold are very clear to me. If I can get by writing less function code and reuse one of the already defined functions, I will do that. In any case, this is a heuristic. Of course I break my own rules when I see better alternatives but these better alternatives arise from the specifics of the types involved.

Just look at the API of the libraries hosted on the elm organization. Read Evan’s Design Process.

Proposal: Alternative Syntax for the Built-in Typeclasses

via Elm Discourse - Latest posts by @ThomasKagan Thomas Kagan on Wed, 20 Mar 2019 07:58:25 GMT

To reiterate, I’m looking for:

  • A justification of the current syntax, or
  • Ideas about a different syntax which may conform to/deviate from mine, with justification

Cheers

Proposal: Alternative Syntax for the Built-in Typeclasses

via Elm Discourse - Latest posts by @ThomasKagan Thomas Kagan on Wed, 20 Mar 2019 07:54:35 GMT

I appreciate the reply, but this doesn’t quite address the issue I raised in my original post. Is a beginner supposed to just know what tools to use for the most didactic syntax highlighting? What are they supposed to think when they see number appear as a different color? What if they see code in a gist or a Discourse thread, etc. So, I think a syntactic solution is better than a subtle visual que for the reasons described briefly in my original post.

Proposal: Alternative Syntax for the Built-in Typeclasses

via Elm Discourse - Latest posts by @MartinS on Wed, 20 Mar 2019 07:46:34 GMT

What about number, comparable, and appendable using a different text color than other generic types? Would that make it clear to beginners that these have special meaning? If it works, it seems like it would be an easier solution to implement.

Proposal: Alternative Syntax for the Built-in Typeclasses

via Elm Discourse - Latest posts by @ThomasKagan Thomas Kagan on Wed, 20 Mar 2019 06:51:19 GMT

Type signatures like

myfun : comparable -> comparable -> Maybe Bool
myfun2 : number -> number -> number2 -> number2 -> (number, number2)

use built-in timeclasses. These typeclasses exist so you dont need new versions of infix operators like < (for comparable) or ++ (for appendable) for each datatype that uses them. This enhances expression for programmers new and old alike.

The syntax for this is confusing, especially for beginners, because there’s really no indication that these types are special. An alternative is

myfun : Comparable a -> Comparable a -> Maybe Bool
myfun2 : Number a -> Number a -> Number b -> Number b -> (Number a, Number b)

If elm ever lets users extend the predefined typeclasses, then it would definitely be useful for these signatures to carry more information about what these types actually are. Especially if these types could someday be inherited to functions defined under the scope, as described at the bottom of this page

But even if that is never implemented, what is the case for the “magic” syntax of elm typeclasses today?

Module design: When to use a pipeline and when to fold a list?

via Elm Discourse - Latest posts by @ThomasKagan Thomas Kagan on Wed, 20 Mar 2019 04:28:32 GMT

If I can express something as a fold I will always express it as a fold

Why is that? Are there more alternatives, other than folding and a pipeline, that I haven’t considered?

Module design: When to use a pipeline and when to fold a list?

via Elm Discourse - Latest posts by @ThomasKagan Thomas Kagan on Wed, 20 Mar 2019 04:21:35 GMT

Thanks for the example @Herteby, it seems like exactly what I’m interested in.

One thing I notice is that the pipeline exposes the default, which might be e g. an empty structure. The fields build it up in incremental steps. This approach seems pretty intuitive to me.

In the List implementation, the user offers an order, but that may not be the actual order the operations are applied, in case some sequences are less efficient or illegal, they can be rearranged behind the scenes. Additionally, the syntax seems more convenient if all the steps are the same. And the user can do convenient operations to this List, like mapping, before it’s sent through the api endpoint build.

Does anyone else have any thoughts on this or other things they notice?

ContaSystemer AS current stats and thank you the community

via Elm Discourse - Latest posts by @akoppela Andrey Koppel on Wed, 20 Mar 2019 04:11:13 GMT

We use elm-analyse at work but it does not have a way to extend it with custom rules. For company-specific rules, we wrote a simple linter. E.g. we have the rule to disallow usage of regex and force to make a parser instead. Or we disallow exposing for anything when importing a module to enforce developers to use module prefixes for functions (e.g. Html.div, Decode.string, etc…). Or we force every top-level function to have documentation.

ContaSystemer AS current stats and thank you the community

via Elm Discourse - Latest posts by @brasilikum Georg Hartmann on Wed, 20 Mar 2019 04:03:27 GMT

Why did you decide to build a custom Linter?

Elm-tiny-inflate - decompress zip, png and woff file formats

via Elm Discourse - Latest posts by @folkertdev Folkert De Vries on Tue, 19 Mar 2019 20:58:56 GMT

I’ve just published elm-tiny-inflate, a package that decompresses deflated data (e.g. zip, png and woff).

These formats compress their data. For instance zip will store the filename of the zipped file and some other stuff (uncompressed), but compresses the file contents using a deflate algorithm.

This package will remove the compression, returning the uncompressed Bytes that can then be further decoded with elm/bytes. I’ve already started work on woff, and (a subset of) zip seems feasible.

Aside: This package has a special Decoder type for bits (it uses Bytes.Decode under the hood, decoding more bytes as needed). This is useful when data can cross byte boundaries (e.g. to decode 3 3-bit numbers). I suspect this is a niche functionality only used for compression and such, but if you do have a use case for this let me know.

ContaSystemer AS current stats and thank you the community

via Elm Discourse - Latest posts by @MartinS on Tue, 19 Mar 2019 14:45:15 GMT

It looks like a little over 50% of your Elm code is generated. What is the generated code used for?

Module design: When to use a pipeline and when to fold a list?

via Elm Discourse - Latest posts by @pdamoc Peter Damoc on Tue, 19 Mar 2019 13:17:29 GMT

This is a very good example as it illustrates the conflict very well.

I have a slight preference for the pipeline version in this case because the “things” are heterogeneous but this is only a slight preference as my mind cannot ignore the fact that Something is a record and that I would always write that using Elm syntax.

test : Something
test =
    { default
        | field1 = "foo"
        , field2 = 5
        , field3 = 0.5
    }

Later edit, if you want to mimic the elm/html API, you could go for the list version.


type alias Options = 
    { foo : String 
    , bar : Int 
    }

type alias Attr = Options -> Options 

foo : String -> Attr 
foo theFoo options = 
     { options | foo = theFoo } 


apiEndpoint : List (Attr) -> SomeResult 
apiEndpoint attrs = 
    let 
        options = List.fold identity defaultOptions attrs 
    in 
    ...

Module design: When to use a pipeline and when to fold a list?

via Elm Discourse - Latest posts by @Herteby Simon Herteby on Tue, 19 Mar 2019 12:54:34 GMT

Something like this? https://ellie-app.com/4TV3pTrBjZYa1

Would you prefer:

test : Something
test =
    default
        |> field1 "foo"
        |> field2 5
        |> field3 0.5

or:

test2 : Something
test2 =
    build
        [ field1 "foo"
        , field2 5
        , field3 0.5
        ]

Json to Elm/Elm-UI

via Elm Discourse - Latest posts by @kfk kfk on Tue, 19 Mar 2019 11:32:51 GMT

Thanks. I have reviewed few of those solutions but came up with roadblocks. Just to be a bit more clear, here is part of the solution I am trying to build:

This is a tool to compose SQL queries that will run into various databases (Exasol, Redshift, Etc.) and then produce an output. The output is materialized into a new table within the db so in theory data does not have to go to the client, but eventually some data will if the client is going to do some more interesting things than just ETL (like charts for instance).

So I don’t have a predefined schema and I don’t have a predefined database. The sync part will be an issue but I was thinking it might be easier if we make communication between client/server super simple by having 1 direction for input (elm to server) and 1 direction for rendering (server json to elm).

Ideally we do most of the computation in the server and just light computation on the client, so the data going to the client could be of somewhat small-ish size. Depending on how much we can do on the server and how much we want to cache on the client.

Json to Elm/Elm-UI

via Elm Discourse - Latest posts by @rupert Rupert Smith on Tue, 19 Mar 2019 10:18:56 GMT

Further to dmy’s comments, for Postgres there is also postgraphile, which you can query with elm-graphql.

 newer latest older