Macro expander bug

Hi,

I tried to load the package defs from SSAX and it killed the macro expander.
It appears that when BIND-ALIASES was switched to the new cenv
representation it stopped including macro eval in the cenvs it generated,
and SSAX touches it somehow, causing a (force #f).

I put up a one-line patch to BIND-ALIASES so that it includes macro eval, as
it did before, at https://bitbucket.org/wnoble/s48. However, I don't know
exactly how SSAX triggers the access and didn't try too hard to come up with
a simple macro to reproduce the faulty expansion. So, if someone would
explain whether this is the correct fix, and why or why not, I would be
grateful!

And Mike: thanks for integrating my POSIX patch!

Best,
Will

Re: Macro expander bug

Will Noble <will <at> cow9.org> writes:

> Hi,
>
> I tried to load the package defs from SSAX and it killed the macro expander.
> It appears that when BIND-ALIASES was switched to the new cenv
> representation it stopped including macro eval in the cenvs it generated,
> and SSAX touches it somehow, causing a (force #f).
>
> I put up a one-line patch to BIND-ALIASES so that it includes macro eval, as
> it did before, at https://bitbucket.org/wnoble/s48. However, I don't know
> exactly how SSAX triggers the access and didn't try too hard to come up with
> a simple macro to reproduce the faulty expansion. So, if someone would
> explain whether this is the correct fix, and why or why not, I would be
> grateful!

I've pulled & pushed the change - thanks!  I'm reluctant to get into the
old macro expander, which has many bugs. One of these days, I'll finish
up the new one started at:

http://www.s48.org/cgi-bin/hgwebdir.cgi/s48-syntax-case/

--

-- 
Cheers =8-} Mike
Friede, Völkerverständigung und überhaupt blabla

Reading primitive procedures

Re: Reading primitive procedures

Frank Lay asked:

> > (read)
> 1 +
> 1
> #{Procedure 93 +}
> 
> Why [...] is the input '+' read as a procedure

When you hit enter after the +  the READ call eats the first datum
and returns the corresponding value, the number 1.
Then the REPL reads and evaluates the second datum, +.
I.e. you did basically the same as

  > (read)
  1
  > +
  #{Procedure 93 +}

In the words of the R5RS,

  READ returns the next object parsable from the given input port,
  updating port to point to the first character past the end
  of the external representation of the object.

> I don't understand how to 'unsymbolise' a symbol into its corresponding procedure.

Have a look at the EVAL procedure, the E in REPL, as in

  (eval '+ (scheme-report-environment 5))

Alternatively & depending on your plans, you could evaluate function symbols yourself,
e.g. map yourself the symbol '+  to the procedure +.

Disclaimer: I am not up to date as to the conformance of s48 with R*RS.

rt

Changeset 0306c5a64775

What is changeset 0306c5a64775 intended to do?

Robert Ransom

Re: Changeset 0306c5a64775

If I'm looking at the right revision, it's to allow the use of wait()
without triggering deadlock detection

-Roderic

On Fri, Dec 30, 2011 at 10:28 PM, Robert Ransom <rransom.8774 <at> gmail.com> wrote:
> What is changeset 0306c5a64775 intended to do?
>
>
> Robert Ransom
>

Re: Changeset 0306c5a64775

On 2011-12-31, Roderic Morris <roderyc <at> gmail.com> wrote:
> If I'm looking at the right revision, it's to allow the use of wait()
> without triggering deadlock detection

It might do that, but it breaks get-address-info from the
net-addresses package (which (ab)uses external-event UIDs in the same
way).  See attached for a script that hangs S48.  (I was expecting the
call to get-address-info to dislodge another of the debug-message
calls, but it just wedged instead.)

Robert Ransom

Re: Changeset 0306c5a64775

On 2011-12-31, Robert Ransom <rransom.8774 <at> gmail.com> wrote:
> See attached for a script that hangs S48.

Oops.  This time it's really attached.

Robert Ransom

Re: Changeset 0306c5a64775

Right, I noted that and had a similar example when I submitted the patch.

The external-events package doesn't work as advertised, but I couldn't
figure out how to fix it. It's really the only mechanism that can be
used to do both library calls correctly though.

-Roderic

On Sat, Dec 31, 2011 at 6:01 AM, Robert Ransom <rransom.8774 <at> gmail.com> wrote:
> On 2011-12-31, Roderic Morris <roderyc <at> gmail.com> wrote:
>> If I'm looking at the right revision, it's to allow the use of wait()
>> without triggering deadlock detection
>
> It might do that, but it breaks get-address-info from the
> net-addresses package (which (ab)uses external-event UIDs in the same
> way).  See attached for a script that hangs S48.  (I was expecting the
> call to get-address-info to dislodge another of the debug-message
> calls, but it just wedged instead.)
>
>
> Robert Ransom