Where communities thrive


  • Join over 1.5M+ people
  • Join over 100K+ communities
  • Free without limits
  • Create your own community
People
Repo info
Activity
  • Sep 06 21:58
    dgcooke opened #55
  • Aug 19 10:38
    joprice opened #43
  • May 20 20:48

    Dierk on dk_producer_consumer

    ProducerConsumer.fr: use stdin.… (compare)

  • May 20 20:25

    Dierk on dk_producer_consumer

    working producer-consumer versi… confirmed that Reader.close is … (compare)

  • May 19 20:51

    Dierk on dk_producer_consumer

    working producer-consumer versi… (compare)

  • May 18 21:56

    Dierk on dk_producer_consumer

    working producer-consumer versi… Merge remote-tracking branch 'o… (compare)

  • May 17 22:26

    Dierk on dk_producer_consumer

    working producer-consumer versi… (compare)

  • May 11 20:52

    Dierk on master

    fix missing commas and other gr… (compare)

  • May 11 20:45

    Dierk on master

    update the frege online repl ur… (compare)

  • May 11 19:48

    Dierk on master

    minor typo fixes in the README.… (compare)

  • May 10 21:04

    Dierk on master

    updated copyright notice to 2021 (compare)

  • May 10 20:50

    Dierk on master

    add Intellij IDEA plugin projec… (compare)

  • May 07 18:28
    psurkov closed #393
  • May 07 17:38
    psurkov edited #393
  • May 07 17:36
    psurkov opened #393
  • Apr 15 05:07
    seancorfield unassigned #6
  • Nov 21 2020 23:30
    decapo01 closed #36
  • Nov 21 2020 23:30
    decapo01 commented #36
  • Nov 21 2020 23:29
    decapo01 edited #36
  • Nov 21 2020 15:06
    Ingo60 commented #36
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.
Sean Corfield
@seancorfield
Just coming back to Frege after a long break. Nice to see the Java 8 support (yes, I've been away a long time!). Is there a reason the Frege releases aren't on Maven or some easily accessible public repo?
Sean Corfield
@seancorfield
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?
Sean Corfield
@seancorfield
It looks like frege.compiler.Main/runCompiler still exists with the same signature so the plugin won't need to change much.
Dierk König
@Dierk
No objections from my side ;-)
Sean Corfield
@seancorfield
Thanks. I'll keep y'all posted on how it goes.
Dierk König
@Dierk
@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)
Sean Corfield
@seancorfield
It turns out that I can no longer deploy Frege's JAR to Clojars because they no longer allow shadowing Maven artifacts -- and there are old versions of Frege up on Maven now. I would only be able to do it by pushing it up under a new group/artifact ID.
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
Sean Corfield
@seancorfield
(rawgit no longer allows directory access and is going away so I'll have to keep poking some more)
Sean Corfield
@seancorfield
@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...)
Dierk König
@Dierk
@seancorfield cool. Let me see if I can find some time this week to try setting this up. It will be instructive either way.
Michael Chavinda
@mchav

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 View

To:

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?

alanmcsherry
@mcsherrylabs
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?
Dierk König
@Dierk
@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
Peter Surkov
@psurkov
Hi, could you please share the latest version of Frege documentation? I cannot compile it from Github
Peter Surkov
@psurkov
We are developing Frege language plugin for IntelliJ IDEA. However, we came across a problem with BNF because Frege documentation is outdated so Frege examples don't parse. Another problem is type inference. We would like to infer expressions fast, so we can't use REPL for this and need to call Frege compiler functions. What's the best way we can do it?
Dierk König
@Dierk
Hi, @psurkov, hey, that's awesome! We're happy to help you in any way we can.
Is there any specific error that you can point to?
Dierk König
@Dierk
@psurkov BTW: have a look at the grammar files in the compiler support under: https://github.com/Frege/frege/tree/06bdbec0c8f2bb3990502958614ea5fe6be9654c/frege/compiler/grammar and the generated Grammar.fr file under /frege/compiler
Peter Surkov
@psurkov
@Dierk Thanks for the provided grammar! It's very helpful.
Dierk König
@Dierk
@psurkov keep us posted about your progress!
23jura23
@23jura23

