- The sum type itself would be the union of all constructor types.
- Every constructor type would be a subtype of any union type that contains it. Type inference could then infer the smallest union that would make the fields accessed or constructors mentioned safe. That is, for the
unJustfunction above, it would inferMaybe{Just} a -> a, and this would preclude using the function on any value that can't be proven at compile time to be aJust
I was looking into making a Frege port of Apache Beam. The implementation "serializes" functions and copies them to remote machines where they are then. They define the following function interface: https://beam.apache.org/releases/javadoc/2.13.0/org/apache/beam/sdk/transforms/SerializableBiFunction.html. Any opposition to rewriting Frege's Func class to follow a similar pattern?
I.e be serializable?
However, perhaps you can write a conversion function something like
SerializableBiFunction toSerializable(frege...Func<...> fun) or its equivalent in Frege.
@Ingo60 Sorry for delayed reply. Regarding records, I think what you are describing sounds a bit like dependent types. For example, in Idris Vector 0 Int and Vector 1 Int are both types of vectors (lists that have their length as part of their type) that hold Ints. They are different types belonging to the same family. Function head for vectors has signature Vect (S len) a -> a, meaning that the input vector cannot be empty.
@Ingo60 In my opinion, Frege probably does not need to go as far as dependent types.
@Ingo60 But I think that what you are discussing also is similar to rows, with structural subtyping. So, if type A has all the fields that B has, then B is a subtype. This is what Purescript's and Elm's extensible records are based on, so I was thinking that maybe it could be interesting to try some sort of extensibility like that in Frege.
@Frege However, I don't like that records in Purescript and Elm are typed only structurally. If I had to choose between nominally typed records like in Frege and structurally typed records like in Purescript or Elm, I would choose Frege's records. I suggested an idea how one could try to implement records with a mix of nominal and structural typing in Purescript.
https://discourse.purescript.org/t/allow-defining-named-records/1052/34
https://discourse.purescript.org/t/allow-defining-named-records/1052/34
@Ingo60 When it comes to packages, I think it would be nice if we could come up with guidelines how to port Haskell code (where do we put the code and licenses)
@0xde_gitlab I haven't tried 12 and above yet, but they should work fine. Most of the new features are meant to make human programmers happier, like, for example, type inference for locals. Such things are, of course, useless for us. The compiler doesn't mind writing the types out. So this would only break backwards compatibility without gaining anything. What could be interesting is the switch-expression, perhaps.
I'm still waiting for groundbreaking changes like proper tail calls, value types and primitives as type arguments. This would justify special support.
I'm still waiting for groundbreaking changes like proper tail calls, value types and primitives as type arguments. This would justify special support.
I'm trying to import frege and frege-interpreter in a Gradle project, but for some reason it's having trouble with the most recent version on sonatype. It's also running into a NoClassDefFoundError for
frege/runtime/Lazy whenever I try to run the scripting engine. The environment is Java 8, with frege version 3.23.288-gaa3af0c and frege-interpreter version 1.2.1-SNAPSHOT. Is there anything I should know about or anywhere better to get a more up-to-date frege version?
(to note, 3.23.288-gaa3af0c is the highest version of frege I've been able to import, and sonatype just went down so I can't try higher versions again right now)
I've installed an updated version of the Web Repl under http://86.119.37.112:9999 . I assume there will be issues that you can report at https://github.com/Frege/try-frege/issues . It currently runs under Java 8 (openjdk version "1.8.0_152") with frege3.24.405 (latest stable)
I'd like the let try.frege-lang.org point to the new repl. Is anyone here the domain owner?
@Dierk did you find out who owns the domain?
Clojure now has official CLI tooling (as an alternative to Leiningen) so I figured I'd update the Leiningen template to work with
clj-new (the CLI equivalent). Both that and the frege-lein-plugin are based on 3.24-7.100 which is available on Sonatype (although browsing oss.sonatype.org I can't actually see anything except 3.23... which makes me wonder whether I published later versions on Clojars?)
(no, apparently I published a few 3.23 snapshots there)
I guess I could publish 3.24.405 to Clojars -- unless @Dierk has an objection to that?
@seancorfield as for the maven repos: it is always a hassle to get things into maven central, sonartype, etc. Since Frege itself has no maven dependencies, we typically just fetch from the github release page. (btw: I guess one can expose github releases directly as mvn dependencies. There was a service called jitpack to facilitate this but maybe github can do this even directly)
This suggests a way to read from a GitHub repo via Maven so I might try that from Clojure's build tooling and see how far I get: https://dzone.com/articles/using-github-as-maven-repository
@Dierk It's looking like you can host Maven-style packages on GitHub via the Actions workflow (there's a maven.pkg.github.com domain) so I think that might be an interesting way to have builds of Frege happen automatically and have the artifacts hosted via GitHub Packages directly on the main repo (this is all new since I last looked at how to publish JAR files...)
With the deprecation of mutable has made my native definitions now look very clunky.
I went from:
data View = native mutable android.view.View where"
native findViewById :: View -> Int -> IO ViewTo:
data View = native android.view.View where"
native findViewById :: MutableIO View -> Int -> IO (MutableIO View)Is there a way to make this look better syntactically?
Hello! I have a small Haskell project here https://github.com/input-output-hk/cardano-addresses, I'd like to cross compile it to a JVM compatible jar. Does that make any sense? Is this something Frege could or should do?
@mcsherrylabs cool project! What you can usually do in such cases is to just take your haskell code and run it through the Frege compiler with minimal changes. In your case though, you use some language extensions like MultiParamTypeClasses and TypeFamilies that Frege does not have, yet. That means that a Frege version of your library requires a bit more work than just renaming files -.)
1 reply