spy16 / sabre

Sabre is highly customisable, embeddable LISP engine for Go. :computer:
GNU General Public License v3.0
28 stars 5 forks source link

Cannot build with GO111MODULE=1 #4

Closed lthibault closed 4 years ago

lthibault commented 4 years ago

Hi @spy16 ,

I just tried building a project that imports sabre using Go's module system:

$go run cmd/ww/main.go
build command-line-arguments: cannot load github.com/spy16/sabre/core: module github.com/spy16/sabre@latest found (v0.1.1), but does not contain package github.com/spy16/sabre/core

Do you know what the problem might be? I'm happy to push a fix.

lthibault commented 4 years ago

After out imports to the core subpackage, I get the following error:

$ go run cmd/ww/main.go                                                                                                                          (705ms)
# github.com/lthibault/wetware/pkg/types
pkg/types/map.go:77:22: undefined: sabre.Reader
pkg/types/path.go:20:23: undefined: sabre.Reader
pkg/types/types.go:9:28: undefined: sabre.ReaderMacro
pkg/types/util.go:32:28: undefined: sabre.Reader
pkg/types/util.go:41:24: undefined: sabre.Reader
pkg/types/util.go:80:19: form.Eval undefined (type sabre.Value is interface with no methods)

I'm guessing go.mod / go.sum somehow out-of-date. I'll give this a quick try and report back.

lthibault commented 4 years ago

Ok, I fixed this by tagging the current tip of master to v0.1.2, and then manually changing the version in my local go.mod.

I'm sure there's a better way to manage Sabre as a dependency... 🤔

I'm closing this for now, but please let me know if you have any insight!

spy16 commented 4 years ago

I think that's because go mod tried to pickup the latest tag. But I had not made a release after creating core package. So latest tag didn't have the core package.

lthibault commented 4 years ago

👍 Agreed. When do you think you'll have a stable public API?

spy16 commented 4 years ago

Also, make sure you use go 1.13+ (binary number parsing fails with lower versions of go).

Also when using go1.13 , GO111MODULE=on env var is not necessary.

spy16 commented 4 years ago

@lthibault currently I'm not very sure about it. There are 2 features that might require some breaking changes. Macros and Metadata.

You can already write macro like functions. For example:

(def when (fn [test body] `(if ~test ~body nil)))

But I'm trying to understand how macros work in Clojure and certain peculiarities around them.

Metadata is tricky too. In clojure each value type implements IMeta interface and by storing it in the value object itself. But Sabre value types are defined using type definitions like type Symbol string, which means that to hold additional data they need to be converted to struct types.

Hoping to take some time this weekend to figure this out.

lthibault commented 4 years ago

currently I'm not very sure about it

No problem -- just wondering 😃

macros / metadata

On my end, I think macros will be more useful than metadata in the short term. Unless you feel otherwise, maybe we can prioritize macros in the short term?

Lastly, can you confirm my understanding of your macro example? The ~ prefix means the test and body symbols are resolved before being inserted into the quoted form, correct?

Cheers!

spy16 commented 4 years ago

Agreed. I'm working on macros already. And will come to metadata later. But I'll be converting Symbol, List, Vector, Set to struct types. Just to make sure when I do start on metadata, It will be simple to add additional meta field into the struct.

Yes. ~ is unquote. When using backtick for quoting (syntax quoting), it recursively quotes everything. So without the unquote test and body would be inserted simply as symbols. With unquote, whatever value was passed in place of test and body args will be substituted.