srfe records in reworked match

srfe records in reworked match

[Stefan]

> Ok, I put the files in a tar directory and published it at
> http:///c-lambda.se/match.tar.gz
> 
> Should we make a more thorough test suite?
> 
> /Stefan
> 
> On Apr 28, 2010, at 10:40 AM, Ludovic Courtès wrote:
> 
>> Hi Stefan,
>> 
>> Thanks for the good news!  :-)
>> 
>> stefan <stefan.tampe@spray.se> writes:
>> 
>>> How to proceed?
>> 
>> Can you post your code somewhere?  (Could be by email.)
>> 
>> If it’s based on Alex Shinn’s match, can you show the diff?  It would
>> also be nice to get in touch with him to have him integrate your
>> changes, possibly using ‘(cond-expand (guile-2 ....))’ for the
>> Guile-specific bits.
>> 
>> Thanks!
>> 
>> Ludo’.
>> 
>> 
>> 
> 

Re: srfe records in reworked match

[Ludovic Courtès]

Hi Stefan,

Sorry for the delay.

Stefan <stefan.tampe@spray.se> writes:

>> Ok, I put the files in a tar directory and published it at
>> http:///c-lambda.se/match.tar.gz

Cool, thanks!

So you started from Shinn’s latest match.scm, backported record-related
stuff from its match-cond-expand.scm, and added Guile-specific record
handling, is that right?

Did you get in touch with him?

>> Should we make a more thorough test suite?

More thorough than what?  Than ‘examples.scm’ if your tarball?

IMO most of this work ought to be done upstream (i.e., in collaboration
with Alex Shinn), so that it benefits most people.  Then we just need a
thin layer to integrate it in Guile (e.g., have the test suite use
Guile’s test-suite library.)

What do you think?

Thanks,
Ludo’.

Re: srfe records in reworked match

[Stefan]

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


On May 3, 2010, at 2:38 PM, Ludovic Courtès wrote:

> Hi Stefan,
> 
> Sorry for the delay.

No problem, let's not stress and have fun instead.

> Stefan <stefan.tampe@spray.se> writes:
> 
>>> Ok, I put the files in a tar directory and published it at
>>> http:///c-lambda.se/match.tar.gz
> 
> Cool, thanks!
> 
> So you started from Shinn’s latest match.scm, backported record-related
> stuff from its match-cond-expand.scm, and added Guile-specific record
> handling, is that right?
> 
> Did you get in touch with him?

I started with the suggested code, I also found a email associated with that
homepage and emailed to it. I'm still waiting for a response.

>>> Should we make a more thorough test suite?
> 
> More thorough than what?  Than ‘examples.scm’ if your tarball?

Yep! I was thinking of going through the list of features and make sure they 
all work.

> IMO most of this work ought to be done upstream (i.e., in collaboration
> with Alex Shinn), so that it benefits most people.  Then we just need a
> thin layer to integrate it in Guile (e.g., have the test suite use
> Guile’s test-suite library.)
> 
> What do you think?

I agree, it is most beneficial to make this portable.

> Thanks,
> Ludo’.
> 


Cheers

/Stefan


[-- Attachment #2: Type: text/html, Size: 2316 bytes --]

Re: srfe records in reworked match

[Ludovic Courtès]

Howdy!

Stefan <stefan.tampe@spray.se> writes:

> No problem, let's not stress and have fun instead.

:-)

>> Stefan <stefan.tampe@spray.se> writes:
>> 
>>>> Ok, I put the files in a tar directory and published it at
>>>> http:///c-lambda.se/match.tar.gz
>> 
>> Cool, thanks!
>> 
>> So you started from Shinn’s latest match.scm, backported record-related
>> stuff from its match-cond-expand.scm, and added Guile-specific record
>> handling, is that right?
>> 
>> Did you get in touch with him?
>
> I started with the suggested code,

Which one?  :-)

> I also found a email associated with that homepage and emailed to
> it. I'm still waiting for a response.

Cool.

Thanks,
Ludo’.

Re: srfe records in reworked match

[stefan]

On Monday 03 May 2010 03:51:27 pm Ludovic Courtès wrote:
> > I started with the suggested code,
> 
> Which one?  :-)
> 

