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

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. That's why there is a syntactic
difference between constants and global variables.
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.  It would introduce yet another
situation in which compiled code and interpreted code do
different things (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=/