profile
viewpoint
Edward Kmett ekmett Groq Farmington Hills, MI http://comonad.com I write a lot of Haskell.

ekmett/ad 322

Automatic Differentiation

ekmett/bound 109

Combinators for manipulating locally-nameless generalized de Bruijn terms

ekmett/algebra 93

constructive abstract algebra

ekmett/cadenza 62

every day i'm truffling

ekmett/bifunctors 50

Haskell 98 bifunctors, bifoldables and bitraversables

ekmett/approximate 41

Approximate discrete values and numbers

ekmett/adjunctions 37

Simple adjunctions

ekmett/categories 35

categories from category-extras

ekmett/abelian 32

Commutative Applicatives and Semigroups

issue commentenso-org/enso

Dataflow Warnings

Another point in the design space that might be worth considering other than a tainting narrative would be for there to be a notion of 'warning scopes'. Enter into a scope, and now any warnings invoked get added to the set for the current scope. Exit the scope and you get your hand on that Set directly in the language. Current scope is always accessible via this stack discipline. Then something like a table join that needs to compute things would create the warning scope, do the operations, with no tainting causing us onto a slow Object-driven path for every single tainted value, and then you can exit the scope and bolt the information into the table that is the result as an extra field or some such, used to display the warnings to the user in the IDE in the visualization for the table itself, maybe with a set of colored warnings and the like. We get something like localization, in that the taint is tracked, but it is more manual but you retain the fast execution path.

Yet another option is to go further and mix these stories, but just tainting the object that is the result of the scope, so you'd locally stay on the fast path with untainted values in a tainted scope, and then exiting the scope taints the computed result.

kustosz

comment created time in 3 days

issue commentenso-org/enso

Dataflow Warnings

FWIW- it is worth mentioning that the warning behavior I offered is orthogonal to this feature. Rather than tainting values with the set of warnings that fed into their construction (and forcing things onto slow paths) they let us back onto a faster path, but lose the correlation between values and the warnings the users see. Both are pretty cool features for a language to offer, though.

kustosz

comment created time in 3 days

issue commentenso-org/enso

Dataflow Warnings

I think there's a possibility for doing something clever here.

Consider a warn_once node that we could place in the truffle syntax tree that is responsible for emitting a warning, and then rewriting itself to its second argument. Then the warning behavior gets a warning to the user but has zero runtime cost after it warms up. e.g. comparing two floating point numbers for equality could trip this. There's some nuance to be had here as you really want the rewrite to be once per source occurence of this node, not however many places it gets copied through the tree, so you'd really be asking for something a little more complicated to parse into, but I think this is the right general space of ideas.

Another case that could be quite useful is a more robust warn_with_count that

