Remove less obious tuple references.

This commit is contained in:
Robin Heggelund Hansen 2022-04-08 10:46:11 +02:00
parent e3b4f0c700
commit cd87922300
8 changed files with 10 additions and 54 deletions

View File

@ -39,7 +39,6 @@ module Data.Name
result,
array,
dict,
tuple,
jsArray,
task,
router,
@ -426,10 +425,6 @@ array = fromChars "Array"
dict :: Name
dict = fromChars "Dict"
{-# NOINLINE tuple #-}
tuple :: Name
tuple = fromChars "Tuple"
{-# NOINLINE jsArray #-}
jsArray :: Name
jsArray = fromChars "JsArray"

View File

@ -314,23 +314,9 @@ generateCoreCall mode (Opt.Global home@(ModuleName.Canonical _ moduleName) name)
if moduleName == Name.bitwise
then generateBitwiseCall home name (map (generateJsExpr mode) args)
else
if moduleName == Name.tuple
then generateTupleCall home name (map (generateJsExpr mode) args)
else
if moduleName == Name.jsArray
then generateJsArrayCall home name (map (generateJsExpr mode) args)
else generateGlobalCall home name (map (generateJsExpr mode) args)
generateTupleCall :: ModuleName.Canonical -> Name.Name -> [JS.Expr] -> JS.Expr
generateTupleCall home name args =
case args of
[value] ->
case name of
"first" -> JS.Access value (JsName.fromLocal "a")
"second" -> JS.Access value (JsName.fromLocal "b")
_ -> generateGlobalCall home name args
_ ->
generateGlobalCall home name args
if moduleName == Name.jsArray
then generateJsArrayCall home name (map (generateJsExpr mode) args)
else generateGlobalCall home name (map (generateJsExpr mode) args)
generateJsArrayCall :: ModuleName.Canonical -> Name.Name -> [JS.Expr] -> JS.Expr
generateJsArrayCall home name args =

View File

@ -22,7 +22,6 @@ defaults =
import_ ModuleName.result Nothing (typeOpen Name.result),
import_ ModuleName.string Nothing (typeClosed Name.string),
import_ ModuleName.char Nothing (typeClosed Name.char),
import_ ModuleName.tuple Nothing closed,
import_ ModuleName.platform Nothing (typeClosed Name.program),
import_ ModuleName.cmd (Just Name.cmd) (typeClosed Name.cmd),
import_ ModuleName.sub (Just Name.sub) (typeClosed Name.sub)

View File

@ -20,7 +20,6 @@ module Gren.ModuleName
result,
array,
dict,
tuple,
platform,
cmd,
sub,
@ -162,10 +161,6 @@ array = Canonical Pkg.core Name.array
dict :: Canonical
dict = Canonical Pkg.core Name.dict
{-# NOINLINE tuple #-}
tuple :: Canonical
tuple = Canonical Pkg.core Name.tuple
{-# NOINLINE platform #-}
platform :: Canonical
platform = Canonical Pkg.core Name.platform

View File

@ -97,7 +97,7 @@ toReport localizer source err =
D.indent 4 $
D.reflow $
"Ints, Floats, Bools, Strings, Maybes, Lists, Arrays,\
\ tuples, records, and JSON values.",
\ records, and JSON values.",
D.reflow $
"Since JSON values can flow through, you can use JSON encoders and decoders\
\ to allow other types through as well. More advanced users often just do\

View File

@ -109,7 +109,6 @@ import List exposing (List, (::))
import Maybe exposing (Maybe(..))
import Result exposing (Result(..))
import String
import Tuple
import Debug

View File

@ -1,18 +0,0 @@
# From Tuples to Records
The largest tuple possible in Gren has three entries. Once you get to four, it is best to make a record with named entries.
For example, it is _conceivable_ to represent a rectangle as four numbers like `(10,10,100,100)` but it would be more self-documenting to use a record like this:
```gren
type alias Rectangle =
{ x : Float
, y : Float
, width : Float
, height : Float
}
```
Now it is clear that the dimensions should be `Float` values. It is also clear that we are not using the convention of specifying the top-left and bottom-right corners. It could be clearer about whether the `x` and `y` is the point in the top-left or in the middle though!
Anyway, using records like this also gives you access to syntax like `rect.x`, `.x`, and `{ rect | x = 40 }`. It is not clear how to design features like that for arbitrarily sized tuples, so we did not. We already have a way, and it is more self-documenting!

View File

@ -10,15 +10,15 @@ This document is going to outline the various things that can go wrong and show
The most common issue is with user-defined type variables that are too general. So let's say you have defined a function like this:
```gren
addPair : (a, a) -> a
addPair (x, y) =
addPair : a -> a -> a
addPair x y =
x + y
```
The issue is that the type annotation is saying "I will accept a tuple containing literally *anything*" but the definition is using `(+)` which requires things to be numbers. So the compiler is going to infer that the true type of the definition is this:
The issue is that the type annotation is saying "I will accept two parameters that can be literally *anything*" but the definition is using `(+)` which requires things to be numbers. So the compiler is going to infer that the true type of the definition is this:
```gren
addPair : (number, number) -> number
addPair : number -> number -> -> number
```
So you will probably see an error saying "I cannot match `a` with `number`" which is essentially saying, you are trying to provide a type annotation that is **too general**. You are saying `addPair` accepts anything, but in fact, it can only handle numbers.
@ -31,8 +31,8 @@ In cases like this, you want to go with whatever the compiler inferred. It is go
It is also possible to have a type annotation that clashes with itself. This is probably more rare, but someone will run into it eventually. Let's use another version of `addPair` with problems:
```gren
addPair : (Int, Int) -> number
addPair (x, y) =
addPair : Int -> Int -> number
addPair x y =
x + y
```