I've had the idea of tracking function purity in my head for some time now, and now I discover that Nim has a similar system!

This prior art will be very useful for designing any future effects tracking in Gleam :)

Links

• Nim: https://nim-lang.org/docs/manual.html#effect-system
• Koka: https://koka-lang.github.io/koka/doc/kokaspec.html

Rough sketch of how it might look in Gleam

https://github.com/gleam-experiments/experiments/blob/master/effects.gleam

Initial work here: https://github.com/gleam-experiments/time

Type Providers are an interesting approach to consuming resources in a type-safe way; it is a feature of the F# programming language and can be used to consume:

• Documents like XML, JSON, HTML.
• Mapping SQL relations into types or check SQL at compile type.
• Communicate with APIs, Protocols, Datasets or complex domain idiomatically.

Lectures:

• Strongly-Typed Language Support for Internet-Scale Information Sources by Microsoft, Et al.
• Approximating type providers with procedural macros in Rust by Erik Vesteraas
• Dependent Type Providers by David Christiansen.

Why?

This issue was spawned from a previous discussion for an SQL query builder library. This is just meant as an exploration of what Type Providers could bring to the table as an useful or feasible feature for the language.

• Built at compile time
• Plugin based escaping (supply no escaping, xml/html)
• Logic-less?

At least for devs you could simplify the installation by just publishing your crates to crates.io via the normal mechanisms. gleam is already taken, but maybe something like gleam-lang would suite you. That way installation for anyone who has rust installed would just be cargo install gleam-lang.

This could be a wrapper around Poolboy

After reading about the OCaml implicit module PR I've had the idea for a system of implicit parameters bouncing round my head, giving Gleam a way of producing polymorphic functions such as enum:map which could operate on more than 1 type of data structure with less boilerplate.

Now it seems Scala has a very similar system already! A good place to start research.

https://docs.scala-lang.org/tour/implicit-parameters.html

https://docs.scala-lang.org/tutorials/FAQ/finding-implicits.html

http://tycon.github.io/modular-implicits.html

https://discuss.ocaml.org/t/critique-of-implicits/3031/59

Original issue: gleam-lang/gleam#69

This article talks about the interface and could be useful: https://dockyard.com/blog/2019/03/07/taming-ets-for-high-performance-software

Apologies if this has already been discussed elsewhere:

Are there plans to implement a macro system for gleam? If so, has any thought been put into the syntax/mechanics of such a system (i.e. more like Rust's, Elixir's, etc)?

This OCaml library has a nice interface that would map well onto Gleam (minus the async)
https://medium.com/@bobbypriambodo/interfacing-ocaml-and-postgresql-with-caqti-a92515bdaa11

I would suggest we wrap epgsql
https://github.com/epgsql/epgsql

We would likely want to provide an easy to set up pool, perhaps this lib could provide some inspiration (not read the source yet). See also #2
https://github.com/egobrain/epgpool

https://github.com/elli-lib/elli_access_log/blob/master/src/elli_access_log.erl

https://elixirforum.com/t/erleans-now-with-elixir-and-ecto/27752

enum Role {
  Teacher
  Student
}

enum SchoolPerson {
  Janitor
} + Role

type Role = enum {
  Teacher
  Student
};

type SchoolPerson = enum Role + {
  Janitor
}

Gleam has no subtyping, so is this useful? It would remove some boilerplate but doesn't make the language more expressive.

At the moment there are, to my knowledge, primarily two places (excepting GitHub) in which conversations about Gleam happen on the internet: 1) the IRC channel, and 2) this Elixir Forum thread. Neither of these seem like great solutions for the people who discover Gleam and then want to learn more/build things/express their interest and excitement/collaborate on Gleam projects or project ideas.

What are some better options? The first ones that came to mind were Slack, Discord, and Discourse, and I think any of those might be great. Another option which might be a good compromise between the aforementioned is Spectrum, which was apparently bought by GitHub ~1.5 years ago.

I think that any solution that is more accessible than IRC and more Gleam-centric than the Elixir Forum would be a big win for growing the Gleam community and garnering excitement for the Gleam language!

Original issue: gleam-lang/gleam#25

Suggested here -> https://elixirforum.com/t/gleam-a-statically-typed-language-for-the-erlang-vm/20349/210?u=lpil

Info

• http://davidchristiansen.dk/tutorials/bidirectional.pdf
• https://ncatlab.org/nlab/show/bidirectional+typechecking
• https://www.reddit.com/r/haskell/comments/9rrmlq/resources_on_implementing_a_bidirectional_type/
• https://news.ycombinator.com/item?id=15583923
• https://github.com/ollef/Bidirectional
• https://github.com/atennapel/bidirectional.js

Hello
First, thanks for great project.

Currently, seems that there are only build command to make .erl file, and no command for running the module directly.

For example, new project with gleam new, I sometimes just want to make console print message in hello_world() just using single command.

pub fn hello_world() {
  "Hello, from first_project!"
}

Is there a plan to make such thing?

https://typeclasses.com/phrasebook/invert

Simplest path: bindings to jsx.

We could create bindings to Jiffy, which is much faster but requires C compilation to use.

Hardest but possibly most beneficial path: Fork Jason, strip out the protocols and Elixir specific bits, then decompile to Erlang and write bindings. This would us a very fast pure Erlang Json library without the Elixir dependency.

https://github.com/beam-telemetry/telemetry

The most common mistake I make when writing Gleam is typing true or false instead of True or False when pattern matching 🤦‍♂️ . This compiles just fine but silently fails because e.g. when false is first, it always matches and binds the value to first.

Basic cases of this, i.e. where a catch-all pattern is not at the last position, could be caught at compile time and show a warning.

