Skip to content
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

Renamed the builtin-signature, again. #121

Closed
wants to merge 1 commit into from
Closed

Conversation

skx
Copy link
Owner

@skx skx commented Jan 15, 2023

So we have an interpreter which has STDIN, and STDOUT. However builtin functions don't have access to the interpreter so they can't use either.

Right now only (print ..) needs access, but it is possible to imagine that other built-in functions might need such access.

To avoid import-cycles we can't type the interpreter instance, but we can pass an any / interface{} which has a pointer to the interpreter.

This is a biggish change, but purely mechanical so I'm confident enough about it.

So we have an interpreter which has STDIN, and STDOUT.  However
builtin functions don't have access to the interpreter so they
can't use either.

Right now only `(print ..)` needs access, but it is possible to
imagine that other built-in functions might need such access.

To avoid import-cycles we can't type the interpreter instance,
but we can pass an `any` / `interface{}` which has a pointer to
the interpreter.

This is a biggish change, but purely mechanical so I'm confident
enough about it.
@skx
Copy link
Owner Author

skx commented Jan 15, 2023

This doesn't work - I tried passing anyas the type to avoid import cycles.

However when trying to use it I get the same thing:

@@ -1454,13 +1455,18 @@ func printFn(yal any, env *env.Environment, args []primitive.Primitive) primitiv
                return primitive.ArityError()
        }
 
+       // Get the interpreter
+       ev := yal.(*eval.Eval)
+
        // one arg
        if len(args) == 1 {
                // expand
                str := expandStr(args[0].ToString())
 
                // show & return
-               fmt.Println(str)
+               ev.STDOUT.WriteString(str)
+               ev.STDOUT.Flush()
+
                return primitive.String(str)
        }

I will rethink this ..

@skx
Copy link
Owner Author

skx commented Jan 19, 2023

Doomed approach.

Better plan is to have a struct/interface passed to the interpreter to store I/O handles.

@skx skx closed this Jan 19, 2023
@skx skx deleted the builtin-signature branch January 19, 2023 07:22
skx added a commit that referenced this pull request Jan 25, 2023
This pull-request supersedes #121, which was never merged, as a
solution to embedding the interpreter and allowing flexible I/O
handling:

* Rather than changing our builtin-signatures we introduce a new
  config/ package.
* We pass an instance of the configuration object, containing handles,
  to the interpreter.
* This is then accessed to read/write to STDIN/STDOUT.

The test-case for (print), TestPrint, was updated to send output
to a faux I/O helper - which is actually a buffer - and shows that
the indirection works.

And now that we've implemented the I/O helper we've updated (read)
to use it appropriately too.
@skx skx mentioned this pull request Feb 13, 2023
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

Successfully merging this pull request may close these issues.

1 participant