[<<][staapl][>>][..]

Sun Aug 19 17:41:15 CEST 2007

eliminating global path variable

to be able to eliminate the path state, i probably need dynamic
variables (parameters).

is this cheating?

not really.. since i'm using with-output-file already, and that
doesn't really feel like cheating.

this would also solve the problem with IO of course.. still i'm not
convinced it's not cheating..

one could say it's not cheating because the value has finite extent?
so why not implement monads as dynamic variables? because dynamic
variables are not referentially transparent, which you would want when
you 'run' a monad: it should still act just on the state provided, not
on something else...

so why are parameters different then? are they less evil when they are
constant? they represent 'context'.

* one thing is sure: they are less evil than global variables due to
  limited extent.

* if they are constants, they are less evil than when they are not

To really answer the question is to implement dynamic variables with
monads, and see how they are different. The problem i'm facing in my
ad-hoc state hiding approach is that i can't combine monads:

When i'm running something in the macro monad, i can't access anything
else. To have access to path, the monad should be bigger and include
'compilation context'.

The real solution is of course to make compilation independent of file
system access. Source code needs a preprocessing step that expands all
include' statements. Since it's only one keyword, this can be
implemented in the forth-load function. That function already
implements 'file system dereference', so why not include path
searching?

Ok, made it so. 'load' is now a load-time word so file system access
is concentrated in one point. 'path' is removed: this needs to be
specified in the state file, because it really is a meta-command.

[Reply][About]

[<<][staapl][>>][..]