Extending Prelude in a project

Questions
1

Is there a way to have my own, extended version of Prelude in a project?

Of course one way to go about this is to have a CustomPrelude.daml for instance and import it in every other DAML files.

I wonder if this is the only way and can I do better?

2

I think that’s pretty much it. Just start your module with

{-# LANGUAGE NoImplicitPrelude #-}

to disable the standard prelude, and then import your own.

3

Hm, that’s good to know. However, that has to go into every file I suppose. Also, I’m not trying to get rid of Prelude but rather have an extended version of it.

Maybe a “magical” option in daml.yaml:

sdk-version: 1.3.0
name: example-project
version: 1.0.0
source: src/main/daml
prelude: CustomPrelude.daml
dependencies:
- daml-prim
- daml-stdlib

And here CustomPrelude.daml could export Prelude itself along with whatever is in it.

4

In that case perhaps call it something like global or alwaysimport so that it’s clear it doesn’t need to be prelude-related.

Also could this be an anti-pattern? It’s somewhat odd to have imports without them being explicitly defined in the file, at least I’ve not really encountered it. For the prelude in particular you’d have a set of commonly understood functions that now may behave differently and it not being readily apparent why that’s the case. Or that it’s happening at all if type definitions stay the same.

5

I’ve used NoImplicitPrelude and a Haskell-specific feature (as in not supported in DAML atm) to not just hide Prelude but replace it fairly heavily in the past. However, over time I pretty much stopped using it for two reasons:

  1. It seems like a useful feature at first glance but the benefits are pretty small. It saves you a few lines of typing imports. In my experience, that is never what is slowing me down.
  2. It gets really confusing especially if you frequently switch across projects. Even if you stay within a project, having the imports there explicitly doesn’t do any harm and if you use explicit imports, it’s easy to see where things come from.

So overall, I would recommend against trying to use this here.

1 Like
6

Yeah, probably you guys are right the more I think about it. I guess if DAML Studio offered imports for project types as well (not just the ones from stdlib) this would not bother me that much.

1 Like
7

Do you mean that there is some autocomplete feature which you would want to work differently? If so, this may be worth raising as a GitHub issue (or clarifying here a bit and I’ll make an issue for you).

1 Like
8

6 posts were split to a new topic: Improving import handling in VS Code