search

typelead / eta

The Eta Programming Language, a dialect of Haskell on the JVM
https://eta-lang.org
BSD 3-Clause "New" or "Revised" License
2.61k stars 145 forks source link

Refactor/Rename existing code base #715

Open NickSeagull opened 6 years ago

NickSeagull commented 6 years ago

Refactor progress

more modules can be added...

Description

Working through the Parser module, functions like amsu, sLL, mj, etc... make very hard to start working on stuff.

It would be nice if they had meaningful names, aswell as all the existing legacy GHC code, like for example types like RdrName.

Maybe I can refactor some code I have touched? This issue could serve as a tracker

rahulmutt commented 6 years ago

Completely agree with this. Before you carry out a refactoring of a core type or function, make sure you list out the name changes here so we can discuss.

jneira commented 6 years ago

I wonder if it would make more difficult a hypothetical change to ghc 8. As haskell packages will increase the use of ghc >= 8 features we'll reach a situation that patches (or changes upstream) would be near impossible to accomplish

NickSeagull commented 6 years ago

Agree with @jneira , although I'm not sure if that would be harder than refactoring...

NickSeagull commented 6 years ago

Thinking on this again, maybe this is the point when we start departing from GHC? Is our aim to be GHCJVM or a different language that is compatible with most Haskell packages?

There is effort that maybe could be invested in generating a better ecosystem rather than keeping the pace of GHC

I don't know, I'm just giving all the ideas that come to my mind :smile:

jneira commented 6 years ago

Well, i would quote this relevant faq question:

How is Eta different from Frege? Eta is strategically designed so that Hackage packages can be compiled with little modification, allowing reuse of existing infrastructure. This is done by supporting many of the GHC-specific extensions that are used heavily in popular libraries. On the other hand, Frege, while it supports basic Haskell, lacks many of the key extensions required to compile Hackage, and hence cannot reuse the existing infrastructure. Moreover, because Eta uses a modified version of GHC’s frontend, we have access to all the powerful and well-tuned optimizations that Frege does not.

Also this early issue about frege and eta: https://github.com/typelead/eta/issues/3

I think eta fills a space betwen haskell and the jvm (with all it existing langs like scala, clojure, frege..) in a delicate balance. In my opinion haskell continue being the state of the art for lazy functional languages and i would like eta to be as close to haskell ecosystem philosophy (maybe not to the actual implementation) as possible.

NickSeagull commented 6 years ago

Yep, definitely @jneira , I didn't want to imply that we should depart in philosophy. I'm with you about the Haskell philosophy.

I was talking about implementing GHC8.

I understand the differences between Frege and Eta :smile:

rahulmutt commented 6 years ago

@jneira My gut says the scenario where GHC 8 makes a lot of patches impossible probably won't happen that soon. If/when such a situation happens, it means whatever features GHC 8 has are extremely practical and useful and it is imperative that we adopt them too.

Now, as you said, merging patches from GHC 8 upstream will become difficult if we do a refactoring. So does this mean we keep the codebase intimidating for newbies to contribute patches, especially in places like the Lexer/Parser? That's something we should discuss.

rahulmutt commented 6 years ago

Thinking on this again, maybe this is the point when we start departing from GHC? Is our aim to be GHCJVM or a different language that is compatible with most Haskell packages?

I would say we want to be closer to the latter. The whole point of Eta since inception was to package Haskell in a way that everyone can use without sacrificing on the nice reasoning properties that the language gives you.

Moreover, we wanted to be able to take advantage of both the JVM & Haskell ecosystems and we would love to keep that going as much as possible. Of course, there are going to be some Haskell packages that we'll probably never be able to use since they'll use the most recent features and I think that's OK (singletons is a good example, though there is a way to encode it to work well with GHC 7.10). I'm sure that people who really want to use such packages will find a way to encode it differently using just the features Eta has, just like how Scala devs have been encoding Haskell constructs into Scala.

NickSeagull commented 6 years ago

Awesome! Sounds great to hear that I'm on the same page as you :smile: