public inbox for kawa@sourceware.org
 help / color / mirror / Atom feed
* Re: behavior of CASE with strings PART 2
@ 2017-01-20 22:54 Damien Mattei
  0 siblings, 0 replies; 9+ messages in thread
From: Damien Mattei @ 2017-01-20 22:54 UTC (permalink / raw)
  To: Kawa

Hi Per,

i could use string->symbol instead of strings with the normal CASE but
i finally wrote a macro for CASE with strings,
it was harder than expected , i learned macro at university with the
define-macro style ,i was familiar with this style, now define-syntax
is used, here is my macro:

(define-syntax case-string

  (syntax-rules ( => )


    ;; (define dog "dog")
    ;; (case-string dog (("dog") "animal")   (else => "mineral or vegetable"))
    ((case-string var
          lst
          (else => res-else  ...))

     (if (member var (car (quote lst)))
       (cadr (quote lst))
       (begin
         res-else
         ...)))

    ;; (define cat "cat")
    ;; (case-string cat (("dog") "animal") (("cat") "my daughter say
cats are not animals!")  (else => "mineral or vegetable"))
    ((case-string var
              lst
              lst2
              ...
              (else => res-else ...))

     (if (member var (car (quote lst)))
     (cadr (quote lst))
     (case-string var
              lst2
              ...
              (else => res-else ...))))



    ;;(case-string dog  (else => "silly case"))
    ((case-string var
          (else => res-else ...))

     (begin
       res-else
       ...))))

i'm not sure if this macro is r5rs compliant but i have test it
working. I will test it monday in our Kawa apps in Tomcat but i'm
almost sure it will solve all the errors.

Regards,

 Damien

^ permalink raw reply	[flat|nested] 9+ messages in thread

* Re: behavior of CASE with strings PART 2
  2017-01-19  4:53       ` Per Bothner
  2017-01-19 10:04         ` Damien MATTEI
@ 2017-01-21  9:47         ` Damien Mattei
  1 sibling, 0 replies; 9+ messages in thread
From: Damien Mattei @ 2017-01-21  9:47 UTC (permalink / raw)
  To: Kawa, bigloo

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/

^ permalink raw reply	[flat|nested] 9+ messages in thread

* Re: behavior of CASE with strings PART 2
  2017-01-19 10:04         ` Damien MATTEI
@ 2017-01-19 16:00           ` Per Bothner
  0 siblings, 0 replies; 9+ messages in thread
From: Per Bothner @ 2017-01-19 16:00 UTC (permalink / raw)
  To: Damien MATTEI, kawa

On 01/19/2017 02:04 AM, Damien MATTEI wrote:
> i understand the various implementation of Scheme follow or not the R5RS and R7RS
>  but this could be changed in a future revision because it is limitating to be able to use CASE with STRINGS
> in language such as ASP, Java and not Scheme, with Racket it seems that equal? predicate is used,
> so probably my code will work with Racket.

I guess it may be worth considering extending case to use equal? rather than eqv?.
Though in theory an incompatible change, I don't see how it would break working programs.
What do people think?  Though note this is not just a one-line change.  I'd have to study to case
implementation and optimizations and see what would need to change.  So it could be a
"wishlist" item, but not necessarily right away.

> i think of many solutions and finalyy begin to write a  recursive macro implementing a case-string
>  but i'm facing proble with multiple "ellipsis" in a recursive macro and wanted to debug it this morning
> when  i read your last message, so here it is:

There is a syntax-rules implementation of case in R7RS (7.3 Derived expression types).
You could use thtat as a starting-point.  Of course it wouldn't have the optimizations
of Kawa's builtin case.
-- 
	--Per Bothner
per@bothner.com   http://per.bothner.com/

^ permalink raw reply	[flat|nested] 9+ messages in thread

* Re: behavior of CASE with strings PART 2
  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
  1 sibling, 1 reply; 9+ messages in thread
From: Damien MATTEI @ 2017-01-19 10:04 UTC (permalink / raw)
  To: kawa

Le Thursday 19 January 2017 05:53:05 Per Bothner, vous avez écrit :
> 
> 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.

Hi Per,

thanks for your answer...
i read the many answers to the mailing list about CASE and STRINGS and delayed my answer because i 
wanted to answer after having a solution (still not done)

i understand the various implementation of Scheme follow or not the R5RS and R7RS
 but this could be changed in a future revision because it is limitating to be able to use CASE with STRINGS
in language such as ASP, Java and not Scheme, with Racket it seems that equal? predicate is used,
so probably my code will work with Racket.

i think of many solutions and finalyy begin to write a  recursive macro implementing a case-string
 but i'm facing proble with multiple "ellipsis" in a recursive macro and wanted to debug it this morning 
when  i read your last message, so here it is:

;; CASE adapted for string comparison

(define-syntax case-string
  
  (syntax-rules ()
    
    ((_ var
	(lst res)
	(... ...)
	(else => res-else))
     
     (if (member var lst)
	 res
	 (case var
	   (... ...)
	   (else => res-else))))
    
    ((_ var
	(else => res-else))

     res-else)))

ellispsis have to be fixed and the behavior seems to be not defined in R5RS i tried many scheme and it behave diffrently, even in Racket with #lang R5RS
it does not work now

Damien

-- 
Damien.Mattei@unice.fr, Damien.Mattei@oca.eu, UNS / OCA / CNRS

^ permalink raw reply	[flat|nested] 9+ messages in thread

* Re: behavior of CASE with strings PART 2
  2017-01-18  6:37     ` Per Bothner
@ 2017-01-19  4:53       ` Per Bothner
  2017-01-19 10:04         ` Damien MATTEI
  2017-01-21  9:47         ` Damien Mattei
  0 siblings, 2 replies; 9+ messages in thread
From: Per Bothner @ 2017-01-19  4:53 UTC (permalink / raw)
  To: kawa



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/

^ permalink raw reply	[flat|nested] 9+ messages in thread

* Re: behavior of CASE with strings PART 2
  2017-01-17 15:57   ` Jamison Hope
@ 2017-01-18  6:37     ` Per Bothner
  2017-01-19  4:53       ` Per Bothner
  0 siblings, 1 reply; 9+ messages in thread
From: Per Bothner @ 2017-01-18  6:37 UTC (permalink / raw)
  To: Jamison Hope, kawa



On 01/17/2017 07:57 AM, Jamison Hope wrote:
> On Jan 17, 2017, at 8:23 AM, Per Bothner <per@bothner.com> wrote:
>
>> CASE *cannot* meaningfully be used with strings.
>
> Indeed.  Meanwhile, this sort of categorization of strings can be
> useful, as evidenced by the addition of String switches to Java 7.

I guess we could add it as a Kawa "extension", but it would explicitly
violate r5rs/r7rs.

> The portable Scheme way to do this would be to use symbols instead of
> strings, since ordinarily symbols are interned and thereby eqv?, but I
> could see a place for Kawa-specific syntax that compiles to the
> equivalent of a Java String switch block (which uses hash codes and a
> lookupswitch to avoid doing every string comparison in a big if-else
> chain).

I think this is something to think of for the Kawa 3.0 release,
using the new PATTERN construct in each clause.
-- 
	--Per Bothner
per@bothner.com   http://per.bothner.com/

^ permalink raw reply	[flat|nested] 9+ messages in thread

* Re: behavior of CASE with strings PART 2
  2017-01-17 13:24 ` Per Bothner
@ 2017-01-17 15:57   ` Jamison Hope
  2017-01-18  6:37     ` Per Bothner
  0 siblings, 1 reply; 9+ messages in thread
From: Jamison Hope @ 2017-01-17 15:57 UTC (permalink / raw)
  To: kawa

On Jan 17, 2017, at 8:23 AM, Per Bothner <per@bothner.com> wrote:

> CASE *cannot* meaningfully be used with strings.

Indeed.  Meanwhile, this sort of categorization of strings can be
useful, as evidenced by the addition of String switches to Java 7.

The portable Scheme way to do this would be to use symbols instead of
strings, since ordinarily symbols are interned and thereby eqv?, but I
could see a place for Kawa-specific syntax that compiles to the
equivalent of a Java String switch block (which uses hash codes and a
lookupswitch to avoid doing every string comparison in a big if-else
chain).

I'm not sure what we would call the macro, though -- string-case makes
me think of uppercase vs lowercase.

--
Jamison Hope
The PTR Group
www.theptrgroup.com



^ permalink raw reply	[flat|nested] 9+ messages in thread

* Re: behavior of CASE with strings PART 2
  2017-01-17 10:07 Damien MATTEI
@ 2017-01-17 13:24 ` Per Bothner
  2017-01-17 15:57   ` Jamison Hope
  0 siblings, 1 reply; 9+ messages in thread
From: Per Bothner @ 2017-01-17 13:24 UTC (permalink / raw)
  To: kawa



On 01/17/2017 02:07 AM, Damien MATTEI wrote:
> testing with eqv? predicate (that seems to be used in kawa CASE if it follow R5RS) and according to https://www.gnu.org/software/kawa/Conditionals.html i have this:
>
> |kawa:1|# (case "dog" (("cat" "dog" "mouse") "animal") (else "mineral or vegetable"))
animal

CASE *cannot* meaningfully be used with strings.

#|kawa:2|# (case (string-copy "dog") (("cat" "dog" "mouse") "animal") (else "mineral or vegetable"))
mineral or vegetable

The reason is that case tests use eqv?, and "The eqv? procedure returns #f if" ...
"obj 1 and obj 2 are pairs, vectors, bytevectors, records,
or strings that denote distinct locations. (quoting directly from R7RS).
R5RS is the same in this respect.

Thus (eqv? (string-copy "dog") "dog") is #f, as is (eqv? (string #\d #\o #\g) "dog").
Even (eqv? "dog" "dog") is *unspecified* according to R7RS, because it does not
require that the two "dog" literals are the same location.

It might be reasonable to add a warning, like Kawa does with lists:

#|kawa:8|# (case "dog" ((("cat") "dog" "mouse") "animal") (else "mineral or vegetable"))
/dev/stdin:8:15: warning - List and vectors will never be matched in a case clause
/dev/stdin:8:15: warning - datum type incompatible with the key

-- 
	--Per Bothner
per@bothner.com   http://per.bothner.com/

^ permalink raw reply	[flat|nested] 9+ messages in thread

* behavior of CASE with strings PART 2
@ 2017-01-17 10:07 Damien MATTEI
  2017-01-17 13:24 ` Per Bothner
  0 siblings, 1 reply; 9+ messages in thread
From: Damien MATTEI @ 2017-01-17 10:07 UTC (permalink / raw)
  To: Kawa mailing list

testing with eqv? predicate (that seems to be used in kawa CASE if it follow R5RS) and according to https://www.gnu.org/software/kawa/Conditionals.html i have this:

|kawa:1|# (case "dog" (("cat" "dog" "mouse") "animal") (else "mineral or vegetable"))
animal
#|kawa:2|# (invoke "dog":class 'getName)
java.lang.String
#|kawa:3|# (eqv? "dog" "dog")
#t
#|kawa:4|# (define a "dog")
#|kawa:5|# (eqv? a "dog")
#t

and now in my code:

i modified the code to display things:

(begin

		 (display-msg-var-nl  "ResultatGeneralAFKawa : work : type1 = " type1)
		 (display-msg-var-nl  "ResultatGeneralAFKawa : work : type2 = " type2)

		 (display-msg-var-nl  "ResultatGeneralAFKawa : work : Nom = " Nom)

		 (if (equal? "B5" type1)
		     (display-nl "ResultatGeneralAFKawa : work : equal? test TRUE")
		     (display-nl "ResultatGeneralAFKawa : work : equal? test FALSE"))

		 (if (eqv? "B5" type1)
		     (display-nl "ResultatGeneralAFKawa : work : eqv? test TRUE")
		     (display-nl "ResultatGeneralAFKawa : work : eqv? test FALSE"))

		 ;;(display (string-append "|" (type1:getClass:getName) "|"))
		 (display "ResultatGeneralAFKawa : work : type1 is of type : ") 
		 (display   (invoke type1:class 'getName) )
		 (newline)

		 (display "ResultatGeneralAFKawa : work : B5 is of type : ") 
		 (display   (invoke "B5":class 'getName) )
		 (newline)

	
		 (if (eq? "B5" type1)
		     (display-nl "ResultatGeneralAFKawa : work : eq? test TRUE")
		     (display-nl "ResultatGeneralAFKawa : work : eq? test FALSE"))


		 (set! nutype1
		       (case type1
			 (("O") 1) ;; java.lang.String
			 (("O0") 2)
			 (("O1") 3)
			 (("O2") 4)
			 (("O3") 5)
			 (("O4") 6)
			 (("O5") 7)
			 (("O6") 8)
			 (("O7") 9)
			 (("O8") 10)
			 (("O9") 11)
			 (("B") 12)
			 (("B0") 13)
			 (("B1") 14)
			 (("B2") 15)
			 (("B3") 16)
			 (("B4") 17)
			 (("B5") 18)
			 (("B6") 19)
			 (("B7") 20)
			 (("B8") 21)
			 (("B9") 22)
			 (("A") 23)
			 (("A0") 24)
			 (("A1") 25)
			 (("A2") 26)
			 (("A3") 27)
			 (("A4") 28)
			 (("A5") 29)
			 (("A6") 30)
			 (("A7") 31)
			 (("A8") 32)
			 (("A9") 33)
			 (("F") 34)
			 (("F0") 35)
			 (("F1") 36)
			 (("F2") 37)
			 (("F3") 38)
			 (("F4") 39)
			 (("F5") 40)
			 (("F6") 41)
			 (("F7") 42)
			 (("F8") 43)
			 (("F9") 44)
			 (("G") 45)
			 (("G0") 46)
			 (("G1") 47)
			 (("G2") 48)
			 (("G3") 49)
			 (("G4") 50)
			 (("G5") 51)
			 (("G6") 52)
			 (("G7") 53)
			 (("G8") 54)
			 (("G9") 55)
			 (("K") 56)
			 (("K0") 57)
			 (("K1") 58)
			 (("K2") 59)
			 (("K3") 60)
			 (("K4") 61)
			 (("K5") 62)
			 (("K6") 63)
			 (("K7") 64)
			 (("K8") 65)
			 (("K9") 66)
			 (("M") 67)
			 (("M0") 68)
			 (("M1") 69)
			 (("M2") 70)
			 (("M3") 71)
			 (("M4") 72)
			 (("M5") 73)
			 (("M6") 74)
			 (("M7") 75)
			 (("M8") 76)
			 (("M9") 77)
			 (else => (begin
				    (display-nl "display values:")
				    (dv type1)
				    (dv nutype1)
				    (display "WARNING : ResultatGeneralAFKawa : work : CASE type1 in ELSE")
				    (newline)
				    '()))))
				   
		 (dv nutype1)

display* and dv are macro to display variables.

here is the output in logs:

ResultatGeneralAFKawa : work : type1 = B5
ResultatGeneralAFKawa : work : type2 = F5
ResultatGeneralAFKawa : work : Nom = FIN
ResultatGeneralAFKawa : work : equal? test TRUE
ResultatGeneralAFKawa : work : eqv? test FALSE
ResultatGeneralAFKawa : work : type1 is of type : java.lang.String
ResultatGeneralAFKawa : work : B5 is of type : java.lang.String
ResultatGeneralAFKawa : work : eq? test FALSE
display values:
type1 = B5
nutype1 = ()
WARNING : ResultatGeneralAFKawa : work : CASE type1 in ELSE

my concern is with type1 which is of type java.lang.String ,also "B5" in case is of type java.lang.String ,and they should be equal in the sense of eqv? and the CASE should be satisfied in (("B5") 18) but in,stead it goes in ELSE clause 
because "B5" and type1 are not equal (eqv?) as "dog" and "dog" (depends of the scheme implementation ) 
i do not want to rewrite the CASE in other things, is there a way to have String that equal in the sense of eqv?  ?

regards,

damien


-- 
Damien.Mattei@unice.fr, Damien.Mattei@oca.eu, UNS / OCA / CNRS

^ permalink raw reply	[flat|nested] 9+ messages in thread

end of thread, other threads:[~2017-01-21  9:47 UTC | newest]

Thread overview: 9+ messages (download: mbox.gz / follow: Atom feed)
-- links below jump to the message on this page --
2017-01-20 22:54 behavior of CASE with strings PART 2 Damien Mattei
  -- strict thread matches above, loose matches on Subject: below --
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 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).