No.22
Racket is a general purpose programming language descendent of Scheme. Its key features are its powerful hygenic macros, simple module system, and contract-based type system. Racket's designers describe it as "A Programmable Programming Language", with the aim of allowing programmers to easily create and interop DSL's. The way Racket achieves this is primarily through the "#lang" option, which treats libraries as languages, and allows syntax and semantics to be imported, borrowed, extended or completely rewritten.
Racket is prominent in introductory teaching of Computer Science, in courses based around the book How to Design Programs. HtDP takes advantage of Racket's DSL capabilities by providing the student with subsets of the language which gradually introduce more features as they become more experienced with programming.
This doesn't mean that Racket is restricted to teaching. Racket shares many features with other popular languages, and more. Racket has list comprehensions, pattern matching, object orientation, a C FFI, a statically typed variant (Typed Racket), threading primitives, and more. Racket can be thought of as a "batteries included" Scheme, and is a breeding ground for experimental language design.
Have you ever used Racket? What do you like about it? What don't you like about it?
No.23
To start the thread off, here's some GUI code using semaphores for events instead of a callback system.
#lang racket/gui
(define my-frame%
(class* frame% ()
(super-new [min-width 200]
[label "example GUI"])
(define btn-click-evt (make-semaphore))
(define win-close-evt (make-semaphore))
(define both-evt (choice-evt win-close-evt btn-click-evt))
(define btn (new button%
[label "Count: 0"]
[parent this]
[callback (λ _ (semaphore-post btn-click-evt))]))
(define/augment (on-close)
(semaphore-post win-close-evt))
(queue-callback
(λ _
(for ([i (in-naturals 1)])
#:break (eq? win-close-evt (yield both-evt))
(send btn set-label (format "Count: ~a" i)))))
))
(send (new my-frame%) show #t)
(yeild …) is interesting; it essentially blocks on an event (in this case, waits for a semaphore). But it passes control to the UI thread while it's blocking so that you don't have to worry about threading.
No.395
>>23>(yeild …) is interesting; it essentially blocks on an event (in this case, waits for a semaphore)For those who dont know the jargon, is this equivalent to python's await statement?
No.486
>>22> What don't you like about it?Adding unnecessary things like #:term or #rx. I feel like there could've been a more aesthetically pleasing way to do what they do.
No.1616
I would really like to see more production-ready Racket code, it really isn't being used to its full potential as a toy language for learning and education. I guess Clojure and Clojurescript are starting to take the mantle of the hottest production lisp variant lately, but I much prefer the syntax and features of Racket.
No.1631
racket has a really wonky VM that IMO makes it kind of unusable for production environments. Whenever I do something memory-heavy, the GC is slow as hell and sometimes segfaults.
It's great as a toy language, and for low-intensity data crunching. By far the most fun language I've ever coded in. I wouldn't use it for anything where I get in trouble if it doesn't work, though.
No.1632
>>1631This seems like a really easy fix though, look at the notable improvements and optimizations that have been around since Chez Scheme was open sourced and the advances that were published because of it. It is clear that this is a solved issue in the scheme compiler community. I don't understand why Racket should be any different?
No.1633
>>1632Especially since Racket is switching to use Chez as a backend.
No.1692
https://github.com/racket/racket/wiki/Racket2Looks like Racket is planning to move away from s-expressions.
No.1693
>>1692racket already has infix expressions
this is wack
