Re: string_exec()
- Posted by petelomax Mar 04, 2015
- 2120 views
Not that any of this is likely to happen any time soon, but what I've gathered so far:
The notion of extendable, re-usable "contexts" is getting more and more appealing to me.
Fatal errors should(must) terminate (in) the supplied context rather than the host context.
A context contains enough (error) information to determine precisely what just happened, eg:
code = "a = 1\n"& "b = 2/0\n"& "c = 3" context = string_exec(context,code)
Somewhere in context (I am implying the above is not the first time it is used), there should now be one of:
- line 1, variable a has not been defined
- line 2, variable b has not been defined
- line 3, variable c has not been defined
- line 2, attempt to divide by zero
Obviously, if code contains no '\n' then everything gets reported on line 1, and it is left as a programming challenge to map whatever lines numbers you get back to whatever source code you threw at string_exec, but there will be reasonable clues, normally including a <=80-character code snippet.
Under no circumstances will c have been set to 3, and in that sense it is still a fatal error, but there is a separate outer context still running that can trap it.
Perhaps string_exec(or_all({NO_MSG,NO_ERRFILE}),code) or WITH_MSG,WITH_ERRFILE or even WITH_FATAL or something of that ilk could also be allowed, as an alternative to the initial string_exec(NULL,code). Obviously any such flags would be preserved within the returned context so they would not need to (and in fact could not) be re-specified on every call, and we can decide on the default settings so that in most cases no flags are required, later.
I am also thinking that should you pass a context with any non-zero error information back to string_exec then it should cause a fatal (host) error, because you clearly just completely ignored a problem. Or maybe once you get a fatal error, that context is forever non-reusable.
Migration
=======
Instead of (my initial ideas of) rebuilding a context from some previous (static) compilation, dynamic programming should be achieved by migrating more and more of the host app into the naturally dynamic playground of string_exec().
Instead of string_exec(contextX,...) being able to "magically" refer to data and routines declared in the hosting application, anything and everything needed should have previously been migrated into "contextX".
Scope issues vanish because what you are effectively doing is interperting some source, and later optionally extending that source code with some more code.
Multiple contexts can be declared as completely isolated from one another, or if you prefer you can run everything in a single context. You can save a "snapshot" or continuously extend a context as you please, eg:
context1 = string_exec(NULL,"integer a") context2 = string_exec(context1,"integer b") trash = string_exec(context1,"b = 3") -- error, b has not been defined trash = string_exec(context2,"integer b") -- error, b has already been defined trash = string_exec(context2,"b = 4") -- fine trash = string_exec(context1,"a = 5") -- fine trash = string_exec(context2,"b = a") -- sets b to 5
(I've used "trash" for clarity only, in general that sort of thing would be a terrible idea.)
The last line works because a context does not contain data but pointers to data blocks. Or we might want a WITH_CLONE flag to ensure that is not the case. It would make sense to automatically give contexts some (private) delete-routine-type and extra-reference-count-style handling. There would also no doubt be issues with shared or overlapping contexts being used by multiple threads, that are probably not very productive to get into just yet, given that we ain't got threads yet.
I am undecided whether lines 3 and 4 should scupper any attempts to carry on. At some level you must have a "clean compile", and it is not yet clear whether line 3 should scupper lines 4/5, because context2 is a derivative/extension of the now-invalidated context1 (and we did not specify WITH_CLONE anywhere).
Going somewhat beyond a 5-line example, a natural division might be to write the (largely static) gui logic as a host and the "business logic" in an entirely separate and dynamic string_exec context, obviously with an appropriate mechanism to retrieve items for display.
The one big obvious and compelling example that I somehow completely forgot about is a REPL.
Pete
