Here, \/ is from Data.Either.
This example is copied from the link above:
f :: (Int \/ String \/ Boolean) -> String
f = show \/ identity \/ if _ then "Yes" else "No"
What does the import statement look like?
Here you need to import both the type \/ and the value \/.
The syntax for importing type operators is type (\/). The prefix type is necessary for disambiguation - that is, to let the compiler know that you're importing the type, not the value that might have the same name.
And the syntax for importing the value is as usual.
So the whole import would look like this:
import Data.Either.Nested (type (\/), (\/))
In conclusion, I would recommend using your IDE integration (for example, here's a VSCode extension) to insert imports for you. That way you don't have to know the precise syntax.
Related
I'm trying to model in Purescript the SetOptions data type from Firestore.
Up to now I have the following
foreign import data FieldPath :: Type
foreign import buildFieldPath :: Array String -> FieldPath
foreign import fieldNames :: FieldPath -> Array String
type MergeFields = Array (String \/ FieldPath)
data SetOptions
= MergeOption Merge
| MergeFieldsOption MergeFields
Note that SetOptions is a sum type since the merge and mergeFields are mutually exclusive (even if this is not documented).
Now I need to convert SetOptions into a Javascript object, so that I can pass it to some function from the Javascript firebase library.
It should be something of the form
{
"mergeFields": [
"foo",
new FieldPath("bar", "baz")
]
}
My issue is the type of this.
I can't use Object since the contained data are not homogeneous (merge refers to booleans, mergeFields refers to arrays).
I can't use Json because I need to have FieldPath objects in the result.
The only solution I found up to now is returning some Json and then on the javascript side parse it and add the FieldPath objects where needed, but it looks dirty and brittle.
I would probably skip coproduct SetOption representation on the PS side and just provide these two "dirty" constructors:
foreign import data SetOption :: Type
merge :: Boolean -> SetOption
merge m = unsafeCoerce { merge: m }
mergeFields :: MergeFields -> SetOption
mergeFields mf = unsafeCoerce { mergeFields: mf }
I would probably do the same for MergeFields coproduct.
We are doing something similar in our community project - material ui bindings: purescript-react-basic-mui. Additionally we are grouping these related constructors into records to achieve "cheap namespacing" because we are generating all these bindings from typescript declarations, but this is not really important in this context.
Please take a look at some definitions in this example module:
https://github.com/purescript-react-basic-mui/purescript-react-basic-mui/blob/codegen-read-dts/src/MUI/Core/Badge.purs#L20
EDIT: I think that this latest discourse thread can be a good additional inspiration for you #macrosh.
I have a series of nested records of config information in PureScript that I want to pass to a JavaScript function. These records predominantly consist of Maybe-typed values. Is there a way I can serialize this to JavaScript objects which omit the Nothing-valued methods and unwrap the Just-valued methods?
I've taken a shot at writing this in JavaScript using semi-hacky instanceof checks, but it's been very painful, e.g. because there is no easy way to stop the recursion (I can't differentiate my records from random other JavaScript objects). Is there a better way?
One option is to use the purescript-nullable package. You can turn Maybe values into Nullable values using toNullable :: forall a. Maybe a -> Nullable a. The resulting runtime representation is appropriate for passing to JavaScript functions, since toNullable (Just value) becomes value during runtime and toNullable Nothing becomes null during runtime.
Another option is to use the purescript-simple-json package. You can use the write :: forall a. WriteForeign a => a -> Foreign function to turn a record with Maybe values into a record where Just value is replaced with value and Nothing is replaced with undefined. This approach should more straightforward for your use case of nested records with Maybe values.
You can use genericEncodeJson from Data.Argonaut and set the omitNothingFields flag to true. This flag does exactly what you expect.
module Main where
import Prelude
import Control.Monad.Eff.Console (logShow)
import Data.Argonaut.Generic.Aeson (options)
import Data.Argonaut.Generic.Encode (Options(..), genericEncodeJson)
import Data.Generic (class Generic)
import Data.Maybe (Maybe(..))
data TheRecord = TheRecord { a :: Maybe Int, b :: Maybe String, c :: String }
derive instance gRecord :: Generic TheRecord
main =
-- Prints {"c":"Always here","a":42}
logShow $ genericEncodeJson (Options o { omitNothingFields = true }) rec
where
rec = TheRecord { a: Just 42, b: Nothing, c: "Always here" }
Options o = options
After searching for some time I found in Pursuit the module DOM.HTML.History which has the data type DocumentTitle. This type could probably be used together with the function
replaceState ::
∀ e. Foreign -> DocumentTitle -> URL -> History -> Eff (history :: HISTORY | e) Unit
To change the document.title property of the page, however, I can't find examples showing how to call this function (e.g., where do I get the external Foreign data type?). Also, I'm not even sure if this function would do what I expect it to do...
In the unfortunate case that the Purescript team didn't include in their core API a way to change the document title, it's still possible to do so by making use of purescript's handy FFI mechanism.
Add these two files into your project:
Document.js
exports.setDocumentTitle =
function (title)
{
return function ()
{
window.document.title = title;
};
};
Document.purs
module Document
where
import Control.Monad.Eff (kind Effect, Eff)
import Data.Unit (Unit)
foreign import data DOCUMENT :: Effect
foreign import setDocumentTitle ::
∀ fx . String -> Eff (document :: DOCUMENT | fx) Unit
Now you can call setDocumentTitle as you would call Console's log function, except the effect would be DOCUMENT instead of CONSOLE, of course.
kazouas answer would look like this (in PS 0.12)
import Effect (Effect)
import Data.Unit (Unit)
foreign import setDocumentTitle :: String -> Effect Unit
Javascript remains the same.
Would the Haskell equivalent of the code below produce correct answers?
Can this Scala code be fixed to produce correct answers ? If yes, how ?
object TypeErasurePatternMatchQuestion extends App {
val li=List(1,2,3)
val ls=List("1","2","3")
val si=Set(1,2,3)
val ss=Set("1","2","3")
def whatIsIt(o:Any)=o match{
case o:List[Int] => "List[Int]"
case o:List[String] => "List[String]"
case o:Set[Int] => "Set[Int]"
case o:Set[String] => "Set[String]"
}
println(whatIsIt(li))
println(whatIsIt(ls))
println(whatIsIt(si))
println(whatIsIt(ss))
}
prints:
List[Int]
List[Int]
Set[Int]
Set[Int]
but I would expect it to print:
List[Int]
List[String]
Set[Int]
Set[String]
You must understand that by saying o:Any you erase all the specific information about the type and further on the type Any is all that the compiler knows about value o. That's why from that point on you can only rely on the runtime information about the type.
The case-expressions like case o:List[Int] are resolved using the JVM's special instanceof runtime mechanism. However the buggy behaviour you experience is caused by this mechanism only taking the first-rank type into account (the List in List[Int]) and ignoring the parameters (the Int in List[Int]). That's why it treats List[Int] as equal to List[String]. This issue is known as "Generics Erasure".
Haskell on the other hand performs a complete type erasure, which is well explained in the answer by Ben.
So the problem in both languages is the same: we need to provide a runtime information about the type and its parameters.
In Scala you can achieve that using the "reflection" library, which resolves that information implicitly:
import reflect.runtime.{universe => ru}
def whatIsIt[T](o : T)(implicit t : ru.TypeTag[T]) =
if( t.tpe <:< ru.typeOf[List[Int]] )
"List[Int]"
else if ( t.tpe <:< ru.typeOf[List[String]] )
"List[String]"
else if ( t.tpe <:< ru.typeOf[Set[Int]] )
"Set[Int]"
else if ( t.tpe <:< ru.typeOf[Set[String]] )
"Set[String]"
else sys.error("Unexpected type")
println(whatIsIt(List("1","2","3")))
println(whatIsIt(Set("1","2","3")))
Output:
List[String]
Set[String]
Haskell has a very different approach to polymorphism. Above all, it does not have subtype polymorphism (it's not a weakness though), that's why the type-switching pattern matches as in your example are simply irrelevant. However it is possible to translate the Scala solution from above into Haskell quite closely:
{-# LANGUAGE MultiWayIf, ScopedTypeVariables #-}
import Data.Dynamic
import Data.Set
whatIsIt :: Dynamic -> String
whatIsIt a =
if | Just (_ :: [Int]) <- fromDynamic a -> "[Int]"
| Just (_ :: [String]) <- fromDynamic a -> "[String]"
| Just (_ :: Set Int) <- fromDynamic a -> "Set Int"
| Just (_ :: Set String) <- fromDynamic a -> "Set String"
| otherwise -> error "Unexpected type"
main = do
putStrLn $ whatIsIt $ toDyn ([1, 2, 3] :: [Int])
putStrLn $ whatIsIt $ toDyn (["1", "2", "3"] :: [String])
putStrLn $ whatIsIt $ toDyn (Data.Set.fromList ["1", "2", "3"] :: Set String)
Output:
[Int]
[String]
Set String
However I must outline boldly that this is far from a typical scenario of Haskell programming. The language's type-system is powerful enough to solve extremely intricate problems while maintaining all the type-level information (and safety). Dynamic is only used in very special cases in low-level libraries.
GHC does even more type erasure than the JVM; at runtime the types are completely gone (not just the type parameters).
Haskell's approach to types is to use them at compile time to guarantee that no ill-typed operation can ever be carried out, and since Haskell doesn't have OO-style subtyping and dynamic dispatch, there's no purpose at all to keeping the types around. So data is compiled to a memory structure that simply contains the right values, and functions are compiled with baked-in knowledge of the structure of the types on which they operate1, and just blindly expect their arguments to have that structure. That's why you get fun things like segmentation faults if you mess with unsafeCoerce incorrectly, not just a runtime exception saying the value was not of the expected type; at runtime Haskell has no idea whether a value is of any given type.
So rather than Haskell giving "the right answer" to the equivalent program, Haskell disallows your program as unsafe! There is no Any type in Haskell to which you can cast whatever you want.
That's not 100% true; in both Haskell and Scala there are ways of keeping type information alive at runtime. Essentially it's done by creating ordinary data structures that represent types, and passing them around together values that are of those types, so at runtime you can refer to the type representation object for information about the type of the other object. There are library and language facilities in both languages to let you use this mechanism at a higher (and more principled) level, so that it's easier to use safely. Because it requires the type tokens to be passed around, you have to "opt-in" to such features, and your callers have to be aware of it to pass you the required type tokens (whether the actual generation and passing of the token is done implicitly or explicitly).
Without using such features, Haskell provides no way to pattern match on a value that could be of type List Int or Set String to find out which one it is. Either you're using a monomorphic type, in which case it can only be one type and the others will be rejected, or you're using a polymorphic type, in which case you can only apply code to it that will do the same thing2 regardless of which concrete type instantiates the polymorphic type.
1 Except for polymorphic functions, which assume nothing about their polymorphic arguments, and so can basically do nothing with them except pass them to other polymorphic functions (with matching type class constraints, if any).
2 Type class constrained polymorphic types are the only exception to this. Even then, if you've got a value a type that's a member of some type class, all you can do with it is pass it to other functions that accept values in any type that is a member of that type class. And if those functions are general functions defined outside of the type class in question, they'll be under the same restriction. It's only the type class methods themselves that can actually "do something different" for different types in the class, and that's because they are the union of a whole bunch of monomorphic definitions that operate on one particular type in the class. You can't write code that gets to take a polymorphic value, inspect it to see what it was instantiated with, and then decide what to do.
Of course Haskell prints the right answer:
import Data.Set
import Data.Typeable
main = do
let li=[1,2,3]
let ls=["1","2","3"]
let si=Data.Set.fromList[1,2,3]
let ss=Data.Set.fromList["1","2","3"]
print $ typeOf li
print $ typeOf ls
print $ typeOf si
print $ typeOf ss
prints
[Integer]
[[Char]]
Set Integer
Set [Char]
Given the generic register method below I would like to define the := operator as a symbolic alias.
def register[Prop <: Property[_]](prop: Prop): Prop
#inline
final def :=[Prop <: Property[_]] = register[Prop] _
Originally I wanted to write something like this:
val := = register _
But that gives me the function signature Nothing => Nothing. My next attempt was to parameterize it with the type Prop but that apparently works only if I make it a def, which can take type parameters and pass them onwards.
Ideally I would like to omit the #inline annotation but I am not sure what object code the Scala compiler makes out of it.
Most important my goal is it not to have the := method duplicate all parts of the register method's signature except for the name and then simply let the former delegate to the latter.
def :=[Prop <: Property[_]](prop: Prop) = register(prop)
should work.
I don't believe that there's any way to achieve what you're after (basically what alias gives you in Ruby) in Scala as it currently stands. The autoproxy plugin is an attempt to address this kind of problem, but it's not really ready for production use yet due to various issues with generating code in compiler plugins.
You can do this:
def := : Prop => Prop = register
So basically here you define a function of type (Prop => Prop) that just references another function.