Lisplog

Skinney/murmur3 not downloading

via Elm - Latest posts by @system system on Thu, 01 Oct 2020 12:43:52 GMT

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

Elm-music-theory: A toolkit for musical ideas

via Elm - Latest posts by @evelios Tommy Waters on Wed, 30 Sep 2020 18:40:10 GMT

This is awesome! Been following your progress for a while and I’m excited you are able to get to a 1.0.0 release! Your api is well thought out and provides a strong foundation for both application and new framework support. My musical application using your code has fallen to the side in favor of other projects but I look forward to using your library for playing with concepts of music generation!

Can the compiler skip virtual DOM?

via Elm - Latest posts by @MarkHamburg Mark Hamburg on Wed, 30 Sep 2020 15:33:16 GMT

Proper use of Html.lazy is indeed tricky. It is, however, also key to bringing down the rendering and diffing costs. One thing that Elm could do with no changes to the language or the library APIs is make the equality test in Html.lazy go a bit deeper. The most frequent errors I’ve seen with Html.lazy are people constructing records to pass view function parameters — often because the number of parameters supported by Html.lazy is limited — which thereby entirely defeats the optimizations provided by Html.lazy and instead increases the costs. Going one extra level deep on the comparison would fix this.

The more complicated place to put work would be in not rendering data that isn’t on the screen. To the extent that the DOM (and virtual DOM) size is proportional to the visible data as opposed to the entire model data, the costs of rendering and diffing should be insignificant for most uses.

Svg-folder-to-elm-module: import SVG icons into your elm codebase

via Elm - Latest posts by @FranzSkuffka Jan Wirth on Wed, 30 Sep 2020 12:56:40 GMT

I decided to publish a little tool I built using elmx. I hope it will be useful for you.

Here’s a demo:

Parsers with Error Recovery

via Elm - Latest posts by @rupert Rupert Smith on Wed, 30 Sep 2020 11:49:38 GMT

The recovery tactics I implemented so far require you to add them in to exising parsing code - which is not simple to do. The idea of having error recovery handled automatically, is appealing.

So the other thing I have been looking into is error recovery in LL grammars and parser generators. I don’t think elm/parser is really restricted to LL grammars, its just that the way we most commonly use it is to write recursive descent style parsers.

A recursive descent parser using a parsing combinator library, embeds implicit knowledge about the grammar being parsed into code. An LL parser generator can generate recursive descent parsers, but can also make use of explicit knowledge about the grammar it is parsing and has been giving as input to generate a parser for. When it comes to error recovery, this makes a big difference.

This paper gives details of how to calculate for a given token and parse state, how to figure out the set of things that could come next. That means that the parser can automatically figure out where it can continue from. There is also an algorithm for repairing the input, by inserting imaginary tokens not in the input, in order to get to the continuation token, and this algorithm also always terminates. The result is an LL parser generator that can recover and repair all errors automatically. Pretty nice:

I did not realize it because I have never used Antlr (but have used StringTemplate, one of Terrence Parr’s other projects - all my StringTemplate code is now ported to Elm ), but Antlr also uses this technique. Antlr is a popular LL(k) parser generator with auto error recovery. The (k) bit means it can look-ahead k tokens to figure out ambiguities in the input grammar - that is when 2 or more things start out the same way so both branches need to be explored in more depth, to figure out which one is correct.

And there is a port of it to Standard ML, which might provide some insights on how it could be written in Elm:

I think a parser generator could be written on top of elm/parser, essentially elm/parser would just do the tokenization, with the parser code generated on top of a List of Tokens, rather than parsing direct from the input String. That is, in elm/parser we use the combinators to do both the lexing and parsing, in a single step, which is quite convenient for hand-written recursive descent parsers but for a parser generator, probably conceptually easier to be thinking at the level of tokens.

This also proves my point above that elm/parser is not restricted to LL grammars - you could do an LR parser on this token list too. It is clear though that error recovery in LR parsers is more difficult than for LL.

If anyone knows of any LL parser generator proejcts implemented in functional languages (seeing something in Haskell or OCaml might be nice), do post a link.

Can the compiler skip virtual DOM?

via Elm - Latest posts by @jfmengels Jeroen Engels on Wed, 30 Sep 2020 10:31:19 GMT

