Feed Aggregator Page 671

Rendered on Fri, 23 Jul 2021 15:32:31 GMT newer latest older

Embed Elm-UI into HTML Page

via Elm - Latest posts by @John_Orford John Orford on Fri, 23 Jul 2021 12:50:46 GMT

Hi Guys,

is it possible to embed an Elm-UI “widget” into a larger HTML page?

Thanks,

John

New release of elm-charts!

via Elm - Latest posts by @paulh Paul Hollyer on Fri, 23 Jul 2021 10:56:01 GMT

This looks great, I’ve been for waiting for this for a current project

One question, is there any way to control the y-axis ticks? Specifically I need to have the minimum value at the top, and the maximum value at the bottom - think sports league table where a dot or line should be right at the top if the team/player is 1st in the table, or right at the bottom if the team/player is bottom of the table.

I want to plot a line graph that displays the varying league positions throughout a season. My only issue is the y-axis.

Measuring cognitive complexity with elm-review

via Elm - Latest posts by @system system on Fri, 23 Jul 2021 07:17:53 GMT

This topic was automatically closed 10 days after the last reply. New replies are no longer allowed.

Writing Spreadsheets in Elm

via Elm - Latest posts by @system system on Fri, 23 Jul 2021 06:56:47 GMT

This topic was automatically closed 10 days after the last reply. New replies are no longer allowed.

about elm katex

via Elm - Latest posts by @system system on Thu, 22 Jul 2021 21:49:17 GMT

This topic was automatically closed 10 days after the last reply. New replies are no longer allowed.

Write CLI scripts in Elm (IO Monad)

via Elm - Latest posts by @miniBill Leonardo Taglialegne on Thu, 22 Jul 2021 18:24:55 GMT

Files API

Yupp

I mean, most errors are not avoidable at the API level: write errors, permission errors, full filesystem, etc etc etc, can and need to be managed via Result/IO err, as you already do.

Writing to a closed fd feels like one of those problems that are be fixable with a Strict Enough API but:

not sure it actually exists in the Elm typesystem
not sure, if it exists, if it is nice enough to be worth using over a trivial withFile : (FD -> IO e a) -> IO e a
not sure, if it exists, if it’s flexible enough for all usecases

Something something records keeping tracks of open files via type level shenanigans, elm-css-ish style.

albertdahlin:

Call JS

I had that in the beginning but then I wanted to do async stuff, like
sleep: function(delay) {
    setTimeout(this.send, delay);
}
so I went with the more flexible approach of using callbacks. My thinking was that increased flexibility outweighs the increased risk. I’m open to other opinions or suggestions here though, maybe it is better to revert to returning values.
Is it maybe a better idea to have the functions return either a value or a Promise to allow both styles?

I think allowing either a value or a Promise should be flexible enough yet clean and avoid the issue.

Elm Online Meetup: Call for speakers

via Elm - Latest posts by @supermario Mario Rogic on Thu, 22 Jul 2021 16:58:59 GMT

Hi all!

The next Elm Online Meetup will be on Wednesday the 4th of August: https://meetdown.app/group/10561/Elm-Online-Meetup

This is a call for speakers, both for the upcoming meetup, and future meetups!

I would like to particularly encourage first-time speakers and newcomers to the Elm community! The Elm Online Meetup is a friendly and low risk place to practice public speaking.

Talks are generally aimed to be max 10-15 minutes long (as inevitably talks always run over), but they can also be any duration shorter. We usually have two per meetup before going into community open mic and an online open coding session.

The bar is very low as well, no formal presentation slides are necessary! You’re welcome to show-and-tell code or something you’ve built, and speak through it.

If you’re interested in doing a talk, or know someone who is (or should be!), please either comment here or DM me to let me know!

Thanks

Function equality

via Elm - Latest posts by @mika on Thu, 22 Jul 2021 10:36:50 GMT

Thanks for the thorough explanation. I understand now why this is complex and seems elm-review is bound by the same restrictions as the compiler I guess. Have made some progress so might continue on it but got a bit uninspired by the fact that elm-review doesn’t check dependencies. Did not know/realize that was the case which makes pursuing this not very worthwhile. I have learned something about writing elm-review rules at least.

Function equality

via Elm - Latest posts by @jfmengels Jeroen Engels on Thu, 22 Jul 2021 10:15:44 GMT

You can find a short discussion/proposal on a rule that would do something in the same vein

I think you will have false positives (when you report an error but shouldn’t have) and false negatives (when you don’t report anything while you should have)

I think you need some kind of type inference to be able to detect these.

For instance, if you have

Maybe.withDefault identity maybeFunction == ...

Then you need to infer the type of the expression on the left to understand that it will result in a function. It’s possible, but not something I have been able to have built-in into elm-review at the moment.

Another false negative is that you need to understand when a function will try to compare things.

isEqual = (==)
a = isEqual b c

If b and c are or contain functions, then this should not be allowed. The places where isEqual is used should also be checked, in addition to all the places where == is used. Same thing for any function that does this equality check at any point in their code (directly or indirectly) where the types would allow the comparison of something that contains functions (meaning all functions except where from the type signature you can confirm the inputs won’t contain a function, or when you can determine that one of the == operands is not a function).

A third false negative, is that elm-review doesn’t look at the source code of dependencies, and without doing that, you can’t know whether a custom type (directly or indirectly) from a dependency, or a value from/containing that type, contains a function. We could if we knew whether the type was equatable or not though.

I can’t think of false positives off the top of my head, but I guess that detecting some true positives while never reporting a false positive could already be useful to prevent crashes.

I’m probably forgetting cases, and I haven’t looked at your code too much (don’t have access to a laptop at the moment), but this would be quite a complex rule to create.

This is typically a case where you’d want the type system to take care of this, because we want to make something impossible based on the type of a value, not based on how it’s written.

I’m looking forward to see the equatable type in the language! And I’m very curious to see how the documentation (and docs.json) would display it.

New release of elm-charts!

via Elm - Latest posts by @lucamug on Thu, 22 Jul 2021 08:34:24 GMT

This is amazing work! Now I need to find excuses to add charts to all our apps

New release of elm-charts!

via Elm - Latest posts by @terezka Tereza Sokol on Thu, 22 Jul 2021 08:09:21 GMT

It supersedes it! I’ll make a note of this on the line-charts lib

I made a meetup.com clone

via Elm - Latest posts by @system system on Thu, 22 Jul 2021 06:32:49 GMT

This topic was automatically closed 10 days after the last reply. New replies are no longer allowed.

New release of elm-charts!

via Elm - Latest posts by @sammarten Sam Marten on Wed, 21 Jul 2021 13:13:40 GMT

Very excited about this, thanks @terezka !

Function equality

via Elm - Latest posts by @mika on Wed, 21 Jul 2021 11:32:22 GMT

I decided to give it a go but as most of the times stuff is not as easy at it seems.

My assumption is that we should be able to report error when using a “non applied” function in equality checks. That is assuming this always results in a runtime error. Does there exist cases when that would not give a runtime error?

Here is my attempt if someone wants to help out:

gist.github.com

https://gist.github.com/mikaxyz/f7e2ff3e0745a29cf0c0f85c42c67366

NoFunctionEquality

module NoFunctionEquality exposing (rule)

import Dict exposing (Dict)
import Elm.Syntax.Declaration as Declaration exposing (Declaration)
import Elm.Syntax.Expression as Expression exposing (Expression)
import Elm.Syntax.Module as Module exposing (Module)
import Elm.Syntax.ModuleName exposing (ModuleName)
import Elm.Syntax.Node as Node exposing (Node(..))
import Elm.Syntax.Range exposing (Range)
import Review.Rule as Rule exposing (Direction, Error, ModuleKey, Rule)

