bug#17096: Guile 1.8: syntax-case messed up when "void" is defined

bug#17096: Guile 1.8: syntax-case messed up when "void" is defined

[David Kastrup]

[-- Attachment #1: Type: text/plain, Size: 37 bytes --]


When running the following program


[-- Attachment #2: baba.scm --]
[-- Type: text/plain, Size: 136 bytes --]

(define void 6)
(use-modules (ice-9 syncase))
(define-syntax absurd
  (lambda (x)
    (syntax-case x ()
      ((_ var) (syntax var)))))

[-- Attachment #3: Type: text/plain, Size: 446 bytes --]


through Guile 1.8, I get the error

ERROR: Wrong type to apply: 6

The same appears to go through without problem (apart from the
deprecation warning for the module) on Guile 2.0.

Is there any workaround?  Apart from the obvious "don't define void"
which is not a good option for the actual application at hand since the
function is part of a user-level API.  And it's not like "void" is
documented as being anything here...

-- 
David Kastrup

bug#17096: Guile 1.8: syntax-case messed up when "void" is defined

[Mark H Weaver]

David Kastrup <dak@gnu.org> writes:

> When running the following program
>
> (define void 6)
> (use-modules (ice-9 syncase))
> (define-syntax absurd
>   (lambda (x)
>     (syntax-case x ()
>       ((_ var) (syntax var)))))
>
> through Guile 1.8, I get the error
>
> ERROR: Wrong type to apply: 6
>
> The same appears to go through without problem (apart from the
> deprecation warning for the module) on Guile 2.0.
>
> Is there any workaround?  Apart from the obvious "don't define void"
> which is not a good option for the actual application at hand since the
> function is part of a user-level API.  And it's not like "void" is
> documented as being anything here...

It would be good if Andy or Ludovic would chime in here, because my
knowledge of Guile 1.8 is extremely limited, and frankly I have no
interest in learning more about this obsolete version of Guile.

However, I looked at the implementation of syntax-case in Guile 1.8.8
and in short, I think you're stuffed.

IIUC, the implementation freely inserts references to 'void' in the
expanded code, on the assumption that (void) will return the unspecified
value.  Unlike the version in Guile 2, this version of psyntax is not
integrated with Guile's module system, and the inserted top-level
references do not refer to 'void' from the (ice-9 syncase) module, but
rather from whatever module happens to be current when the expansions
are done.

At first I thought of monkey-patching the 'chi-void' procedure, which
produces these references, but alas it is not a top-level procedure, but
rather an internal one.

I'm afraid the best suggestion I can think of is to make your own local
copy of ice-9/syncase.scm and ice-9/psyntax.pp, under different
filenames and module names, to be used only when built with Guile 1.8.
In these files, make the following changes (assuming for now that you
name them scm/old-syncase.scm and scm/old-psyntax.pp):

* In old-syncase.scm, change the two occurrences of "void" to "%void".
* In old-syncase.scm, change "ice-9/psyntax.pp" to "scm/old-psyntax.pp".
* In old-psyntax.scm, change the only occurrence of "(quote void)"
  to "(quote %void)".

* Where you need to import syncase, do it as follows:
  (cond-expand (guile-2) (guile (use-modules (scm ly-syncase))))

* Drop support for Guile 1.8 in the first version of LilyPond that
  supports Guile 2.0, so you can clear out the horrible workarounds
  and compatibility cruft.

I'm sorry I don't have a better answer for you, and I realize that
LilyPond is in a very uncomfortable position w.r.t. Guile.  I'll try to
find some time in the next few months to help more with the porting
effort.

     Regards,
       Mark

bug#17096: Guile 1.8: syntax-case messed up when "void" is defined

[David Kastrup]

Mark H Weaver <mhw@netris.org> writes:

> David Kastrup <dak@gnu.org> writes:
>
>> When running the following program
>>
>> (define void 6)
>> (use-modules (ice-9 syncase))
>> (define-syntax absurd
>>   (lambda (x)
>>     (syntax-case x ()
>>       ((_ var) (syntax var)))))
>>
>> through Guile 1.8, I get the error
>>
>> ERROR: Wrong type to apply: 6
>>
>> The same appears to go through without problem (apart from the
>> deprecation warning for the module) on Guile 2.0.
>>
>> Is there any workaround?  Apart from the obvious "don't define void"
>> which is not a good option for the actual application at hand since the
>> function is part of a user-level API.  And it's not like "void" is
>> documented as being anything here...
>
> However, I looked at the implementation of syntax-case in Guile 1.8.8
> and in short, I think you're stuffed.

Well, ok.  I thought this would be a nice thing to use syntax-case for,
but it would have been a first in the LilyPond code base (and obviously
no users of LilyPond have used anything but procedural macros so far, or
we'd have heard complaints).

> I'm afraid the best suggestion I can think of is to make your own
> local copy of ice-9/syncase.scm and ice-9/psyntax.pp, under different
> filenames and module names, to be used only when built with Guile 1.8.

Not going to do that.  I'll just use something else.  And it's
conceivable that stuff would work when placed into LilyPond's internals
before the user-level "void" is loaded.  But it's probably a bad idea
for maintenance to use features that cannot sensibly be
debugged/tested/used outside of LilyPond's internals since that means no
LilyPond users/programmers can become well-acquainted with them.

> * Drop support for Guile 1.8 in the first version of LilyPond that
>   supports Guile 2.0,

Guile 2.0 is pretty much ubiquitous by now, so we will not have to
support multiple versions.  We'll be able to more or less do a hard cut
here once Guile 2.0 is supported in an acceptable manner.

> so you can clear out the horrible workarounds and compatibility cruft.
>
> I'm sorry I don't have a better answer for you, and I realize that
> LilyPond is in a very uncomfortable position w.r.t. Guile.  I'll try
> to find some time in the next few months to help more with the porting
> effort.

Well, at least Guile 2.0.10 has been released recently with the fix to
the curried definitions, so we can expect those to be available for
builds from distributions sometime this fall.

Redefinitions in LilyPond itself have proven infeasible since they
clashed with the module system, leading to warnings about definitions
stemming from different modules.

For similar reasons, most hot-patches of Guile will not be feasible
unless we hot-patch the module system as well.

-- 
David Kastrup

bug#17096: Guile 1.8: syntax-case messed up when "void" is defined

[Mark H Weaver]

tags 17096 wontfix
close 17096
thanks

David Kastrup <dak@gnu.org> writes:

> Mark H Weaver <mhw@netris.org> writes:
>
>> However, I looked at the implementation of syntax-case in Guile 1.8.8
>> and in short, I think you're stuffed.
>
> Well, ok.  I thought this would be a nice thing to use syntax-case for,
> but it would have been a first in the LilyPond code base (and obviously
> no users of LilyPond have used anything but procedural macros so far, or
> we'd have heard complaints).

Okay.

>> * Drop support for Guile 1.8 in the first version of LilyPond that
>>   supports Guile 2.0,
>
> Guile 2.0 is pretty much ubiquitous by now, so we will not have to
> support multiple versions.  We'll be able to more or less do a hard cut
> here once Guile 2.0 is supported in an acceptable manner.

Sounds good.

> Redefinitions in LilyPond itself have proven infeasible since they
> clashed with the module system, leading to warnings about definitions
> stemming from different modules.

FWIW, you can avoid those warnings by using '#:replace' to export
definitions that are expected to conflict.  See
ice-9/curried-definitions.scm for an example.

Alternatively, as noted in the manual:

  A ‘#:replace’ clause is equivalent to ‘(export! LIST)’
  in the module body.

     Mark