Re: [racket-users] Embedded Racket reimplementation for constrained hardware?
Hi, Marc Feeley has done some work on embedded scheme. Here are a couple of links: http://www.iro.umontreal.ca/~feeley/papers/StAmourBouchardFeeleySW08.pdf http://www.iro.umontreal.ca/~feeley/papers/DubeFeeleyHOSC05.pdf == Arthur Nunes-Harwitt Computer Science Department, Rochester Institute of Technology Room GOL-3509 585-475-4916 == "I don't know what the language of the future will be called, but it will look like LISP." This email is confidential and intended for the named recipient(s). In the event the email is received by someone other than the recipient, please notify the sender at a...@cs.rit.edu. On Sat, 5 Jun 2021, dbohdan wrote: Has anyone tried making a small embedded implementation of Racket? I mean "embedded" not in the sense of 8-bit microcontrollers but more powerful yet still constrained devices, like routers with 64 MB RAM running Linux or the PlayStation 2. I think you don't have to work from scratch to make one. You can implement Racket on top of an embedded Scheme like Chibi-Scheme. It doesn't need to be a full, maximally compatible port of Racket like Racket CS, just a large subset. For example, you can skip futures and places. What features do you need to implement natively in the interpreter rather than in Scheme? You can implement delimited continuations in terms of call/cc. The concurrency primitives (threads, boxes, etc.) and the FFI? You may be able to, but don't have to, optimize the interpreter for immutable conses. This is just something I have been musing about. If no project like this exists, I am not starting one soon. -- 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/da72cdd0-2143-4610-9e4d-f987931c9314n%40googlegroups.com. -- 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/alpine.DEB.2.21.2106070918490.22607%40heracles.
Re: [racket-users] Does Racket interpreter exist?
Hi, While you're enumerating these possibilities, I think it's worthwhile to mention a technique related to the FORTH implementation technique: Marc Feeley style compilation (see "Using Closures For Code Generation" in Computer Language Vol 12 No 1 pages 47-66). This idea is also mentioned in SICP. -Arthur ====== Arthur Nunes-Harwitt Computer Science Department, Rochester Institute of Technology Room GOL-3509 585-475-4916 == "I don't know what the language of the future will be called, but it will look like LISP." This email is confidential and intended for the named recipient(s). In the event the email is received by someone other than the recipient, please notify the sender at a...@cs.rit.edu. On Wed, 29 Jul 2020, Hendrik Boom wrote: On Wed, Jul 29, 2020 at 01:56:05AM -0700, zeRusski wrote: This is a really cool piece of history! Thank you. I'll admit I'm somewhat fuzzy here - it maybe a bit too meta for me or perhaps I don't quite understand what you're trying to say. Isn't interpreting n levels deep also linear in n? Answer 1. Let's say, for example, that it takes 10 instructions executed in an interpreter to decode, take decisions, and execute an interpreted instruction. (In real life this varies a lot between interpreters and between interpreted instructions but let's keep the example simple.) (and, also to keep things simple, let's say the interpreter in interpreting the machine language of the machne it's running on -- not an unusual technique in a debugger.) Then interpreting a program using an interpreter running on hardware would take ten times as long as executing the program on the same hardware. And likewise, interpreting the program in an interpreter being interpreted by the interpeter running on the hardware would take another ten times as lng as just interpreting the program with an interpreter running on the hardware. Thus 10 x 10, times as slow; this is where the exponential comes in. Only difference between the two approaches I see is that compiler lets you persist the fruits of its labor so you don't have to start from scratch every time. Couldn't you accommodate this with an interpreter (with some effort) although at this point it becomes a compiler I suppose. Definitely fuzzy here. That is exactly the difference between a compiler and an interpreter. Answer 2: Time to muddy the situation. There are mixed-style language implementations. If you only execute each piece of code once, interpreters tend to be faster. But if you are to execute code many times, it's faster to compile. It takes time to compile, but you get it back by saving time in later executions. So what thee mixed implementations to is to interpret the code, but keeping track how often each piece of code (such as a function) is called. When the count reaches a particular threshold, it pauses interpretation and compiles that code, the compiled code to be used thereafter. There is some time penalty over compilation, because you waste time interpreting functions several times before you compile them. This is offset by not having to compile code that is used only a few times. The time behaviour of this kind of system overall is more like a compiler than an interpreter because the code that is executed the most does eventually get compiled and the rest gets interpeted only a limited number of times. However, if it were to execute a copy of its own code, it would have to recompile it, unless it had a mechanism to check if the newly input program is the same as one it has already compiled. This isn't impossible, but is not usually done. But when going n levels deep, the total execution time with a compiler is linear in n, and with an interpreter it's exponential. I use this criterion to tell whether a particular implementation is more like an interpreter or a compiler. That makes interpreting interpreters impractical when n gets large (even with n around 3 or 4); whereas compiling compilers can be done even for larger n. Answer 3. On modern machines, it is also important to keep memory demands low. Accessing large amounts of memory regularly tends to push other data our of cache, or even out of RAM onto disk. Conserving storage is a common reason for using interpreted bytecode as the target language for a compiler. The bytecode is usually smaller than the machine language. If the bytecode interpreter is small enough, this is a definite win. Bytecode was first used, as far as I know, on machines with small memories -- about 64K RAM total or even less. Byte-code can also be portable. You just need to write a (usually amall) bytecode interpreter for each new machine. Of course it's still possible to, at run-time, compile the most-used byte-coded functions in to actual machine code to trade memory use for execution time. A
Re: [racket-users] R6RS history
Dear Matthias, Would you be willing to share your thoughts about the history of denotational versus operational semantics in the report? Thanks. == Arthur Nunes-Harwitt Computer Science Department, Rochester Institute of Technology Room 70-3509 585-475-4916 == "I don't know what the language of the future will be called, but it will look like LISP." This email is confidential and intended for the named recipient(s). In the event the email is received by someone other than the recipient, please notify the sender at a...@cs.rit.edu. On Tue, 26 Feb 2019, Matthias Felleisen wrote: Let me inject some comments that make it a bit more obvious what’s happening here: On Feb 26, 2019, at 3:33 PM, Sam Tobin-Hochstadt wrote: RnRS meetings from 1984 thru 2003 adhere to the “unanimity rule” originating from the MIT group. In 2001, I created and ran “Scheme and Functional Programming” (SFP), a first annual Scheme workshop that also subsumed “Scheme Report” meetings. 2003: New Scheme Standard proposed at the Scheme Workshop At the 2003 Boston SFP, I proposed going to a majority rule so that the Scheme standard could grow into a useful language after a long long day, with many people gone. The motion passed. 2006: First draft of R6RS released 2007: R6RS Ratified by community vote after extensive discussion and revision I wrote an essay entitled “The R6RS is Perfect”. The certification vote succeeded with just a few votes more than needed (60% or 66% or something like that). 2009: A new Scheme Standard steering committee elected by a community vote. The new committee reflected opposition to the R6RS. (as in “community vote” by another Scheme workshop) We, the Racketeers, didn’t want to be in their way so we wrote this: https://racket-lang.org/new-name.html History is history. The future you can change, unless Gödel is right about Einstein’s equations and it’s practical. — Matthias -- 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. For more options, visit https://groups.google.com/d/optout. -- 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. For more options, visit https://groups.google.com/d/optout.
Re: [racket-users] C level bit manipulation - Racket Manifesto
Hi, Racket seems to depricate redefinition of functions at run-time. Since Racket isn't Scheme, why not prevent that and get back that performance? -Arthur == Arthur Nunes-Harwitt Computer Science Department, Rochester Institute of Technology Room 70-3509 585-475-4916 == "I don't know what the language of the future will be called, but it will look like LISP." This email is confidential and intended for the named recipient(s). In the event the email is received by someone other than the recipient, please notify the sender at a...@cs.rit.edu. On Mon, 13 Aug 2018, George Neuner wrote: On 8/13/2018 10:02 AM, 'Paulo Matos' via Racket Users wrote On 11/08/18 19:41, Sam Tobin-Hochstadt wrote: > There are basically two differences between the `unsafe-lsb` function > in Racket and the C one: > - the Racket calling convention vs the C calling convention > - the instruction used to perform the LSB calculation > > For a variety of reasons Racket's function calling convention is more > heavyweight than C's, but if that code is inlined into some larger > function that will go away (as it would in C). The simpler instruction > used by the C compiler is because the C compiler recognizes that > pattern of bitwise and, whereas the Racket JIT does the obvious `and`. > That could of course be fixed in the JIT, although it's not clear how > much of a win it is. Is this something that will change with Racket-on-Chez? i.e. Racket will then use the Chez optimizer to generate machine code? Racket's function call convention is heavier than C's because it has to deal with the possibility that functions may be redefined at runtime, or may be overloaded ... things C does not have to deal with. The same function may have multiple entry points depending on number of arguments, or presence of keywords, etc. And functions that may be redefined must be called indirectly to avoid (re)patching every call site when/if the definition changes. These things make (average) function calling in Racket slower than in C. It is expected that the Chez compiler will do a better job at optimizing code, but it can't overcome differences in call semantics. If you do something "schemely" with your functions, then you WILL pay the price for it. George -- 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. For more options, visit https://groups.google.com/d/optout. -- 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. For more options, visit https://groups.google.com/d/optout.
[racket-users] Re: Algol
Dear Dupéron, Thanks for looking into the issue. I am running Racket 6.7. Algol 60 is an option in the Other Languages section in the Experimental Languages sub-section. I don't remember which version used to work. I may have raised this same question last year. I would guess that it was working in version 5.*. Thanks again. == Arthur Nunes-Harwitt Computer Science Department, Rochester Institute of Technology Room 70-3509 585-475-4916 == "I don't know what the language of the future will be called, but it will look like LISP." This email is confidential and intended for the named recipient(s). In the event the email is received by someone other than the recipient, please notify the sender at a...@cs.rit.edu. On Sun, 9 Apr 2017, Dupéron Georges wrote: As you say, it works with "#lang algol60", but I can't find "Algol60" in the language selection dialog on DrRacket 6.9.0.1, only R5RS, "Pretty big Scheme" and "ProfessorJ" (which I installed manually). Which version are you using? Which version were you using when it used to work?This may help others diagnose your issue. -- 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. For more options, visit https://groups.google.com/d/optout.
[racket-users] Algol
Hi, The following Algol program used to work in DrRacket with the language Algol 60 selected. begin integer i; real procedure sum(j, lo, hi, term); value lo, hi; integer j, lo, hi; real term; comment term is passed by-name; begin real temp; temp := 0; for j := lo step 1 until hi do temp := temp + term; sum := temp end; i := 1; printnln(sum(i, 1, 100, i)) end Now it gives the following error. for-body96339: unbound identifier; also, no #%top syntax transformer is bound in: for-body96339 Has something changed? It does seem to work in Racket with a #lang directive, and simpler Algol 60 programs do work in Algol 60 mode. Why should this be? Thanks. -Arthur == Arthur Nunes-Harwitt Computer Science Department, Rochester Institute of Technology Room 70-3509 585-475-4916 == "I don't know what the language of the future will be called, but it will look like LISP." This email is confidential and intended for the named recipient(s). In the event the email is received by someone other than the recipient, please notify the sender at a...@cs.rit.edu. -- 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. For more options, visit https://groups.google.com/d/optout.
Re: [racket-users] Literate program a math course with Racket?
Dear Lawrence, You may want to check out Peter Norvig's _Paradigm's of AI Programming: Case Studies in Common LISP_. -Arthur == Arthur Nunes-Harwitt Computer Science Department, Rochester Institute of Technology Room 70-3509 585-475-4916 == "I don't know what the language of the future will be called, but it will look like LISP." This email is confidential and intended for the named recipient(s). In the event the email is received by someone other than the recipient, please notify the sender at a...@cs.rit.edu. On Mon, 28 Nov 2016, Lawrence Bottorff wrote: I'm tackling SICP -- using Racket and Emacs/orgmode, which I think is the best combination (YMMV). I like SICP because it puts computational math in the mix of learning functional programming. Then Sussman did SICM (...Classical Mechanics; 2nd edition) -- which is way over my head. But again, it is the spirit of literate programming where the math and coding are combined, i.e., you don't sit in the vacuum of theory only, but code what you're learning. But on the other hand, there are all the math packages: Maxima, Matlab, Mathematica, etc., where the programming has been done, or they want you to do code snippets in their own blub syntax. Most computational texts use these. So is there anyone doing what Sussman and Wisdom did with SICM? For example, how would you do derivatives and integration and differential equations in Racket? A while back I found Steven L. Tanimoto's "The Elements of Artificial Intelligence Using Common Lisp," which had some basic POC derivative-itegration code. I will look at the OCW's "Classical Mechanics: A Computational Approach" (12.620J / 6.946J / 8.351J) in the Earth, Atmospheric, and Planetary Sciences section. So, yeah, is there anything going on with the SICM style of literate programming a math course? LB -- 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. For more options, visit https://groups.google.com/d/optout. -- 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. For more options, visit https://groups.google.com/d/optout.
[racket-users] Algol 60
Hi, I'm using Racket v6.4. I tried to run an Algol 60 program (that worked in the past) by selecting the Algol 60 option in the experimental languages section. I got the following error message. for-body43686: unbound identifier; also, no #%top syntax transformer is bound in: for-body43686 Is Algol broken? Is it still supported? Thanks. -Arthur == Arthur Nunes-Harwitt Computer Science Department, Rochester Institute of Technology Room 70-3509 585-475-4916 == "I don't know what the language of the future will be called, but it will look like LISP." This email is confidential and intended for the named recipient(s). In the event the email is received by someone other than the recipient, please notify the sender at a...@cs.rit.edu.
