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
@badbadboy Sure, you're right, it'd always be better to have more documentation. Regarding the examples, no they aren't part of the fregec.jar, but the tutorial gives a curl command line to download one.
Paul Kapustin
@pkapustin
@Ingo60 It seems there is a maintained fork of Impulse framework here: https://github.com/usethesource/impulse. Do you think it would be interesting to try if we could get fregIDE to work with this?
Ingo Wechsung
@Ingo60
Yes, @badbadboy, we actually do use this. The eclipse-plugin/ is a PDT project that references the impulse-plugin, which must be installed as a plugin along with all the stuff that is needed for plugin development. This is why it probably won't work in a vanilla eclipse installation. But it should when you have the prerequisites.
Paul Kapustin
@pkapustin
@Ingo60 Yes, I understand that. As I see from Frege/eclipse-plugin#1, the plan is to move away from the Impulse framework, as it is no longer supported / worked on, and develop a standalone plugin. However, it seems to be a maintained fork of the Impulse framework here: https://github.com/usethesource/impulse. I am wondering if you think that investigating whether we could migrate to this fork is a viable option (as it is probably less work than developing a standalone plugin).
Ingo Wechsung
@Ingo60
Wait wait, @badbadboy The plan was to move away from the IMP framework, which we did, and we replaced it with impulse (the one you are pointing to). I forgot we had an open issue for this, but indeed! It's closed now.
Paul Kapustin
@pkapustin
@Ingo60, I see, thanks for the clarifications. I managed to build fregIDE, but have not yet found out why the editor is not always refreshed, as described here: Frege/eclipse-plugin#35. I hope to take look at it again later. I was also thinking about writing some notes in the wiki describing how one can build fregIDE.
Ingo Wechsung
@Ingo60
That'd be great, @badbadboy
Paul Kapustin
@pkapustin
How is it going with the movement of the server, @Ingo60, @Dierk? It would be nice to have the services up again.
matil019
@matil019

@Ingo60 I found a peculiar grammar. native definitions accept non type variables as generics parameter. For example, the following compiles

native emptyListFoo java.util.Collections.emptyList {[a]} :: () -> STMutable s (List [a])

On the other hand, native data type declaration crashes the compiler:

data ArrayList a = native java.util.ArrayList {[a]} -- crashes

Is it intended? Because I intend to disallow it as a part of refactoring TauT, so that only type variables can appear as generics parameter.

Paul Kapustin
@pkapustin
@matil019 Briefly saw your PR. Wow. Thanks for doing this.
Paul Kapustin
@pkapustin
@Ingo60 I have a question about contributing and getting more people onboard. Would it be nice with a package manager? But even before that, is there any guidance on where the things should go? Say, something is in Haskell's base, then it should probably be a part of standard library. But if it is in some other package? Where should it go, and what is the correct way to deal with licensing if we are porting Haskell code? What should go in contrib and how should it be structured?
matil019
@matil019
@badbadboy Thanks. That was quite an effort but I hope it opens up new possibilities for Frege.
Paul Kapustin
@pkapustin
@matil019 @Ingo60 Absolutely. Actually, one thing that I think would be very nice to have is some sort of extensible records, maybe with row types (or something else?). Also, I am not a fond of the sum-record types with partial accessor functions. Maybe it could be a good idea to produce a warning when this is used, explaining that this is only available for compatibility with Haskell.
matil019
@matil019
@pkapustin Do you mean something like PureScript's one?
Paul Kapustin
@pkapustin
@matil019 Yes, maybe something like that? I think both PuresScript and Elm have a similar approach to this. But I don't really like that in PureScript there is a distinction between wrapped and unwrapped records, so one can either have dot notation (unwrapped) or instances (wrapped). I think Frege has this part right.
Paul Kapustin
@pkapustin
@matil019 Then again, I cannot say that I am very fond of the idea that I can have a function that can update "name" field in any record that has this field. However, this is probably "type-safe enough" and rather useful. What do you think? Are there other good ways of extending records?
matil019
@matil019
@pkapustin I'm not sure how a record type can work with Java ecosystem Frege tries to deal with. The "record type" makes easy to interact with JavaScript's objects but Java doesn't have something like that (perhaps Groovy supports it? IDK). The dot notation is indeed useful but doesn't mix well with other syntax IMO.
Ingo Wechsung
@Ingo60
Lots of questions here. Sorry for not having listened over the week.
@pkapustin Certainly, if something is in Haskell module X, it should be the same in Frege. If not, it's mostly for historic reasons.
@pkapustin Most of standard Haskell should be BSD licensed, so I don't see a problem here. We ported Quickcheck, for example, by just compiling the source code. (Well, almost).
Paul Kapustin
@pkapustin
@matil019 I agree. I am not sure what should be the right approach for extensible records in Frege and even whether there should be extensible records, but still I would like to raise this question as some functionality of that sort can be quite practical.
Ingo Wechsung
@Ingo60
Regarding record types, well, I just see them as more convenient form of product types. And sum of records likewise. It's true, they make it easy to introduce partial functions, but that is true for any sum types. (It's just also more convenient with records.)
Extensible record types? I've thought about this earlier, but it's a nightmare when you consider the representation in the target language (i.e. Java).
What I mean is, I'm not aware of a way to do this, but if someone has an idea, please come forward.
Paul Kapustin
@pkapustin
@Ingo60 Regarding contributing, what if the code belongs to some Haskell package? Where should it go then? And also, those packages sometimes have license files, I am not sure how this needs to be handled.
Ingo Wechsung
@Ingo60
@matil019 you're right, within the braces there should only be type veriables.
@pkapustin Well. I don't see the problem with package names? Please explain.
Paul Kapustin
@pkapustin
@Ingo60 Regarding partial functions, what do you mean? How can one create partial functions with sum types? As long as there are no accessors for the fields of sum types, isn't pattern matching the only way to get the values, or am I wrong?
Ingo Wechsung
@Ingo60
And, for sure, the licenses must be respected. But if it is for example, a BSD type license that says you can use the code at your will, then just do it.
@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?