gren-lang / core Goto Github PK

Gren's core package

License: Other

JavaScript 99.93% Shell 0.07%

core's Introduction

Core Libraries

Every Gren project needs this package!

It provides basic functionality like addition and subtraction as well as data structures like arrays, dictionaries, and sets.

New to Gren? Go to gren-lang.org for an overview.

Default Imports

The modules in this package are so common, that some of them are imported by default in all Gren files. So it is as if every Gren file starts with these imports:

import Basics exposing (..)
import Array exposing (Array)
import Maybe exposing (Maybe(..))
import Result exposing (Result(..))
import String exposing (String)
import Char exposing (Char)

import Debug

import Platform exposing (Program)
import Platform.Cmd as Cmd exposing (Cmd)
import Platform.Sub as Sub exposing (Sub)

The intention is to include things that are both extremely useful and very unlikely to overlap with anything that anyone will ever write in a library. By keeping the set of default imports relatively small, it also becomes easier to use whatever version of map suits your fancy. Finally, it makes it easier to figure out where the heck a function is coming from.

core's People

Contributors

Stargazers

Watchers

Forkers

atlewee alexislozano arkham jwashton revathskumar blaix joeybright

core's Issues

Add Array.range function

`run-tests.sh` is broken

elm/core#1103

Core still imports Tuple

If I recall correctly, one difference of gren from elm is to not use tuples, but records instead.

prefix binary operations → curry-able functions

Using an operator's prefix notation is unintuitive and prone to errors:

Just 3 |> Maybe.map ((-) 3)
--> Just 0

Proposal: remove (symbol) syntax and prefix binary operations in favor of actual functions:

(^) n exp → n |> toPower exp
(/) n div → n |> divideBy div
(//) n div → n |> Int.divideBy div
(*) n mul → n |> multiplyBy mul
(-) n sub → n |> subtract sub
(+) a b → b |> add a
...
bool |> and also
bool |> or also
min a b → a |> atMost b
max a b → a |> atLeast b
(<) a b → a |> isBelow b
(<=) a b → a |> isAtMost b
(>=) a b → a |> isAtLeast b
(>) a b → a |> isAbove b
(++) init tail, .append init tail → init |> .append tail
(::) element list → list |> cons element
(<|) → apply? remove?
(|>) → eat/feed/feedWith/with? remove?
(>>) → remove?
(<<) → over/overTo/to/then/thenTo/compose/furthermore/furtherTo? remove?

including parser operators (replaced by |> skip, |> grab, ...).

My secret hope is that just like %, which was removed in favor of modBy & remainderBy,
conventions will develop abandoning, for example

&&, ||, min, max, unary -, ^, all parser operators
init |> append middle |> append tail
> [ init, middle |> operation, tail ] |> concat
> init ++ (middle |> operation) ++ tail

(I'm not opposed to removing all listed and more)

leap seconds aren't handled

elm/time#30

`Seed` ⇄ 2 `Int`s conversions

elm/random#17

Comparing Arrays will crash

It seems like there is issues comparing Arrays. ( This also makes using Array as key for Dict crash )

This thing compiles:

But crashes in the browser:

Could it be some "cons" logic from Elm-lists that does not work for arrays?

number operations: only some truncate results to 32-bit

The commonly suggested fix is to always truncate to 32-bit.

regression: capture groups can't match `""`

elm/regex#5

documentation: point out browser irregularities

elm/regex#10

`Dict.get` with `List` keys on `--optimize`: unreliable

elm/core#1013

`"" |> String.any`, `"" |> String.all` documentation examples missing

elm/core#1076

`_Platform_gatherEffects` can throw runtime exception - Maximum call stack size exceeded

elm/core#1123

subscription not receiving response

(not sure if that issue was placed in the right repo)
elm/core#1128

`==` on `Value`s of different shape misbehaves

Encode.object properties
- elm/json#30
- elm/json#29
elm/core#945

Note: It is discouraged to actively call == on js Json.Encode/Decode.Values:

Should compile-time constraints on == be introduced, Values would be disallowed from being compared, allowing these cases could be ignored.

human time display example: missing `0`-padding

elm/time#14

`customZone` requirement to sort exceptions from latest to earliest

elm/time#16

`Decode.index` doesn't check for negative numbers

elm/json#18

setting `Date.prototype._nth = null;` from js → Uncaught TypeError

elm/core#1005

runtime exception in `subscribe` → side effects stop working

elm/core#1046

`Regex.fromString ""` → js heap out of memory error

elm/regex#6

many String functions' documentation invalid/incomplete (characters vs UTF-16 code units)

elm/core#1061

Zone transitions don't take effect on their start times

elm/time#7

`Char.toUpper` on special-cased unicode characters returns 2-character `Char`

elm/core#1001

`port`s inside `Cmd.batch` are called asynchronously

elm/core#989

`Array` sorting

elm/core#1112

`float` lacks sanitization of input and emits invalid numbers when bounds are swapped

elm/random#21

`NaN` is equal to zero in several cases involving literal `0`

elm/core#1115

`NaN > NaN` and `NaN >= NaN` do not adhere to IEEE-754

NaN > NaN and NaN >= NaN do not adhere to IEEE-754

`port` sending an unexpected value → uninformative error message

elm/core#1043

js object with circular dependencies `|> Encode.encode` → runtime error

elm/json#5

type `Zone` documentation: reference to non-existing `Browser.Env`

elm/time#22

`split` doesn't include capture groups in results

elm/regex#7

`==` on `Decoder`s of different shape misbehaves

However, when ui diffing, equality seems to matter if I understood correctly.

`Decode.oneOf` falsely `True`

`String.toList` on non-UTF-8 encoded `String` → infinite loop

elm/core#1060

`Decode.dict` on a JSON created with `Object.create(null)` → runtime exception

elm/json#24

Provide direct access to JS Strings

Gren currently abstracts away the fact that JavaScript Strings uses a 16-bit encoding, and performs runtime conversion between different representations in an attempt to make Strings and Characters easier to understand.

This abstraction isn't free however. The current implementation has bugs and performance implications. Certain code, like String hashing, becomes harder to do well because it's sometimes necessary to undo the runtime conversions that the Gren runtime performs.

It might be better to simply remove this abstraction, so that Gren strings are JS strings, with all the benefits and downsides that entail.

Pros:

Simpler maintance
Improved performance
One less abstraction to worry about when dealing with strings

Cons:

Users, especially those who don't already know JS, might find strings harder to reason about.