Re: string_exec()
- Posted by petelomax Mar 05, 2015
- 2044 views
I still do not understand why string_exec() would be useful. Would someone please show a code example that demonstrates what string_exec() can do that can't currently be done in Euphoria, or that would make something easier to do?
An old idea, but I thought it is about time I at least got a start on some design. ...
I've not had much need for this facility (that I can recall), so what would be its purpose? Can anyone give me some useful, concrete examples?
The only half-decent concrete example I've got is a REPL.
To be honest, I was expecting more interest, and examples...
I'm pretty sure I'd want some control over how such unknown code can update "my app"'s environment.
My current thinking is that sting_exec can only see the things it has been explicitly told about. The reference-counted nature of the language should make it easy/fast to shunt even big data into and out of workspaces as needed.
One specific case I mused on the other day was that if it automatically granted full access to the underlying data, then string_exec("symtab=0") would guarantee instant death with no error, no warning, and no diagnostics. Since the presence of string_exec means a complete embedded copy of the compiler/interpreter, literally hundreds of other identifiers that could cause strange and highly intermittent bugs might also be exposed. While I probably/hopefully could avoid such issues, I took that level of potential devastation as fair warning.
The closest I've gotten is that I've written some macro's that run in an app's space (eg. Excel, Word, Access, etc...) but they have pretty limited access to the underlying application's data space.
Indeed, from a programming language perspective such things have zero access to the application's data space, except for some user-defined bits in a handful of specific tables, that it doesn't even know the names of.
I think the safest route to go would be to have string_exec() take two parameters - the code text, and a work-space environment that would contain values supplied by the calling app. string_exec() would return two things: A success/failure code and an updated work-space. The calling app could then decide what to do with the updated values.
I've gone with "context" as in context = string_exec(context,code). The (as yet loosely defined) context would contain extend-able symbol and lookup tables, code and data block(s), result codes, and anything else needed.
One other thing I'd like to mention is Matt's embed_routine idea. I've no real problem with that method of granting selected access to the underlying application's data, except for potential confusion if it plays with a different "mytable" to the one in the string_exec workspace. Hence I'm somewhat hesitant on that.
Pete
