Re: behavior of CASE with strings PART 2

[Damien Mattei <damien dot mattei at gmail dot com>]

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. (
http://www.schemers.org/Documents/Standards/R5RS/HTML/ )

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

regards,

damien




On Thu, Jan 19, 2017 at 5:53 AM, Per Bothner <per@bothner.com> 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:
>   https://docs.racket-lang.org/guide/match.html
>   https://docs.racket-lang.org/reference/match.html
>
> 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
> per@bothner.com   http://per.bothner.com/