On Thu, May 03, 2012 at 03:48:17PM -0400, Eli Barzilay wrote:
> With the trend of having shorter names, I'll try suggesting it again.
> Looking at some random slides (the ones from Matthew's talk), one
> thing that is -- still -- very strikingly inconvenient is code like
>
> (parameterize ([curr
Matthias Felleisen wrote at 05/03/2012 10:57 PM:
I don't think Eli is proposing an elimination of the old names but
supplementing the code base with new ones.
I am in favor -- Matthias
Would be good to have a shorter naming convention for all parameters.
The "current-" prefix is not short,
I don't think Eli is proposing an elimination of the old names but
supplementing the code base with new ones.
I am in favor -- Matthias
_
Racket Developers list:
http://lists.racket-lang.org/dev
On 05/03/2012 02:09 PM, Neil Van Dyke wrote:
Eli Barzilay wrote at 05/03/2012 03:48 PM:
(parameterize ([stderr (stdout)])
...)
I'm not sure how I feel about shortening these, but an additional
consideration is that a naming convention for parameters (so far,
prefixing with "current-") has been
On Thu, May 3, 2012 at 3:58 PM, Danny Yoo wrote:
> > IMO, anyone who is not coming from some kind of Scheme background
> > would view this as ridiculously long. If they're renamed to the usual
> > names, things look much better:
> >
> > (parameterize ([stderr (stdout)])
> >...)
>
>
> Defini
Eli Barzilay wrote at 05/03/2012 03:48 PM:
(parameterize ([stderr (stdout)])
...)
I'm not sure how I feel about shortening these, but an additional
consideration is that a naming convention for parameters (so far,
prefixing with "current-") has been useful. I think a naming conve
> IMO, anyone who is not coming from some kind of Scheme background
> would view this as ridiculously long. If they're renamed to the usual
> names, things look much better:
>
> (parameterize ([stderr (stdout)])
> ...)
Definitely +1.
_
Racket Developers list:
htt
With the trend of having shorter names, I'll try suggesting it again.
Looking at some random slides (the ones from Matthew's talk), one
thing that is -- still -- very strikingly inconvenient is code like
(parameterize ([current-error-port (current-output-port)])
...)
IMO, anyone who is not
I would say no, since a "syntax rule" is a single rewrite rule. Perhaps you
want a simple shim around syntax-rules?
Like:
(define-syntax-rules [(id . pat) rhs] ...+)
where id must be the same in all templates?
Simple implementation:
(define-syntax (define-syntax-rules stx)
(syntax-case stx (
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1
Hi,
would it make sense for define-syntax-rule to have an implicit begin
such that it could accept multiple forms for the template?
Marijn
-BEGIN PGP SIGNATURE-
Version: GnuPG v2.0.19 (GNU/Linux)
Comment: Using GnuPG with Mozilla - http://eni
10 matches
Mail list logo