a.) prints the warning b.) allocates a counter for the use site (or more likely uses a global static counter for this error, possibly by source location so we don't need to deal with multiple uses while under function arguments) c) rewrites itself into a function that bumps that counter d.) Either installs an atexit(3) style hook to print the final count on the command line, or provides an ID or source location with the warning for use in the IDE, that can be queried to get a running count as the program runs.

Feel free to bikeshed the names, and I'm not sure I've got the right idea for how to expose them in-language, but both would make effective use of Truffle on the backend while giving good warnings.

Zero-cost warnings could be a heck of a selling point.

kustosz

comment created time in 4 days

pull request commentenso-org/enso

Implement conversions (#180312665)

Ugh. It is even worse than I feared.

ekmett

comment created time in 4 days

pull request commentenso-org/enso

Implement conversions (#180312665)

The direction you gave in your Maybe example should work (insofar as it parses) today. The other direction converting from a Maybe, has to be written case by case off the actual constructors for Some and Nothing, but conversions into something that is morally a sum type should just work.

@wdanilo and @kustosz want to make "proper" sum types, but that starts to expose all sorts of infelicities in the type system (or lack thereof as the case may be). With those in hand, we'd be able to define the other direction where you have

Foo.from (that : Maybe) = ...

Doing that today will fail because the maybe Atom is never constructed. You should be able to use

Foo.from (that : Some) = ...
Foo.from (that : Nothing) = ... 

as a workaround for the lack of first class sum types today.

Having conversions adds a lot of pressure to make those things real.

ekmett

comment created time in 4 days

Pull request review commentenso-org/enso

Implement conversions (#180312665)

   Additionally, made the `library/preinstall` endpoint able to install any   transitive dependencies of the library. +## Interpreter/Runtime++- Added support for overloaded conversions. This allows the `from` method to+  be implemented with several overloads. ([#3227](https://github.com/enso-org/enso/pull/3227))+

Happy to put this in the right place. I was just reacting to a red checkmark in the build process.

ekmett

comment created time in 5 days

PullRequestReviewEvent

push eventenso-org/enso

Edward Kmett

commit sha 9f6d9f86ff1226946896bee9f0f76e06022219b4

update RELEASES.md

view details

push time in 8 days

PR opened enso-org/enso

Implement conversions (#180312665)

Pull Request Description

Data analysts should be provided with a unified way to convert between data structures (from method)

Important Notes

This was slightly harder than expected.

Implemented a notion of an UnresolvedConversion.

This allows the user to write

type Foo foo
type Bar bar
type Baz baz

Foo.from (that:Bar) = Foo that.bar

Foo.from (that:Baz) = Foo that.baz

main = (Foo.from (Bar 10)).foo + (Foo.from (Baz 20)).foo

In addition to handling atoms and atom constructors properly we also handle Text (both foreign and domestic), functions, arrays and all the other built-in types of the language.

The format of a conversion is required to be

<Type>.from (that:<Type>) <other arguments> = ...

the name of the first parameter must be that or _, and all other arguments must be defaulted.

Overloading is used to resolve the dispatch of the from method.

Overloads resolve from the most specific type of that to the least.

An incidental issues had to be fixed along the way:

All type level errors were being swallowed by the compiler. Notably, operator methods could not be typed, but the error for this was being swallowed silently by the compiler.

UnresolvedConversions are exposed to users like any other UnresolvedSymbols in the Meta API. The user should see no difference (other than the dynamic overloading behavior).

Extension conversions can be defined in imported modules just like extension methods.

Documentation should be supplied as we update the standard library to use this feature.

Checklist

Please include the following checklist in your PR:

  • [ ] The documentation has been updated if necessary.
  • [X] All code conforms to the Scala, Java, and Rust style guides.
  • [X] All documentation and configuration conforms to the markdown and YAML style guides.
  • [X] All code has been tested where possible.
+2220 -431

0 comment

48 changed files

pr created time in 8 days

push eventenso-org/enso

Edward Kmett

commit sha 05c67cf8d08bab7091d39b9ee7051a2bd92bb38a

Implement conversions start wip branch for conversion methods for collaborating with marcin add conversions to MethodDispatchLibrary (wip) start MethodDispatchLibrary implementations conversions for atoms and functions Implement a bunch of missing conversion lookups final bug fixes for merged methoddispatchlibrary implementations UnresolvedConversion.resolveFor progress on invokeConversion start extracting constructors (still not working) fix a bug add some initial conversion tests fix a bug in qualified name resolution, test conversions accross modules implement error reporting, discover a ton of ignored errors... start fixing errors that we exposed in the standard library fix remaining standard lib type errors not caused by the inability to parse type signatures for operators TODO: fix type signatures for operators. all of them are broken fix type signature parsing for operators test cases for meta & polyglot play nice with polyglot start pretending unresolved conversions are unresolved symbols treat UnresolvedConversons as UnresolvedSymbols in enso user land

view details

push time in 8 days

push eventenso-org/enso

Edward Kmett

commit sha 4b8ea1d6007b962f227c82da94568f2190d88e66

treat UnresolvedConversons as UnresolvedSymbols in enso user land

view details

push time in 8 days

push eventenso-org/enso

Edward Kmett

commit sha 1821f21232d5314469566c5500030c35f5e8d99f

start pretending unresolved conversions are unresolved symbols

view details

push time in 8 days

push eventenso-org/enso

Edward Kmett

commit sha 6e7c669df825d94fa80514738c7b8ffb72e93fb1

play nice with polyglot

view details

push time in 8 days

push eventenso-org/enso

Marcin Kostrzewa

commit sha d48c8d59f44d7d625730f86cb3731c0a6e1526b3

Implement a bunch of missing conversion lookups

view details

Edward Kmett

commit sha c1f71ebb432ad8b4e9d2eefc9a45dfe8581b8986

final bug fixes for merged methoddispatchlibrary implementations

view details

Edward Kmett

commit sha 1e79915ed173926ee5387d8f3a287253a878b03b

UnresolvedConversion.resolveFor

view details

Edward Kmett

commit sha ec2324f1e4b3b5a483252bf8d99fce95d869be69

progress on invokeConversion

view details

Edward Kmett

commit sha 084453488ac14b1ff6c129ecec676011e9747976

start extracting constructors (still not working)

view details

Marcin Kostrzewa

commit sha 41530466ccb4bb6eb0e27e01c15ac3208918975d

fix a bug

view details

Edward Kmett

commit sha 317c0cfe1477e622ba12ddd417e0729ce9113cc0

add some initial conversion tests

view details

Marcin Kostrzewa

commit sha 99f9c3b8240d1adb1a8da3afe7185da6bdb59ced

fix a bug in qualified name resolution, test conversions accross modules

view details

Marcin Kostrzewa

commit sha 106ec172f859643e6fe9aaf22a6f356dfdb51ac0

implement error reporting, discover a ton of ignored errors...

view details

Edward Kmett

commit sha b6193e7f07ba1aa5549617ad57f86e34b3028edc

start fixing errors that we exposed in the standard library

view details

Edward Kmett

commit sha 056dc1e73a5ae5f1cc14fe1e4ad102cd445f074a

fix remaining standard lib type errors not caused by the inability to parse type signatures for operators TODO: fix type signatures for operators. all of them are broken

view details

push time in 8 days

push eventenso-org/enso

Edward Kmett

commit sha a99d4ef5535b8d47405845b3a5b9c1a5dd4245d9

fix remaining standard lib type errors not caused by the inability to parse type signatures for operators TODO: fix type signatures for operators. all of them are broken

view details

push time in 8 days

push eventenso-org/enso

Edward Kmett

commit sha 0bf95dabef79e51a43e243ffe437befd2ccee93b

start fixing errors that we exposed in the standard library

view details

push time in 8 days

push eventenso-org/enso

Edward Kmett

commit sha 9a5599d619cb469e089b83490aab52f87f21c0fe

add some initial conversion tests

view details

push time in 9 days

push eventenso-org/enso

Edward Kmett

commit sha 258129ef38e43ae50b7d52109a3853de9a9f7a14

start extracting constructors (still not working)

view details

push time in 10 days

push eventenso-org/enso

Edward Kmett

commit sha 7fb13f6217a791bdf184e6b6f0269b3aa7680726

progress on invokeConversion

view details

push time in 10 days

push eventenso-org/enso

Edward Kmett

commit sha 23cd40f67b910bc7c5df81a2f4784b531111d44e

UnresolvedConversion.resolveFor

view details

push time in 10 days

issue commenthaskell/core-libraries-committee

Proposal: `showLitChar` (and `show @Char`) shouldn't escape readable Unicode characters

The main difference with the Show/Read for a unicode-named type mentioned above is it is often have a lot more control over the data types I show than the contents of the strings users put in them.

ksqsf

comment created time in 10 days

issue commenthaskell/core-libraries-committee

Proposal: `showLitChar` (and `show @Char`) shouldn't escape readable Unicode characters

So we're proposing to break use of Show/Read and ghci for non-utf8 terminal / codepages? (along with all serialization tests that wrote out data beforehand and are checking golden datasets, and serialization of data with Show from code running on new GHC versions to old?)

If we wanted to make this configurable, there's not really a good way to smuggle knowledge of the surrounding host environment into Show without changing a lot of code, e.g. by adding an argument to showsPrec, diverging further from the standard, or doing something awful like plumbing around a big implicit parameter indicating if we expect to be serializing with unicode, or passing flags to the executable and hoping you don't need to use things with different semantics in different parts of your code. But then if you are going to go that far with settings, adding all sorts of options for indentation and spacing and whether it should use record syntax or not seems to be in order, whereupon it has become a full fledged pretty printing library.

ksqsf

comment created time in 10 days

push eventenso-org/enso

Edward Kmett

commit sha 80b8324960bcfa04a99a358ea0b9835227e3db8b

final bug fixes for merged methoddispatchlibrary implementations

view details

push time in 11 days

push eventenso-org/enso

Edward Kmett

commit sha 8cfa7b2da6cc8f2063fbec9ad6bf53b02f70317c

conversions for atoms and functions

view details

Edward Kmett

commit sha 4e4e1eb4ffaefd2ae2afa33e0078dd34e6e3d1e0

Merge branch 'compiler/wip/eak/conversions' of github.com:enso-org/enso into compiler/wip/eak/conversions

view details

push time in 11 days

push eventenso-org/enso

Edward Kmett

commit sha 8ce97fc7887ed2fb1bea4dfc34adf71ef9b18fb6

start MethodDispatchLibrary implementations

view details

push time in 11 days

startedschmelczerandras/sdf-2d

started time in 12 days

push eventenso-org/enso

Edward Kmett

commit sha 9c169229c6574df8679c81f992d3e5b0c72d8044

add conversions to MethodDispatchLibrary (wip)

view details

push time in 15 days

create barnchenso-org/enso

branch : compiler/wip/eak/conversions

created branch time in 15 days

issue commenthaskell/core-libraries-committee

Proposal: Remove method (/=) from class Eq

At one point I was supportive of the idea of offering lawless and lawful versions of various classes, at least in my own work, but I've since recanted by and large, at least within the confines of Haskell.

The two main reasons I generally think adopting LawlessFoo and Foo splits is a bad idea:

Consider something like liftA3:

liftA3 f m n o = f <$> m <> n <> o liftA3 f m n o = liftA2 f m n <> o liftA3 f m n o = liftA2 id (liftA2 f m n) o liftA3 f m n o = pure f <> m <> n <> o liftA3 f m n o = ((a,b,c) -> f a b c) <$> ((,,) <$> m <> n <> o) ...

If I don't have any laws I have no reason why I get to know these should compute the same answer! Therefore I'm forced to basically supply all of them to the user and give them all names. This leads to a combinatorial explosion in the number of names for operations that are all uselessly equivalent-except-for-niggling-laws, exposing internal implementation details we normally use the laws to omit transmitting to the user. Users now need to know every single detail of every single function they call in order to function in the ecosystem.

In addition to implementation explosion, type inference will happily supply the LawlessFoo constraint, even if canonicity of the implementation is lost, or if the correctness of the operation really does requires all those laws you dropped on the floor. You can get them back by duplicating all the operations, by making lawful (+) delegate to the lawless (+~) or something, but this method doesn't scale as you add finer and finer grained structure to your class hierarchy to capture the individual weakenings of more and more laws.

-Edward

On Mon, Nov 22, 2021 at 8:18 PM David Feuer ***@***.***> wrote:

@augustss https://github.com/augustss, suppose I'm reading some code and I come across an expression 3 * 1_000_000 * 7. Does that mean the same thing as 21 * 10^6? Maybe. Maybe not. A wild Num instance could define fromInteger and (*) as utterly arbitrary functions. Another example: if I see fmap f (fmap g x), can I change that to fmap (f . g) x? Or do I have to first perform a careful investigation of whether fmap for this type deletes some of the line breaks? My ability to understand code locally goes out the window.

— You are receiving this because you were mentioned. Reply to this email directly, view it on GitHub https://github.com/haskell/core-libraries-committee/issues/3#issuecomment-976086122, or unsubscribe https://github.com/notifications/unsubscribe-auth/AACKMEOPKXNCB42XIBRS5WTUNLTXBANCNFSM5GZ2YRQQ . Triage notifications on the go with GitHub Mobile for iOS https://apps.apple.com/app/apple-store/id1477376905?ct=notification-email&mt=8&pt=524675 or Android https://play.google.com/store/apps/details?id=com.github.android&referrer=utm_campaign%3Dnotification-email%26utm_medium%3Demail%26utm_source%3Dgithub.

nomeata

comment created time in 2 months

issue commenthaskell/core-libraries-committee

Proposal: Rename `Foldable1` and `Bifoldable1` and then move them into base

I'm happy to go with whatever the CLC wants to do here, up to and including handing the package over to the CLC.

gwils

comment created time in 3 months

more