Confusion when importing type and its constructor

[hoosierEE]

I'm new to Gleam and had some code like this:

import pog

pub type Context {
  Context(db: pog.Connection)
}

fn handler(ctx: Context) {todo}

pub fn main() {
  // ... skipping other stuff
  let ctx = Context(con)
}

As the file was growing larger I decided to factor the Context type into its own file, so now there's two files:

context.gleam

import pog

pub type Context {
  Context(db: pog.Connection)
}

main.gleam

import context.{type Context}

fn handler(ctx: Context) {todo}

pub fn main() {
  // ... skipping other stuff
  let ctx = Context(con)
}

This fails to compile with this error:

➜  gleam-site git:(main) ✗ gleam build
  Compiling learn_gleam_todo
error: Unknown variable
    ┌─ /Users/me/repo/gleam-site/src/learn_gleam_todo.gleam:280:17
    │
280 │   let context = Context(con)
    │                 ^^^^^^^

`Context` is a type, it cannot be used as a value.

Ok, I guess I can import it without the type keyword, like import context.{Context}, but that results in error: Unknown type.

Through trial and error I eventually discovered how to resolve the issue via import context.{Context, type Context}. So this solved the problem for me. But I assumed that import context.{type Context} would be sufficient, so the error message was confusing to me.

Now I have updated my mental model of how modules work in Gleam to something like "there are separate namespaces for types and type constructors, even though in the source code they are syntactically similar".

Perhaps this needs more explanation in the intro documentation, or maybe the compiler could "do what I mean". I don't feel strongly either way since now I know how to avoid this issue, but I wanted to make an Issue for it since it may trip up other beginners.

[lpil]

Can you think of something that the error message could say that would help you understand better in this situation?

Perhaps this needs more explanation in the intro documentation

Which documentation did you study prior to this point? Our introduction does carefully explain this, so it's useful to understand how you got here.

or maybe the compiler could "do what I mean".

We definitely do not want to make the syntax ambiguous, it makes it harder to understand. We did previously have a system like this but it was removed, and that change made the language better.

[hoosierEE]

I read the language tour and writing gleam and didn't see examples of importing both a type and its constructor, e.g:

import foo.{Bar, type Bar}

There is one example in the tour showing an import of both a type and what I assume are type constructors, but the distinction between type and constructor isn't mentioned in the text.

There's also an example of a record type where the constructor has the same name as the type, but the fact that they're in separate namespaces (and therefore must be imported separately) is not mentioned.

An example showing how to import a record and its constructor would be helpful.

We definitely do not want to make the syntax ambiguous

I think record constructors are ambiguous, because the docs say:

A type's name always starts with a capital letter, contrasting to variables and functions, which start with a lowercase letter.

...and yet a record constructor is not the same thing as a type (or at least, it must be imported separately from its type).

[lpil]

but the fact that they're in separate namespaces (and therefore must be imported separately) is not mentioned.

It's challenging to document things not about Gleam, because that list is infinite in size! I'm trying to find examples of languages where types and values are the same, to better understand where that idea would come from, and Idris is the only one I have managed to find. Why is it that you would expect them to be the same? What languages are you most familiar with?

An example showing how to import a record and its constructor would be helpful.

You linked to one example, and the "unqualified imports" and "type imports" pages explain the system.

I think record constructors are ambiguous

They are not ambiguous: type imports are prefixed with the keyword type.

[hoosierEE]

I feel like we're not understanding each other. Here's a made-up example that would have eliminated my confusion:

Importing Records

When importing a record, you can import its type, its constructor, or both (even if the constructor and type use the same name):

import mymodule.{type MyRecord}  // import the type only
import mymodule.{MyRecord}  // import the constructor for MyRecord only
import mymodule.{MyRecord, type MyRecord}  // import both

The last line that imports both a record type AND its constructor with the same name is absent from the docs. I assumed import x.{Y, type Y} must be illegal in Gleam for the same reason import x.{Y, Y} is illegal.

[jzwood]

I definitely ran into this particular mental model confusion when I started Gleam too. I'm trying to figure out where it would feel best to provide guidance: docs or compiler message. Docs are safer b/c they only effect people who specifically seek them out and are not imposed on all users, but compiler messages are more likely to reach a new user encountering this issue.

You could imagine the message

`Context` is a type, it cannot be used as a value.

could be altered to

`Context` is a type, it cannot be used as a value. Possible fix: `import context.{Context}`

only when the compiler sees that a constructor of the same name was exported from the same file that the type was defined in. I realize that might be a lot of work for a small benefit to only a few users but I could imagine that being a helpful reminder for even a veteran Gleam user. 🤷‍♂️

[lpil]

I feel like we're not understanding each other.

I understand what you are saying, but without the information I am asking you for it's difficult for me to understand the context. The tour is very carefully constructed, we cannot make changes without understanding the needs, even if you personally are certain it is an improvement.

You could imagine the message

Context is a type, it cannot be used as a value.

could be altered to

Context is a type, it cannot be used as a value. Possible fix: import context.{Context}

There is a work in progress PR for this from last year: #4615

[hoosierEE]

Fair enough. Languages that I had in mind are Emacs lisp and Ruby, which are "lisp-2" style languages because functions and variables exist in separate namespaces. This means you can have this:

(defun foo (x) x)  ;; an identity function
(setq foo 42)      ;; a global variable
(foo foo)          ;; returns 42
(foo #'foo)        ;; returns the function foo

To pass the function as a value in Emacs lisp requires you to add sigils to the name like #'foo. I know having a distinction between variables and functions is different from having a distinction between types and values, but it trips up language users in the same way.

In Gleam we can have a record type named Bar whose constructor is also named Bar. You can tell these apart syntactically where they're defined:

pub type Bar {  // this is a type because it has the word type in front
  Bar(x: Int)  // this is a constructor because... parens? lack of "type" keyword?
}

Or you can tell them apart by how they're used:

fn wibble(x: Int) -> Bar {  // this Bar is a type because it's in the type annotation of the function
  Bar(x)  // this Bar is a type constructor because... parens?
}

It's more confusing if you have a generic type:

// wat.gleam
pub type Wut(x) {
  Wut(x)
}

...because now you can have wat.Wut(a) not equal to wat.Wut(a):

// main.gleam
import wat

pub fn g(a) -> wat.Wut(a) {
  wat.Wut(a)
}

If you can only tell two things apart due to context clues, this is ambiguous for the reader (even if it's unambiguous to the compiler). It's not as bad as Buffalo buffalo Buffalo buffalo buffalo buffalo Buffalo buffalo, but it's in the same category.