Re: libc.lsh

On Fri, 31 Jul 2009, Yann LeCun wrote:

> Leon introduced the constants mechanism to avoid crowding the
> namespace, because constants extracted from a C header may
> clash uncontrolably with existing symbols.
>
> Also, @ and @@ are different. @@ evaluates at read time (like #.)
> whereas @ evaluates at compile time. It's not entirely clear that
> we absolutely need both, but they are different.

I think we don't need either read macro anymore.

The compiler, when encountering a symbol that has not been
declared as a local variable or function argument, looks
for global definitions. When the symbol is globally bound,
it will be evaluated at compile time and the value taken
as a constant. (If you had not used defconstant to declare
the global variable, you will be warned by the compiler.)
This is basically the former behavior that of '@xyz'.

For read-time evaluation there is #. .

There currently is no read-macro for compile-time
evaluation of forms in lush2 (what you could do with
'@(foo ...)' before). But I have only seen very few uses
of this. And in all cases I have seen foo was some kind
of constant arithmetic expression. One might as well leave
it to the C-compiler to optimize.


As for name clashes, that is good point. But name
clashes are not a problem specific to compilation, or
to importing names from headers. It's a more general
problem and the namespace facility in lush2 is a
general solution. To avoid name clashes you would place
all constant definitions in a project-specific namespace
and do the compilation in that namespace.


So, updating the code in files that currently do
(libload "libc/constants")
typically mounts to removing all occurrencs of '@' and
updating the defconstant declarations. I finally updated
the opengl interface today, if you want to see an example.

Cheers,
Ralf







>
>  -- Yann
>
>
> On Friday 31 July 2009, Ralf Juengling wrote:
>> Some definitions in libc.lsh might be problematic because
>> memory management had changed (malloc & free), and most
>> others were redundant. @ and @@ as they were defined in
>> libc/constants was unecessary, I thought (why limit your
>> namespace, especially if there are better ways ?).
>> For both situations there are alternatives--just use
>> defconstant and #. for read-time evaluation, as in
>> common lisp.
>>
>> I removed those files so that it is clear which files I
>> still need to update and what to look for.
>>
>> Ralf
>>
>> On Fri, 31 Jul 2009, Yann LeCun wrote:
>>> Hi Ralf,
>>>
>>> Any good reason for not removing libc.lsh and constants.lsh
>>> from Lush2 in lsh/libc?
>>>
>>> SDL and a whole bunch of other packages use them.
>>>
>>> Is there another to do the same thing on Lush2?
>>>
>>>  -- Yann
>>>
>>>
>>>
>>> -------------------------------------------------------------------------
>>> ----- Let Crystal Reports handle the reporting - Free Crystal Reports 2008
>>> 30-Day trial. Simplify your report design, integration and deployment -
>>> and focus on what you do best, core application coding. Discover what's
>>> new with Crystal Reports now.  http://p.sf.net/sfu/bobj-july
>>> _______________________________________________
>>> Lush-devel mailing list
>>> [email protected]
>>> https://lists.sourceforge.net/lists/listinfo/lush-devel
>
>
>

------------------------------------------------------------------------------
Let Crystal Reports handle the reporting - Free Crystal Reports 2008 30-Day 
trial. Simplify your report design, integration and deployment - and focus on 
what you do best, core application coding. Discover what's new with 
Crystal Reports now.  http://p.sf.net/sfu/bobj-july