Re: Unbound variables used within a form

[Panicz Maciej Godek]

2012/10/13 Mark H Weaver <address@hidden>:

> FYI, the standard term for these are "free variables"

I thought about this, but then I thought that it could
cause some confusion, as any variable that isn't bound
in a formula can be considered free (even the one that
does not appear in the formula) -- at least that's what
I recall from my course in logic. But if there's no actual
ambiguity, I can use that term, of course :)

>> I just wanted to ask:
>> - beside lambda*, case-lambda, case-lambda*,
>> are there any additional extensions that guile introduced
>> atop the Report that should be taken into account in this code?
>
> You also need to handle 'with-fluids'.

Thanks, I will take it into account :)

>> - is there any simpler way to achieve the same effect, ie.
>> to acquire all external symbols that are meaningful within
>> a form (assuming the core semantics, that is, that all
>> the macros were expanded)
>
> First of all, it would be much simpler if you traversed the tree-il
> directly, instead of decompiling the tree-il to scheme.  Take a look at
> module/language/tree-il.scm and module/language/tree-il/*.scm for
> details and examples of how to traverse and analyze tree-il.
>
> In tree-il, you wouldn't have to recognize bound variables and remove
> them from the list.  The macro expander already does that job, and
> specifically marks each variable reference by its type:
> (1) <toplevel-ref> or <toplevel-set> for top-level variables,
> (2) <module-ref> or <module-set> for variables in a different module,
> (3) <lexical-ref> or <lexical-set> for non-toplevel variables, and
> (4) <primitive-ref> for selected primitives.  You could simply scan for
> these, discarding the lexicals.

Thanks a lot! I think that this is what I've been looking for.
(It's horrible when the same functionality is implemented twice for
the same program)

> If you still prefer to work with scheme sexps, then there are some
> options you can pass to the tree-il->scheme decompiler that will make
> your job easier.
[...]
> In combination, these two options will allow you to eliminate the
> following cases from your code:

>>     (('@@ name ...)
>>      '())
>
> You need to handle both '@@' and '@', and you cannot simply ignore them.

I just thought about a silly optimization, but I guess you're right :]
(I mean, in my context it seems to work, but I see that it generally
isn't the case)

> Having said all this, I think that you are taking very much the wrong
> approach to how to save the code in your GUI development system.  Any
> programming system needs to work with the *source* code, which means
> "the preferred form for making changes".  In Scheme, that means the
> source code before *any* compilation has taken place, even macro
> expansion.
>
> If you are working with code after macro expansion has taken place, then
> you've already lost many of the key advantages of Scheme.  For example,
> macro expansion turns a simple record type definition into a relatively
> complex set of procedure definitions, which includes internal
> implementation details that may change in future versions of Guile.
[...]
> I would strongly encourage you to adopt a model where your development
> system maintains and manipulates its own copy of the user's source code,
> rather than trying to reconstruct the code from Guile's internal data
> structures.  That way lies madness.

Actually, I am taking a hybrid approach. The above function is needed
to elliminate unnecessary variables that are introduced to the lexical
context on function source re-generation. The source stored in the
procedure property list is left unexpanded, and therefore
human-readable.

The concept of the system I'm working on is still unclear, even to me
-- I only have a few rough ideas. In a way it's meant to be minimal,
as I don't want to devote too much time to create a big system that
would be thrown to trash afterwards. My main development decision is
to avoid making development decisions, or at least to put them off for
as long as I can. Everything can be redesigned eventually, once the
proper idea of what I am doing is found. The sollution I took has two
main advantages: it (apparently) works and is interesting to
implement.
And speaking of madness, isn't lisp programming about coming up with
clever ways to misuse a computer? ;]

Thank you for a very informative response! :)
M