This file has been truncated. show original

Started out copy pasting some example so yes it is a mess.

It seems doable at least. My plan was: Collect all functions (that takes arguments) and collect all Expression.OperatorApplication by ==. Then compare those in the end.

Elm-review is new to me so I have not managed to store the moduleName for functions etc.

fx x = 1
fy x = 2
ffx x y = 1
ffy x y = 2

t1 = fx == fy
t2 = ffx == ffy
t3 = ffx 1 == ffy 1

The thing collecting Expression.OperatorApplication for == needs to be recursive and handle other expressions i.e. records (with functions) etc. So for above code it collects the functions for t1 and t2 but not for t3.
I am unsure if this would cover all runtime error cases though. Are there cases this would give false positives? Also @jfmengels (ignore my ignorance of how to write elm-review rule) do you have any take on if this is feasible or other input?

Function equality

via Elm - Latest posts by @HappMacDonald Jesse Thompson on Wed, 21 Jul 2021 02:49:05 GMT

I could defend Q1=no and Q2=no with the following logic.

An Elm function doesn’t have to be a naked pairing of inputs to outputs. Alternately it could be treated as a specific definition of code that happens to pair inputs to outputs in a repeatable way. Sort of like an ADT opaque wrapping of a naked pairing of inputs to outputs.

If you think about what coders are after when they test for function equality, it’s not usually “will these two things offer the same output for every input”… which is lucky since that’s literally impossible to prove in a general sense, and since it fails to implementational troubles like confusing reals with IEEE 754 floats, etc.

No, usually a coder wants to know “is what’s in this step the same value I fed into the chain of functions earlier?” Or alternately, “Is the token over here the same as the one this package advertises as a default?”

So instead, let’s think of it like an ADT. Where creating a function (\x → x + 1) is really in a sense creating a wrapped object Func#17 (\x → x + 1) where the wrapper is an arbitrary unique product of where that definition was made.

Now only that object defined in that location can ever equal itself, so even x = (\x → x + 1) and y = (\x → x + 1) would set x and y as not being equal — and that could be justified by having different conceptual function wrappers due to being defined at different locations in the code.

