Hey @soegaard2, what’s the danish Racket community like? I actually have a danish friend I was trying to convince to learn Racket, we did a few tutorials together when he came over and visited me a few weeks ago! Maybe I could point him to you guys if he decides to learn more!

hey are there any benchmarks for TR vs Racket and possibly other languages (say Python, C and SBCL?)

All the https://benchmarksgame-team.pages.debian.net/benchmarksgame/faster/racket.html seem to be for regular Racket, and since I read that the math library could be as much as 50x faster

I was wondering how TR compared

Could it be that the current directory is "/" when the error is reported, so as a path is shown relative to the current directory, the "/" is just dropped?

Damn, I didn’t say Good Morning Racketnam that’s why no one answered :stuck_out_tongue:

It’s possible that on OSX the window manager launches the app in /… But the open dialog starts in home. Not sure.

@maxim_jaffe Point him here and to the mailing list. I know that Scheme and Racket is used on some of the universities. I don’t know of any user groups though.

hum ok :wink:!

Will do

@maxim_jaffe FWIW, it sounds to me like you might be misinterpreting the effect of TR on performance. The math library is not 50x faster than an equivalent library would be if written in regular (dynamically typed) Racket; rather, using the typed math library from untyped code can result in up to a 50x slowdown. This is not because typed code is especially fast or because untyped code is especially slow, but rather because, in the worst case, the interaction between typed and untyped code can lead to significant overhead.

ah ok! Still it is faster to some degree no?

yeah come to think of the benchmarks 50x doesn’t make sense..!

I mean it helps the compiler yes?

@lexi.lambda Btw - do you have a copy of Lisp In Small Pieces? Queinnec has a nice explanation of dynamic scope.

actually I got a pdf but haven’t read it

I actually came across it while looking at Lisps before settling on Racket

@maxim_jaffe You should take a look at the paper Is Sound Gradual Typing Dead? which includes benchmarks that explore the overhead of typed/untyped interaction. https://www2.ccs.neu.edu/racket/pubs/popl16-tfgnvf.pdf

ok great :slightly_smiling_face:

thanks

Does Betteridge’s law of headlines apply?

@soegaard2 I don’t, but I believe I understand dynamic scope pretty well… but I could be wrong. Everything I’ve read about dynamic scope has been consistent with my understanding (if we ignore concurrency) about how Racket parameters work. My message on the mailing list was mostly intended to get Matthias to explain why he thinks they’re so different. Perhaps you also understand what he’s getting at, though?

@maxim_jaffe I think the authors would like to think so. :)

Hehe :slightly_smiling_face:

thanks for the links and info

By the way joking aside, this slack seems to have more talk at GMT+00 afternoon and evening, is it because most of you guys are in North America?

(GMT+01 to be more precise actually)

I think you got it. But Queinnec has a really good explanation: he compares them, puts them in a historical context, has references etc. In other words LiSP is just the sort of book, you’ll enjoy.

Sure, I believe you! Maybe I’ll see if anyone around here has a copy.

it’s a good book

I remember liking the Lisp–1, Lisp–2, …, Lisp-ω discussion

I can send you the pdf copy I got if you’d like

Hey @lexi.lambda I saw your talk on languages (think before yesterday) and that you mention ideas for graphical DSLs

At my lab they use Stella a lot for building system dynamic models

and I’ve been thinking for ages on building an alternative

fits nicely into the ideas you mention

Racket lookings promising for that

I tried to do something like that in PYthon as a library and although I got a GUI with a sort of similar looks to Stella, but didn’t get the “guts” working

reckon it is way easier in Racket, especially considering there is a specification language for these sorts of models (XMILE https://docs.oasis-open.org/xmile/xmile/v1.0/csprd01/xmile-v1.0-csprd01.html)

@maxim_jaffe I think the most helpful part of this paper for your question is the typed/untyped ratios in figures 4 and 5

Not a fan, @ben? I’m only ribbing, I swear!

:) I just wanted to say “I’m a coauthor and I do not support this message”

I am genuinely curious, actually: how do you feel about the current state of sound gradual typing? It’s been a couple years now since that paper, but it doesn’t seem very optimistic.

yes, and I’m always embarrassed about how little it seems like I’ve done to help

(1) I think we need to give up on the gradual typing dream — that any combo of typed/untyped is going to run quickly

(2) I’m surprised how much better TR is. The benchmarks from that paper are still really slow, but the improvement is way bigger than I would have guessed

I’m hoping to get rid of the disclaimer on the math library before I graduate. But I’m not sure exactly how that’s going to happen

That all makes sense and seems reasonable, and I appreciate your perspective! I’m really just an outsider into all this, so I don’t feel like I really even have an intuition for how big the improvement you mention actually is.

that’s my problem too. I set up a page that describes the benchmarks, but there’s nothing online where people can see the results for Racket v6.2 vs v7 (http://docs.racket-lang.org/gtp-benchmarks/index.html)

That’s a pretty cool scribble document!

Thanks. Here’s a picture with 6.2 (blue) vs. 6.12 (orange) on a few benchmarks. There’s a nice orange sunrise in 3, and the worst-cases (outside the 22x range) are even better — though that’s not likely to make anyone with a 20x slowdown happy.

It seems like a pretty fundamentally hard problem in certain edge cases, but it does seem like there are more non-fundamentally slow cases than one would hope for.

Coming to Racket from C/C++, I thought in terms of “calling a function with arguments” or “passing arguments to a function”. Arguments or args for short. Racketeers would often talk about “parameters” instead of arguments. (Also “apply” vs. “call”, but I digress.) I thought, OK, fine, different jargon. Then I learned about the other parameters (as in parameterize). I thought gee that could be confusing.

In some sense you can treat them as “implicit” “extra” parameters to a function. Things that would be too tedious to supply explicitly all the time.

I don’t have a formal CS education, so maybe I am wandering around here saying something that amounts to a simple, “Yes there’s a some Greek letter reduction for that, obvs”. :smile:

Had to google, but I think “parameter” is used by C programmers too.

I agree that reusing the word “parameter” for something else is confusing for new comers.

What do other languages call parameters (in the Racket sense)?

Aside from Common Lisp and Emacs Lisp, I only know about “dynamic bindings” in Clojure: https://clojuredocs.org/clojure.core/binding

“As of Clojure 1.3, vars need to be explicitly marked as ^:dynamic in order for them to be dynamically rebindable”

I bet the first version of clojure was an interpreter.

@greg I am porting the indentation functions in racket-mode. I am bit confused by this function: https://github.com/greghendershott/racket-mode/blob/master/racket-indent.el#L358

(let ((sym (intern-soft head))) (or (get sym ’racket-indent-function) …)

Does this mean a user can change the indentation function for a particular form, by setting the racket-indent-function property of the symbol?

Emacs Lisp isn’t just a Lisp 2, it’s a Lisp 3!

Seriously: https://www.gnu.org/software/emacs/manual/html_node/elisp/Symbol-Components.html#Symbol-Components

And https://www.gnu.org/software/emacs/manual/html_node/elisp/Symbol-Properties.html#Symbol-Properties

One use of this is to put a property on a symbol, like say with-input-from-port, whose “key” is mode-name-indent, and whose value is info about how to indent.

And then the function that does indentation for a mode, can use that as a kind of hash table to lookup a number or a function to do indent.

And so the user can put a value on a symbol for say their own custom macro, to set the indent.

That function is complicated b/c it’s trying to ignore certain defaults that scheme-mode may have set up, but not ignore values a user may have added.

“That function” = the one you linked

Thanks for the explanation. I’ll use a hash table instead - and store it in a buffer local variable.

I vaguely recall seeing something similar in Chez.

It was for (at least) this issue: https://github.com/greghendershott/racket-mode/issues/219

I think conceptually symbol properties are more like a global var that’s (hash/c symbol? (hash/c symbol? any/c)) — globally, each symbol has a hashtable from symbol to any/c. But, that’s Emacs. Not sure you need to do it like that.

You have a point. A global will do fine.

Speaking of parameters, buffer-local vars are similar in some respects — if you replace “buffer” with “thread”.

@lexi.lambda I replied to the pango issue, happy to talk more about it here

I just want (integer-in 100 1000) to not be so mysterious in the docs, and I think that should be easy to fix in the next few days