Conversation
|
|
||
| In the more secure type signature, even when `a` is determined to be `Int` based on the input array, we still need to provide valid functions matching the signatures involving `forall x`. | ||
| The *only* option for `(forall x. Maybe x)` is `Nothing`, since a `Just` would assume a type for `x` and then no longer be valid for all `x`. The only options for `(forall x. x -> Maybe x)` are `Just` (our desired argument) and `(\_ -> Nothing)`, which is the only remaining vulnerability. | ||
|
|
There was a problem hiding this comment.
Questioning whether the above distinction is necessary. The vulnerability is really just if there's a mistake in the adjacent wrapper, and the suggested approach doesn't eliminate all vulnerabilities. The suggested approach can't be applied to most other wrapping strategies, either.
| Write instances of `EncodeJson` and `DecodeJson` for the `IntOrString` data type which implement this behavior. _Hint_: The `alt` operator from `Control.Alt` may be helpful. | ||
|
|
||
| ## Address book | ||
|
|
There was a problem hiding this comment.
Should this address book project start with all chapter 8 exercises completed? I think that might be confusing if readers completed those exercises themselves a different way. And those exercises aren't prerequisites for this chapter.
|
|
||
| For more examples, the `purescript`, `purescript-contrib` and `purescript-node` GitHub organizations provide plenty of examples of libraries which use the FFI. In the remaining chapters, we will see some of these libraries put to use to solve real-world problems in a type-safe way. | ||
|
|
||
| # Addendum |
There was a problem hiding this comment.
In the spirit of being an "Introductory Text", I think the most important content to cover in this chapter is how to call JavaScript from PureScript, as is required for building the Address Book app. The details on runtime representation and calling PS from JS don't seem as necessary. I think it would be best to let these sections serve as an addendum, or even just live in the docs repo where they are partially duplicated already.
Some related discussion:
https://functionalprogramming.slack.com/archives/C04NA444H/p1588600540352500
https://functionalprogramming.slack.com/archives/C04NA444H/p1588600910356600
https://functionalprogramming.slack.com/archives/C04NA444H/p1588610399361200
Summary:
Phil originally had a JS app with a pure PS core when he wrote the book, but that use case is less common today, and creating a "reverse ffi" module for effectful purescript seems outside the scope of this book.
This guide has some details on embedding effectful PS within a React JS app.
https://thomashoneyman.com/articles/replace-react-components-with-purescript/#replacing-a-react-component-with-purescript-react
The simpler argonaut workflow replaced these sections in the original text:
- Working With Untyped Data
- Handling Null and Undefined Values
- Generic JSON Serialization
| A full discussion of _parametric polymorphism_ and _parametricity_ is beyond the scope of this book. Note however, that since PureScript's types are _erased_ at runtime, a polymorphic function in PureScript _cannot_ inspect the runtime representation of its arguments (without using the FFI), and so this representation of polymorphic data is appropriate. | ||
|
|
||
| There are three possibilities for the result of `FormData`: | ||
| ## Representing Constrained Types |
There was a problem hiding this comment.
It is not advised to call functions via explicit type class dictionaries, as this section describes.
|
Are any of the additions here based on content you've found elsewhere by other authors? For just bringing things up to date copyright isn't much of an issue, but I would prefer to be more careful about it if we're making larger changes like this. |
The only lifted content is from this section of FFI tips in the docs repo.
I learned about using arrow functions, json, and promises, from this Best Practices Guide, but then wrote the book's content independently with unique examples and explanations. Here's a list of all resources consulted. Although nothing else in the book could be considered derived from these: |
|
Ok great, thanks. In that case I think it should be sufficient to add a note somewhere (perhaps in the readme, or alongside any existing note that talks about licensing?) that some of the content is derived from the documentation repo, and is licensed under the same license, and is copyright "various contributors" (link to CONTRIBUTORS.md), or something like that. |
|
Added license note |
|
Merged to keep the ball moving, but happy to hear additional feedback on this chapter. |
Just noticing that, as of today, MySolutions.js seems to have solutions for all of the exercises. Should these have been removed? |
|
Yep. I forgot to convert this chapter to follow the |
|
Ok, I gave it a shot in #297. |
3 participants
#27 and #58 discuss some gaps in this chapter's FFI material.
To provide more complete FFI coverage and a logical sequence of topics and exercises, I did a major restructuring of this chapter. I feel like the emphasis should be on "Calling JavaScript from PureScript" and adding to the Address Book project.
The other topics on "Calling PureScript from JavaScript" and "Runtime Representation" do not seem as critical for readers, and they don't lead to testable exercises, so I moved these topics to a new "Addendum" section.
A full test suite for the book's examples and exercises is also complete. The solutions are in this draft PR for reference, which I'll remove before merging.
View rendered text here.
Or view mdbook preview by checking-out and running: