Lisplog

Blogging in Lisp

Search

Feed Aggregator Page 681

Rendered on Tue, 01 Feb 2022 22:01:24 GMT  newer latest older 

Simple CSS transitions in Elm?

via Elm - Latest posts by @mattpiz Matthieu Pizenberg on Tue, 01 Feb 2022 19:29:10 GMT

Hi @nsadeh, in case you haven’t tried it yet, elm-simple-animation 2.3.0 was quite nice the last time I used it for simple (stateless) animations.

Travelm-Agency now supports Fluent including usage of the Intl API with Elm 0.19!

via Elm - Latest posts by @andreasmolitor Andreas Molitor on Tue, 01 Feb 2022 18:40:15 GMT

Okay so you would export the translations from the service to .ftl files and then run travelm-agency to generate the corresponding elm code. Should work right?

Travelm-Agency now supports Fluent including usage of the Intl API with Elm 0.19!

via Elm - Latest posts by @francescortiz Francesc Ortiz on Tue, 01 Feb 2022 18:15:52 GMT

We are close to start using translation management services, but we didn’t start yet, but probably what is needed in the tech side will be provided by the services themselves, like a cli tool to export the data in fluent’s .ftl format.

Potential breaking change in github zipballs codec

via Elm - Latest posts by @strickinato Aaron Strick on Tue, 01 Feb 2022 17:54:13 GMT

<It’s actively being discussed in the #core-coordination on the elm-slack>

Travelm-Agency now supports Fluent including usage of the Intl API with Elm 0.19!

via Elm - Latest posts by @andreasmolitor Andreas Molitor on Tue, 01 Feb 2022 17:50:59 GMT

I didn’t run into those yet, I guess my projects so far did not need translation management.
Could you provide a concrete example, what you would like to be possible?
I imagine it would be some kind of plugin like the webpack one I created?

Potential breaking change in github zipballs codec

via Elm - Latest posts by @strickinato Aaron Strick on Tue, 01 Feb 2022 17:46:28 GMT

Interesting - just ran into this as well with - folkertdev/elm-deque

I downloaded the source code for folkertdev/elm-deque 3.0.1 from:

https://github.com/folkertdev/elm-deque/zipball/3.0.1/

But it looks like the hash of the archive has changed since publication:

Expected: d68f199182be5e93097a1e56869e5b29e7bbda91
Actual: e9b1de164452ad0e32ceda86fd5c8d46b9dcfaa4

Potential breaking change in github zipballs codec

via Elm - Latest posts by @francescortiz Francesc Ortiz on Tue, 01 Feb 2022 17:41:28 GMT

Hi. We are facing a strange and potentially dramatic issue with github. The checksum of a couple package zipballs has changed, but the projects haven’t had any recent activity.

The projects are:
GitHub - debois/elm-dom: DOM traversal for Elm event-handlers - version 1.3
GitHub - Chadtech/elm-bool-extra: Convenience functions for working with Bools in Elm - version 2.4.2

Ii looks like the information on tags and commits is consistent with no activity in the last months. Do you have any clue of what can be wrong? What comes to my mind is that github might be changing its zip codec parameters, thing that would be a dramatic problem for the Elm community.

We started to see this issue about 5 hours ago. In order to reproduce it you have to delete/backup your ~/.elm directory.

Travelm-Agency now supports Fluent including usage of the Intl API with Elm 0.19!

via Elm - Latest posts by @francescortiz Francesc Ortiz on Tue, 01 Feb 2022 17:03:22 GMT

Wow, this is great news! Do you use any service for translation management? I have seen that Crowding and locize support fluent format:

Have you tried any them or do you know of an alternative for translations management?

Travelm-Agency now supports Fluent including usage of the Intl API with Elm 0.19!

via Elm - Latest posts by @andreasmolitor Andreas Molitor on Tue, 01 Feb 2022 12:45:34 GMT

Hi there,
a while ago I requested feedback on my Elm Code Generator for Internationalization (I18n).
I’m very happy with the recent breakthrough regarding Fluent compatability which I want to share with you :slight_smile:
I’m also interested in feedback as always.

So while there was a Fluent code generator before (GitHub - elm-fluent/elm-fluent: Fluent for Elm (translation and l10n/i18n solution)) already, it only supports Elm 0.18 due to needing Kernel code for synchronous communication with the browsers Intl API. Travelm Agency (GitHub - andreasewering/travelm-agency: Compile time internationalization for Elm supporting multiple input and output formats) now supports Fluent-based code generation with Elm 0.19! Interestingly enough, the impact of the chosen solution to the user is only

  • npm install intl-proxy
  • Pass the default export of intl-proxy into your Elm program as a flag
  • Pass the intl-proxy into the generated I18n constructor