Hi, I am one of the contributors of IntelliJ IDEA plugin.
I am currently developing the launch of Frege code inside IDEA, including build system and interpreter support.

We have some build system already, and it is based on Gradle. I have found some build.gradle here and modified it for our purposes.

We currently do not have proper support for complicated projects, which contain both frege and java files with difficult dependencies. For example, we don't support projects with dependencies like Java -> Frege -> Java or Frege -> Java -> Frege.
Meanwhile, I am not sure if such projects need to be supported at all, and wondered to ask about it.

Also I am about to start developing interpreter support. We plan to support a command-line execution inside IDEA's terminal, and also an execution of an arbitrary part of code by click.
I think that I understand, how to implement the command-line execution, but I am not sure about the execution of arbitrary code.
it would be very useful if you could point, what methods I should call in compiler to launch an arbitrary part of code and get the result of execution.

Thank in advance!

Dierk König
@Dierk
@23jura23 Hi, cool that you are working on this. You might want to look into the various REPLs (command line, swing, fregeFX/javaFX, and web), which are based on the interpreter. Also https://github.com/Frege/frege/wiki/Using-Frege-in-Intellij-IDEA might be helpful, esp. the part "start the Frege REPL with your code on the classpath".
For the Frege <-> Java interplay at compiletime, it is actually very well supported. Note that if dependencies are "external", they are just Java dependencies and "internally", i.e. code that you write yourself, you can embed Java code directly into your Frege code and compile them together, thus allowing bi-directional dependencies. The FregeFX projects makes use of that for example.
23jura23
@23jura23

@Dierk Thanks for the provided examples of REPLs and Frege wiki reference, I will examine it!

I also examined FregeFX source code. As far as I understand, Java code uses Frege compiler's classes, and vice versa, Frege code uses JavaFX. But as I understand, both Frege compiler and JavaFX contains already compiled .class files, that are used to build the project.

I meant the situation when the project contains, for example, a dependency like this:
File1.fr -> File2.java -> Fiel3.fr

Then the compilation need to be executed in the order C.fr, then B.java, then A.fr, to satisfy dependencies. But Frege compiler does not automatically resolve such dependencies, so I have to resolve them by hand, compiling in the right order.

Here is the example of such project: https://gist.github.com/23jura23/b9e40c6d7d7a98c6684edf4c879f820b

Another problem is the cyclic dependency, like this:
File1.fr <-> File2.java

Here is the example of such project: https://gist.github.com/23jura23/58ce0c73bd7a47015db3a6f908d3d2d6

Although the first project could be built, the second one could not be built at all. This happens because File2.java uses .class file, i.e. File1.class, and File1.class is not created until File1.fr is built. And File1.fr could not be built, because File2.java does not find File1.class.

I am not sure if these problems have solutions at all, or I just failed to find them.

Dierk König
@Dierk
@23jura23 cool. I very much appreciate the work that you all are doing! It really makes my day.
For the compilation order, there are two approaches.
a) you might want to use "inline" Java code as in https://github.com/Frege/FregeFX/blob/42faa5316e6fac75a99cbc1e221f9128cafd5f90/fregefx/src/main/frege/fregefx/JavaFxUtils.fr . Note that in order to start JavaFX correctly, we need a subclass of "Application" - that means that our JavaFX code depends on Java - but that class will need to start our Frege code - and thus depends on Frege again. Of course this only works if both, the Java and the Frege source code is under your control.
b) when you cannot use the a) approach, it is usually best to work factor out the dependencies into Java Interfaces. Compile those first and let all your other subprojects depend on the "interface" subproject.
BTW: the "inline" approach would also allow to write the whole plugin in Frege ;-) (even though I fully understand that working with the PSI is much easier with Java)
23jura23
@23jura23

@Dierk Thank you!
As I understand, as plugin developers we need to provide support for Java inline, and we'll examine what we can do with it.
And as possible future Frege developer, I appreciate solutions you provided

Writing the whole plugin in Frege sounds like a very ambitious task that we are not ready for yet :-)

