From: Ryan McCormack
Subject: environment macros? (allegro CL)
Date: 
Message-ID: <m33d6uwtvt.fsf@ryan.dotcast.com>
Are there any built in macros to tell me a bit more about the
environment I make the macro call in, such as filename, line number,
function I am inside, etc..?

Thanks in advance.

From: Kent M Pitman
Subject: Re: environment macros? (allegro CL)
Date: 
Message-ID: <sfwae12zcmz.fsf@world.std.com>
Ryan McCormack <········@cis.ohio-state.edu> writes:

> Are there any built in macros to tell me a bit more about the
> environment I make the macro call in, such as filename, line number,
> function I am inside, etc..?

Well, first, a very small side point: You used the word "macros" in
the first line.  But such facilities would almost certainly be either
functions (that take an environment as an argument) or special forms
(that sense the environment directly), and not macros.

Second, not all code is from a file, and not all files are line-oriented.
It's important to know that the way Lisp works, programs don't have
to originate in files.  They might have been created structurally and
have no corresponding source code.  As to what function you are
inside, again, you might not be inside any function.   And even if they
were inside a function, the function's name would be only a historical
element; for example, what is the name of the function surrounding the
breakpoint in code below:

 (defun foo () (break "Stopped inside ~S" (the-function-i-am-in)))
 (setf (symbol-function 'bar) (symbol-function 'foo))
 (bar)

Are you in a breakpoint in FOO or in BAR?

That doesn't mean there couldn't be a way to ask whether it was created
in a file and whether such info was available.  Or that there couldn't be
a way to ask the name-for-debugging of the environment.  But there's a
limitation to what can be meaningfully done with that info, and one must
certainly not expect to find it.  The standard language does not
address this.  You'll have to ask your vendor.  Some vendors do keep
code correspondence tables, but I'd bet they vary widely in nature.

Vendor-related questions are best asked of your vendor, not of this
newsgroup.  Except in cases where your vendor is non-responsive or 
where you think your vendor might be wrong or something like that.
From: Ryan McCormack
Subject: Re: environment macros? (allegro CL)
Date: 
Message-ID: <m3pu9yv9wd.fsf@ryan.dotcast.com>
Kent M Pitman <······@world.std.com> writes:

> Well, first, a very small side point: You used the word "macros" in
> the first line.  But such facilities would almost certainly be either
> functions (that take an environment as an argument) or special forms
> (that sense the environment directly), and not macros.

I was thinking along the lines of GNU C's __LINE__ and __FILE__ macros.  

> Second, not all code is from a file, and not all files are line-oriented.
> It's important to know that the way Lisp works, programs don't have
> to originate in files.  They might have been created structurally and
> have no corresponding source code.  As to what function you are
> inside, again, you might not be inside any function.   And even if they
> were inside a function, the function's name would be only a historical
> element; for example, what is the name of the function surrounding the
> breakpoint in code below:
> 
>  (defun foo () (break "Stopped inside ~S" (the-function-i-am-in)))
>  (setf (symbol-function 'bar) (symbol-function 'foo))
>  (bar)
> 
> Are you in a breakpoint in FOO or in BAR?

I am only concerned with code coming from a file that is compiled.  
I want to be able to send out messages to a log that tell me where
these messages are coming from.  So in the above example, I only care
to know that I came from inside foo, I am at line 1, in file foo.cl.
I am looking for information that is more static in nature, which lead
me to believe a macro would be best suited for this kind of thing.
At compile time, the macro would just expand out to the current line
value. 
 
> Vendor-related questions are best asked of your vendor, not of this
> newsgroup.  Except in cases where your vendor is non-responsive or 
> where you think your vendor might be wrong or something like that.

I know this is a vendor related issue.. which is why I put allegroCL
in parens.  I couldn't find any documentation on their site regarding
such things.
From: Kaz Kylheku
Subject: Re: environment macros? (allegro CL)
Date: 
Message-ID: <cbge7.65373$B37.1489240@news1.rdc1.bc.home.com>
In article <··············@ryan.dotcast.com>, Ryan McCormack wrote:
>Kent M Pitman <······@world.std.com> writes:
>
>> Well, first, a very small side point: You used the word "macros" in
>> the first line.  But such facilities would almost certainly be either
>> functions (that take an environment as an argument) or special forms
>> (that sense the environment directly), and not macros.
>
>I was thinking along the lines of GNU C's __LINE__ and __FILE__ macros.  

These are ANSI C macros, not GNU specific, and you will probably be
burned for bringing them up. :) Nice knowing you, however briefly. ;)
From: Frode Vatvedt Fjeld
Subject: Re: environment macros? (allegro CL)
Date: 
Message-ID: <2hheva1ito.fsf@dslab7.cs.uit.no>
Ryan McCormack <········@cis.ohio-state.edu> writes:

> I was thinking along the lines of GNU C's __LINE__ and __FILE__
> macros.

The function COMPILE-FILE binds *compile-file-truename* and
*compile-file-pathname*, which you might find helpful.

-- 
Frode Vatvedt Fjeld
From: Christopher Stacy
Subject: Re: environment macros? (allegro CL)
Date: 
Message-ID: <ug0au5qg3.fsf@spacy.Boston.MA.US>
>>>>> On Tue, 14 Aug 2001 19:04:36 GMT, Kent M Pitman ("Kent") writes:
 Kent> Ryan McCormack <········@cis.ohio-state.edu> writes:
 >> Are there any built in macros to tell me a bit more about the
 >> environment I make the macro call in, such as filename, line number,
 >> function I am inside, etc..?

 Kent> Vendor-related questions are best asked of your vendor, not of this
 Kent> newsgroup.  Except in cases where your vendor is non-responsive or 
 Kent> where you think your vendor might be wrong or something like that.

Or if you're a newbie to Lisp and you do not yet know if what you're
asking is an implementation-specific question!