After that, the locale specific features like matching on PluralRules or formatting numbers and dates just work! The trick is runtime decoding of a JS proxy object, if you have any questions go ahead and ask me :slight_smile:

Additionally, I created a webpack plugin (travelm-agency-webpack-plugin - npm) to make usage of the code generator more convenient.
Are there any other build tools you want to see supported? Personally I have only used parcel and webpack for Elm so far.

How Do You Read Types?

via Elm - Latest posts by @pdamoc Peter Damoc on Tue, 01 Feb 2022 07:54:10 GMT

There are multiple aspects in that type definition that make it a little harder than most.

(<|) : (a → b) → a → b

First, you need to mention that this is a function that is designed to be used infix. An infix function takes 2 arguments. The first argument is the left argument and in this case it is a function from a to b. The second argument is the right argument and in this case it is a value of type a. The result of the infix application of the arguments is of type b.

Explaining a type signature as above requires that the person already understands the concept of a function and of a higher order function ( a function that takes a function as an argument, or returns a function).

value : a - a value of type a

unary : a -> b - a function that takes a value of type a and evaluates to a value of type b

binary : a -> b -> c - a function that takes two arguments. First is a value of type a, second is a value of type b. The function evaluates to a value of type c

higherOrder : (a -> b) -> a -> b - a binary function that takes an unary function as the first argument and a value of type a as the second and evaluates to a value of type b.

And then you get into currying and partial application where a higher arity function can be reduced to a lower arity function by partial application.

So, binary: a -> b -> c it is actually an unary function that produces an unary function so… binary : a -> (b -> c) . ternary : a -> ( b -> ( c -> d)) , etc.

All this gets confusing fast if you don’t understand the idea of higher order functions.

How Do You Read Types?

via Elm - Latest posts by @Lucas_Payr Lucas Payr on Tue, 01 Feb 2022 03:40:16 GMT

(a -> b) -> a -> b A function that takes a function from a to b and an a and returns a b.
a -> (a -> b) -> b A function that takes an a and a function from a to b and returns a b.

Colin Lupton: Project Goals for Open-Blackfire

via Planet Lisp by on Mon, 31 Jan 2022 17:18:04 GMT

There’s no denying, I went a little bit over the top with the closed-source, proprietary version of the Blackfire Framework under my now-defunct start-up, Black Brane Systems. For the new, open-source version, Open-Blackfire, I intend to focus the implementation on the features that will make it most useful for the Common Lisp and Quantum Computing communities, along the shortest path of development to these features.

The core modules of the Blackfire Framework boil down to:

  • The Wittek Machine: quantum virtualization
  • Protocol “Phi”: higher-order quantum type system
  • Blackfire Quantum Assembly: Vendor-agnostic quantum computer machine language

The initial priorities for Open-Blackfire are for Protocol “Phi” and the Blackfire Quantum Assembly language for vendor-agnostic quantum computer programming. The Wittek Machine architecture, which uses a hyperlattice data-structure to represent quantum states and operations under the Quantum Logic formalism, will be a serious pain to reimplement, so I’m saving that migraine as an optimization down the road once the core functionality is exposed.

To start with, Open-Blackfire will rely heavily on CLOS and the MOP in its architecture, and use Complex-valued matrix encodings to represent Quantum States and Operations, which as the standard in the literature will be easily checked for correctness. This will be extensible to use alternate and eventually interchangeable internal encodings, which will allow streamlined Quantum Validation built into Open-Blackfire’s test suite.

The above paragraph feels distinctly hand-wavey, ignoring the complications between various interpretations of Quantum Mechanics and the impact that has on the practical aspects of Quantum Computing. I will be keeping these complications at the forefront of my mind and factoring them into the new codebase from the beginning, and my hope is that I can do it in a way this time that is clear in the codebase for those who care, and a non-issue for those who don’t.

And lastly, as a large-scale open-source project, I will need to rely on the Common Lisp and Quantum Computing communities to see this project through, so if this technology will be of use to you and you are able to help make it a reality, please consider sponsoring me on GitHub Sponsors:

:studio_microphone: Episode 049: Optimizing Performance with Robin Hansen is out!

via Elm - Latest posts by @John_Orford John Orford on Mon, 31 Jan 2022 19:29:05 GMT

Really loved this ep! Favourite so far

:studio_microphone: Episode 049: Optimizing Performance with Robin Hansen is out!