Copied from gleam-lang/gleam#240 (comment)

Full on first-class lenses would be a lot more powerful!

In essense for the OP example, you could have .doodad make a lens, a Lens struct would just be a struct with two fields, a get and an update field (although some systems add in more for efficiency reasons, those are the base two that you need though and is still what most systems do), the fields of which just hold functions. So for something like .doodad on the OP Thing struct, it would create a Lens struct like (in Rust'ish notation as I haven't learned gleam's notation yet ^.^;):

// Global `Lens` definition:
struct Lens<Object, Result> {
  type Result;
  get: Fn(&Object) -> Result;
  update: Fn(Object) -> Object
}

// Create the `.doodad` lens
Lens<Thing, i32>{
  get: |&thing| -> thing.doodad
  update: |doodad, thing| -> Thing{doodad: doodad, ..thing}
}

Which then given a get function and an update function (and you can make others from those two like an update_in that takes a function to transform or so forth as well), you could use it like get .doodad some_thing or update .doodad 42 some_thing, traditionally the value preceeds the object for ease of piping reasons in curried languages, but whatever is appropriate for the language. And of course you can chain them together, like if you had this:

struct Thing {
  doodad: Int
}

struct HoldsAThing {
  thing: Thing
}

Then you could compose them either explicitly like compose .thing .doodad (or to disambiguate if identical names are in scope you can use full names like compose HoldsAThing.thing Thing.doodad), and if you assigned that to a binding named something like thing_in_holder then you could still use it like get thing_in_holder holder or update thing_in_holder holder 42 or so.

A common pattern in some languages is that a tuple of lenses acts as an implicit compose as well, so (.thing, .doodad) is the same as compose .thing .doodad when passed to the get/update functions if it is a language that supports different function types on identical function names (which since the OTP doesn't support currying efficiently then might be a good feature to add to gleam).

And of course, since a lens is just a struct/record, can call it's callbacks straight too .doodad.get thing or .doodad.update 42 thing.

And of course, you can have a pretty trivial pass in the compiler so that if something like get .doodad thing is used then you can optimize the creation of the two closures to just become a direct call too pretty easily.

For note, haskall does implicit composition of lenses by doing things like get (thing . doodad) holder; it doesn't use .thing syntax instead of thing because the fields of structs become 'magical' once compiled, like loose functions, it's generally not a recommended language pattern nowadays and the .thing syntax has become pretty standard now.

Notes

Rust special traits. Send seems very relevent to us https://doc.rust-lang.org/reference/special-types-and-traits.html

Implementation notes

• https://www.reddit.com/r/haskell/comments/9rrmlq/resources_on_implementing_a_bidirectional_type/

It'd be great if we could produce native binaries from Gleam code that can boot quickly as it would expand the range of possible uses for Gleam. The area I am interested in is command line tools.

The Lumen project is a Erlang to LLVM compiler, intended to enable the use of Elixir in the frontend using WASM. This could be a great fit for Gleam. Once Lumen is more mature Gleam's richer type information could be used to Lumen to output further optimised native code. https://github.com/lumen/lumen

Idris 2 / Bodwen outputs Scheme and compiles it with the Chez Scheme compiler, perhaps this is a low effort way to achieve this. https://github.com/cisco/ChezScheme

Malfunction (extracted from OCaml) was also suggested https://github.com/stedolan/malfunction

If we could create native Gleam binaries then perhaps one day the compiler could be written in Gleam itself!

To help with learning. Exercism is rolling out a new v3.

https://www.rebar3.org/docs/dependencies#section-checkout-dependencies

Original issue: gleam-lang/gleam#106

Like the concept! Woo-hoo!

Some thoughts:

1. Make syntax like Python/F#/Elm (e.g. indents, not {})?
2. Compile to Elixir, not Erlang (if possible)? (Mainly because I've never met an Erlang programmer and think it would be much harder to hire vs. and Elixir programmer)
3. Look at F# for how they handle Union Types. I think Elm is similar. In general, I think F# is a pretty nice model to follow in term of syntax for an ML language. Elm is nice, too.
4. Think about integrating with ExDoc? Or an equivalent substitute? (Erlang docs tend to be terrible...)
5. Ecto integration/replacement?
6. GenServer?

F#
https://docs.microsoft.com/en-us/dotnet/fsharp/language-reference/discriminated-unions

Elm
https://guide.elm-lang.org/types/custom_types.html

We use Elixir on the backend and Elm on the front end. Both are great, but the main thing I miss on the backend are proper Union types (and strong typing).

Rock on!

Currently gleam doesn't seem to emit any error or warning for dead code (variables, types and functions). Is there some kind of consensus on dead code detection/elimination?

I guess there could be a couple of paths to take, depending on each situation:

• Emit an error when compiling gleam.
• Emit a warning when compiling gleam.
• Eliminate unnecessary code from the generated erlang files.

Rebar seems to be doing this for us, example:

===> Compiling life
gen/src/life.erl:26: Warning: the guard for this clause evaluates to 'false'
gen/src/life.erl:34: Warning: variable 'Value' is unused
gen/src/life.erl:40: Warning: variable 'Cell' is unused

Original issue: gleam-lang/gleam#66

Research needs to be done into the best approach to implementing this.

working on this. will create gleam repl subcommand

I guess this has already been discussed, but it appears that to declare a record type I need to use a custom type like:

pub type Cat {
  Cat(name: String, cuteness: Int)
}

When I wish I could do

pub type Cat {
  name: String,
  cuteness: Int
}

If custom types are really needed, maybe there could be some sugar that expands to that

• https://github.com/DRMacIver/minithesis
• https://github.com/proper-testing/proper

For creation of OTP compatible processes