@pkapustin Well. I don't see the problem with package names? Please explain.
@pkapustin How about
unJust (Just x) = x
OTOH, I find something like:
somefun (Foo _ _ _ _ _ _ _ _ _ x _ _ _) = ....
hard to read and still harder to maintain. WIth record types, you can simply add a field, or even drop an existing one, and it will only flag errors at the places where you really use them.
@Ingo60 The definition of Maybe type is perfectly fine, the problem is with the unJust function.
@Ingo60 However, if we define a "sum-record", this is already a problem, because the accessor functions are partial.
@Ingo60 But if x turns out not to have "name" field, it's a problem, right?
So, it seems that what we want is extensible records. In PureScript or Elm we can define this function in terms of a record that has "name" field. In Haskell we have HasField type class that allows to express this, and currently discussed RecordDotSyntax proposal is based on this.
So, it seems that what we want is extensible records. In PureScript or Elm we can define this function in terms of a record that has "name" field. In Haskell we have HasField type class that allows to express this, and currently discussed RecordDotSyntax proposal is based on this.
I think the problem of "sum-records" is not partial functions themselves but how easy to write one. For example, we can always write a partial function like this:
foo (Just 42) = error "I hate 42!!!!"
foo (Just n) = n
foo Nothing = 0but we don't do this unless really need to. sum-records are indeed useful for prototyping but Fregec is not in the "prototyping" stage, is it?
I think it's nice to have partial accessors get warned by the compiler, preferably enabled by a specific flag like -Wincomplete-record-updates in GHC (which is, for some reason, not enabled by -Wall).
@Ingo60 About generics parameter, I'm relieved to hear your answer. I'll open another PR for
TauT in a few days.
@Ingo60 Regarding packages, when I wanted to add some functions for Either, that were in Haskell base, I just put them in the standard library in the same module (Data.Either). But some of the functions are in either package. Where should I put the functions that come from different packages? There is not yet a package system for Frege, right? And also, where should the license file from that package go?
@matil019 @pkapustin Rgd. records again. I'm not a friend of the HasField thing. First, it requires multi param type classes. I'm not sure whether they are eliminated at runtime, but if not, it'll be a nightmare. In general, extensible records are a heavyweight language feature in and of themselves, and the runtime costs would be huge - just for accessing a field of a tuple. As such I think it doesn't fit into Frege very well.
However, I still have the idea of a limited subtyping in my mind, that would in principle do what @matil019 did by hand.
However, I still have the idea of a limited subtyping in my mind, that would in principle do what @matil019 did by hand.
- every constructor of a sum type would be a separate type.
- 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?