Palindromes and pattern matching
Howdie,
I've been learning the refal language recently
(http://refal.botik.ru/book/html/ )
and I've been wondering, if there's any way
to simulate the behaviour of the refal's pattern
matcher using the Andrew K. Wright's/Alex Shinn's
pattern matcher for Scheme. Namely,
the Refal tutorial presents a following definition
of a palindrome:
1. An empty string is a palindrome.
2. A string of one symbol is a palindrome.
3. If a string starts and ends with the same symbol, then it is a
palindrome if and only if the string which remains after the removal
of the first and the last letters is a palindrome.
4. If none of the above are applicable, the string is not a palindrome.
The tutorial also presents the Refal code that
implements the above conditions to construct the
predicate that states whether a given object is a
palindrome:
Pal { = True;
s.1 = True;
s.1 e.2 s.1 = ;
e.1 = False; }
The notation is a little bit funny, but it should be
comprehensible. The represents
application of a function, and the empty string
isn't mentioned explicitly.
I don't know whether the Scheme's pattern matcher
has any notation for getting the last element of a list.
At first, I thought that maybe it could be done using
the unquote-splicing operator, so the equivalent code
would look like this:
(define (palindrome? l)
(match l
(() #t)
((s1) #t)
(`(,s1 ,@e2 ,s1) (palindrome? e2))
(else #f)))
but apparently this code doesn't work.
Is there a clean and simple way to achieve this using
the aforementioned pattern matcher?
Best regards,
M.
Re: Palindromes and pattern matching
Panicz Maciej Godek writes: > I don't know whether the Scheme's pattern matcher > has any notation for getting the last element of a list. > At first, I thought that maybe it could be done using > the unquote-splicing operator, so the equivalent code > would look like this: > (define (palindrome? l) > (match l > (() #t) > ((s1) #t) > (`(,s1 ,@e2 ,s1) (palindrome? e2)) > (else #f))) > > but apparently this code doesn't work. > Is there a clean and simple way to achieve this using > the aforementioned pattern matcher? scheme@(guile−user)> (define (palindrome? l) (match l (() #t) ((s1) #t) ((s1 s2 ... s1) (palindrome? s2)) (else #f))) scheme@(guile−user)> (palindrome? '(1 2 1)) $9 = #t scheme@(guile−user)> (palindrome? '(1 2 3 2 1)) $10 = #t scheme@(guile−user)> ... Seems to work. I believe ___ also works. -- Ian Price -- shift-reset.com "Programming is like pinball. The reward for doing it well is the opportunity to do it again" - from "The Wizardy Compiled"
Typed Guile?
Hi, The first part of this message may look irrelevent, but you'll understand why I decided to start this way. I'm going to write a library. Here is the list of things I care about (from the most important to the least important): - Strict type system; - Wide community; - Performance. There are several candidates: - Haskell; - Typed Racket; - Typed Clojure*. Which one should I choose? (Please don't answer right now.) I've already tried to ask TR people: "Typed Racket is designed for Racket. One day Guile will have a Typed Guile companion, and Chez Scheme may have a Typed Chez companion but until then TR is for Racket." [1] Is it this bad? Do we really need Typed Guile? Can we somehow adapt the static code to achieve its features in Guile? I'm really concerned about code reuse. It's time to stop reinventing the wheel. My writing skills are not very great... So I'm going to summarize the above: 1. What language should I choose for my library? 2. Do we need Typed Guile? * I know nothing about TC's type system, but it's a possible candidate. [1] http://lists.racket-lang.org/users/archive/2012-September/054037.html (This is not the first message on this thread.)
Re: Typed Guile?
Hello, Here are a few random thoughts: I had a project a little while ago to try to get some of the benefit of static typing in Guile. It never went very far, but actually some of the same machinery is coming to the surface in the compiler anyway. I think it could be taken farther, to the point that Guile really would have the benefits of a statically-typed language. However, what's in Guile right now is not that, and it might take some work to get it there. So no, Guile is not statically typed right now. Performance is another interesting question. Of the things you named, only Guile doesn't compile to native code (yet), so that's going to be a performance hit. However, performance is relative. Since you didn't list C or Fortran as choices, you don't care about having extreme control over what your machine is doing; I don't know enough about your goals to know whether Guile will give you the performance you want. But Guile can be extended in C, so you have the option to go as fast as you want. That's the best I can do without knowing more about your library. Thanks, Noah Lavine On Tue, Sep 18, 2012 at 10:06 PM, wrote: > Hi, > > The first part of this message may look irrelevent, but you'll > understand why I decided to start this way. > > I'm going to write a library. > > Here is the list of things I care about (from the most important to > the least important): > > - Strict type system; > - Wide community; > - Performance. > > There are several candidates: > > - Haskell; > - Typed Racket; > - Typed Clojure*. > > Which one should I choose? > > (Please don't answer right now.) > > I've already tried to ask TR people: > > "Typed Racket is designed for Racket. One day Guile will have a Typed > Guile companion, and Chez Scheme may have a Typed Chez companion but > until then TR is for Racket." [1] > > Is it this bad? Do we really need Typed Guile? > > Can we somehow adapt the static code to achieve its features in Guile? > > I'm really concerned about code reuse. It's time to stop reinventing > the wheel. > > My writing skills are not very great... > So I'm going to summarize the above: > > 1. What language should I choose for my library? > 2. Do we need Typed Guile? > > * I know nothing about TC's type system, but it's a possible candidate. > > [1] http://lists.racket-lang.org/users/archive/2012-September/054037.html > (This is not the first message on this thread.) > > > >
