Apologies for the long mail. I wanted to get these thoughts out now while they are fresh. Tom
Can Racket make semantics a matter of syntax? If it can, can it produce errors when certain syntactic forms are incompatible with the specified semantics? Can all forms in the language be mapped to all runtime features such that each form can be marked as compatible or incompatible with each feature? #+proper-tail-calls #+continuations #+delimited-contiuations #+unwind-protect #+strong-static-types #+event-loop #+interpreted-same-as-compiled #+jit #+c-preprocessor-style-macros I was revisiting slib today. I tried to port it about 3 years ago, and had had no success. Does LOP work? This is an academic question. Can we convince new, untrained folk, to use LOP? This is a promulgation question. I think that one powerful argument in favor of LOP would be to use the Racket ecosystem to implement and support the entire history of scheme programs. This demonstration would be a feat that to my knowledge no other programming environment has ever been able to achieve. Schemes are notorious for their ... creative extension of standards. If Racket can demonstrate and provide a practical solution for taking random scheme code (e.g. by adding #lang r4rs as the first line of a file), and having the semantics just work, then that would be game changing beyond the wildest dreams of even the most cynical academics. This couldn't happen without a monumental effort to provide facilities for capturing language semantics in a meaningful way beyond simple syntax. This thread started as syntax, but the quote from Matthias during the introduction to Racket School seems quite relevant. The real prize here is not in creating the greatest syntax ever known to humanity [0] but in the mapping between syntax and semantics. Of the many goals that Racket2 could pursue, this seems like the one that could have the most lasting impact. Leave the syntax to #lang algo-me-harder. Syntax can devolve in a political issue, and in the happy realm of Turing completeness everyone can have whatever they want as far as syntax is concerned. You can have all the unicode delimiters you want, I just need my λ. The real challenge (it seems) is to provide a tool that makes it possible to translate the semantics of one language to another in a way that is consistent, understandable, and ideally, performant. (If it is not performant, then an even greater prize would be to be able to show which syntactic feature was missing performant semantic support in the offending runtime.) It seems to me that Matthew has paved the way for this. The differences in semantics between Chez Scheme and Racket and Matthew's solutions provide solid examples for future semantic extensions to Racket. They also provide a taxonomy of the kinds of changes that would need to be made other runtimes to support a performant implementation of Racket's syntax. I can appreciate why Matthew might like to consider alternate direction after having spent the last 2 years working on performance optimizations and semantics translation. However, I wonder whether the knowledge gained as a result is equally valuable. Could it be implemented into Racket itself? Said another way, can we have #lang common-lisp with all the syntax, working as a Lisp-2, and have a performant implementation of unwind-protect that can be used in `#lang r4rs with-extended-semantics`? Even if we couldn't do this, could Racket be the place where we can prove (by virtue of the machinery that it provides) that continuations and unwind-protect are incompatible at a fundamental level? Matthew's work also means that a solution to this problem might also look like a page in the documentation which provides a comprehensive overview of which runtimes provide performant and correct implementations of certain language features, allowing users to choose their runtime to fit their needs. >From a practical standpoint, writing new code almost seems silly when you can burgle libraries that have had man centuries of development put into them by writing the translation layer for the semantics -- especially if we get Racket's support for locating bugs by way of syntax objects. This vision for Racket2 is beyond pie in the sky, and perhaps a departure for the usual vision for LOP, but I wonder whether Racket is now ideally poised to act as the bridge for the infinite and as yet unimagined syntaxes of the future and the enormous variety of existing runtimes. I consider it a mark of the maturity of the community that leadership is planning how to manage the community politics around the next phase of the language, well in advance of any transition. However, I can't help but wonder whether there are goals that we all agree on that would avoid the need for a political process altogether. Maybe the objective of the political process should be just that -- to find a direction which obviates the need for said process. --- [0] The idea that there can be "One syntax to rule them all" seems a fundamental fallacy to me. Human brains are different. They prefer different things for structural genetic reasons, as well as for reasons of habit and familiarity. Trying to optimize for a single most-appealing form will always alienate someone. Of all the languages out there, Racket and LOP seem ideally poised to achieve such an individual fit [1]. [1] https://www.thestar.com/news/insight/2016/01/16/when-us-air-force-discovered-the-flaw-of-averages.html --- On a completely unrelated note: while we are thinking about the future, an industrial strength package manager could be a huge boon. Obstacles to ideas come in many forms, and over time I have found that running the first hello world program on a system can be on of the hardest and most time consuming challenges. Reducing the friction all around the ecosystem seems like it might have the same kind of effect of making any tiny micro optimizations in a compiler. Individually they don't seem to make any difference, but together they are revolutionary. -- You received this message because you are subscribed to the Google Groups "Racket Users" group. To unsubscribe from this group and stop receiving emails from it, send an email to racket-users+unsubscr...@googlegroups.com. To view this discussion on the web visit https://groups.google.com/d/msgid/racket-users/CA%2BG3_PPkkRqg0uOcV_d%3DxA4wGkc9%2BVeWFWCaZpXQ71vRE1662Q%40mail.gmail.com.
