Re: [racket-dev] A Const type constructor
On 07/25/2012 12:29 PM, Neil Toronto wrote: What if TR had a notion of const-ness, like in C? Suppose (Vectorof A) is a subtype of (Const-Vectorof B) when A is a subtype of B, and (Const-Vectorof A) is never a subtype of (Vectorof B). In C, "const" is a contract on the function type, not on the parameter data type. This can be a very useful contract. Once const applies to a variable, it becomes sticky and requires an explicit (and easily searched) const_cast downgrade to become mutable again. This can be useful and quite annoying. Using const in one spot often causes a snowball effect where it must be manually propagated to other function prototypes. C++ allows certain fields to be marked as mutable, even when the containing object is const. A more dynamic language might be able to decorate the value instead of the function, or at least infer const-ness where possible? - Daniel _ Racket Developers list: http://lists.racket-lang.org/dev
[racket-dev] conditional code [was Re: Best way to handle duplicate identifiers]
On 07/25/2012 04:50 PM, Robby Findler wrote: On Wednesday, July 25, 2012, Doug Williams wrote: Racket now includes nan? and infinite? in the core language, which were already defined and provided by the science collection in PLaneT. I think you're best off to release a new version of the science collection and make it require 5.3 as the minimum version (one that differs from the currently released one only by sorting out this conflict). Newbie question here: Isn't there a way that Doug can write his code such that it provides nan? and infinite?, but only when running on an older version of Racket? Some sort of reader conditional? Thanks, Daniel _ Racket Developers list: http://lists.racket-lang.org/dev
[racket-dev] small documentation bug
In the Racket Guide, the documentation for WHEN and UNLESS says "The result is # in any case." http://docs.racket-lang.org/guide/begin.html#%28part._when+unless%29 I think that is incorrect. The Racket Reference says # is the result only when the body is not evaluated. - Daniel _ Racket Developers list: http://lists.racket-lang.org/dev
Re: [racket-dev] Proposal for a "no-argument"
On 07/01/2012 09:27 AM, Eli Barzilay wrote: There rare cases where it is useful to have a value that means that no argument was passed to a function. In many of these cases there is a plain value that is used as that mark, with the most idiomatic one being #f, but sometimes others are used. IMO, while such uses of #f are idiomatic, they're a hack where an argument's domain is extended only to mark "no argument". I believe this is why CL lambda lists allow another variable name when specifying optional parameters. http://www.lispworks.com/documentation/HyperSpec/Body/03_dab.htm http://www.gigamonkeys.com/book/functions.html (defun f (&optional (arg 'default-value arg-supplied?)) (if arg-supplied? 'real-value 'default-value)) Matlab's nargin and nargout are another interesting approach. http://www.mathworks.com/help/techdoc/ref/nargin.html http://www.mathworks.com/help/techdoc/ref/nargout.html A (supplied? arg) special form might also work. - Daniel _ Racket Developers list: http://lists.racket-lang.org/dev
Re: [racket-dev] interactive hack
On 07/10/2011 01:51 PM, Eli Barzilay wrote: Ok, `4racket' and a beer for anyone who knows why. A pun on forehand? Racketlon? If you're looking for odd names, rash: racket shell riti: racket interactive text/terminal interface and Scribble needs to loose its Scheming name and become Rabble. Otherwise, the "long and obvious" naming style has a lot of merit. - Daniel _ For list-related administrative tasks: http://lists.racket-lang.org/listinfo/dev
Re: [racket-dev] Wikipedia images
On 07/01/2011 04:33 PM, Eli Barzilay wrote: Does anyone know how to deal with updating a wikipedia image? Does uploading a new file to the same name work? - Daniel _ For list-related administrative tasks: http://lists.racket-lang.org/listinfo/dev
Re: [racket-dev] Inline caching (was Re: my '312' this semester, how we compare to others)
On 05/04/2011 03:57 PM, Tony Garnock-Jones wrote: A simple experiment I just performed suggests that a monomorphic inline cache hit can reduce the time needed for a send in Racket from 350ns to around 60ns, which is a massive win. I've attached the program I used to measure this, FWIW. (Run it using command-line Racket, not DrRacket: I got some *very* weird timing artifacts out of DrRacket during this experiment!) The question, then, is: how do we implement MICs or PICs using Racket's macro system? Each send site needs to expand into - a piece of global state - a test involving that global state - a possible update to that global state You might borrow some ideas from this description of call-site caching in SBCL. http://random-state.net/log/3507261942.html Later, Daniel _ For list-related administrative tasks: http://lists.racket-lang.org/listinfo/dev
Re: [racket-dev] racket vs. scheme vs. clojure (as it appears to others)
On 04/29/2011 12:10 PM, Matthias Felleisen wrote: On Apr 29, 2011, at 11:31 AM, Neil Van Dyke wrote: "Scheme" is usually a liability when someone used it in school years ago (other than with HtDP). Sad. but true. Exacerbated by lecturers who refused to keep up with the world around them, thus projecting their failings onto their language of choice. It took me several years to forget and some very "made-for-lisp" coding projects at work before I gave lisp a second try. The PLT logo still messes with my subconscious. You might emphasize that Racket is a "new language, borrowing the best parts of Scheme (and other languages?) and extending it with these features"... Put a big "What is Racket?" link on the Racket home page. Fill it with features and promise. (c.f. http://qt.nokia.com/ or http://python.org/) Also collect a set of "cool" programs for people to use. It is easier for people to understand "this was implemented in Racket" than "Racket's features might let me make that". Many people make decisions based on first impressions. When I was an undergrad, I preferred "Clean" over the ML languages largely because the former had a side-scrolling game demo... Here's another anecdote. http://prog21.dadgum.com/97.html - Daniel _ For list-related administrative tasks: http://lists.racket-lang.org/listinfo/dev
Re: [racket-dev] git error help?
On 04/25/2011 10:32 AM, Robby Findler wrote: Anyone recognize this? (git up is git pull --ff-only --stat --all) C:\Users\Administrator\git\exp\plt>git up Fetching origin error: unable to resolve reference refs/remotes/origin/master: No error From git:plt ! [new branch] master -> origin/master (unable to update local ref) error: Could not fetch origin For the future, try 'git fetch -v origin'. A pull is a fetch plus a merge, this error indicates the fetch was failing, and the verbose fetch might give more diagnostics. The following commands show the settings used by fetch. # git config remote.origin.url # git config remote.origin.fetch Maybe one of them was broken? - Daniel _ For list-related administrative tasks: http://lists.racket-lang.org/listinfo/dev
Re: [racket-dev] my '312' this semester, how we compare to others
On 04/21/2011 01:07 PM, Matthias Felleisen wrote: -B- When it comes to raw computational performance (ignore loading Racket, start from REPL and run a single game -- 10 seconds), my implementation is faster than Python (but barely) and one of the Java implementations. But one Java implementation is 10x faster. My hunch is that our OO system is significantly slower than Java's because we lack types to reduce dispatch overhead. Then again I might be wrong. -- Another possibility is that my extremely heavy use of our wonderful (!) contracts may impose a large overhead. I use mostly ->i and ->m. I'd be curious what your timings are with the contract checking disabled. As for lacking types, types are only useful for primitive optimizations; partial evaluation and code profiling and "inlining" sequential dispatches have the potential to outperform C++ vtables, etc. C/C++ must rely on link-time optimization frameworks and Java is hampered by doing everything at runtime... I think this is a big area of opportunity for lisp systems to regain the performance lead. As to the wider issue, "glue languages" will probably win in the long run; there are huge masses of legacy code, but everybody wants to use a newer language. If you could fairly seamlessly employ a C++ or Java library in lisp... C is dominant largely because it has a simple calling convention. Lisp systems do not... They tend to be frameworks, not externally extensible tools. - Daniel _ For list-related administrative tasks: http://lists.racket-lang.org/listinfo/dev
