On 2024-06-26 11:36, Maxime Devos wrote:

>>> (use-modules (system vm program)
>>>              (ice-9 eval-string))
>>>
>>> (eval-string "(define (test-fn) 'hey)"
>>>              #:file "hello.scm"
>>>              #:line 1
>>>              #:column 1
>>>              #:compile? #f)
>>>
>>> (format #t "~a\n" (program-sources test-fn))
>>> ;; ((0 ice-9/eval.scm 329 . 13) (12 ice-9/eval.scm 330 . 21) (44 ice-9/eval.scm 330 . 15))
>
>>What you are seeing here is that in general the debugging experience is
>> different for interpreted and compiled procedures.  For example, you
>> will not be able to set a breakpoint in interpreted code, because the
>> code for the closure that is part of `eval` corresponds to potentially
>> many different functions.  program-sources will only work usefully on
>> compiled procedures.
>>https://www.gnu.org/software/guile/manual/html_node/Compiled-Procedures.html.
>
> IIRC, the question wasn’t about debugging in general, it was about
> source locations in particular. Surely program-sources (or, in this
> case, procedure-source maybe?) (why are the procedures in this family
> even named program-whatever, this prevents doing the same for
> interpreted code later) could be adjusted to also work for ‘eval’. For
> example, ‘eval’ could set the ‘source’ (*) procedure property when a
> closure is made.
>
> Likewise for arity and procedure name.
>
> (*) Looking at
> https://www.gnu.org/software/guile/manual/html_node/Procedure-Properties.html,
> it appears the documentation doesn’t actually document what the
> ‘source’ property is for – It could be interpreted in multiple ways
> currently.
>
>>I would suggest that if you are working on a rich IDE, that you pass
>> #:compile? #t.  Nothing else will work as you like.

I do pass (use compile directly to be more precise) :) but there is
another very important problem related to this approach:
https://yhetil.org/guile-devel/20240621164008.eEg72C00D1xd29F01Eg7DF@baptiste.telenet-ops.be/T/#t

It also leads to problem with define-once, which sets the value to
#<unspecified> in most cases, when "evaluated" with compile.

>
> Something else will work as well: adjusting ‘eval’ to set procedure
> properties or something like that.

Agree with Maxime here, and that is what I propose in the original
message.

>> That said, the evaluator does attach so-called "meta-data" information
>> to procedures, such as the procedure name.
>> https://www.gnu.org/software/guile/manual/html_node/Procedure-Properties.html.
>> If you know that you are making a procedure you can insert some
>> meta-data for use by your run-time, in an initial vector alist.  See
>> https://www.gnu.org/software/guile/manual/html_node/Procedure-Properties.html.
>> But that's limited and doesn't take macros, etc into account.

Yep, that's is why I wrote:

--8<---------------cut here---------------start------------->8---
The another related problem is that the metainformation is stored in
prodecures properties, but not in variables, which makes it impossible
to implement a proper goto definition in general case.
--8<---------------cut here---------------end--------------->8---

How hard is to make a generic metainformation, which is attachable to
macros, symbols and other objects of the language, not only to
procedures?

>> That said, the evaluator does attach so-called "meta-data" information
>> to procedures, such as the procedure name.
>> https://www.gnu.org/software/guile/manual/html_node/Procedure-Properties.html.
>> If you know that you are making a procedure you can insert some
>> meta-data for use by your run-time, in an initial vector alist.  See
>> https://www.gnu.org/software/guile/manual/html_node/Procedure-Properties.html.
>> But that's limited and doesn't take macros, etc into account.
>
> That’s the job of ‘eval’, not the user of ‘eval’.

Think the same, eval should respect information provided by reader and
attach it to corresponding objects.

-- 
Best regards,
Andrew Tropin