The newest without a record implementation.

/Stefan

srfe records in reworked match

[stefan]

Ok,

I have started to code in some record recognition into the match construct

I need first to make sure that I grok the intention of the syntax!

Now, one can do ...

* (define rtf      (make-record-type "n" '(x y z)))
* (define make-n   (record-constructor rtf))
* (define v        (make-n 1 2 3))
* (define g        (record-accessor rtf 'x))
* (define s        (record-modifier rtf 'x))

* (match v ((= g 1) 'yes))    ;; This is the old behavior
yes

;; = allow for a getter and setter argument so that we can do ...
* (match v ((= (g s) (and (set! x.set) 
*			  (get! x.get) 
*			  1)) 
*	    (begin (x.set 2) 
*		   (x.get))))
2

;;Now the $ syntax work, although a lot of unpacking of accessors and 
modifiers
;;are done dynamically and not at compile time.
* (match v (($ rtf x 2 3) x))
2

* (match v (  ($ rtf 
*		 x 
*		 (and (set! y.set) 
*		      (get! y.get)) 
*		 3) 
*	    (begin (y.set 4) 
*		   (+ x (y.get)))))
6

It's recursive.

Not solid yet though, need to make sure that variables can be extracted
correctly from $ and =
/Stefan

Re: srfe records in reworked match

[Ludovic Courtès]

Hello Stefan,

stefan <stefan.tampe@spray.se> writes:

> I have started to code in some record recognition into the match construct

Excellent!  :-)

Are you hacking Wright’s match as currently in Guile or Alex Shinn’s
rewrite from <http://synthcode.com/scheme/>?

> I need first to make sure that I grok the intention of the syntax!

Do the comments in (ice-9 match) and the examples in the paper that in
match.tar.gz at
<http://www.cs.indiana.edu/scheme-repository/code.match.html> help?

You could ask on comp.lang.scheme too.  :-)

> Now, one can do ...
>
> * (define rtf      (make-record-type "n" '(x y z)))
> * (define make-n   (record-constructor rtf))
> * (define v        (make-n 1 2 3))
> * (define g        (record-accessor rtf 'x))
> * (define s        (record-modifier rtf 'x))

FWIW I’d really prefer if it could work with SRFI-9 (which is purely
syntactic, so there’s no run-time record type descriptor) rather than
with Guile’s records (as above).

> * (match v ((= g 1) 'yes))    ;; This is the old behavior
> yes
>
> ;; = allow for a getter and setter argument so that we can do ...
> * (match v ((= (g s) (and (set! x.set) 
> *			  (get! x.get) 
> *			  1)) 
> *	    (begin (x.set 2) 
> *		   (x.get))))
> 2
>
> ;;Now the $ syntax work, although a lot of unpacking of accessors and 
> modifiers
> ;;are done dynamically and not at compile time.
> * (match v (($ rtf x 2 3) x))
> 2

I think it should be:

  (match v (($ n x 2 3) x))

The original API assumes that when ‘n’ appears as the record-type above,
then there exists a type predicate called ‘n?’, a procedure called ‘n-x’
to access the ‘x’ field, etc.

> * (match v (  ($ rtf 
> *		 x 
> *		 (and (set! y.set) 
> *		      (get! y.get)) 
> *		 3) 
> *	    (begin (y.set 4) 
> *		   (+ x (y.get)))))
> 6
>
> It's recursive.

OK.

So would the following work?

  (define x (make-n 1 2 (make-n (3 4 (make-n 5 6 7)))))
  (match x
    (($ n x y ($ n p q ($ n a b c)))
     (list a b c p q x y)))

As noted in Shinn’s match-cond-expand.scm, this record matching form is
not ideal:

  ;; Annoying unhygienic record matching.  Record patterns look like
  ;;   ($ record fields...)
  ;; where the record name simply assumes that the same name suffixed
  ;; with a "?" is the correct predicate.

Thanks!

Ludo’.

Re: srfe records in reworked match

[Ludovic Courtès]

Hi,

[Keeping the list CC’d.]

Stefan <stefan.tampe@spray.se> writes:

> Question? should we make it lean and just allow sfri-9 or perhaps
> allow for both styles of records?

Actually, record matching in Wright’s match assumes users follow a
simple naming convention for the type predicate (only for the type
predicate in fact, not for accessors as I thought before.)

Then it also assumes to be able to access record fields directly (e.g.,
with (struct-ref x n)), not through field accessors.  This part is in
theory specific to a given record implementation, though in practice
Guile’s records and SRFI-9 implementations can both be accessed as raw
structs with zero-indexed fields:

--8<---------------cut here---------------start------------->8---
scheme@(guile-user)> (eq? (struct-ref (current-module) 0) (module-obarray (current-module)))
$2 = #t
scheme@(guile-user)> (use-modules (srfi srfi-9))
scheme@(guile-user)> (define-record-type foo (make-foo x y) foo? (x foo-x)(y foo-y))
scheme@(guile-user)> (let ((x (make-foo 'x 'y))) (eq? (foo-x x) (struct-ref x 0)))
$3 = #t
--8<---------------cut here---------------end--------------->8---

(Guile also has other record types: SRFI-35 error conditions, GOOPS
objects, and R6RS records, which Julian recently implemented in the
‘wip-r6rs-libraries’ branch.  There might be others floating around, who
knows.  ;-))

[...]

>> As noted in Shinn’s match-cond-expand.scm, this record matching form is
>> not ideal:
>> 
>>  ;; Annoying unhygienic record matching.  Record patterns look like
>>  ;;   ($ record fields...)
>>  ;; where the record name simply assumes that the same name suffixed
>>  ;; with a "?" is the correct predicate.
>> 
>> Thanks!
>> 
>> Ludo’.
>
> Exactly what do you mean by unhygien.

(The excerpt above is by Alex Shinn.)

It’s unhygienic in the sense that it introduces a reference to a binding
that is to be looked up at the point where the macro is expanded, and
which may or may not be bound.

(See <http://en.wikipedia.org/wiki/Hygienic_macro> for an intro on this
topic.)

Right below, Shinn writes:

  ;; Why not just require the "?" to begin with?!

Indeed, requiring users to enter the record type predicate, instead of
the record type name, would make the macro hygienic, and would be just
as convenient:

  (match x (($ foo? x y) (list x y)))

Thanks,
Ludo’.

Re: srfe records in reworked match

[Andy Wingo]

On Wed 21 Apr 2010 10:40, ludo@gnu.org (Ludovic Courtès) writes:

> FWIW I’d really prefer if it could work with SRFI-9 (which is purely
> syntactic, so there’s no run-time record type descriptor) rather than
> with Guile’s records (as above).

There is a run-time rtd, of sorts; it is the struct-vtable. There would
be no penalty making Guile's records interoperable with SRFI-9 records.

Andy
-- 
http://wingolog.org/

Re: srfe records in reworked match

[Ludovic Courtès]

Andy Wingo <wingo@pobox.com> writes:

> On Wed 21 Apr 2010 10:40, ludo@gnu.org (Ludovic Courtès) writes:
>
>> FWIW I’d really prefer if it could work with SRFI-9 (which is purely
>> syntactic, so there’s no run-time record type descriptor) rather than
>> with Guile’s records (as above).
>
> There is a run-time rtd, of sorts; it is the struct-vtable.

Yes, but it’s Guile-specific.

> There would be no penalty making Guile's records interoperable with
> SRFI-9 records.

Currently Guile’s SRFI-9 accessors are “integratable” whereas record
accessors aren’t.  IOW, until Guile has an inliner, there’d be a penalty
making them interoperable.

Thanks,
Ludo’.

Re: srfe records in reworked match

[Andy Wingo]

Hi,

On Thu 22 Apr 2010 14:27, ludo@gnu.org (Ludovic Courtès) writes:

>> There would be no penalty making Guile's records interoperable with
>> SRFI-9 records.
>
> Currently Guile’s SRFI-9 accessors are “integratable” whereas record
> accessors aren’t.  IOW, until Guile has an inliner, there’d be a penalty
> making them interoperable.

Perhaps I didn't explain myself here. I would like to be able to take a
record, and ask what fields it has. I can do this with Guile records,
and I could do so with SRFI-9 records if the vtable were an instance of
record-type-vtable.

This would also allow SRFI-9 records to return #t for `record?'.

This does not affect SRFI-9 accessors at all; they can still be
integrable.

Andy
-- 
http://wingolog.org/

Re: srfe records in reworked match

[Ludovic Courtès]

Andy Wingo <wingo@pobox.com> writes:

> This does not affect SRFI-9 accessors at all; they can still be
> integrable.

Not unless ‘record-accessor’ is bypassed.

Thanks,
Ludo’.

Re: srfe records in reworked match

[Andy Wingo]

On Thu 22 Apr 2010 14:57, ludo@gnu.org (Ludovic Courtès) writes:

> Andy Wingo <wingo@pobox.com> writes:
>
>> This does not affect SRFI-9 accessors at all; they can still be
>> integrable.
>
> Not unless ‘record-accessor’ is bypassed.

I'm not talking about implementing srfi-9 record accessors in terms of
guile record accessors. I'm talking about having the vtable be a record
type. Accessors can still be integrated.

Andy
-- 
http://wingolog.org/

Re: srfe records in reworked match

[stefan]

ok,

It took much longer time to make this work then the logic deserved
acording to your wishes, mainly because I have not wrapped my head correctly
around define-syntax and friends. 

There is a discussion going on right know on accessors et all. I hope that 
you can detail the conclusion of that discussion in the end so that my 
inexperienced ears can understand.

Anyway. Setters and getters of the match construct works as well on a basic
level. e.g. (struct-ref n 1), (struct-set! n 2 x). So if there is a record 
with a custom getter and or setter that getter and setter will not be used.
This is verified to work with srfi-9.

From a man with a strangly twisted head
/Stefan

Re: srfe records in reworked match

[stefan]

On Wednesday 21 April 2010 10:40:29 am Ludovic Courtès wrote:
> As noted in Shinn’s match-cond-expand.scm, this record matching form is
> not ideal:
> 
>   ;; Annoying unhygienic record matching.  Record patterns look like
>   ;;   ($ record fields...)
>   ;; where the record name simply assumes that the same name suffixed
>   ;; with a "?" is the correct predicate.
> 

Entering,

scheme@(guile-user)> (macroexpand '(n? x))
(if (struct? x) (eq? (struct-vtable x) n) #f)

So, I just tok the expanded line directly instead of n?. 

/Stefan

Re: srfe records in reworked match

[Ludovic Courtès]

Hi,

stefan <stefan.tampe@spray.se> writes:

> On Wednesday 21 April 2010 10:40:29 am Ludovic Courtès wrote:
>> As noted in Shinn’s match-cond-expand.scm, this record matching form is
>> not ideal:
>> 
>>   ;; Annoying unhygienic record matching.  Record patterns look like
>>   ;;   ($ record fields...)
>>   ;; where the record name simply assumes that the same name suffixed
>>   ;; with a "?" is the correct predicate.
>> 
>
> Entering,
>
> scheme@(guile-user)> (macroexpand '(n? x))
> (if (struct? x) (eq? (struct-vtable x) n) #f)

That’s an implementation detail that you should ignore.  :-)

Just have users write:

  (($ n? a b c) ...)

Where ‘n?’ is bound to the record type predicate, and have ‘match’
invoke that record type predicate.

Thanks,
Ludo’.

Re: srfe records in reworked match

[stefan]

Ok,

I have validated it as you suggested. I also added the missing
match-define. Not all features of the old match construct is implemented
yet though. They are

1. The boxing, which I don't know what the meaning is.
2. The special record construction 
3. Error handling features.

How to proceed?

/Stefan

Re: srfe records in reworked match

[Ludovic Courtès]

Hi Stefan,

Thanks for the good news!  :-)

stefan <stefan.tampe@spray.se> writes:

> How to proceed?

Can you post your code somewhere?  (Could be by email.)

If it’s based on Alex Shinn’s match, can you show the diff?  It would
also be nice to get in touch with him to have him integrate your
changes, possibly using ‘(cond-expand (guile-2 ....))’ for the
Guile-specific bits.

Thanks!

Ludo’.