|
|
|
|
|
by tel
3601 days ago
|
|
I'm not really interested in putting in the effort to convince you. This opinion arises from conversation I've had with users of ghcjs, developers of ghcjs, and people very familiar with GHC compilation pipeline details and runtime details. The last I heard, the primary dev of ghcjs intended to build a new codegen which would alleviate some of the issues here, but that hasn't happened yet to my knowledge. The comment about imperfect semantics arises from a few weirdnesses around JS interaction with laziness. Perhaps the biggest one I remember is that when calling Haskell from JS you have to be prepared for the idea that results may not be fully evaluated. There wasn't any real mechanism to force and block on the Javascript side and certainly no mechanism to handle it asynchronously (promises wouldn't work unless they decorated inner layers of a data types which would be terrible). This also plays out on the Haskell side in terms of managing retention strategies. In a strict language both of these obviously just vanish. |
|