Html.Lazy is definitely tricky. It’s really easy to put in place, but also really hard to keep make it keep work and not fail on you silently because of “spooky actions at at distance”.

IMO, this could be solved through static analysis (probably through some other means too), and I proposed an elm-review rule idea targeting this exact problem (link below).

Detecting the problem will not solve the problem entirely as you will have to re-think and re-structure how you architecture the parts of the code that lead to that lazy view, which might be more work than what Svelte gives you out of the box, but it would remove the biggest pain point around it.

Alexander Artemenko: place-modifiers

via Planet Lisp by on Tue, 29 Sep 2020 19:18:05 GMT

This is a library by @HexstreamSoft. It provides a shorthand macro to modify data-structures in place.

The library has comprehensive documentation so, I'll only show you one example to demonstrate how it works.

Let's pretend we have some data received from an API and "age" field should be converted into the integer in place.

In plain CL we'll do it like this:

POFTHEDAY> (let ((data
                   '#((:name "Bob" :params (:age "45"))
                      (:name "Alice" :params (:age "23")))))
             (loop for item across data
                   do (setf (getf (getf item :params)
                                  :age)
                            (parse-integer
                             (getf (getf item :params)
                                   :age))))
             data)
#((:NAME "Bob" :PARAMS (:AGE 45)) (:NAME "Alice" :PARAMS (:AGE 23)))

But place-modiifiers allows you to keep your code DRY:

POFTHEDAY> (let ((data
                   '#((:name "Bob" :params (:age "45"))
                      (:name "Alice" :params (:age "23")))))
             (loop for item across data
                   do (place-modifier:modify
                       (parse-integer
                        (getf (getf item :params)
                              :age))))
             data)
#((:NAME "Bob" :PARAMS (:AGE 45)) (:NAME "Alice" :PARAMS (:AGE 23)))

Here I've extracted forms responsible for the modification:

;; Plain Common Lisp
(setf (getf (getf item :params)
            :age)
      (parse-integer
       (getf (getf item :params)
             :age)))

;; Using Place Modifiers macro
(place-modifier:modify
 (parse-integer
  (getf (getf item :params)
        :age)))

To learn more about place-modifiers, read it's docs! There is a lot of examples.

You might also be interested in reading the post about access library.

Can the compiler skip virtual DOM?

via Elm - Latest posts by @Rich-Harris Rich Harris on Tue, 29 Sep 2020 10:30:22 GMT

Rich here - Svelte creator (and Elm admirer), someone pointed me at this thread. I’ve written a bit more about why a Svelte eschews the virtual DOM at https://svelte.dev/blog/virtual-dom-is-pure-overhead - the tl;dr is that the real problem with VDOM isn’t the diffing, it’s the fact that you have to rerun lots of user code on every state change (which is very garbagey, as well as involving lots of unnecessary computation). I’m not very familiar with how Elm works but I’d imagine the guarantees provided by the language enable it to do this step a lot more efficiently than, say, React.

I won’t go into what techniques Svelte is using right now, partly because I’m typing on my phone but also because it’s possible that we’ll be making some substantial changes in the near future. Suffice it to say that the key is to try and do as little work as possible, and AFAICT Elm is already doing a fantastic job here, so there’s probably limited upside to Elm adopting Svelte-like techniques.

Elm-review 1-year anniversary - what lies ahead?

via Elm - Latest posts by @jfmengels Jeroen Engels on Tue, 29 Sep 2020 06:50:01 GMT

elm-review v1 was officially released on September 29th 2019, so that makes it turn one today!

I wanted to take this opportunity to write some some of the plans and ambitions I had for the tool, that I had been keeping in personal notes until now.

I’m at the same time releasing a blog post about Hacktoberfest, but I’ll be sharing that over here

Float types with inputs?

via Elm - Latest posts by @Sidney Sidney Nemzer on Tue, 29 Sep 2020 04:13:07 GMT

Generally, you will want to store the exact input in the model (as a string). When you want to display an error message (perhaps on field blur, or maybe only when submitting the form), you would run a validation function that returns Result Float ValidationError or a type like that.

I’ve used hecrj/composable-form in the past, which does a great job of abstracting a lot of this (although it might be a bit complex for a small project).