search

shriram / smol

The SMoL (Standard Model of Languages) Family of Languages
15 stars 3 forks source link

check for duplicate definitions #3

Open shriram opened 4 years ago

shriram commented 4 years ago

defvar and deffun should probably check for and reject duplicate definitions in some meaningful way. (Though what exactly is a "duplicate" definition? Perhaps we need a list of prior top-level definitions? What about inside nested scopes?)

LuKuangChen commented 2 years ago

dyn-scope-is-bad must have this issue. Are you also referring to other #langs?

shriram commented 2 years ago

Yes, in general, because otherwise people try to use this "feature" to create weird programs that are not actually interesting SMoL programs (this is an artifact of the Scheme/Racket definitions window semantics, not of the standard model).

My ultimate goal here is to keep students focused on SMoL, and not get distracted by Racket-permitted artifacts. The excessively lightweight embedding into Racket means Racket percolates too much, and needs to be blocked more.

LuKuangChen commented 2 years ago

I understand that you want to keep students focused on SMoL. But I can't see how Racket differs from other SMoL languages. AFAIK, Python, Java, and OCaml all allow shadowing, same in #lang smol. Both Java and OCaml disallow declaring one identifier as two variables at the same scope level, also same in #lang smol. (Python is a bit special because it merges the syntax of definition and mutation.)

shriram commented 2 years ago

The problem is that the "top-level scope" is screwed up in so many languages. I don't even think there is a "standard model" — each one is messed up somewhat differently. (And it gets even more complicated when you get to the REPL.)

Given that there is no SMoL for this, I would rather we have a simple and easy-to-understand semantics. That both avoids picking one non-trivial solution out of many solutions where none is standard, AND keeps students from getting caught up in knots.

It seems to me that rejecting programs with duplicate definitions might be the simplest of those solutions.

But if you want to argue for a different semantics, go ahead!