Dear list members,
Firstly happy holidays to everyone.
In DrRacket expression comments aren't greyed out as other comments
but maintain their syntax coloring. I originally thought this was a
bug and submitted a bug report about a year ago, but was told this is
intended behavour.
The Style Guide
IMO, it would be best if they turned into comment color but were still
indented properly. But an option would be nice too.
Patches welcome.
Robby
On Thu, Dec 27, 2012 at 12:21 PM, Harry Spier wrote:
> Dear list members,
>
> Firstly happy holidays to everyone.
>
> In DrRacket expression comment
On Dec 27, 2012, at 1:52 PM, Robby Findler wrote:
> it would be best if they turned into comment color but were still indented
> properly.
> Patches welcome.
+1
_
Racket Developers list:
http://lists.racket-lang.org/dev
I think that there is a point in keeping the colors so it would be best to
have some indication of comment-ness that gets added, like a different
background.
On Dec 27, 2012 10:48 PM, "Matthias Felleisen" wrote:
>
> On Dec 27, 2012, at 1:52 PM, Robby Findler wrote:
>
> it would be best if they tu
I have clarified the interface specification part of the Style guide.
The original draft was written before contract-out existed. I have
rewritten all provide/contracts into provide plus contract-out.
Having said that, I absolutely,
It would be really easy to mix the comment and code highlighting colors
by averaging their RGB values pointwise.
Another, easier and possibly more visually robust way to mix the colors
is to set the text's alpha to 1/2 to blend it with the editor background.
Neil ⊥
On 12/27/2012 03:39 PM, El
1. Robby responded to your first item some time back. He and I had discussed
contract-stronger and eq? check several times in the past. But even that
doesn't assure improved checking w/o some performance-oriented thinking on the
programmer's side.
2. Sam didn't respond to the second part, whi
OC could suggest moving heavily called functions across boundaries, that'd
be cool.
One other place that we realized pretty quickly where we were wrong about
the boundaries and inefficiencies is struct declarations. It isn't uncommon
to put contracts on structs and put them in their own module (sc
On Fri, Dec 14, 2012 at 10:44 AM, Matthias Felleisen
wrote:
>
> It is critical to inform clients of the services that a module
> provides. In the absence of types, contracts are the closest
> information we have.
AND
On Fri, Dec 14, 2012 at 11:43 AM, Ray Racine wrote:
> For the TR folks you can h
Sorry it took so long to reply.
I applied the patch and verified that my example runs a *lot* faster
(with domain and range contracts identical, of course). Unfortunately, a
similar test using arrays isn't any faster. This is how the identity
function for arrays is defined in the test:
(:
10 matches
Mail list logo
