Where communities thrive


  • Join over 1.5M+ people
  • Join over 100K+ communities
  • Free without limits
  • Create your own community
People
Repo info
Activity
  • Oct 07 08:54
    Dierk commented #392
  • Oct 07 08:43
    szabi commented #392
  • Aug 02 15:14
    Dierk commented #356
  • Aug 02 13:45
    Dierk commented #356
  • Jul 30 21:27
    Dierk commented #356
  • Jul 30 08:46
    gilinykh commented #356
  • Jul 01 21:22

    Dierk on master

    update README.adoc (compare)

  • Jul 01 20:01

    Dierk on master

    added Frege_Gradle_Tasks.png (compare)

  • Jun 29 15:09

    Dierk on master

    update images for the frege wik… (compare)

  • Jun 28 13:47

    Dierk on master

    compiles and runs with frege-3.… upgrading to gradle 6.5 add images for the frege wiki p… (compare)

  • Jun 28 12:18

    Dierk on master

    remove the duplicated line abou… small documentation clarificati… updating the comment around App… (compare)

  • Jun 24 20:58
    Dierk edited #392
  • Jun 24 20:50
    Dierk edited #392
  • Jun 24 20:41
    Dierk edited #392
  • Jun 24 20:39
    Dierk edited #392
  • Jun 24 20:39
    Dierk opened #392
  • Jun 24 08:28
    Ingo60 commented #391
  • Jun 22 14:49
    Dierk commented #391
  • Jun 19 17:04
    Dierk labeled #391
  • Jun 19 17:04
    Dierk labeled #391
Ingo Wechsung
@Ingo60
@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.
Paul Kapustin
@pkapustin
@Ingo60 Regarding partial functions, the example with unJust will produce a compiler warning due to non-exhaustive pattern matching, so it is much easier to detect the problem. However, this is not the case with sum-records.
@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.
Ingo Wechsung
@Ingo60

Only those that don't appear in all constructors. As said before, it just makes it (perhaps too) convenient, since

x.name

is simply sntactic sugar for something like

\h -> case h of
    A _ name _ -> name
   B  name -> name
Paul Kapustin
@pkapustin
@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.
Paul Kapustin
@pkapustin
@Ingo60 I am not sure what the best solution is, but I think that we should discuss it. I totally agree with you that there should be a way to make this convenient, but I don't think that the possibility of runtime errors is a good price to pay for this convenience.
matil019
@matil019

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 = 0

but 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.
Paul Kapustin
@pkapustin
@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?
Ingo Wechsung
@Ingo60
@pkapustin I think I get you now. Sure, there is not really smth. like Haskell packages. Maybe I misunderstood them until now, but is this more than some organisatorical measure or just introduced by some build tool?
Ingo Wechsung
@Ingo60
@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.
  1. every constructor of a sum type would be a separate type.
  1. The sum type itself would be the union of all constructor types.
Ingo Wechsung
@Ingo60
  1. 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 infer Maybe{Just} a -> a, and this would preclude using the function on any value that can't be proven at compile time to be a Just
Ingo Wechsung
@Ingo60

Hence

unJust Nothing

would be a compile time error.
Until now, this is just fantasy. I'm not good enough in type theory to know if this could work at all, and maybe it would turn out that it is not practical.

Ingo Wechsung
@Ingo60
Apart from that, I don't have the time to do anything presently. I shall be happy to keep up with @matil019 's pull requests :)
Michael Chavinda
@mchav
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?
matil019
@matil019
Hi @mchav. From the logical point of view, I don't think it can be. The reason is the same as that an instance Show (a -> b) can't be defined.
However, perhaps you can write a conversion function something like SerializableBiFunction toSerializable(frege...Func<...> fun) or its equivalent in Frege.
Cary Robbins
@carymrobbins
Isn't this possible with something like StaticPointers?
Dierk König
@Dierk
we recently had a master project with Frege and Apache Spark where we needed the same but had to revert to sending code as text. If we could pull this off, it would be awesome!
Paul Kapustin
@pkapustin
@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.
Paul Kapustin
@pkapustin
@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
Paul Kapustin
@pkapustin
@Ingo60 Actually, I am very happy with records in Frege. For me possibilities of extension are interesting, but not important.
@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)
Paul Kapustin
@pkapustin
@Dierk Just a kind reminder, how is it going with the server? I think it would be really nice to get things up and running again, especially thinking about services like "Try Frege" and "Hoogle".
Dierk König
@Dierk
@pkapustin thanks for the reminder ;-) Honestly, it would be great if anybody else could take over that task. In my task list it never quite rises above more urgent topics.
Ingo Wechsung
@Ingo60
@pkapustin Hi Paul, nice to see you. I'm afraid I don't understand enough Purescript to follow the discussion you linked to. Maybe I have to go for some sleep before I read it again.
mlnIGZlbGxhCg==
@0xde_gitlab
Are there plans to maintain support for Frege for JDK 11, 12, .., 14, etc.?
Ingo Wechsung
@Ingo60
x
Ingo Wechsung
@Ingo60
@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.
Meredith Espinosa
@Boundarybreaker
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)
Ingo Wechsung
@Ingo60
@Boundarybreaker there is no current version on sonatype. If you need gradle, you'll have to configure it to use a local jar.
Michael Chavinda
@mchav
Any big milestones coming up language wise? With all this coronavirus stuff happening I have free time to work on some Frege.
Dierk König
@Dierk
@mchav we should bring up the online repl again.
Dierk König
@Dierk
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)
Dierk König
@Dierk
I updated the web repl again. It now uses the frege3.25.42.
I'd like the let try.frege-lang.org point to the new repl. Is anyone here the domain owner?
Michael Chavinda
@mchav
I'm trying to compile the Frege compiler and I run into a "Code too large" error. Can anyone else reproduce?
@Dierk did you find out who owns the domain?
Dierk König
@Dierk
@mchav you might need to increase the stack space. Last I checked the domain should now be available again or become available this month.