Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Draft: Change API to emit multiple ComponentOptions if available #304

Closed
wants to merge 4 commits into from

Conversation

fendor
Copy link
Collaborator

@fendor fendor commented Aug 23, 2021

Introduce API changes necessary for #301

This PR can be merged before #301, and released, then HLS can be updated for the new API.

@fendor fendor requested a review from jneira August 23, 2021 09:10
@fendor
Copy link
Collaborator Author

fendor commented Aug 23, 2021

cc @OliverMadine

Copy link
Member

@jneira jneira left a comment

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

horror vacui 👍

@fendor
Copy link
Collaborator Author

fendor commented Sep 14, 2021

What are the semantics of the provided NonEmpty? Do we require that the component the file path is part of has been loaded and is the first element of the NonEmpty? How can we communicate that we can not load a component because one of our dependencies has failed to build?
I propose, mainly for the sake of argument, a new data type instead of NonEmpty:

data LoadResult = 
  { loadComponent :: Maybe ComponentOptions,
  , componentDependencies :: Maybe (NonEmpty ComponentOptions)
  }

intended semantics: it is possible to extract component dependencies and load these immediately, but we were unable to load the component the file target is part of.
No guarantee for the order of dependencies. They may not exist, but if they do exist, there must exist at least. This type is isomorphic to just [ComponentOptions], but maybe expresses the intent better.

Opinions?

@jneira
Copy link
Member

jneira commented Sep 15, 2021

Opinions?

i like the precision of the new data type and it can be extended if we find out other nuances

@fendor fendor force-pushed the feature/non-empty branch 4 times, most recently from 73b4f97 to 556d09d Compare October 13, 2021 08:51
Comment on lines 65 to 87
type LoadResult = LoadResult' ComponentOptions

data LoadResult' a = LoadResult
{ loadResultComponent :: Maybe a
-- ^ Component options for the FilePath that produced this 'LoadResult'.
-- See 'CradleAction.runCradle' for information on how to produce a 'LoadResult'.
--
-- This field can be 'Nothing' to indicate that loading partially failed.
, loadResultDependencies :: [a]
-- ^ Direct or indirect dependencies from the component from above.
-- Indirect means that it is not required that 'ComponentOptions' in this list
-- are required dependencies of 'loadResultComponent'. It is specifically allowed
-- to list 'ComponentOptions' that have no relation with 'loadResultComponent'.
--
-- Example:
--
-- Assume we load an executable component, then its options must be located
-- in 'loadResultComponent', additionally it is possible to list other
-- executable component's options in 'loadResultDependencies'.
} deriving (Eq, Ord, Show, Functor, Foldable, Traversable)
Copy link
Collaborator Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

I honestly don't really like this naming. Signatures be like: CradleLoadResult LoadResult. Seems really redundant

Comment on lines +98 to +99
pattern Main :: a -> LoadResult' a
pattern Main opts <- (loadResultComponent -> Just opts)
Copy link
Collaborator Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

We can have more of these such as:

Deps :: [a] -> LoadResult' a
MainAndDeps :: a -> [a] -> LoadResult' a

for typesafe pattern matching.

Copy link
Collaborator Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Well, if we need patterns, we might just introduce a more elaborated datatype

@jneira
Copy link
Member

jneira commented Dec 15, 2021

@fendor hi! any chance to get this merged to make progress in enable rename plugin in hls?

@fendor fendor changed the title Change API to emit NonEmpty ComponentOptions Draft: Change API to emit NonEmpty ComponentOptions Dec 15, 2021
@fendor
Copy link
Collaborator Author

fendor commented Dec 15, 2021

It is right now still kind of a WIP. Do you have opinions on naming?

Comment on lines +77 to +78
-- Indirect means that it is not required that 'ComponentOptions' in this list
-- are required dependencies of 'loadResultComponent'. It is specifically allowed
Copy link
Collaborator Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

The sentence makes no sense, what I mean is, that items here are either local dependencies in some form, or completely independent but can be loaded, too.
It might still be important to have some kind of order on them.


-- | Record for expressing successful loading.
-- Can express partial success.
data LoadResult' a = LoadResult
Copy link
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

What about somethin like

data ComponentInfo = ComponentInfo
  { componentOptions :: Maybe a
   componentDependencies: [a]
  }

It would be generic enough to allow add more component information afterwards

Copy link
Collaborator Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Hm, maybe we can drop the prefix somehow to be less "Component"-y? However, since the record field prefix will probably still be required, probably pointless.

Copy link
Member

@jneira jneira Dec 15, 2021

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

yeah, Info sounds good too, maybe too generic but whatever

@fendor fendor changed the title Draft: Change API to emit NonEmpty ComponentOptions Draft: Change API to emit multiple ComponentOptions if available May 3, 2022
@michaelpj
Copy link
Contributor

What's the status of this?

@fendor
Copy link
Collaborator Author

fendor commented Aug 16, 2022

It is on hold because it is semi-blocked on haskell/cabal#7500 to get reliably the build-info location.

Technically, it is not blocked, the API could be changed without cabal support, but then we have a slightly harder time to test the implementation. Also, if there is no cabal or stack support for it, I see barely an incentive to implement it, currently.

@fendor
Copy link
Collaborator Author

fendor commented Nov 6, 2023

Superseded by #409

@fendor fendor closed this Nov 6, 2023
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

Successfully merging this pull request may close these issues.

None yet

3 participants