Repository navigation
Feedback on qualified names #152
Description
Activity
Why qualified imports
I guess I never knew they were a problem cause all the tools I use assume they are e.g.
import pandas as pdandimport polars as pl,import qualified Data.Text as Tand so forth for Haskell maps, sets and other things that are expected to clash a lot with Prelude. But now that you point it out I see why they are annoying. I'm curious how you use packages like containers/text without all the namespace clashes?Why the functions namespace
The expression stuff came a little later and at the time I was writing a lot of pyspark at work. PySpark puts all the columns looking functions in a functions namespace. Aside from that a lot of the initial functions clashed with other functions in the uber namespace.
E.g.
D.mean col df -- get mean of a column as a value. D.derive "m" (F.mean col) df -- mean expression
Monad/applicative/integral instances
toIntegeris undefined for expressions unless you have an accompanying dataframe. So aretoRationalandtoEnumwhich integral requires. I guess we could make those specific functions throw exceptions but fully define all the other functions in the class so they don't use them but then you get surprising behaviour from time to time when you assumetoIntegerworks.Monad instances require the type to be unconstrained. We at least need a show constraint so probably not possible. Also some laws would just not hold for expressions. It gets messy. But this is something I've fought with GHC about for months. Open to solutions.
I'm curious how you use packages like containers/text without all the namespace clashes?
I rarely need everything from everything in one file, so I usually manage to import the main one unqualified and hide/expose/qualify the extra one. But I'll reuse the same name for the same package if possible as in
import Text.Megaparsec qualified as P import Text.Megaparsec.Char qualified as P import Text.Megaparsec.Char.Lexer qualified as P hiding (space)I don't like Haskell qualified syntax because it makes things look like constructor or type. Python
panda.read_csvis consistent with OO python syntax.F.collooks likeF_col.Aside from that a lot of the initial functions clashed with other functions in the uber namespace.
Well, it is an egg and chicken situation. If you qualify, you can have duplicate and once you have duplicates you'll need to qualify :-)
toIntegeris undefined for expressions unless you have an accompanying dataframeFair enough, I didn't think of
toInteger. I'm not sure why it is even need to integer division. It is probably due to the original Num hierarchy. It is just odd that you can use/and*from the Prelude, but notmodanddiv...
I understand this package has been intended to be imported qualified. But some people (like me) don't like qualified import neither they do like to be forced to do so (when there is no real need to do so)
Moreover, the tutorial import
DataFrameasDandDataFrame.FunctionsasF? Why using to different letters ? (Haskell syntax allows to import different modules with the same qualifier)Is it for clarity or because using the same name for both will result in name conflict ?
I find it rather confusing (and unnecessary) to have remember what is in
For inD.Could not
DataFramenot export everything ?I probably could try importing
DataFrame.Functionswithout qualifying it , because things likenameandcolmakes perfect sense on their own, but then things likedivandliftconflicts with the prelude.Could not
Expr abe made an instance ofIntegraland/or Applicative/Monad ?