On Jul 15, 2014, at 6:37 PM, Stephen Chang wrote:
>> Also I was thinking I could use it to make gen-bind expanders for
>> match-patterns if I need them.
>
> There's a define-match-bind that consumes a match pattern and defines
> a $-prefixed name for that specific pattern that can be used in
>
> Also I was thinking I could use it to make gen-bind expanders for
> match-patterns if I need them.
There's a define-match-bind that consumes a match pattern and defines
a $-prefixed name for that specific pattern that can be used in
gen-bind positions. Does that help?
>
>>
>>
>>> And is there
On Jul 15, 2014, at 5:40 PM, Stephen Chang wrote:
>> Is there any reason why you can’t just use match-patterns instead of using
>> ($ match-pattern) ?
>
> The idea was to support a generic interface so different instances
> could be defined, but thus each instance needs it's own name. For
> ex
> Is there any reason why you can’t just use match-patterns instead of using ($
> match-pattern) ?
The idea was to support a generic interface so different instances
could be defined, but thus each instance needs it's own name. For
example, I need to differentiate when I'm binding a match pattern
By the way I’m just wondering:
Is there any reason why you can’t just use match-patterns instead of using ($
match-pattern) ?
And is there anything like a “generic-binding-expander” that would act sort of
like a match-expander?
And is there some kind of "generic-bind/renamed” module or somet
> I just found this, which has a lot of forms for just about everything I can
> think of (and more) that support things like match-patterns:
> https://github.com/stchang/generic-bind
>
> I haven’t tried it yet, but It looks pretty amazing.
>
> It probably has everything you want.
Thanks for the k
I just found this, which has a lot of forms for just about everything I can
think of (and more) that support things like match-patterns:
https://github.com/stchang/generic-bind
I haven’t tried it yet, but It looks pretty amazing.
It probably has everything you want.
On Jul 13, 2014, at 12:4
On Jul 12, 2014, at 10:17 PM, Alexander D. Knauth wrote:
>
> On Jul 12, 2014, at 6:43 PM, Brian Adkins wrote:
>
>> I probably won't keep my defpat macro, at least not in its present form (for
>> one, it only handles a single arg); there's probably a balance between being
>> concise and bein
On Jul 12, 2014, at 6:43 PM, Brian Adkins wrote:
> On Jul 12, 2014, at 6:19 PM, Daniel Prager wrote:
>
>> Hi Brian
>>
>> r >= 0 && r <= 4 && c >= 0 && c <= r
>>
>>
>> implies
>>
>> 0 <= c <= r <= 4
>>
>>
>> Or using prefix and the variable-arity of <=:
>>
>> (define (is-pos r c)
>> (<=
On Jul 12, 2014, at 6:17 PM, Asumu Takikawa wrote:
> On 2014-07-12 16:18:55 -0400, Brian Adkins wrote:
>> 1) It's odd to me to specify the l argument, and then never refer to it.
>> 2) The syntax of the former seems less "noisy".
>
> I agree that the syntax can be noisy for simple cases.
>
> The
On Jul 12, 2014, at 6:19 PM, Daniel Prager wrote:
> Hi Brian
>
> r >= 0 && r <= 4 && c >= 0 && c <= r
>
>
> implies
>
> 0 <= c <= r <= 4
>
>
> Or using prefix and the variable-arity of <=:
>
> (define (is-pos r c)
> (<= 0 c r 4))
>
>
> which I think works well for clarity, concision, an
Hi Brian
r >= 0 && r <= 4 && c >= 0 && c <= r
implies
0 <= c <= r <= 4
Or using prefix and the variable-arity of <=:
(define (is-pos r c)
(<= 0 c r 4))
which I think works well for clarity, concision, and efficiency.
Dan
Racket Users list:
http://lists.racket-l
On 2014-07-12 16:18:55 -0400, Brian Adkins wrote:
> 1) It's odd to me to specify the l argument, and then never refer to it.
> 2) The syntax of the former seems less "noisy".
I agree that the syntax can be noisy for simple cases.
The design rationale for having the header is to allow optional,
ke
Brian Adkins wrote at 07/12/2014 04:19 PM:
Thanks for the advice Neil. I'm a little confused by your "Racket is an imperative
language" statement though - it seems quite "functional" to me, which was one of the
attractions.
[...]
Racket can be used as a functional language, so long as one rem
Thanks for the advice Neil. I'm a little confused by your "Racket is an
imperative language" statement though - it seems quite "functional" to me,
which was one of the attractions.
The Haskell code was written a few years ago, as a relative newbie, as an
exercise in emphasizing readability and
Thanks. I did look at define/match but:
(defpat (is-pos (list r c))
(and (member r (lgen 0 4))
(member c (lgen 0 r
seems nicer to me than:
(define/match (is-pos l)
[((list r c)) (and (member r (lgen 0 4))
(member c (lgen 0 r)))])
for two reasons:
1) It's odd to
Complementary to the suggestions that Matthias and Jens Axel made, also
remember that Racket has a very different evaluation model than Haskell.
Consider reworking the use of the "and" form and everything within it:
instead, test "r" and "c" for "integer?", and then use "<=" and ">=" to
determ
Hi Brian,
I think you want define/match.
(define/match (is-pos l)
[((list r c)) (and (member r (range 0 4))
(member c (range 0 r)))])
(is-pos '(2 5)) ; => #f
(is-pos '(2 1)) ; => '(1)
/Jens Axel
2014-07-12 18:53 GMT+02:00 Brian Adkins :
> I'm porting more Haskell code
On Jul 12, 2014, at 12:53 PM, Brian Adkins wrote:
> I'm porting more Haskell code to Racket as a learning exercise. When I got to
> this line:
>
> isPos (r,c) = elem r [0..4] && elem c [0..r]
>
> I first wrote this:
>
> (define (is-pos r c) (and (member r (lgen 0 4))
>
19 matches
Mail list logo