If we do it that way then currying might not be so difficult for the compiler to support as well.
x = {conceptual ADT Func#66} (\x y → x + y)
y = x 3 {conceptually, now y = ( 3 |> Func#66 (\x y → x + y) ) or even just ( Func#66 3 ) internally}
z = x 3

and then it makes sense that y == z or y == (x (2+1)) or whatever because they are all derived from the same function defined at the same location, and then only ever curried together with equal input values.

If we were able to define function equality that way, and allow all functions that do not spring from the same definitions to be unilaterally not equal, then I think I would be comfortable with things on every level:

I don’t think there are any concrete uses that would be stymied
We’d shut down that path to runtime exception, obviously
We would support black box implementations where module developers could swap opaque objects out for things that contain functions without breaking calling code
We would avoid leaky abstractions where people might expect “mathematical” equality to translate into demonstrable equality.
And our concept of equality would survive currying, function nesting, and basically every real-life thing I can think of that would actually lead people to care about in what sense any functions are “equal”.

Furthermore, I don’t see how @yosteden’s point about refactoring helps here: currently “f == (identity >> f)” gives a runtime error, and I don’t see why that would be preferable to having a false value.

We shouldn’t write tests comparing functions as a shorthand for all possible input/output pairs anyway, we should just be writing good fuzz tests to directly test said input/output pairs. if g = identity >> f then we can feed as many inputs into f and g that we’d like and test to confirm their outputs match instead of trying to interrogate the function directly in a sense that is literally impossible.

But at least my proposal let’s us do things like compare functions curried from the same source with matching partial inputs, and a fair few other — predictable — transformations as well.

Write CLI scripts in Elm (IO Monad)

via Elm - Latest posts by @albertdahlin Albert Dahlin on Wed, 21 Jul 2021 01:40:10 GMT

Files API

I think the ideas you are writing about are interesting, thank you.

I want to be pragmatic in the design of the API. The “gut feelings” I have been basing my decisions on are something like this:

90% of the use cases for this package would be satisfied with just reading / writing whole files at once.
Writing to closed file descriptors are just one of all the problems you can have and need to watch out for. I am afraid that solving this without something like linear types would make API feel very complex. But of course I am open to suggestions and I will try to think in the lines the ideas you are describing.

Call JS

I had that in the beginning but then I wanted to do async stuff, like

sleep: function(delay) {
    setTimeout(this.send, delay);
}

so I went with the more flexible approach of using callbacks. My thinking was that increased flexibility outweighs the increased risk. I’m open to other opinions or suggestions here though, maybe it is better to revert to returning values.
Is it maybe a better idea to have the functions return either a value or a Promise to allow both styles?

🎙️ Elm Radio Episode 35 - elm-spa v6

via Elm - Latest posts by @sammarten Sam Marten on Tue, 20 Jul 2021 23:45:42 GMT

Terrific episode! elm-spa and elm-graphql are my two most-used libraries and I always enjoy Elm Radio. Thank you for all your contributions Dillon!

Write CLI scripts in Elm (IO Monad)

via Elm - Latest posts by @miniBill Leonardo Taglialegne on Tue, 20 Jul 2021 23:10:38 GMT

My idea for this package is to make it more ergonomic to write simple CLI scripts, for example dev tools and build pipelines. I also want to make it as open as possible to allow others to implement their own I/O in nodejs.

Cool!

Supporting HTTP-servers is however out of scope for now.

Fair

Files API

While the API for reading and writing a whole file at once can work for simple cases, having a streaming API is definitely something one eventually wants. On the other hand the 1.0 API you published has the obvious problem (that I guess you’re aware of) wrt writing to closed files.

Ideas:
One could imagine a withFile : Filename -> (FD x -> IO e a) -> IO e a API that automatically closes the file at the end, BUT the problem is that you would be able to “smuggle out” the file descriptor via return.
What if we don’t expose the file descriptor, but instead withFile : Filename -> ({read : Int -> IO e String, write : String -> IO e ()} -> IO e a) -> IO e a? Again, you can just return the read and andThen it out, so doesn’t work.
We could force a to be () and then one wouldn’t be able to smuggle out anything, but you could only use that for writing, not for reading… not great.
We could have an opaque type FileIO e a = FileIO (IO e a). Then withFile : Filename -> FileIO e a -> IO e a and then read : FileIO Err String, write : String -> FileIO Err () + monad operations for FileIO but then you can’t allow nesting withFile calls because we either get back to the smuggling problem or you have an API where only the inner file can be read/written to inside the nested call. Not flexible enough I think.

Uhm. You could restrict the return to be an IO Value where Value is the Json.Encode one but… meh, it’s unclean.

I’ll think a bit more about this.

CallJs

Javascript

Why not have the functions return the value (instead of calling send)? You avoid both double-send and no-send that way

Elm

Great!

Put it together

Simple, I like it!

Function equality

via Elm - Latest posts by @wolfadex Wolfgang Schuster on Tue, 20 Jul 2021 21:46:02 GMT

@mika I would recommend reaching out to @jfmengels. He would likely know best and would probably point you in the right direction if you wanted to attempt to write this rule yourself (assuming it’s possible).

Function equality

via Elm - Latest posts by @mika on Tue, 20 Jul 2021 19:59:07 GMT

Would it not be pretty easy to have a “compile time error” for this using elm-review in the meantime? I have not yet written my own rule/looked at the api so would someone with knowledge give their view? (I could not find any existing elm-review rule for it.)

newer latest older

Lisplog

Files API

Files API

Call JS

Files API

CallJs

Javascript

Elm

Put it together