#Recommended project structure

1 messages · Page 1 of 1 (latest)

granite kiln
#

I was wondering what the recommended project structure is since I keep running into circular import errors. For example, I have a data folder that contains some of my data structures:

data/
  datatype.gleam
  scope.gleam
  ...

However, datatype.gleam requires something from scope.gleam, and vice-versa. I'm not sure how to fix this up.

past marsh
#

Rather than group by "kind" of thing, I think it's better to group by business domain

#

So I wouldn't have a data directory for types, and split them up into modules

#

Rather I might have directories in src/myapp/ called things like accounts, reporting, adminstration, billing, etc

#

And all the related types, functions, and constants are together in the same modules

#

This makes the imports simpler, makes it easier to make items private, and means you don't have to have lots of files open at the same time, because everything will likely be in one module

granite kiln
#

Ohh that makes sense!

#

By module do you mean a single directory or a single file?

past marsh
#

I'd start with a single module

#

Nothing wrong with big modules 🙂

granite kiln
#

What exactly is a module in Gleam?

#

Is it like a package in TS?

past marsh
#

JS module -> Gleam module
npm package -> Gleam package

granite kiln
#

Ah

#

Don't know what I was thinking

granite kiln
#

So far development has gone pretty well, but now I'm starting to feel "restricted" inside each module. For example, in my language's evaluator module, I have a section for builtin functions (https://github.com/MystPi/bella/blob/1cda347188e4c28ba3a1100f3f47c3180c5c697b/src/bella/evaluator.gleam#L378). I wanted to extract that section to a new module in evaluator/builtins.gleam because I plan on adding a bunch more builtins, but I'm running into the circular import problem again. Every time I try to extract something from a module and put it in a submodule, I run into this problem. It's kind of frustrating. Is it just my lack of FP experience? I can't recall this being a problem in TypeScript.

GitHub
bella/evaluator.gleam at 1cda347188e4c28ba3a1100f3f47c3180c5c697b ·...

Bella ⌁ A simple functional programming language ⌁ Written in Gleam! - bella/evaluator.gleam at 1cda347188e4c28ba3a1100f3f47c3180c5c697b · MystPi/bella

past marsh
#

TypeScript permits circular imports so it doesn't have the same situation

#

What's the cause of the import cycle if you move those out?

Though that's a very small module so I personally wouldn't move anything yet.

granite kiln
#

The builtins module would depend on types and functions from the module that imports it.

past marsh
#

Specifically which ones

#

Sorry, it's hard to make suggestions without context

#

The options are

  1. Keep them in one module
  2. Split out 2 modules to make, A, B, and C, where A and B depend on C, and A depends on B
granite kiln
#

No problem. It requires the DataType type, which is basically the languages runtime type system, and a few utility functions, to_string and to_type. There may be other things that I have forgotten as well.

past marsh
granite kiln
#

Thank you! I modelled it similar to Elm.

past marsh
#

If you wanted to split it you could have a module for the definition of DataType which both could use, or move DataType to the module with the builtins perhaps

granite kiln
#

I tried that before, but I can't remember why it didn't work out. I'll try it again.

granite kiln
#

Now I remember. There is a function, evaluate_str, that depends on the evaluator and a builtin function depends on it, so no matter where I move it, it creates a circular import.

past marsh
#

I think the import should remain part of the evaluator as it evaluates code

granite kiln
#

I didn't think of that. I'll give it a go!

#

That worked nicely! Thank you for putting up with my stupid problems. 😅

past marsh
#

Not stupid at all!!

devout rock
#

Oh another language in gleam!! 😮😮

past marsh
#

Another glanguage