Clarify the situation around Data.List

[mpickering]

In https://gitlab.haskell.org/ghc/ghc/-/issues/20025 it was observed that the proposed changes to monomorphise Data.List were not well communicated with the community and many people were surprised at the change. It was therefore decided to revert the patch whilst the CLC proposals system was set-up, it has now been set-up so the CLC should decide on the plan for this issue.

The plan articulated by @chessai was as follows:

1. Revert for now
2. Wait for -Wcompat to become part of -Wall (which is happening and will be a part of 9.4)
3. Wait for 1+ GHC releases, and announce extensively in the meantime
4. Re-introduce the change
5. Provide a retrie command for automatic refactoring (see Feasibility of using retrie to refactor for Data.List monomorphisation facebookincubator/retrie#26)

I am executing part 1 of this plan currently (https://gitlab.haskell.org/ghc/ghc/-/merge_requests/6409)

The new CLC need to agree to the rest of this plan and communicate the result with the community.

[Bodigrim]

We briefly discussed the issue on one of CLC meeting back in October.

According to @chessai, CLC has approved monomorphisation of Data.List back in 2019. I think the process was abysmal: the vote was not recorded publicly, the decision was not announced clearly, no justification was circulated and no migration plan has been prepared at all. Nevertheless, it would set a bad precedent if current CLC just dismisses its earlier decision, without a material change of circumstances invalidating justification.

Since there is no agreed and voted migration plan, besides a draft discussed between @chessai, @emilypi and @bgamari, GHC developers may revert the change from GHC HEAD for now.

CLC will work on migration plan, but it is likely to take time and will not happen overnight. We will communicate it to GHC developers and to the community when ready.

[goldfirere]

I'm fine with the plan above -- though it sounds like "We will communicate it ..." suggests that the CLC is going to set up a migration plan without community input. Maybe that's fine: we, as a community, do not tend to address issues like this efficiently.

But I want to speak up to say we can make this less painful by adding a new feature to the language: narrowing re-exports. I will illustrate with an example:

module Poly ( id ) where

id :: a -> a
id x = x

module Mono ( id :: Int -> Int ) where
import Poly

module A where
import Poly

x = id 'x'   -- accepted
y = id undefined   -- accepted; y :: forall a. a is inferred

module B where
import Mono

x = id 'x'   -- rejected: id has type Int -> Int
y = id undefined  -- accepted; y :: Int is inferred

module C where
import Mono
import Poly

x = id 'x'   -- accepted
y = id undefined   -- accepted; y :: forall a. a is inferred

The idea is that an export list can narrow the type of an export. If only the narrowed type is imported, that's the type of the identifier. If the narrowed type and the original type are both imported, then the identifier has the original type. If two different narrowed types are imported, a use of the identifier is rejected as ambiguous (not exemplified above); one could imagine some scheme looking for a more general type, but I think that's more complicated than it's worth.

Using narrowing re-exports, Data.List could simply re-export many identifiers with narrower types. This would have the following changes, compared to the status quo:

• Data.List would be fully monomorphic, including in its Haddocks.
• import Data.List would not introduce any ambiguous identifiers.
• The change is still backward-incompatible: if a user imports a polymorphic function from Data.List (and does not have the polymorphic function imported via other means), that function would now be monomorphic. (It would be easy, though, to suggest where to find the polymorphic version in an error message.)

Compared to the plan to make Data.List monomorphic without using narrowing re-exports, the narrowing re-exports plan prevents much of the backward incompatibility, especially for those users who do not use an import list.

Narrowing re-exports might be useful elsewhere, though it's not clear quite how useful they would be. Is the benefit here worth the cost? It's not clear to me. If this narrowing re-exports feature were very widely applicable, that would be exciting... but I don't think the feature would be used much. So it does seem like a largish language-level change for a smallish use case. I wanted to float the idea, regardless, to see if anyone else thought it a better way forward.

[Bodigrim]

though it sounds like "We will communicate it ..." suggests that the CLC is going to set up a migration plan without community input

Sorry that it made such impression. This was a mere statement that CLC is responsible to get it done, not that it will work on it behind closed doors.

The change is still backward-incompatible: if a user imports a polymorphic function from Data.List (and does not have the polymorphic function imported via other means), that function would now be monomorphic.

Given that -Wcompat already urges users to import Data.List qualified, breakage of polymorphic functions imported from Data.List is likely to be the biggest migration concern. If narrowed re-exports do not resolve it, I'm not sure they are worth implementing.

[Bodigrim]

As discussed on the last CLC meeting back in February, current intention is to proceed with the migration plan as described in #22 (comment). However, given that this is a breaking and disruptive change, we would like to seek community's feedback on the proposed approach. The floor is open, please be civil.

[tomjaguarpaw]

But what actually are the proposed changes? I mean, I can guess, but others less familiar with the situation may have no clue. Can we link to an accepted proposal or at least a statement of the proposal and some discussion? (Since the proposal predates the current GitHub-based CLC process I suppose the link would be to a mailing list archive.) Although I can guess what this proposal means I don't know who proposed it, what arguments were made for and against and why the decision was made as it was. I found some justification but it would be good to have that fleshed out.

I apologise if I've missed the obvious here, but I've been clicking between the GitHub and GitLab issues trackers for five minutes without gaining clarity.

[Bodigrim]

@tomjaguarpaw the change is in https://gitlab.haskell.org/ghc/ghc/-/merge_requests/5304

[jappeace]

why would you monomorphize data.list ?

[Bodigrim]

@jappeace the justification, used by the previous composition of CLC, is here: https://gitlab.haskell.org/ghc/ghc/-/issues/20025#note_365364

[jappeace]

Nice, thanks, makes sense. 👍

[JakobBruenker]

Is it likely that changing imports for the affected bindings from Data.List to Data.Foldable would be sufficient to fix any issues arising from this change?

[phadej]

Is it likely that changing imports for the affected bindings from Data.List to Data.Foldable would be sufficient to fix any issues arising from this change?

Yes, except if you actually use list specific functions like intercalate, sort, nub or isPrefixOf etc. I.e. In general you'd change

import Data.List

to

import Data.Foldable (foldl')
import Data.List (sort)

or

import Data.Foldable (foldl')
import qualified Data.List as L

... sort to L.sort...

[runeksvendsen]

As discussed on the last CLC meeting back in February, current intention is to proceed with the migration plan as described in #22 (comment). However, given that this is a breaking and disruptive change, we would like to seek community's feedback on the proposed approach. The floor is open, please be civil.

Please don't do this. These sorts of "cleanup" changes make perfect sense in ones own personal packages, but not for a package like base whose API is depended on by thousands of packages. I know I have no vote in this, but I would like to voice my opinion that being able to use some old Haskell package I find on GitHub five years down the road with a newer GHC version is worth much more to me than an attempt to "[make] Haskell easier to learn" [1].

I'm an application developer, and the first step for me when evaluating the amount of work required to create a Haskell application is to go look for a package either on Hackage or (more often) on GitHub that does what I want. I very often find some old Haskell library on GitHub that does what I want but hasn't been updated in several years. Changes like the one suggested here increases the amount of work needed to use libraries like these, thus directly increasing the amount of work associated with developing applications in Haskell compared to other languages that have more users and therefore more libraries that remain maintained years down the road.

Also, importantly, I would like to point out that the practice of having the CLC produce patches for the newest version of the affected packages because of a breaking change to base does practically nothing to fix the issue I described above, since the only way a five year old Haskell library can make use of this patch is to update the given dependency to the newest version, which usually requires updating all other dependencies to their newest version as well (since they transitively depend on each other), which is a huge task.
Thus, only if this policy, of providing patches for libraries affected by breaking changes to base, is modified to include backporting changes to all released versions of the given package (or at least the released versions depended on by old libraries in the wild) would it actually solve the problem. This, however, would place a much greater burden on the CLC when adopting backwards-incompatible changes, but it would more accurately reflect the amount of work required by other developers down the road.

Consequently, if the CLC is genuinely interested in shifting to themselves the burden created by backwards-incompatible changes to base, then the practice of requiring patches for the newest version of affected packages would be changed to:

1. Go look for Haskell packages on the internet: on Hackage, GitHub, GitLab, Bitbucket, and privately hosted Gitea/Gitweb/cgit/etc. instances
2. Enumerate all of these packages that depend on some version (either directly or transitively) of the affected packages
3. Produce patches for all the versions of the affected packages that are depended on by the packages enumerated in step 2

To be clear, I'm not categorically against breaking changes to base. I just see how they make it more difficult for me to write applications in Haskell. And in the case of the kind of the breaking change suggested here — which I would put in the category of "cleanup" — they have a very real and quantifiable negative impact on the development of Haskell applications, and a much less real and quantifiable benefit. The main argument for the change, brought forward in [1], is that it makes Haskell easier to learn. But to what extent this is the case is more or less unknown. My opinion is that the degree to which this change makes Haskell easier to learn, and the impact of this on actually learning Haskell, does not outweigh the cost of increasing the amount of work required to use older Haskell packages with newer GHC versions.

[Ericson2314]

@runeksvendsen You might be interested in https://discourse.haskell.org/t/pre-hftp-ghc-x-hackage-a-tool-for-easing-migrations-to-new-ghc-versions/4239 / https://github.com/bgamari/tech-proposals/blob/ghc-x-hackage/proposals/001-ghc-x-hackage.md

I want this change, and for me the breakage you describe is real but also a pointless tragedy. The above proposal is a very good stop-gap solution to this; the breakage this causes is quite trivial to fix, and so if we can crowd-source fixes to each other's packages it should be not to hard to fix the issues. But this should also be but the first step, there are many more thing we can do such as support the old and new Data.List interfaces at the same time (there are no deep incompatibles like changed instances here).

One argument might be to fix make the solutions, then agree to do the breakage. (Remember, there is still a deprecation cycle here.) That sounds nice, but history doesn't pain this method in a good like, because the vast majority of languages to avoid breakage until tools are available just end up stagnating (See https://twitter.com/__phantomderp/status/1510309539538690055 and really @ThePhD's entire mission with C.)

So given the bias towards stagnation, affirming decisions like this, with long road maps, while concurrently making better tools to deal with cruft and breakage and hopefully accelerate those timelines, I think is the only path forward. It may not have much precedent, but at least it doesn't have precedent of failure.

[tomjaguarpaw]

I wonder why @runeksvendsen is the only person so far asking for long-term backwards compatibility. Are there no others that want it? Do they not know of this discussion? [1] Do they want it, and know of this discussion, but they're too burnt out arguing against breaking changes?

Personally I like cleaning things up, and this change will probably cause me personally some breakage, but not too much. On the other hand, I don't like the idea that the people who are going to be most resentful of this change are just too frustrated to participate. How can we work out if there are such people and if so, encourage them to participate?

[1] It has been posted on Reddit at least, and I posted it on Twitter.

[sjakobi]

I wonder why @runeksvendsen is the only person so far asking for long-term backwards compatibility.

I think backwards compatibility is important. But it's more important to fix API design issues like Data.List.null :: Foldable t => t a -> Bool.

[runeksvendsen]

I wonder why @runeksvendsen is the only person so far asking for long-term backwards compatibility. Are there no others that want it? Do they not know of this discussion? [1] Do they want it, and know of this discussion, but they're too burnt out arguing against breaking changes?

FYI: I have reached out to Graham Hutton (@GrahamHutton) and Erik Meijer (@headinthebox) on Twitter (https://twitter.com/runeksvendsen/status/1510526460162940931), urging them to voice their opinion in this thread, because we share views on #3 and I'm interested in hearing whether this extends to this issue.

[sjakobi]

@runeksvendsen I completely disagree that the situation with Data.List is similar to #3.

The surprising polymorphism of functions like Data.List.null and Data.List.length is a serious pitfall that has lead to bugs and will continue to cause bugs until it is finally reverted. I've encountered such bugs myself, for example dhall-lang/dhall-haskell#1115 (comment) – in this case with Prelude.null.

[phadej]

@sjakobi note that Prelude.null or Prelude.length wont change.

[sjakobi]

@sjakobi note that Prelude.null or Prelude.length wont change.

I know. I hope that Data.List will soon offer monomorphic alternatives though.

[tomjaguarpaw]

I know. I hope that Data.List will soon offer monomorphic alternatives though.

There is a backwards-compatible alternative: add a new module Data.List.Monomorphic and keep Data.List as it is (for now - I hope that we can monomorphise Data.List in due course, but I think it's important to note that we can have the benefits of monomorphisation without the costs of breakage).

[sjakobi]

What would happen to Data.List.Monomorphic once Data.List has been monomorphised? Would it hang around forever, for the sake of stability?! That doesn't seem ideal, either.

For now I can use GHC.List.null and GHC.List.length, although it feels a bit weird to use the GHC namespace for such elementary functions. Or -XTypeApplications, e.g. null @[].

[tomjaguarpaw]

Would it hang around forever, for the sake of stability?!

Not forever, just for a while. The sequence of states could look something like

1. Status quo as of GHC 9.2
2. Add Data.List.Monomorphic
3. Monomorphise Data.List
4. Remove Data.List.Monomorphic

The situation proposed in this thread seems to be a particular instance of this scheme, whereby 2, 3, and 4 are collapsed. I'm pointing out that we don't have to collapse them. We can add some delay between 2 and 3 and between 3 and 4, three releases seems reasonable, off the top of my head, but other amounts of delay are possible.

On the other hand, perhaps doing it in one "big bang" to get it over with is more desirable.

[jneira]

On the other hand, perhaps doing it in one "big bang" to get it over with is more desirable.

Given the recent sensitivity about breaking changes, i would go for the progressive way (assuming there would be breaking changes at any level)

We even could add a Data.List.Generic at same time we add Data.List.Monomorphic and remove it after removing Data.List.Monomorphic, but maybe it is too cautious

[JakobBruenker]

Would it be possible to add a warning for non-list usages of Data.List functions before the actual change is made?

[tomjaguarpaw]

Would it be possible to add a warning for non-list usages of Data.List functions before the actual change is made?

I think this is the intention of step 2 in the original post

2. Wait for -Wcompat to become part of -Wall (which is happening and will be a part of 9.4)

[JakobBruenker]

@tomjaguarpaw ah, thanks, I missed that

[TeofilC]

My impression is that this more gradual scheme would lead to more breaking changes not less (as we are introducing then removing a new module).

A nice thing about fixes to accommodate making Data.List monomorphic is that they are automatically backwards compatible, as old versions of base will have types that are more generic. The same doesn't apply to changing code to depend on Data.List.Monomorphic, some CPP would be required to make code compatible with old versions of base.

I also doubt that users of base will apply the change until it becomes breaking. This is what happened with the removal of some modules from bytestring -- many dependent libraries didn't change their imports for years until the modules were finally removed.

This was implied by sjakobi's comment, but such a module already exists in the form of GHC.List and GHC.OldList (not sure why there's two), which was introduced in base-4.8.0.0:

New (unofficial) module GHC.OldList containing only list-specialised versions of the functions from Data.List (in other words, GHC.OldList corresponds to base-4.7.0.2's Data.List)

[goldfirere]

There is a non-breaking way to proceed, as I outline above. It would require a new language feature, allowing a module to re-export an identifier with a more specific type. I think that it's a sound language feature -- the only question (to me) is whether there are use-cases beyond the update to Data.List. If we could find more motivation for the feature, then I would advocate for going that route, simply because it would be backward compatible.

[tomjaguarpaw]

Perhaps I missed something in your suggestion @goldfiere, because I don't understand how it is non-breaking. Currently this is valid code

Data.List.length (Just ())

I don't see how it can continue to be valid code after the proposed Data.List monomorphisation, even if narrowing reexports were used for that monomorphisation.

[goldfirere]

You're right, @tomjaguarpaw -- that would break. Indeed, we want that example to break, so the very essence of this move is to break code. What it wouldn't break is

module X where

import Data.List
-- NB: Prelude is imported unqualified

... length (m :: Map k v) ...

But your question highlights an aspect of this discussion that has remained implicit: precisely what breakage are we worried about? What breakage are we OK with? For example, if we're not OK with Tom's Data.List.length (Just ()) example breaking, then the matter is simple: we just abandon this direction. So I suspect we are OK with that. We're probably less OK with my example here. Bottom line: we must identify what it is we're worried about before we take steps to avoid the situation we're worried about.

[goldfirere]

I'm in favor of @Bodigrim's proposal. Indeed, as I've written elsewhere, I think that changes to core tools [definition needed] should be released only when all libraries in Stackage have patches submitted. This is a lot of work, but the work is unavoidable -- the only question who does it. The policy here makes the proponents of the change responsible; not doing this makes arbitrary open-source authors (who may strongly disagree with the change) responsible. If you're going to agitate for a breaking change, then it seems appropriate for you to put in the muscle to make it palatable for others. (Perhaps we make an exception for security holes.)

Regarding @konsumlamm's worry about Hackage vs Stackage: You make good points. But given that many Hackage packages are unmaintained or otherwise broken, it seems unnecessary to try to patch everything there. Stackage makes for a good middle ground. And note that patches for Hackage are seen as a necessary condition, not a sufficient one. That is, if every Stackage package breaks but has a patch, we probably still shouldn't merge. This would be decided on a case-by-case basis.

If we are now discussing @Bodigrim's recent proposal, can I ask that it be made more prominent? In general, where do long-term CLC proposals live? It doesn't seem there's a convenient spot in this repo, but maybe I'm just misunderstanding something. In any case, as a community member, it would be great to have a canonical URL where we can all look to understand what is being proposed and whether that proposal has been accepted (and with what debate). Right now, this ticket still seems to be about the proposal summarized by @mpickering at the top. Thanks!

[phadej]

In fact, I now kind of expect to see a set of patches for libraries (on Stackage) to be provided to maintainers as soon as GHC-9.4 is released. Because this is how I read the above "no breaking changes without Stackage patches". I don't care if it's change in base or GHC itself or some corner of transformers or mtl.

That would be very nice, I think. If every breaking change in GHC was gated by such policy, we'd live in a much healthier ecosystem.

@Bodigrim, @goldfirere I hope that CLC and GHC Steering committee (and whatever other committees & groups relevant) agree and adhere on that then.

[goldfirere]

To be clear, @phadej, no one has agreed to that plan. Do not expect this to be adhered to. It's something I personally think is a good idea, but there has been no wide discussion in this direction.

My take is that we can't promise this in good faith right now. First, we have to get GHC CI working generally, and have the head.hackage process working well. Then, we can start to tackle Stackage. The good news is that the impending arrival of Bryan as a GHC CI guru gives us reason to hope that we will get there, say, by the end of this year. Only once we have the technical infrastructure in a reasonable enough state to imagine doing this well would I try to push to make this a promise GHC makes to the world.

[phadej]

@goldfirere Then, until there's infra to do things, CLC shouldn't ask patch sets for changes either. As practitioner I don't care if the breakage is due change in base or how GHC interprets language or some other change bundled with GHC.

Instead, the valuable resource have been GHC migration guide (like there is for 9.4: https://gitlab.haskell.org/ghc/ghc/-/wikis/migration/9.4 and others https://gitlab.haskell.org/ghc/ghc/-/wikis/migration/9.2).
These are great, but for some reason not advertised resources.

I'm also sceptical about quality of patches if they were (mass)-produced. head.hackage patches are just good enough to get head.hackage job done, not uncommon they are not good enough as is to be used (e.g. they make break libraries using older GHC / libraries).

I repeat, I ask CLC to not ask for patches until there is alignment with all GHC stuff. E.g. ~ becoming an operator: https://gitlab.haskell.org/ghc/ghc/-/wikis/migration/9.4#-is-now-a-type-operator will break things (otherwise it wouldn't mentioned in the migration guide).

I could claim that ~ change is as unnecessary "cleanup" as making Data.List monomorphic. For sure neither is strictly required, both could stay as small warts / special cases in GHC Haskell for eternity. (~ is just warning though, but so is Data.List thing for now).

[goldfirere]

@phadej You're suggesting that the CLC and GHC should agree on our approach here. That sounds quite sensible to me.

But I don't think we need to stop all potentially breaking changes until we have the Stackage plan worked out. It's just that each breaking change signals our unreadiness as an enterprise-level language, in proportion with how much breakage it causes. If we believe that the ~ change would cause widespread breakage, pushing it out before the Stackage-update plan is in place adds to this signal. My recollection is that we're anticipating minimal breakage there, but I could be wrong (I didn't re-look at this to make this post). The current Data.List proposal is likely to cause worse breakage, and then has greater incentive to be held back.

I, for one, think that the Data.List proposal is breaking enough that it is in our interest to delay until we can supply the Stackage patches. But we can (and in my opinion, should) accept the proposal sooner, even if its implementation is delayed. At this point, we're not making a blanket policy -- just describing that this one proposal requires an extra step. When we're ready to, we can institute a blanket policy.

[phadej]

But we can (and in my opinion, should) accept the proposal sooner,

This proposal is accepted, see @Bodigrim comment #22 (comment)

And the whole discussion is about getting community input for CLC to decide on migration plan. I think everything has been said already, so i'll wait for CLC to write down the plan.

[gbaz]

I would propose the following:

1. Agreement that -Wall should imply -Wcompat and a corresponding change to the three release policy. (The latter is the purview of the CLC with community input -- the former is a change that the GHC team would be fine making, if the latter is resolved -- as per a recent discussion with @bgamari).

2. Adding the warning to -Wcompat for unqualified import of Data.List

3. Release ghc 9.4 and... wait.

Now, at such a time as people feel comfortable "pulling the lever" on the actual changes to Data.List, they can be implemented. This may involve a patchset, this may involve more tooling with head.hackage, etc, or it may require something somewhat different.

The outstanding questions are really about just what the criteria are for pulling the lever. But the next steps are the same regardless, and should proceed.

[Ericson2314]

That sounds good to me. While improved CI should obviate the criticality of -Wall (since we would be relying on testing hope hoping community members hitting something by accident), I nonetheless think -Wall including -Wcompat is indeed a good idea.

[mpickering]

See the recent reddit thread about breaking changes for why we need to tread extremely carefully here..

https://old.reddit.com/r/haskell/comments/ujpzx3/was_simplified_subsumption_worth_it_for_industry/

[Bodigrim]

Here is my final proposal, slightly amended from above:

1. Wait until GHC X.Y makes -Wcompat-unqualified-imports a part of -Wall, either directly or by including all -Wcompat into -Wall.
   Fixing -Wcompat-unqualified-imports should eliminate the majority of breakage, which is caused by conflicting identifiers from Prelude (polymorphic) and from Data.List (monomorphic). The only remaining cases would be when users explicitly imported Data.List as L, but used L.foldl for something else, which is arguably wrong.
2. Wait until Stackage for GHC X.Y is available, which roughly coincides with GHC X.Y+1 released.
3. Ask proponents of the change to prepare patches for all Stackage packages. This is likely to be a huge task to perform manually, so volunteers are encouraged to develop a semiautomatic migration tool (in form of retrie, regexp, HLS plugin, or whatever technology is available in the glorious future), covering the majority of cases.
4. Once a patch set is ready (it does not need to be merged, just readily available for public), we pull the trigger and make the change in base for GHC HEAD (to become X.Y+2 or X.Y+3).

This plan puts the burden on the proponents of the change. If they wish to speed up the process, they can potentially start patching existing packages right now, not even waiting for GHC X.Y. On the other hand, if few people are interested to put their efforts into it, the change is likely to be delayed until a day when the majority of packages choose to comply with -Wcompat-unqualified-imports themselves.

Dear CLC members, let’s vote on this migration plan. @tomjaguarpaw @emilypi @chessai @cgibbard @mixphix

---

+1 from me.

[tomjaguarpaw]

+1

[chessai]

+1

[mixphix]

+1

[Bodigrim]

With 4 votes in favour out of 6 possible, the migration plan is approved. Thanks all.

[ulysses4ever]

Presumably, there needs to be a GHC ticket tracking at least the first step of this plan?

[Bodigrim]

@ulysses4ever feel free to raise one.

[ulysses4ever]

https://gitlab.haskell.org/ghc/ghc/-/issues/21791

[mpickering]

I think there is a step missing from the plan, namely, communicating about the breaking change to the community. Does the CLC have a blog or another platform which can be used to communicate about things like this?

[Bodigrim]

@mpickering I'll post on Reddit once #76 is merged.

[chshersh]

I'm trying to summarise the state of this proposal as part of my volunteering effort to track the progress of all approved CLC proposals.

This particular issue is about clarifying the situation around the Data.List monomorphism. However, I'm tracking the progress of the Data.List monomorphisation itself.

Field	Value
Author	@mpickering
Status	not implemented
base version	Unknown
Merge Request (MR)	none
Blocked by	GHC Issue #21791, Retrie Issue #26
CHANGELOG entry	missing
Migration guide	https://github.com/haskell/core-libraries-committee/blob/main/guides/monomorphic-data-list.md

Please, let me know if you find any mistakes 🙂

---

@mpickering could you share a status update on the implementation and what are next steps? Also, please do let CLC know if you need any help, so we can coordinate and prioritise approved proposals accordingly!