via Elm - Latest posts by @jfmengels Jeroen Engels on Mon, 31 Jan 2022 19:04:49 GMT

:studio_microphone: Episode 049: Optimizing Performance with Robin Hansen is out!

We talk about @robin.heggelund’s work optimizing Elm, and the opportunities that remain for Elm performance improvements.

We hope you enjoy the episode!

How Do You Read Types?

via Elm - Latest posts by @dta David Andrews on Mon, 31 Jan 2022 16:26:03 GMT

If I’m reading them to myself:
(a → b) → a → b (A to B) to A to B
a → (a → b) → b A to (A to B) to B
where the words in parentheses are said more quickly together.

If I’m explaining them to someone else:
(a → b) → a → b a function that takes two arguments and returns a B. The first of argument is a function from A to B and the second argument is an A.
a → (a → b) → b a function that takes two arguments and returns a B. The first argument is an A and the second argument is a function from A to B.

Colin Lupton: Announcing Open-Blackfire and Open-Quicksilver

via Planet Lisp by on Mon, 31 Jan 2022 15:36:41 GMT

With the death of my start-up, I’ll be switching my focus back to open-source software and open-science, starting with developing new, open-source versions of the Blackfire framework and Quicksilver Quantum Lisp programming language. I will also be resuming work on Learn Lisp The Hard Way and Learn Quantum The Hard Way.

You can follow these projects at:

My goal is to work full-time on open-source software, open-science, and educational material for Common Lisp and Quantum Programming, but I can’t do it without your support. Please consider sponsoring development of Open-Blackfire, Open-Quicksilver, LLTHW, and LQTHW through my GitHub Sponsors profile:

Micha Herda: LOAD-TIME-VALUE, or How I Started Worrying About STATIC-LET Again

via Planet Lisp by on Mon, 31 Jan 2022 12:20:01 GMT

#CommonLisp #Lisp

Usually you are not supposed to know whether a piece of Common Lisp code has been compiled or is being interpreted without compilation. It's possible to observe e.g. that macroexpanders are not called in code that has been already compiled, and variables like *COMPILE-FILE-PATHNAME* are bound when a file is being compiled - but, in particular, compiling a Common Lisp program shouldn't change its semantics in any way, right?

See, there is one thing that surely is an exception to that rule. It is specified in a way that allows it to differ in terms of how it behaves between compiled and non-compiled code: LOAD-TIME-VALUE, which I recently used to implement STATIC-LET.

See, there is one thing that surely is an exception to that rule. It is specified in a way that allows it to differ in terms of how it behaves between compiled and non-compiled code: LOAD-TIME-VALUE, which I recently used to implement STATIC-LET.

And it's not a nice thing to discover.

Rationale

CLHS 3.2.2.2 Minimal Compilation states (emphasis mine):

The first argument in a load-time-value form in source code processed by compile is evaluated at compile time; in source code processed by compile-file, the compiler arranges for it to be evaluated at load time. In either case, the result of the evaluation is remembered and used later as the value of the load-time-value form at execution time.

More, CLHS Special Operator LOAD-TIME-VALUE states (emphasis mine):

If a load-time-value expression is processed by compile-file, the compiler performs its normal semantic processing (such as macro expansion and translation into machine code) on form, but arranges for the execution of form to occur at load time in a null lexical environment, with the result of this evaluation then being treated as a literal object at run time. It is guaranteed that the evaluation of form will take place only once when the file is loaded, but the order of evaluation with respect to the evaluation of top level forms in the file is implementation-dependent.

If a load-time-value expression appears within a function compiled with compile, the form is evaluated at compile time in a null lexical environment. The result of this compile-time evaluation is treated as a literal object in the compiled code.

If a load-time-value expression is processed by eval, form is evaluated in a null lexical environment, and one value is returned. Implementations that implicitly compile (or partially compile) expressions processed by evalmight evaluate form only once, at the time this compilation is performed.

COMPILE-FILE and COMPILE have a "must", where EVAL only has a "might". This means that functions defined using EVAL, without compilation, can cause a new object to be instantiated every time, which will both call the initialization form every time the body is entered and break all code that depends on the static binding values to stay static.

So, in order to get the behavior we want (in which an object is only allocated once), the code containing the STATIC-LET form must be compiled, at which point the load-time values will either be instantiated (in case of COMPILE) or stored in the resulting FASLs to be instantiated at load time (in case of COMPILE-FILE).

Test

We can make a quick test to figure out how different Lisp implementations handle this.

            ;;; the test goes like this:

;;; let's grab two functions with the same body
;;; which uses the LOAD-TIME-VALUE trick
(defun test-function ()
  (let ((counter-var (load-time-value (cons 0 nil))))
    (symbol-macrolet ((counter (car counter-var)))
      (incf counter))))

(defun test-function-2 ()
  (let ((counter-var (load-time-value (cons 0 nil))))
    (symbol-macrolet ((counter (car counter-var)))
      (incf counter))))

;;; let's compile only the second one
;;; and leave the first one possibly uncompiled
(compile 'test-function-2)

;;; let's call each one a few times
(format t "Possibly not compiled code: ~D ~D ~D~%"
        (test-function) (test-function) (test-function))

(format t "Compiled code: ~D ~D ~D~%"
        (test-function-2) (test-function-2) (test-function-2))

          

The results divide the CL world pretty much in half, speaking numerically.

  • SBCL 2.1.11

    • Possibly not compiled code: 1 2 3
    • Compiled code: 1 2 3
  • CCL 1.12

    • Possibly not compiled code: 1 2 3
    • Compiled code: 1 2 3
  • ECL 21.2.1

    • Possibly not compiled code: 1 2 3
    • Compiled code: 1 2 3
  • Clasp current

    • Possibly not compiled code: 1 2 3
    • Compiled code: 1 2 3
  • ABCL 1.8.0:

    • Possibly not compiled code: 1 1 1
    • Compiled code: 1 2 3
  • CLISP 2.49.93+:

    • Possibly not compiled code: 1 1 1
    • Compiled code: 1 2 3
  • ACL 10.1 Express:

    • Possibly not compiled code: 1 1 1
    • Compiled code: 1 2 3
  • LW 7.1.2 Personal:

    • Possibly not compiled code: 1 1 1
    • Compiled code: 1 2 3

So, it's time to update the STATIC-LET article I wrote yesterday and add a warning to it that it's only safe to use STATIC-LET in compiled code, or on implementations which are compiler-only.

Detection

But alas! It's also possible to use this behavior to check if a piece of code has been minimally compiled. The following example signals an error only on the latter four implementations and only in code that has not been compiled.

            ;; I used the stones to destroy the stones
;; CLISP 2.49.93+

[1]> (defun foo ()
       (flet ((fn () (let ((x (load-time-value (list 0)))) (incf (car x)))))
         (declare (notinline fn))
         (when (= (fn) (fn))
           (error "STATIC-LET will not work in uncompiled code."))))
FOO

[2]> (foo)
*** - STATIC-LET will not work in uncompiled code.
The following restarts are available:
ABORT          :R1      Abort main loop

Break 1 [3]> :r1

[4]> (compile 'foo)
FOO ;
NIL ;
NIL

[5]> (foo)
NIL

          

On non-compiler-only implementations, it's possible to splice such a piece of code into a macroexpansion in order to have a check which will signal an error (or possibly do something else) on code which was not minimally compiled.

Or, in other words, I just realized that (flet ((fn () (let ((x (load-time-value (list 0)))) (incf (car x))))) (= (fn) (fn))) is a non-portable but luckily working poor man's "was this code minimally compiled" predicate.

I bet $3 that it's useless other than for the above.

What's wrong with using Html.map?

via Elm - Latest posts by @Atlewee Atle Wee Førre on Mon, 31 Jan 2022 15:59:55 GMT

I think the difference is this: Highly reusable things is probably ok to build as component.
But In react you might split your app into header component, leftSidebar component++
I think the strong message in the community is to prevent you from doing exactly that. This is what most people would find natural to do if coming from react, but you will have a really bad time in elm doing this.

How Do You Read Types?

via Elm - Latest posts by @r4z4 on Mon, 31 Jan 2022 15:55:06 GMT

Still plugging away and trying to grasp the concepts here. I love it, and I am committed now, but just wanted to stop and ask everyone something pretty general — How you do read the types? As in, what words go through your head in your attempt to translate these things.

A good example for me is the definition for the pipe operator and backwards func operator.

(<|) : (a → b) → a → b
&
(|>) : a → (a → b) → b

I get the idea, and have a good understanding of how they work, but when I try to just explain these type definitions I cannot really do it. Just wondering how people with more experience read these things. Thought maybe it will unlock something trapped in my brain or something.

Thanks everyone!

How to test that a function doesn't infinite loop

via Elm - Latest posts by @jackyjoy123 jackyjoy on Mon, 31 Jan 2022 12:08:55 GMT

thanks my issue has been fixed.

 newer latest older