Dierk König
@Dierk
@23jura23 support for inline Java would be cool but it is not the most important feature. When Java support for the inline Java is needed, one can just copy/paste it into a Java file, edit there, and copy/paste back. However, the IDEA "language injection" feature might be possible to employ here.
Writing the whole plugin in Frege was only mentioned to show the potential. It's not a practical approach for the moment - even though the Eclipse Plugin was written in Frege ;-)
BTW: cool to see the latest commits!
Kirill Karnaukhov
@kkarnauk
@Dierk Hello! I'm a contributor to the Intellij-Frege plugin. Mainly I develop the navigation and resolving references. More and more often I face the problem of inability to get the types of elements. Type system is a difficult part of the plugin and we have no idea how to implement it. What we want is to be able to get the types of elements on the fly without any lag. Many of functional languages have language servers doing that job, but as far as I know Frege doesn't have it, unfortunately.
Do you have any advice or suggestion how to implement fast type inference in our plugin?
Also we were exploring the source code of the Eclipse plugin and found out that you used Global for type inference. As we understand, Global is the result of parsing of the whole file. So there is a question: can we incrementally keep Global updated? I mean: if an user changes a small part of file, can we get an actual Global without re-parsing the whole file? If so, could you, please, give us a hint how to do it or where we can see an example of that.
Another problem of using Global is that we build a PSI tree and resolve all references on our own. As we understand, if we use Global, the compiler will do it one more time. Can we reuse PSI trees and references somehow?
Thanks in advance!
Dierk König
@Dierk
@kkarnauk Hi Kirill, it's great to see your work moving forward! The best person to ask is @Ingo60. He did all the work :-) However, since Eclipse always parses whole files, it is no surprise to see the Global in the way you mentioned. There is a more flexible (yet arguably less sophisticated) way to deal with this issue: one can use the Interpreter just like the REPLs do: https://github.com/Frege/frege-repl/blob/5701b6bbce25662b1ce172dd677a6fe2e058a885/frege-repl-core/src/main/frege/frege/repl/FregeRepl.fr#L556 . This allows to pass arbitrary strings for inspection (:type, :browse, etc.). That means that if you can partition the file into pieces that would compile separately, you can pass them into the Interpreter for inspection. In fact, that somehow mimics my working style when programming Frege where I have the REPL running, load my current file, reload on changes, and work with the REPL for compiler feedback and type information ;-)
Dierk König
@Dierk
BTW: a language server is in the works...
Kirill Karnaukhov
@kkarnauk
@Dierk Thanks for your answer! We thought a lot about using Interpreter for type inference. But we're afraid that it would be slow so we're searching for another option. However, @23jura23 is now trying to implement type system by invoking Interpreter commands. If it still turns out to be not fast enough, we'll have to come up with something else.
Another idea of implementing type inference is to reuse resolving generics and types from Intellij-IDEA for Java. But we haven't explored this option much yet. Do you think that it could work or Frege types are much more difficult than Java ones?
Dierk König
@Dierk
@kkarnauk hi! That is an interesting approach. One could actually inspect the Java code that the Frege compiler creates from Frege source code. There is a lot of type information in the @ Meta annotations that are kept in that Java code.
Kirill Karnaukhov
@kkarnauk
@Dierk Hi! We finally published our plugin on JetBrains Marketplace! It's available here: https://plugins.jetbrains.com/plugin/17187-frege.
Dierk König
@Dierk
@kkarnauk Awesome! Thank you so much for your work to the whole team! I assume this work also has an additional purpose. Let me know if I can support with any of that ;-)
Kirill Karnaukhov
@kkarnauk
@Dierk you posted in twitter "I struggle myself". What kind of problem do you have? Maybe we can help you.
For you information: you must create a new project to make it work.
Dierk König
@Dierk
@kkarnauk I struggled to find the right IDEA version where the plugin appears in the marketplace. It works with 2021.1.3 Ultimate non-EAP. First impression: I LOVE it !!!
Kirill Karnaukhov
@kkarnauk
We're so happy that you like our work! Thanks!
We'll try to handle a problem with different versions. However, we expected that it will work with any IDEA version since 2021. It's sad that it doesn't.
Kirill Karnaukhov
@kkarnauk
@Dierk Thank you so much for your feedback and issues! We'll try to fix them.
Peter Surkov
@psurkov
Hi @Dierk
We have just published the first part of our article about the development of a plugin for Frege. But it is written in Russian) https://habr.com/ru/company/hsespb/blog/574692/