Local variables can't share names with commands/macros/functions in the dynamic context.

[sdilts]

When trying to use a name for a local variable that has the same name a command, macro, or dynamic function in the dynamic context, Carp doesn't overshadow that global variable or provide warnings. Changing the variable name to something else fixes the problem.

For example, you cannot use c as a variable name, as it is a function.

(let [c (car (list 1 2 3))]
     (list c))

= > invalid args to 'c' command

Issue #555 suggests we wrap the result in (quote ...) while using the REPL, which results in:

(quote (let [c (car (list 1 2 3))]
     (list c)))

= > ((command c))

If we use a variable name that is not a function, everything works fine:

(quote (let [foo (car 0 (list 1 2 3))]
     (list foo)))
=> (1)

This is the case for code run in the REPL and while compiling a file. If you place the following code into a file, then load it and look at test-val's value, you will see that the same thing occurs.

(defdynamic test-val (let [c (car (list 1 2 3))]
                        c))

You can try this with car, e, nthcdr, nthcar, etc. and a similar result occurs.

[sdilts]

Possibly related to #597

[hellerve]

I suspect this is also the root cause of the weird issues we’re seeing in #460.

As discussed in #555, we’ll have to rewrite the evaluator ina more principled manner; hopefully that will fix a bunch of these issues all at once.

[eriksvedang]

Nice find @sdilts! But yes, what @hellerve said. I'll leave this open though, as a reminder.

[eriksvedang]

Is this fixed now because of #695 being merged?

[hellerve]

It is not, because of the ordering of lookups still not being quite correct. The offending code block is this:

Carp/src/Eval.hs

Lines 44 to 64 in b63b940

	case lookupInEnv (SymPath ("Dynamic" : p) n) (contextGlobalEnv ctx) of
	Just (_, Binder _ found) -> return (ctx, Right (resolveDef found))
	Nothing ->
	if null p
	then
	case tryInternalLookup path of
	Just v -> return v
	Nothing -> tryLookup path
	else tryLookup path
	where tryInternalLookup path =
	case contextInternalEnv ctx of
	Nothing -> Nothing
	Just e ->
	case lookupInEnv path e of
	Just (_ , Binder _ found) -> Just (ctx, Right (resolveDef found))
	Nothing -> Nothing
	tryLookup path =
	case lookupInEnv path (contextGlobalEnv ctx) of
	Just (_, Binder _ found) -> return (ctx, Right (resolveDef found))
	Nothing ->
	return (evalError ctx ("Can't find symbol '" ++ show path ++ "'") i)

The lookup order matters, and currently its behavior is to first look for builtins. This could be changed, but it breaks other things, and we agreed in Gitter to postpone fixing this. I’m not sure what exactly broke anymore, sadly.

[eriksvedang]

OK, it's not a giant problem but I'll keep the issue open then.

[scolsen]

As @hellerve stated, this ultimately comes down to our lookup orders.

Ideally, preferring local environments before the Dynamic environment wouldn't cause any problems and could fix this issue. I'll give it a shot.

[scolsen]

I have a fix for this...but oddly it seems to make postwalk, and co. unacceptable performance wise. It doesn't seem to have any other effect, though.

[scolsen]

In particular, it makes the performance of walk-replace prohibitve and breaks the behavior of postwalk. Prewalk is strangely unaffected as are all other functions and test thus far—so the solution doesn’t account for an edge

[hellerve]

In particular, it makes the performance of walk-replace prohibitve and breaks the behavior of postwalk. Prewalk is strangely unaffected as are all other functions and test thus far—so the solution doesn’t account for an edge

Is this still the case with #1214?