Re: [racket-dev] racket vs. scheme vs. clojure (as it appears to others)

2011-04-29 Thread Joe Marshall
On Fri, Apr 29, 2011 at 8:38 AM, Matthias Felleisen
matth...@ccs.neu.edu wrote:

 2. Could you point me to a criteria that classify Racket as a 'fringe' 
 language
 and Clojure as a non-fringe language?

This is no criterion, but it is suggestive:
http://www.google.com/insights/search/#cat=5q=racket%20-%20tennis%2Cclojuredate=1%2F2008%2040mcmpt=q

But to be fair, popularity is a terrible metric:
http://www.google.com/insights/search/#q=porn%2Cfood%2Cwatercmpt=q

This page shows the relative popularity of `DrScheme' to `Racket'.
https://sites.google.com/site/evalapply/name-change

It appears that `Racket' has only recently overtaken `DrScheme' in
what people search for.



-- 
~jrm
_
  For list-related administrative tasks:
  http://lists.racket-lang.org/listinfo/dev


Re: [racket-dev] A curious question about quote

2011-01-26 Thread Joe Marshall
On Wed, Jan 26, 2011 at 8:02 AM, J. Ian Johnson i...@ccs.neu.edu wrote:
 Hello all. I have a historical question about quoted constants. Does anyone 
 know why '1 = 1? My intuition is that this is an artifact of conflating quote 
 with list constructors. Is that indeed the case?

I doubt it.  More likely it was when someone realized that if (quote 1) is not
the number 1, then everyone would be confused.  What else would it be?

-- 
~jrm
_
  For list-related administrative tasks:
  http://lists.racket-lang.org/listinfo/dev


Re: [racket-dev] relative lines of C in gracket vs. gracket2

2010-10-28 Thread Joe Marshall
On Thu, Oct 28, 2010 at 10:48 AM, John Clements
cleme...@brinckerhoff.org wrote:

 So, if I'm reading this correctly, we've gone from ~590K lines of C to about 
 ~340K lines of C. That's amazing.

Something is wrong.  In your listing, the only two lines that have changed are
these:
   8404   22017  233781 ./racket/src/thread.c
   9132   24942  230277 ./racket/src/port.c

from the original:
   8380   21961  233205 ./racket/src/thread.c
   9123   24924  230059 ./racket/src/port.c

Which seems to be a difference of 33 lines.  I don't see where the
590K to 340K is coming from.

-- 
~jrm
_
  For list-related administrative tasks:
  http://lists.racket-lang.org/listinfo/dev


Re: [racket-dev] internal-definition parsing

2010-10-13 Thread Joe Marshall
On Wed, Oct 13, 2010 at 7:08 AM, Carl Eastlund c...@ccs.neu.edu wrote:
 In the case I have, though, I want the sequence to be empty.  The
 problem is that these bodies -- (let () ...), (parameterize () ...),
 etc. -- are used for a lot of different things.  A macro may splice in
 a sequence that is intended to represent definitions to bind in a
 scope, expressions to evaluate for effect, expressions to evaluate in
 order and return the last, mixed definitions and expressions, or
 perhaps some other odd interpretation of the body sequence.

This is the reason that I prefer a lot of lattitude in Scheme syntax.
There are forms that no human would write but that are marginally
legitimate and might be generated by a macro.  It is painful to try
to make every part of a complex macro expand into well-written
code.


-- 
~jrm
_
  For list-related administrative tasks:
  http://lists.racket-lang.org/listinfo/dev

Re: [racket-dev] `cond' / `when' / `unless' / etc bodies

2010-10-11 Thread Joe Marshall
On Mon, Oct 11, 2010 at 9:59 AM, Neil Toronto neil.toro...@gmail.com wrote:
 If I get a vote, +1/2 from me.

 My vote isn't +1 because I'd rather see a syntactic restriction removed:
 make the inside of a `begin' an internal definition context. Then the change
 would happen in every similar macro at once.


 Would it break much?

BEGIN is overloaded as a `splicing' macro.  When you have a single macro call
that needs to expand into multiple `actions', you return the actions
within a BEGIN,
and they are `flattened' into the containing context.  Automagically
introducing a
new scope would break this behavior.

It might be a good idea to introduce some sort of specific
macro-splicing special form.



-- 
~jrm
_
  For list-related administrative tasks:
  http://lists.racket-lang.org/listinfo/dev


Re: [racket-dev] gc vs assignment

2010-08-25 Thread Joe Marshall
On Tue, Aug 24, 2010 at 2:47 PM, Neil Toronto neil.toro...@gmail.com wrote:

 In my defense, I was talking about framerate, not total or average cost of
 memory management.

That is very different situation.

  Games are really almost real-time apps.

I'd say that they *are* real-time apps.  You really want to be
prepared to redraw
at every frame.  `Hard' real-time GC is possible, but tricky.  With processors
so fast these days, it'd be interesting to do a real-time GC and see how it
performs.  Obviously the total or average delay would be longer, but it'd be
interesting to try to put a hard limit on the pause time and pause ratio.

 I'm still doing the game universe-style, so I haven't moved to mutation yet.
 I'm halfheartedly considering it. I'll probably try an allocation pool of
 same/similar-sized arrays first. I'd gladly pay half of my ideal 16ms per
 frame to eliminate hitches.

I'm currently playing `Red Dead Redemption' and there are a huge number
of `glitches' in the game that are obviously caused by mutation errors
(that is, they didn't do the mutation correctly).  These can
be quite hilarious.  I've seen boxes floating in mid-air, people
buried up to their neck
in the ground (and acting quite non-chalant about it), and one character
was nailing some thin air.



-- 
~jrm
_
  For list-related administrative tasks:
  http://lists.racket-lang.org/listinfo/dev


Re: [racket-dev] P4P: A Syntax Proposal

2010-07-30 Thread Joe Marshall
On Fri, Jul 30, 2010 at 5:30 AM, Shriram Krishnamurthi s...@cs.brown.edu 
wrote:

 My experience teaching Scheme beginners is that Lisp-style prefix for
 arithmetic is NOT a problem; they get the hang of it quickly.  It's
 when things start to nest and parens start to add on that they start
 to get frustrated.  (COND is a special pet peeve.)

If I dig through the remainder of my memory, I recall that I found COND just
a tad tricky.  It was LET that I had problems with.  I used to write
out the expansion
((lambda (foo bar) body) (baz x) (quux y)) and then `unexpand' it
(let ((foo (baz x))
  (bar (quux y)))
   body)

-- 
~jrm
_
  For list-related administrative tasks:
  http://lists.racket-lang.org/listinfo/dev