-
Notifications
You must be signed in to change notification settings - Fork 145
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
Using dhall with eta #704
Comments
Sounds good!! |
Good stuff! Finally looked into Dhall this morning and it looks great. One cool thing to try out is to make a Dhall-to-Gradle compiler to make Gradle configuration type-safe, similar to the Gradle Kotlin DSL. It would be nice to have proper syntax highlighting for it. Functions and imports are actually nice for configurations. It means you can provide a standard template configuration and have users modify it to their needs without having to copy/paste which can be error prone. YAML's syntax for key/value abstractions actually uses ad-hoc symbols and I'd take a If we do shift to Dhall though, we should make sure we have lots of templates + examples because StackOverflow won't help people like it would with existing formats. |
I love Dhall, but for sure, we should have lots of templates as Rahul mentioned 😄 |
dhall-to-cabal has been released!
|
Really cool :) Does Dhall have a feature to show a simplified version of the config with all the |
@rahulmutt yeah, it names it reduce to the normal form:
Moreover
(from https://github.com/dhall-lang/dhall-to-cabal/blob/master/README.md) |
That's great to hear - looks like it is going to be good for practical use. |
it lives! |
|
|
|
@jneira Awesome thanks! I think this means we can add support for something like Would you be interested in implementing the parser bit that will parse the |
@rahulmutt Totally agree with moving the project to eta-lang. The version to use withint eta could be a patch in eta-hackage but obviously the fork to be included in eta it is not. If dhall maintainers think it is a good idea include the branch with ghc-7.10.3 compatibility in the upstream project we could use a git reference in stack.yaml. In any case i am going to move the project.
Sure! |
It turns out that dhall-to-cabal already does the conversion of a dhall file to a |
In that case, this line: |
mmm, it seems it would need some more changes. Maybe we would need a dhall-to-etlas... |
@jneira Yes most likely that will be the case. You can create a fork and name is as |
So there's two things that need to be changed in the internal logic for
How does that sound? |
Otoh, the actual version of dhall is throwing |
@rahulmutt sounds good to me, i'll give a try asap |
@jneira Can you file the issue with |
Hi, patching megaparsec with typelead/eta-hackage#86, dhall works again with eta
|
@jneira I have a hunch that's caused by some inconsistent sequence of operations in the |
Hi, i have a version of dhall-to-etlas that compiles! |
I agree that it should be a submodule of It can generate a You'll have to override the In general, grep for |
Hi, before including dhall-to-etlas in etlas i've wanted to write a valid dhall-to-etlas.dhall. |
|
module Dhall.Eta where
import qualified Dhall
import qualified Data.Text as Text
import Java
input :: Dhall.Type a -> JString -> IO a
input ty = ( Dhall.input ty ) . Text.pack . fromJava
foreign export java "@static org.dhall.eta.Input.bool" bool
:: JString -> IO Bool
bool = input Dhall.bool
foreign export java "@static org.dhall.eta.Input.str" str
:: JString -> IO JString
str = fmap toJava . input Dhall.string
foreign export java "@static org.dhall.eta.Input.integer" integer
:: JString -> IO JInteger
integer = fmap toJava . input Dhall.integer
foreign export java "@static org.dhall.eta.Input.natural" natural
:: JString -> IO JInteger
natural = fmap ( toJava . toInteger ) . input Dhall.natural
package org.dhall.eta.example;
import org.dhall.eta.Input;
public class Client {
public static void main (String[] args) {
System.out.println("Testing dhall");
System.out.println(Input.bool("True"));
System.out.println(Input.bool("True && False"));
try {
System.out.println(Input.bool("1"));
} catch (Exception e) {
System.out.println(e.getLocalizedMessage());
}
System.out.println(Input.str("let str=\"dhall\" in \"Hello ${str}\""));
System.out.println(Input.integer("+1234567"));
System.out.println(Input.natural("2 * 3 + 4"));
System.out.println("The end");
}
} Output:
|
Awesome work @jneira ! |
We have started the integration between etlas and dhall: https://github.com/jneira/etlas/tree/dhall:
|
One thing that would help on my end is getting this integrated into https://github.com/eta-lang/eta-nix That would allow me to add an Eta build of Dhall to my CI so that I can catch potential Eta-related issues earlier (like adding new dependencies that might require work to port to Eta) I tried using that repository directly but I ran into issues due to mismatch between that repository and |
@Gabriel439 that would be awesome, thank you very much |
@Gabriel439 I've got |
Added a chunk of overrides to get Dhall close to compiling. Got stuck on Cryptonite - it has a jar dependency and I'll have to figure out a way to supply that. |
Actually for build master version of dhall-haskell with etlas we would need patch the new dependecy cborg-0.2.0.0: typelead/eta-hackage#111. It seems it could take some effort cause it uses low level data representation and c ffi. |
Some updates on running dhall on Eta: I fixed the Bad Record MAC bug (was a bug in cryptonite patch) and the next step is to implement the zlib bits in streaming-commons. |
Ok great, https requests seem to work now with the latest patches on |
We have patched cborg-0.2.0.0 in typelead/eta-hackage@e400525 - just updating since that issue wasn't linked with @jneira's previous comment. |
Hi, after patching the transitive dependency of cborg, serialise, we can build again master version of dhall-haskell. Moreover, with the recent work of @rahulmutt, http imports finally work!:
|
@Gabriel439 I have When evaluating I get:
I don't know where this problem is coming in. I'll try updating Eta and eta-hackage and see if it's still a problem. |
@puffnfresh do you mean when evaluating a Dhall expression you get that? It looks possibly like a bug with |
@puffnfresh: The problem you ran into sounds similar to this: What expression did you test on? |
@jneira: Would a new dependency on |
@Gabriel439 I am afraid that eta doesnt support |
@Gabriel439 You can go ahead and add the dependency. At worst, once the dhall integration is done, we can add an |
Although the wrapper of dhall for java is still a wip and full of bugs, i managed to implement almost all public api of package org.dhall.eta.example;
import org.dhall.core.*;
import org.dhall.core.expr.ExprIntegerShow;
import org.dhall.parser.*;
import org.dhall.parser.error.*;
import org.dhall.typecheck.TypeError;
import org.dhall.eta.Parser;
import org.dhall.eta.TypeCheck;
import org.dhall.eta.Core;
import org.haskell.types.*;
public class Client {
public static void main (String[] args) {
Either<ParseError,Expr<Src,Import>> parsed = Parser.exprFromText("example","1");
System.out.println("Parsing \"1\":");
System.out.println(parsed);
System.out.println("-----------------------------");
Either<ParseError,Expr<Src,Import>> eParsedFun =
Parser.exprFromText("example","λ (t : Text) -> 1");
System.out.println("Parsing \"λ (t : Text) -> 1\":");
System.out.println(eParsedFun);
System.out.println("-----------------------------");
Either.Matcher<ParseError, Expr<Src,Import>, Expr<Src,Import>> matcher =
new Either.Matcher<>(any -> null);
matcher.Right(r -> r.getValue());
Expr<Src,Import> parsedFun = matcher.match(eParsedFun);
System.out.println("Pretty printing parsed fun");
System.out.println(Core.pretty(parsedFun));
System.out.println("-----------------------------");
Expr<Unit,Import> norm = Core.normalize(parsedFun);
System.out.println("Normalize fun");
System.out.println(norm);
System.out.println("-----------------------------");
Expr<Unit,Import> alphaNorm = Core.alphaNormalize(norm);
System.out.println("Alpha normalize fun");
System.out.println(alphaNorm);
System.out.println("-----------------------------");
Expr<Src,Void> importedExpr = new ExprIntegerShow<>();
Either<TypeError<Src, Void>,Expr<Src,Void>> checked = TypeCheck.typeOf(importedExpr);
System.out.println("Type of ExprIntegerShow");
System.out.println(checked);
System.out.println("-----------------------------");
System.out.println("The end");
}
} with this output:
|
Hi, more advances in public class Client {
public static void main (String[] args) {
System.out.println("Testing dhall main module");
Type<Boolean> tyBool = Types.bool();
Boolean bool = Input.type(tyBool, "True");
System.out.println(bool);
Type<Optional<String>> optStrTy=Types.optional(Types.str());
Optional<String> optStrIn = Input.type(optStrTy, "Some \"hello\"");
System.out.println(optStrIn);
Type<List<Natural>> nsTy = Types.list(Types.natural());
List<Natural> ns = Input.type(nsTy, "[1, 2, 3]");
System.out.println(ns);
Project p = Input.type(Types.record(new ProjectType()),
"{ name = \"dhall\", description = \"desc\", stars = 123 }");
System.out.println(p);
System.out.println("The end");
}
public static class Project {
private String name;
private String description;
private Natural stars;
public Project(String name, String description, Natural stars) {
super();
this.name = name;
this.description = description;
this.stars = stars;
}
// getters and toString boilerplate
}
public static class ProjectType implements RecordType<Project> {
public Map<String,Type<? extends Object>> getFieldsTypes() {
LinkedHashMap<String,Type<? extends Object>> fields= new LinkedHashMap<>();
fields.put("name", Types.str());
fields.put("description", Types.str());
fields.put("stars", Types.natural());
return fields;
}
public Project fromFieldsValues(Map<String,Object> m) {
return new Project((String)m.get("name") ,
(String)m.get("descripcion"),
(Natural)m.get("stars"));
}
}
} Output:
|
We already have released the eta lib to expose a java friendly api over dhall-haskell! |
Super stuff @jneira! Is this issue ready to be closed? |
Well, only left a more complete etlas integration but we could close this one, if nobody disagrees |
(from https://github.com/dhall-lang/dhall-lang)
Dhall is a relatively new configuration language written in haskell and its goals and features marry very well with langs like haskell/eta. Its main advantage over yaml f.e. is that dhall is typed and is guaranteed to terminate so you can make your config more discoverable and safe.
Its main drawbacks are:
The goal of this issue is track the progress and possible problems of the use of dhall ant its tools:
The text was updated successfully, but these errors were encountered: