Re: global constants (was: re-using comma ...)

On Wed, 22 Oct 2008, Yann LeCun wrote:

> I think there is a semantic difference between accessing
> a global variable and accessing a constant. When accessing
> a global variable, you are supposed to get the value
> of the variable at the time of execution, not at the
> time of compilation.

Yes.

> That's why there is a syntactic
> difference between constants and global variables.

But the syntactic difference ought to be in the declaration
of the object. I.e., defvar & defparameter vs. defconstant.

> Allowing the access of global variables at compile time
> as you suggest is likely to cause a lot of confusion
> and hard-to-find bugs.

Yes, that would be a problem.

> It would introduce yet another
> situation in which compiled code and interpreted code do
> different things

That's the situation we have now with the @-mechanism, though.

The cleanest thing to do then seems to be, for now, to only
accept global variables as constants that were declared with
defconstant (and to issue an error for all others). In Lush2
defconstant-declared bindings are locked, so they really are
constants on the interpreter side as well.

Ralf



> (it's already the case because of
> dynamic vs lexical binding for local variables).
> That's why I think it's best to keep the difference explicit.
>
>  -- Yann
>
> On Wednesday 22 October 2008, Ralf Juengling wrote:
>> I think we are not quite on the same page. Here is what I mean:
>>
>> (defparameter ag 1)
>> (defparameter bg 2)
>> (defconstant  cg 3)
>>
>> (defun myfun (b)
>>    (declare (-double-) b)
>>    (let ((bg b))
>>      (+ ag bg cg) ))
>>
>> (dhc-make ()
>>            myfun)
>>
>> This will not compile in Lush, because the compiler cannot
>> create code that would access global variables at runtime.
>>
>> But often all you want is using a symbol for a constant
>> value. So you may add (libload "libc/constants") and change
>> myfun to read
>>
>> (defun myfun (b)
>>    (declare (-double-) b)
>>    (let ((bg b))
>>      (+ @ag bg @cg) ))
>>
>> The @-macro character fetches the value of ag and cg,
>> respectively, at compile time (or at runtime if you don't
>> compile). All I'm saying is: that is something the
>> compiler might as well do, we don't need to use a special
>> macro character for this. E.g., here is how looks after a
>> little modification of the compiler when compiling the
>> above code:
>>
>> ? (libload "compiling-constants.lsh")
>>      [compiling-constants.lsh]
>> Preprocessing and parsing myfun ...
>> *** Warning: Treating global variable 'ag' as constant.
>> ***          Declare with 'defconstant' to eliminate this warning.
>> Generating C for myfun ...
>> gcc -DHAVE_CONFIG_H   -std=c99 -DNO_DEBUG -Wall -O3 -march=i686 -mmmx
>> -msse -pthread -I /u/juenglin/include
>> -I/u/juenglin/projects/lush2-tinyat/include -I/usr/include/freetype2 -c
>> /u/juenglin/src/lsh/C/compiling_constants.c -o
>> /u/juenglin/src/lsh/C/i686-pc-linux-gnu/compiling_constants.o
>> = "/u/juenglin/src/lsh/compiling-constants.lsh"
>> ? (myfun 2)
>> = 6
>> ? (myfun 12)
>> = 16
>> ?
>>
>> Note the warning, we may turn it into an error if desirable.
>>
>> Accessing global lisp variables from compiled code is a
>> different matter. I think it's possible but requires much
>> more work.
>>
>> So, are there any good reasons for keeping @ or @@?
>>
>> Ralf
>>
>> On Tue, 21 Oct 2008, Yann LeCun wrote:
>>> Reading global variables would be nice, but @ and @@
>>> serve a different purpose. They are more akin to #define
>>> in C/C++.
>>>
>>> Reading global vars from compiled code is actually not easy.
>>> At least, I have no idea how to implement that cleanly.
>>>
>>>  -- Yann
>>>
>>> On Tuesday 21 October 2008, Ralf Juengling wrote:
>>>> On Tue, 21 Oct 2008, Yann LeCun wrote:
>>>>> I'd try to avoid non-backward compatible changes that
>>>>> make the documentation more complicated.
>>>>
>>>> Ok. I think we should at least deprecate the current use of
>>>> @ and fix the compiler so that it sees lisp global variables.
>>>> That will also simplify the documentation. ;-)
>>>>
>>>> Ralf
>>>>
>>>> ------------------------------------------------------------------------
>>>> - This SF.Net email is sponsored by the Moblin Your Move Developer's
>>>> challenge Build the coolest Linux based applications with Moblin SDK &
>>>> win great prizes Grand prize is a trip for two to an Open Source event
>>>> anywhere in the world
>>>> http://moblin-contest.org/redirect.php?banner_id=100&url=/
>>>> _______________________________________________
>>>> Lush-devel mailing list
>>>> [email protected]
>>>> https://lists.sourceforge.net/lists/listinfo/lush-devel
>>>
>>> -------------------------------------------------------------------------
>>> This SF.Net email is sponsored by the Moblin Your Move Developer's
>>> challenge Build the coolest Linux based applications with Moblin SDK &
>>> win great prizes Grand prize is a trip for two to an Open Source event
>>> anywhere in the world
>>> http://moblin-contest.org/redirect.php?banner_id=100&url=/
>>> _______________________________________________
>>> Lush-devel mailing list
>>> [email protected]
>>> https://lists.sourceforge.net/lists/listinfo/lush-devel
>
>
>
>

-------------------------------------------------------------------------
This SF.Net email is sponsored by the Moblin Your Move Developer's challenge
Build the coolest Linux based applications with Moblin SDK & win great prizes
Grand prize is a trip for two to an Open Source event anywhere in the world
http://moblin-contest.org/redirect.php?banner_id=100&url=/