You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
{{ message }}
This repository has been archived by the owner on Nov 18, 2021. It is now read-only.
In #646 we discuss renaming cue get go to be cue import go. In the future we also intend to more clearly support exporting from CUE to some other language representation (this is currently made possible via the cuelang.org/go/encoding/gocode package) from the command line.
Which begs the question: what about languages other than Go?
For example, @nyarly has previous enquired about Rust being added to that list.
This is a general placeholder for import/export support for "insert your language here".
Building on the motivation in #646, this would purely be the support for importing/exporting from/to "a another language", e.g. Rust. The method for resolving packages (or the equivalent in any given language) would be delegated to language specific tooling/loader/something. e.g. for Go, package resolution is handled by go/packages, which requires that (as of Go 1.16) a go.mod is present through which a package can be resolved.
The text was updated successfully, but these errors were encountered:
I'm going to guess that "tree-standing" (for export) won't work out well after exploring some of the grammars. We'd probably need to define a language format (in CUE of course :) for generation. Maybe that format maps onto the tree-sitter grammar, but it looks to be quite complicated due to the widely varied syntax across languages.
For import (currently cue get go) we need type information for Go, and suspect we would for every other language: syntax by itself would not be enough (unless I misunderstood what you were suggesting, or am missing a piece in the puzzle here with respect to tree sitter?). For export I'm not sure of the need for a common format - we simply need to take convert from CUE API values (already well defined) to a target language (could be as simple as fmt.Printf calls, could use text/template, could use an AST for the language...)
In #646 we discuss renaming
cue get go
to becue import go
. In the future we also intend to more clearly support exporting from CUE to some other language representation (this is currently made possible via thecuelang.org/go/encoding/gocode
package) from the command line.Which begs the question: what about languages other than Go?
For example, @nyarly has previous enquired about Rust being added to that list.
This is a general placeholder for import/export support for "insert your language here".
Building on the motivation in #646, this would purely be the support for importing/exporting from/to "a another language", e.g. Rust. The method for resolving packages (or the equivalent in any given language) would be delegated to language specific tooling/loader/something. e.g. for Go, package resolution is handled by
go/packages
, which requires that (as of Go 1.16) ago.mod
is present through which a package can be resolved.The text was updated successfully, but these errors were encountered: