public inbox for
 help / color / mirror / Atom feed
From: Damien Mattei <>
To: Kawa <>,
Subject: Re: behavior of CASE with strings PART 2
Date: Sat, 21 Jan 2017 09:47:00 -0000	[thread overview]
Message-ID: <> (raw)
In-Reply-To: <>

Hi Per,

in my opinion , rather than following Racket guide lines that are
complex , i prefer to write macro some times,
 and do things that are R*RS compliant because it's the best way to
keep progams compatible as i use many scheme
implementations,Kawa,Bigloo,Racket  .

the last macro i wrote case-string is working with Kawa and Racket
(even with #lang r5rs activated! should not work) but not with Bigloo
because the macro is not r5rs compliant ,it has some variable after
the ellipsis, and it is forbidden in r5rs and r7rs. ( )

i will try to understand how this one :

(define-syntax case
  (syntax-rules (else)
    ((case (key ...)
       clauses ...)
     (let ((atom-key (key ...)))
       (case atom-key clauses ...)))
    ((case key
       (else result1 result2 ...))
     (begin result1 result2 ...))
    ((case key
       ((atoms ...) result1 result2 ...))
     (if (memv key '(atoms ...))
         (begin result1 result2 ...)))
    ((case key
       ((atoms ...) result1 result2 ...)
       clause clauses ...)
     (if (memv key '(atoms ...))
         (begin result1 result2 ...)
         (case key clause clauses ...)))))

works next week....
and modify it for strings



On Thu, Jan 19, 2017 at 5:53 AM, Per Bothner <> wrote:
> On 01/17/2017 10:36 PM, Per Bothner wrote:
>> I think this is something to think of for the Kawa 3.0 release,
>> using the new PATTERN construct in each clause.
> The invoke branch has a 'match' form, which has the syntax:
> (match TARGET-EXPR (PATTERN BODY...) ...)
> This matches TARGET-EXPR against each PATTERN, until one matches,
> at which point the BODY... forms are evaluated.
> This is the 'match' form from Racket:
> Unfortunately, the implemented forms of PATTERN are very
> limited, but the intention to allow literals and quoted forms.
> These will be compared using equal?, so you will be able to write:
>    (match "yes"
>     ("no" #f)
>     ("yes" #t))
> THIS IS NOT YET IMPLEMENTED.  (It's not conceptually hard; I just need to
> decide the best way to present such match forms.)
> I think this is the generalization of 'case' that we're looking for.
> --
>         --Per Bothner

  parent reply	other threads:[~2017-01-21  9:47 UTC|newest]

Thread overview: 12+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2017-01-17 10:07 Damien MATTEI
2017-01-17 13:24 ` Per Bothner
2017-01-17 15:57   ` Jamison Hope
2017-01-18  6:37     ` Per Bothner
2017-01-19  4:53       ` Per Bothner
2017-01-19 10:04         ` Damien MATTEI
2017-01-19 16:00           ` Per Bothner
2017-01-21  9:47         ` Damien Mattei [this message]
2017-01-22  4:36           ` match form as a generalization of case Per Bothner
2017-01-23 22:12             ` Damien Mattei
2017-01-23 22:27               ` Per Bothner
2017-01-20 22:54 behavior of CASE with strings PART 2 Damien Mattei

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \ \ \ \ \

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for read-only IMAP folder(s) and NNTP newsgroup(s).