[racket-users] [package announce / RFC] Extenor
Hello, Today I uploaded an experimental package that I made called Extenor[1]. Extenor is a shortened name for “Extensible Nominal Record”. The key goal behind it was to have something like Racket's structs that can have struct-type-properties, but also be extensible and keep extensions when functionally updated (unlike Racket's structs). Secondarily, but similarly, I wanted a low-hassle flexible dictionary-like object for use in Rash pipelines that has struct-type-properties that let it hook into various generic interfaces. Eg. imagine an `ls-in-racket` that returns a dictionary with a bunch of information about each file that can be easily filtered, augmented, etc, but that also implements a hypothetical `prop:path` that allows it to be used with `open-file` and other functions that accept paths. I've talked to a few people about the functional update of extended structs problem before, so I thought I would reach out and ask for comments on this design. It's somewhat shoe-horning two problems into one solution, but I find that I like it so far, at least for the uses I imagine. A more strictly struct-like version of this with extenor-ref/extenor-set removed might be better for general-purpose uses. I haven't really read the literature on mixins and multiple inheritance, so I can imagine this design could be falling for some classic design blunders, and I'm open to any suggestions on good papers or other resources to read about that. [1] https://pkgd.racket-lang.org/pkgn/package/extenor (At the time of writing, the package system reports on a version that has a bug in Racket BC because I originally only tested it on Racket CS, and the hosted documentation doesn't have examples in the Guide section while the git master branch does. So... if you want to play around with it or read the docs you might want the git version until the package server runs again...) Thanks, William Hatch -- 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/20201220041729.GA19473%40conspirator.
Re: [racket-users] Towards an Incremental Racket Parser for better IDE experience?
On Wed, Dec 02, 2020 at 01:56:41PM -0500, Sam Tobin-Hochstadt wrote: A few thoughts on these topics, which I've been thinking about for a while. First, let's distinguish two things. One is an _incremental_ system, such as a parser, which is one which does less work in response to a small change than it would need to do from scratch. The other is a system with _error recovery_, which is one where in the presence of one error, the system can still provide a useful answer and/or continue on to discover other errors. tree-sitter, for example, aims to do both of these, but they're quite different. I thought I might as well chime in here that I'm currently working on an incremental parsing system for Racket that will support parser combinators, BNF, and arbitrary ad-hoc parsing procedures. I already have a parsing system[1] that supports expressive parsing with any mix of those constructors that supports all context-free grammars and beyond, so that much is already “successful”. Unfortunately, I haven't been able to make it as performant as I would like. The original goal wasn't to support incremental parsing, and I didn't write incremental support into that implementation. However, while trying to optimize it I also decided to figure out how to make it incremental, so now I have the solution for that too. I'm now working on another similar parsing system that is a little less expressive (in particular it has more limited support for ambiguous grammars, and thus doesn't support the full class of context-free grammars, though it will still support useful things outside of CFG, such as non-CFG things that Racket and Scribble parsers do), but should be much faster (because it gets to avoid extra work supporting the possibility of ambiguity). I'm adding my solution to incremental parsing support to this version. If I can ever make the original algorithm faster I'll add incremental support to it too. Both systems leverage delimited continuations at their core -- it turns out they are really useful for parsing, both for improving expressiveness and for incrementality. That said, I'm not currently aiming to solve the error recovery part of the problem. [1] https://github.com/willghatch/racket-chido-parse -- 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/20201214234324.GA13213%40conspirator.
[racket-users] [ANN] Xsmith 2.0
Announcing the release of Xsmith version 2.0! Xsmith is a DSL for making random test case generators (fuzzers) for programming language implementations. Xsmith is designed to generate valid test cases that can be used for differential testing between multiple different implementations of programming languages. Xsmith version 2 is not backwards compatible with version 1, but it's pretty easy to upgrade if you happen to have written a fuzzer with Xsmith version 1. Many things have improved since version 1: • Improvements to the type and effect systems, including subtyping support. • New ways to control the order of subtree generation and refine programs. • Better interfaces featuring less boiler-plate code. • Integration with the Clotho[1] library to provide Zest[2]-style support for feedback-directed fuzzing. • A library of drop-in components for common language constructs. • Many bug fixes, so there should be fewer (or at least different) bugs! • Improved and expanded documentation. Xsmith is available as the `xsmith` package, with example fuzzers in the `xsmith-examples` package. xsmith package: https://pkgd.racket-lang.org/pkgn/package/xsmith xsmith-examples package: https://pkgd.racket-lang.org/pkgn/package/xsmith-examples source code repository: https://gitlab.flux.utah.edu/xsmith/xsmith [1] - Clotho package: https://pkgd.racket-lang.org/pkgn/package/clotho paper: https://www.flux.utah.edu/paper/darragh-scheme20 [2] - Semantic Fuzzing With Zest by Padhye et al: https://doi.org/10.1145/3293882.3330576 -- 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/20200901201903.GA32539%40conspirator.
Re: [racket-users] [ANN] Transducers library
On Wed, Oct 23, 2019 at 12:39:43PM -0700, Jack Firth wrote: and it uses *no macros at all*: Gotcha! You're using the `define` and `#%app` macros in this example, aren't you! More seriously, ever since I watched a Rich Hickey talk about transducers I've wanted Racket to have them. Thanks for making this; I'm excited to use it. -- 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/20191023200629.GA23461%40conspirator.
Re: [racket-users] make extensions or replacements
On Tue, Apr 16, 2019 at 04:55:49PM -0400, Hendrik Boom wrote: On Tue, Apr 16, 2019 at 10:13:47PM +0200, Jens Axel Søgaard wrote: Hav you tried the make library? https://docs.racket-lang.org/make/index.html?q=make If you like Racket's make library but want something a little more shell-like, I made a toy rash/demo/make language that has something closer to a traditional `make` feel. It's definitely a toy now, but I don't think it would be a huge project to make a version that is more reasonably useful. I'm not offering to do that right now, but I'm offering it as an idea you can chase if you like. (Someday I'm likely to do it myself. But not in the immediate future.) -- 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] Escaping strings for the shell
On Tue, Jan 15, 2019 at 04:11:39PM -0500, 'John Clements' via Racket Users wrote: Does rash have autocompletion of paths, yet? That’s my one super-super wishlist item. It has some basic path autocompletion -- if you type `ls /e` and hit tab it will complete to `ls /etc/`, and you can hit tab again for a list of files/directories in /etc. But it doesn't see through variables or anything that needs to be evaluated, and completion is not really very programmable at all. On Jan 15, 2019, at 6:17 AM, 'Paulo Matos' via Racket Users wrote: I am surprised nobody mentioned Rash. I have been using it for all my shell scripting needs and it's awesome. https://pkgs.racket-lang.org/package/rash On 29/12/2018 05:09, David Storrs wrote: I am using 'system' to offload some work onto wget and other applications in a few one-off scripts. Is there an easy way to escape a string so it's suitable for usage in the shell? Things like backwhacking all the quotes and relevant spaces and such. -- Paulo Matos -- 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. -- 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] LOP cultural anthropology, phases
I just read “Language Oriented Programming in Racket: A Cultural Anthropology” on my flight home from Racketcon. I enjoyed reading it, and recommend it. One point I noticed was that the most common response to the question of “What is difficult about LOP?” seemed to be phasing. I propose a mode in DrRacket (maybe with infrastructure that can be shared by other editors...) that shows different phases in different colors. Eg. all code in phase 0 is yellow, phase 1 is green, phase 2 is blue, phase -1 is orange, phase -2 is red, and you see the color change under define-syntax, syntax, unsyntax, begin-for-syntax, etc. Since we already have binding arrows and know what phase they're bound at, coloring the identifiers probably shouldn't be too hard. Of course, I'm not volunteering to make it, just asserting that it seems like it would be nice. ;) Thanks, everyone, for a fun Racketcon! -- 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] Re: Concise way to get completions for Racket code?
On Wednesday, February 7, 2018 at 5:12:00 PM UTC-6, noch...@gmail.com wrote: My google-fu is failing me today. Is there a concise way in Racket to request possible completions for some Racket code? Another function that may be useful for you is `namespace-mapped-symbols`. The readline library uses this to provide completion in the repl. -- 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] switching to an alternate syntax using a lang extension: binding issues
On Thu, Nov 09, 2017 at 11:23:47PM -0800, Vincent Nys wrote: Hi, I have a domain-specific language with a non-parenthesis-based-syntax and running programs written in this DSL sometimes leads to the creation of some fairly large data structures. By "large" I mean that it is still feasible to type them out, but an absolute drag. Doubly so when I have to translate back and forth between the DSL syntax and Racket's syntax for the data structures that are used internally. So I started working on a language extension (called alpha-gamma) which allows me to switch to the DSL syntax inside a #lang racket program by typing α(...) or γ(...), where ... is in non-Racket syntax. I'm struggling a bit with the Racket reference, but by looking at some other language extensions, I figured out how to do most of this with make-meta-reader. I don't understand how the whole process works, though, and now I'm stuck with unbound identifiers in files using the extended language. Specifically, in a file called test.rkt written in #lang alpha-gamma racket I have α(foo(bar)). The part between the outer parentheses is then parsed as '(abstract-atom (abstract-atom-with-args "foo" "(" (abstract-term (abstract-function-term "bar")) ")")), which is what I want. But the bindings for abstract-atom, abstract-atom-with-args, abstract-term and abstract-function-term are missing in test.rkt. I can get the value I want by adding (require (only-in cclp/cclp-expander abstract-atom abstract-atom-with-args abstract-term abstract-function-term)) at the top of test.rkt, but I don't want to do that wherever I use the language extension. I guess these are the most important bits: (define (wrap-reader reader) (define (rd . args) ; reader can read multiple datums at once... (parameterize ([current-readtable (make-αγ-readtable (current-readtable))]) (apply reader args))) rd) (define-values (αγ-read αγ-read-syntax αγ-get-info) (make-meta-reader 'αγ "language path" (λ (bstr) (let* ([str (bytes->string/utf-8 bstr)] [sym (string->symbol str)]) (and (module-path? sym) (vector `(submod ,sym reader) (string->symbol (string-append str "/lang/reader")) wrap-reader wrap-reader (lambda (proc) ; don't really care too much about get-info right now (lambda (key defval) (define (fallback) (if proc (proc key defval) defval)) (case key [else (fallback)]) What I get from this is that my extended language still produces a module like a regular language, but (require (only-in cclp/cclp-expander abstract-atom abstract-atom-with-args abstract-term abstract-function-term)) should be spliced into this module somehow. Any suggestions on how to pull that off? To have those identifiers available to everything in the module (including both inside the α language and the γ language) you can have your #%module-begin add a require form to the basic #%module-begin form it creates. But for the binding to be visible, it needs to have a subset of the scopes that identifiers used in the module will have. To do that you can make the syntax objects for the identifiers required using `datum->syntax`, using the syntax of the #%module-begin (or in this case just #f would make them visible to the whole module). I would also recommend looking at two projects that attack similar problems. One is my Rash package[1], where I have a macro called `rash` that lets you embed code in a particular non-s-expression syntax inside normal Racket (and also allows escaping back into racket and nesting arbitrarily deeply). You can use it to write things like this: (let* ([project-dir "my-racket-project"] [rktfiles (rash «cd $project-dir ls | grep rkt |> string-split _ "\n"»)]) ...) The key thing that I think you might find appealing about rash's method of embedding is that rather than trying to have one reader at the top level that can read multiple languages, it instead delimits sections of code that a macro can apply a different reader to during expansion time. The other project you should look at is Michael Ballantyne's multiscope package[2]. It essentially lets you switch back and forth between two different namespaces within one module. This could let you eg. have different bindings visible inside the α and γ blocks (if eg. α and γ use the same name for semantically different things). [1] https://github.com/willghatch/racket-rash [2] https://github.com/michaelballantyne/multiscope -- 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] Re: preferences file
Recent discussion thread: https://groups.google.com/forum/#!topic/racket-users/6hn9J-r0Nek Since we're discussing dotfiles and I missed the previous thread, I'm going to shamelessly promote my basedir package[1], which provides functions for conveniently reading/writing config files according to the XDG base directory specification (eg. in ~/.config/, or similar directory on Windows) respecting the standard environment variables. Using the standard also makes it more convenient for a user to have parts of their configuration in multiple files, eg. having both public and private components, as well as local and global components, and have the parts composed together. Let's not clutter up home directories anymore with one-off config files or directories. Let's let them live in a sane and configurable space. [1] http://docs.racket-lang.org/basedir/index.html -- 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] Plumbum for racket
I wrote a couple of libraries that address this. As was mentioned, there's Rash, which lets you swap back and forth between normal racket and a more bash-like syntax for running pipelines. There's also the shell-pipeline package, which provides the runtime functions behind rash and lets you run pipelines with a more normal lispy syntax. They aren't stable, but the shell-pipeline package is... closer to being stable. As an aside, for all those who asked if I was using rash as my daily-driver interactive shell at Racketcon: while the answer was unfortunately "no" at Racketcon, it is now "yes" because I've added some completion. But it only works with the git version of the readline package. That said it's still missing several important features, but I would love it if some Racketeers would try it and give me feedback on it (what do you like, dislike, how would you improve the API before I say it's stable and have to live with it forever, etc, both at the rash and shell-pipeline layers). On Tue, Oct 24, 2017 at 08:33:07PM +0200, 'Paulo Matos' via Racket Users wrote: Hi, In Python I see myself using plumbum (https://plumbum.readthedocs.io/en/latest/) on a regular basis to do shell related stuff instead of messing with subprocesses. Is there anything remotely like this for racket? Kind regards, -- Paulo Matos -- 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] Rackterm error
On Tue, Sep 05, 2017 at 05:07:41PM -0400, James wrote: I'm trying out Rackterm for the purpose of running commands put together from a GUI but it looks like the thread is crashing as soon as I try to create a terminal canvas. Is it something I am not doing right or is there a bug? I am able to run rackterm/xterm without error and that contains very similar code. Here's my code: #lang racket (require racket/gui rackterm/private/terminal-canvas ) (define frame (new frame% [label "Example"] (width 800) (height 800) )) (send frame show #t) (define my-term (new terminal-canvas% [parent frame] [font-size 14] [font-name "Courier"] [term-var "rackterm"] [command-and-args '("ls -lh")] [set-title-callback (lambda (title) (send frame set-label title))] [horiz-margin 2] [vert-margin 2] )) The terminal window appears and then immediately closes with the following error message: "The evaluation thread is no longer running, so no evaluation can take place until the next execution. Exited successfully." Well, this is caused by my not having actually cleaned up the code for it to be used in any sort of general way, rather than specifically only by my one xterm (hence terminal canvas is still in the private directory). But there is a `handle-subproc-ended` method that I put a TODO in to make it configurable, but currently just kills the canvas, because usually you want an xterm to close when the shell inside it exits. But you could make a subclass that overrides that method, or even better, improve my bad code and send a pull request. Or eventually I'll fix things up and release them properly. Also '("ls -lh") should be '("ls" "-lh"). -- 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] GUI for ffmpeg and mrlib/terminal
On Wed, Aug 30, 2017 at 09:57:01AM -0400, David Storrs wrote: Still, I'm also interested in the original question: if I wanted an interactive GUI terminal in Racket, what's the best way to do it? Another thing you can look at is my Rackterm package[1]. It is currently an undocumented mess (and the first Racket project I made over a couple hundred lines), but it is also a reasonably compliant xterm that handles colors/styles, curses applications (eg. emacs and vim work fine in it), etc. I've always intended to clean up the parser and make it available as a library for applications that want to parse and use input with ANSI control characters in it, make the various pieces available as stable interfaces for embedding terminals into applications, etc. I haven't gotten around to doing that, but there is an unstable terminal-canvas.rkt that provides the terminal gui widget. [1] https://github.com/willghatch/rackterm -- 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] Re: Readers and Namespaces
On Thu, Aug 17, 2017 at 10:11:12PM -0700, Alexis King wrote: Generally, my recommendation is to essentially define your language in two passes: a direct translation to s-expressions, followed by a phase of macroexpansion. The first phase is what your reader interacts with. Give the primitives that your reader produces names that are unlikely to conflict with users’ code — specifically, prefix them with “#%” so that they are clearly special. It can also be useful to include characters in the identifier names that aren’t even valid identifier characters in your language, but this is not always possible if any character can be legally used in an identifier. Either way, this means your my-let macro should likely be named something like #%let or #%my-language-let, and your reader produce syntax objects without lexical context that use these #%-prefixed primitives. Just a clarification about how `#%` is special: in general identifiers prefixed with `#%` signal that they may be redefined for other languages. For instance, identifiers like #%app, #%datum, #%module-begin, etc, are added by the macro expander at various points and people are invited to implement new versions of them when making a new language so that these positions in a program mean something different. So if your reader may be used by multiple languages, beware that you are communicating that #%whatever is a place where you invite the new language to hijack it. It feels a little inelegant that Racket’s hygiene system does not extend to read-time, since it means the sort of hacks necessary in unhygienic languages are sometimes necessary in Racket when implementing a reader. Fortunately, a reader is much more self-contained and smaller in scope than a macro-enabled language, so it usually isn’t a big deal. Perhaps some language will eventually motivate a hygienic reader layer, but Racket doesn’t current have one. The problem is that the guarantees of separate compilation (all the stuff about module visits and instantiation) only apply to expansion, not reading. However, if you write a macro that uses `read-syntax` and returns the result, you can have binding information on the syntax objects and it will work as expected -- the visit and instantiation guarantees will be enforced because you are in macro-expansion time, not the initial read time. If the initial `read-syntax` used on a module were treated as if it were a function used in phase 1, and the visits and instantiations of the modules used by the reader were done as they are with expansion, I think it would work for the reader to return syntax objects with binding information. -- 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] Printing Quickly
On Fri, Jul 28, 2017 at 11:55:14PM -0700, Lehi Toskin wrote: On Tuesday, July 25, 2017 at 9:07:14 AM UTC-7, Jens Axel Søgaard wrote: The Interaction Window in DrRacket supports snips, picts etc., so it is reasonable that is slower than a terminal. But ... maybe it is possible to let the user choose a simpler interaction window. One that only supports text? As a feasibility experiment, is William Hatch's terminal faster than the DrRacket interaction window? https://github.com/willghatch/rackterm /Jens Axel Actually, using rackterm with some script that prints a lot will make the rackterm terminal freeze up. I have to kill the process before anything visible happens. Late to the party because I was in the wilderness for a week. Rackterm is probably significantly worse than the DrRacket interaction window. Rackterm currently does nothing very clever, just draws on a canvas% for printing, and is very slow. It's the main reason I still can't really use it as a daily-driver terminal emulator, so it's high on my list of priorities for Rackterm. But Rackterm isn't high on my list of priorities right now, so... -- 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] Replacing multiple characters in a string?
Or, arguably, not Rackety enough, until it's possible to embed one #lang within another (submodules at least, but hey why not lambdas?) I've been exploring this more and more. It is related to my shell project (rash, which does allow embedding at the expression level), and I've been thinking about it a lot in relation to other things I want to do or have otherwise been considering. Some time soon I'll have to write up my thoughts on the subject. -- 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] Boot To Racket
I would love to see a Racket unikernel, and be able to essentially run a modern Lisp machine. That seems like a really big project, but I guess I have no real understanding of how big it would be, or what parts you could use off the shelf (eg. from OS-kit. I understand this was done before in Racket some years ago). But I recall some talk about MirageOS (I think) where they said something about it taking something like 2 years to rewrite the IP/TCP stack in OCaml. But whatever the timeline I would *love* to see it. On Fri, Jul 07, 2017 at 06:19:52PM -0700, Lehi Toskin wrote: Well there is the racket-rash project[1]. So you're thinking of more a *NIX environment inside the REPL? Just FYI, Rash is near the end of a major rewrite, so the documentation that is up (what there is of it) is all wrong, and the language is very different now. But it does aim to do everything that a unix shell (eg. bash) does, as well as much more, embeddable in any Racket program at the expression or module level (also you can escape to normal Racket, embedding any normal Racket code inside Rash). Also eventually I hope to have a nicer interactive repl with completion, etc, as half of the purpose is to have a better interactive shell environment. But the language part is close to being more or less done. If someone did make a Racket unikernel, I suppose the parts for running Unix (or Windows, if you're into that kind of thing) programs and pipelining them wouldn't work on it. But pipelines of Racket functions would still work normally. -- 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] Forwarding syntax or srcloc
The reason why you are getting the source location from b.rkt is that in `mk-data` you are getting the info from `stx`. In this case, `stx` is the filled-in template you get from `simple-data` in b.rkt. The pattern variables `name` and `x` are filled in with `unlucky` and `262`, which do have location info from c.rkt. But the parentheses, the `mk-data` identifier, the quote around the `name` variable, and `42` all have location info pointing back to b.rkt. In this case, the outermost piece of syntax corresponds to the whole list '(mk-data 'name x 42), so you are getting the location of the parentheses. In the `simple-data` macro you can copy that location info, and as others have said, you can stuff it in a syntax property or put it on the new syntax, or you can have the `mk-data` macro use the location info on `name` or `y` rather than the info on `stx`. IE (define-syntax (mk-data stx) (syntax-case stx () [(_ name x y) #`(data-internal name x y (srcloc #,(syntax-source #'name)) #,(syntax-line #'name) #,(syntax-column #'name) #,(syntax-position #'name) #,(syntax-span #'name)))])) This gives you the location of just `name` rather than the whole s-expression, which may or may not be what you actually want. On Tue, Jul 04, 2017 at 01:39:01PM -0700, reilithion wrote: I'd like to be able to get source location information from behind two or more layers of macros. I have a macro, call it mk-data, whose job it is to make an internal data structure. Among other things, it records a srcloc for later tracking. In another module, I have another macro whose job it is to specialize mk-data and present a simpler interface. Unfortunately, the srcloc that gets stored ends up being the location of the simplifying macro. Not what I want. I need to somehow forward the srcloc of its use-location. Example follows: a.rkt: #lang racket (provide mk-data getloc) (struct data-internal (name x y srcloc) #:guard (λ (n x y srcloc struct-name) (unless (real? x) (raise-argument-error 'data-internal "real?" x)) (unless (real? y) (raise-argument-error 'data-internal "real?" y)) (values n x y srcloc))) (define-syntax (mk-data stx) (syntax-case stx () [(_ name x y) #`(data-internal name x y (srcloc #,(syntax-source stx) #,(syntax-line stx) #,(syntax-column stx) #,(syntax-position stx) #,(syntax-span stx)))])) (define (getloc d) (srcloc->string (data-internal-srcloc d))) b.rkt: #lang racket (provide simple-data) (require "a.rkt") (define-syntax (simple-data stx) (syntax-case stx () [(_ name x) #'(mk-data 'name x 42)])) c.rkt: #lang racket (require "a.rkt" "b.rkt") (getloc (simple-data unlucky 262)) I want the result in c.rkt to be "c.rkt:3:9" or so, rather than "b.rkt:7:7". I realize I could probably make the simple-data macro in b.rkt a bit more sophisticated to help matters, but I'm really resisting doing so. There are going to be a lot of macros like simple-data, and some of them may be written by users, so I'd like to make it as simple as possible to make new ones. I'd rather change mk-data, even if it means making it significantly more complex. What's the best way to accomplish this? -- 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] Readtable extensions and syntax coloring in DrRacket
I would also like to know about this. For what it's worth, I also have an extension for literal strings (the udelim package, and I've been behind using «guillemets» as nestable literal string quotes), and I haven't figured out how to extensibly change the coloring either. One of my more adventurous reader extensions treats | as a normal character, and in the interactions pane it additionally doesn't accept a line unless it has an even number of | characters. Is the interaction lexing connected to the color lexing, or is that somewhere else? Thanks, William On Mon, May 01, 2017 at 03:48:06PM -0700, Andrew Gwozdziewycz wrote: Hi Brendan, I'm wondering if you tried the here string syntax for your use case, which other than the fact that it requires a couple of newlines seems similar in vein to what you were going for (e.g. it doesn't escape anything)? ```racket #< Any text here, and nothing gets escaped, This is somewhat surprising. HI "Any text here, and nothing gets escaped. This is somewhat surprising." ``` Cheers, Andrew On Mon, May 1, 2017 at 2:37 PM, brendan wrote: I wrote a little Racket meta-language that adds a dispatch macro to the readtable for typing string literals without escape characters. You start with two or more #'s followed by any non-# character, then the actual string content, then end with the same non-# character and the same number of #'s. So ##|"foo\bar"|## evaluates the same as "\"foo\\bar\"" Works great, but it does wreak quite some havoc on DrRacket's syntax coloring. Unfortunately as far as I can tell the only way to fix that is to replace the color lexer entirely; there's no compositon like there is with readtables. Is that correct, or is there a trick that I'm missing? -- 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. -- http://www.apgwoz.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. 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] udelim package -- more parens than you can shake a stick at
On Mon, Sep 26, 2016 at 01:54:35AM -0400, Eli Barzilay wrote: But I'm guessing that I lost you again, so none of this would move you. All I can do at this point is sigh and hope that you'll end up at the best case of re-implementing @-expressions with the slightly more verbose syntax that you want. The worst case will be ... well, much worse. I don't think you lost me either time. I think we agree on more than you think we do, but I think mostly we just disagree on what things we want to be simple, and what features we find useful. This might be a more useful conversation if we were in person and could hopefully communicate more clearly, but I think going back and forth on this over the mailing list would be edifying for nobody. Thanks for your responses, though. Maybe we can meet and chat about such things at the next RacketCon or something. William -- 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] udelim package -- more parens than you can shake a stick at
On Sun, Sep 25, 2016 at 01:50:51PM -0700, Dupéron Georges wrote: If I understand you well, the intended use of your nested delimiters can be more or less described as syntactic sugar for #reader, with auto-detection of where the string ends: (filter foo? (python-ish-list-comprehend «thing for x in sqlish(«select * from foo») where some_pred(x)»)) could be rewritten as: (filter foo? #reader"python-ish-list-comprehend.rkt" thing for x in #reader"sqlish.rkt" select * from foo where some_pred(x) That seems like a very reasonable way of looking at it I it. Here is a little step through of what my rash macro does: (define pwd-var "pwd") (rash «ls $(rash/trim «dirname $(rash/trim «$pwd-var»)»)») ;; after one step of expansion, this looks something like this: (rash-line-parse 'ls (rash/trim «dirname $(rash/trim «$pwd-var»)»)) ;; rash-line-parse would expand to (run-pipeline ...) or (begin ...) if ;; there were multiple lines, but if we pretend that the inner macro ;; would expand first, it would be (rash-line-parse 'ls ( (rash-line-parse 'dirname (rash/trim «$pwd-var» ;; then (rash-line-parse 'ls ( (rash-line-parse 'dirname ( ;; the $ in rash keeps pwd-var from being quoted (rash-line-parse pwd-var) So each rash macro reads another layer of string (each one needing a $ due to the syntax specifics of the rash language), but nested strings will still become strings after applying the reader again, while other things will become symbols, s-expressions... So you could also use \" and \\" instead of «», «» is just nicer. So it is very much like your #reader example above. William -- 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] udelim package -- more parens than you can shake a stick at
On Sun, Sep 25, 2016 at 05:10:27AM -0400, Eli Barzilay wrote: To be clear, no offense taken That's good. After I read "Eli bait" my mind took the rest as having an annoyed tone, probably from reading too many online flame wars. It's hard to tell people's emotions in text. I think ultimately we just disagree on what features we want, but I'd like to clarify a few misunderstandings: Yes, and you can do all of that with just a string, which you can still get from an @-form -- just throw a syntax error if it's not all strings. And with just that you get the *benefit* of ignoring indentation which makes it possible to use your syntax in a sane way. I was doing that before, and I just didn't see that as a benefit. Yes, and you can get the same with any string, and (rash "stuff in a different language") Yeah, if you look at the rash docs you'll see that I have examples that do exactly that. It's kind of the point that the macro can just use any string. All the nestable string delimiters bring to the table for these macros is that it makes it easier to nest them without crazy escapes. using @-forms would be a tiny delta for the implementation -- basically just a string-append (actually, not even a delta since your macro already allows multiple strings), and the use is more convenient: @rash{stuff in a different language} Well, my current macro doesn't allow multiple strings as you state, but my previous macro when I was using at-expressions was exactly like what you have there. The only tricky bit here is that if you want to deal with only strings and at the same time maintain a syntax-time parsing of strings, then you need to do this whole multi-level collapsing as a macro thing, which means no runtime expressions. I do get runtime expressions. I'm parsing the inner strings into syntax objects at macro expansion time, and some of those end up being themselves macro calls, and some of them are just normal expressions that are evaluated at runtime. Maybe the languages have very different views on which characters do something special (or specifically should not do something special), including flag characters like @ (or any one you choose at the top level or a higher level up in the nesting). Note that the scribble syntax uses "@" by default, but it's easy to change, as Matthew B. did with pollen. Yes, I'm aware, but any character you choose ends up being a magic character through each nested level unless you use |{}|, which I didn't want. For example, something like this could happen: (define some-output (rash/out «some-query $(first (python-ish-list-comprehend «machine for i in machine-list where should-i-query(i)»)) $(make-query «this is a bogus example that I'm really stretching for, but maybe this is some nice syntax for some sort of query producing dsl? And maybe it has some macro in it in whatever its syntax is to (go-a-level-deeper «in this nonsense ...») But importantly, no top-level reader has to know or care what the syntax here is, nor the rash reader, nor any reader in between, aside from simply preserving it as a string, which I can hopefully do in most any language.»)»)) And here you're falling into the trap I mentioned above. You're trying to use "$" as an escape, but, for example, what happens if you want to escape a single identifier and not an expression? Anyway, here's the same thing using the scribble syntax: The $ is an escape that rash has due to its design (because it essentially quotes everything that doesn't have $), and is not something that's generally necessary for any nested language that just uses strings. For example: ;; starting in normal racket syntax, but with «» for convenience (filter foo? (python-ish-list-comprehend «thing for x in sqlish(«select * from foo») where some_pred(x)»)) The example again is silly, but syntactically it needs neither $ nor @ nor any other magic character. The «» nesting quotes are just convenient to avoid \" nonsense (and \\", " if there were more nesting). As for $ in rash, I chose $ because I'm giving it *some* similarities to eg. bash. To escape just an identifier in rash (as opposed to a larger expression in parens), you can use $id, which you'll see if you look at the examples in theh rash docs. As an aside, eventually I plan on changing it so it creates a macro that will do different things than just escape, eg. $CAPS looks up environment variables rather than normal variables, and maybe $«*.ext» expands globs, etc. But my point is that the $ is a feature of the rash language that I want, not some added complexity that I would want to avoid. So I'm not saying I want a different @-like character for each level down, but
Re: [racket-users] udelim package -- more parens than you can shake a stick at
On Sat, Sep 24, 2016 at 05:33:18PM -0400, Alex Knauth wrote: The way racket already does this is with a 'paren-shape syntax property, which you can ignore if you want to use 「」 as a normal visually distinctive paren type *without* needing a special macro with a weird name. I hadn't thought about the 'paren-shape property. I should put that on. I hadn't thought as much about these paren shapes being used to be distinguished in other macros (eg. macro foo will do something different if its argument is wrapped in bold brackets or in moon faces), but had thought more about either just having them be normal parens or making them be transformers for a fancy macro shorthand - eg. 〘+ _ 3〙might be a shorthand lambda wrapper or something. But at the same time, I don't see how matching on the 'paren-shape property is any better or worse than matching funky #%paren-shape lists. So... yeah. I should definitely add the 'paren-shape property, and I'll make that change. And I don't want all paren shapes to create a #%paren-shape wrapper. But I found #%braces part of Jay's talk to be persuasive, at least in that I definitely want it on some of my parens. So maybe some unicode paren turned on by #lang udelim should have the #% wrapper and others not. Thanks for your thoughts. William -- 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] Re: udelim package -- more parens than you can shake a stick at
One note about the docs: when you write: (open-input-string "«this is a string with nested «string delimiters.» No \n escape interpreting.»") the "\n" is already escaped by the "…" fed into open-input-string I think, so what udelim parses in that example is a raw newline, not the \ character followed by the n character. Thanks, I clearly wasn't thinking about that very hard while writing the docs. Fixed. Scribble supports "element transformers" which allow to change how an identifier is printed. Unfortunately, when the identifier appears in the first position of a form (like the #% wrappers), only the identifier itself can get styled, not the whole form. I added a few days ago a quick hack to my unstable scribble-enhanced library to add catch-alls which can re-style any identifier matching a given pattern. The hack [1] should also work for whole forms (untested, though), so that in scribble or scribble/lp2, @racketblock[(a ⟦b⟧ c)] would be properly typeset. Thanks. I didn't put too much thought into the typesetting so far (apologies to Mr. Butterick), but I'll look into that more when the library stabilizes more. -- 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] udelim package -- more parens than you can shake a stick at
First of all, I really didn't mean any offense. I think the at-reader and my nestable string delimiters are trying to solve slightly different problems, and I didn't really convey that well. I didn't mean for it to be "Eli bait". Let me explain my use case a little, and maybe my earlier mail will seem less baiting in the context I had intended, albeit poorly communicated. It's your use of "nestable" here that seems to me like it's making things bogus. If you really want it to be nested, then this is exactly what the scribble syntax is doing -- to an extreme. But if all you want is to be able to nest the string *delimiters*, than any string delimiter pair that is not using the same character will do... but more importantly I don't see any cases where you would want *that* but not the rest of the scribble syntax features. So I really do just mean that the string delimiters themselves nest -- IE it balances them so that the string doesn't necessarily end once it hits an ending delimiter. So yes, any two characters will do for the job. That in itself is something that I've wanted independent of anything else, so for me that was a good enough reason to make this, and is something that I'll use it for, to avoid things like \", which have always irked me (whether or not it's reasonable that that should bother me). As for other aspects of nesting and my other uses of these strings, the at-reader makes perfect sense if you want to nest various expressions inside a string that needs to remain a string at run-time, such as is done in scribble. But in my case that's not what I want for, say, #lang rash, or other nebulous embedded language ideas I have floating around my mind. Basically, I want to have a macro that will be fully in charge of determining the meaning of the string, and I want to be able to use the same reader functions in the macro that I use in the #lang. But to use the same read-syntax function that my language uses, I need a port to run it on. To make this port, I really just need a string with no pre-read syntax objects inside it. So in this case I don't want the top-level reader of whatever #lang I'm in to look in the string, I just want the macro to be able to use read-syntax on the full string. If the middle of the string has already been read into syntax objects, my reader functions would be much more complicated to write (IE I'd have to figure out how to deal with the port ending in the middle of a parenthesised expression or something, then use a pre-read syntax object, then jump back into reading the next section that remained a string while conveying whatever context I was in in the last string segment...). And the string splitting, which is as you've shown quite helpful in many cases, would in this case simply be something that I would have to undo, which as you point out would be a bit of a waste. So I see the difference as being that in uses like scribble, the bold procedure isn't trying to use a reader on its arguments, and the at-reader needs to have split them up and turned the nested expressions into s-expressions already for them to have their intended meaning. Whereas the macros I want to make want to just have a string to turn into a port. It could potentially be that my plans for these macros are misguided, but I have liked the results I've gotten so far and feel like it has promise. Here is an example of the sort of thing I've been doing with it: ;; Here is my rash macro (define-syntax (rash stx) (syntax-parse stx [(rash arg:str) ;; Note that since I just get one string, it is easy to turn it into a port ;; and use my read function on it. (with-syntax ([(parg ...) (map (λ (s) (replace-context #'arg s)) (syntax->list (rash-read-syntax* (syntax-source #'arg) (stx-string->port #'arg]) ;; rash-line-parse is what the #%module-begin of rash uses around everything. #'(rash-line-parse parg ...))])) ;; So basically the rash macro does exactly the same thing as #lang rash, ;; but is embeddable in #lang whatever! Is this the best way of going about it? I don't know. But it's easier than the way I was going about it before. Something I like about this method is that I could nest several of these macros into each other, and each one can do the reading however it sees fit, as long as at each level I can pass an appropriate string to the next level down. Maybe the languages have very different views on which characters do something special (or specifically should not do something special), including flag characters like @ (or any one you choose at the top level or a higher level up in the nesting). For example, something like this could happen: (define some-output (rash/out «some-query $(first (python-ish-list-comprehend «machine for i in machine-list where should-i-que
[racket-users] udelim package -- more parens than you can shake a stick at
Hello everybody, I'm announcing another little package I've written to get comments on it: udelim. Udelim is a library for adding extra parens and string delimiters to your language. For many years, before ever coming to racket, I've wanted nestable string delimiters. Especially when working with web stuff. Now that I have a programmable programming language, I have them. The big push to making them now is that lately with rash I've been working on nesting different syntax with macros and alternative readers. Some weeks ago I found myself dissatisfied with the method I was using (at-expressions), and wrote the code for balanced strings instead, and have loved it. Additionally, I've long wanted more types of parens in Racket. I haven't really known what I would do with them -- I use Racket's conventions for () and [], and have my own loose convention for {}. But after seeing Jay McCarthy's wonderful talk on Remix, I am now blatantly stealing his idea of wrapping different paren types with a macro-dispatchable symbol. So udelim has functions for extending readtables to have more parens and balanced string delimiters, optionally wrapped up a-la Remix. It also has a stx-string->port function for convenience in making macros that read an alternate syntax with those nestable strings. It has a metalanguage with some delimiters auto-enabled: «» (guillemets, used as quotes in many European languages) as nestable, non-escaping quotes, 「」 likewise but wrapped so 「foo bar」 reads as (#%cjk-corner-quotes "foo bar"), and several unicode paren types (﴾﴿, ⦓⦔, ⦕⦖, 🌜🌛, ...) wrapped with a starter symbol as well. Some people I've talked to about this package have seemed unhappy with my introduction of nestable strings, and my recommendation of using them over the at-expressions for nesting different syntax, so I feel I ought to explain that a little. First, nestable strings are nice for other things as well. For instance, since they don't escape backslashes, they are nice for constructing regexps, which famously explode into mountains of backslashes due to being inside "" strings. They are a great alternative to #
Re: [racket-users] Racket Shell
I've looked over the scsh docs at various times, though I've never actually used it -- it's never been pre-packaged for distros I've used, and every time I've tried to build it I've run into errors. Perhaps I should try again. As far as the process syntax goes, a little bit of macros over my pipeline library should be able to get you something pretty close. I'll probably do that later. The parts of scsh aside from the process forms, like the regex stuff, I think are mostly orthogonal to the process stuff, so that could probably just be a different library, then they could be used together. I just ran across this little thing: https://asciinema.org/a/0utgivr7glk3ssn01fn5uwtey A lot of that does look pretty good. I think he's probably right that the |> piped output should be the last argument (I've had my `shellify` wrapper making it the first). I’d love to use a Racket shell and script Unix in a ‘natural’ way. Not just Unix -- it works on Windows too ;) So is scsh what you consider natural? I definitely want a nice s-expression syntax for it, but also a convenient line-based syntax for interactive use. I like the idea that you can more or less turn a transcript of such commands into a script -- one of the reasons I always encourage people to get used to using a shell is that it makes you think a lot more about automating tasks when you type the same command sequence often. It's something you just can't do with GUI interfaces, and automating boring stuff is one of the joys of programming. Having a nice upgrade path (just gradually put more of it in regular racket until it turns into a "real" program) for those scripts that seem to grow over time is also really appealing to me. Thanks for the feedback. William -- 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] Racket Shell
Is this at all related to Vincent's work? [1] [1]: https://github.com/stamourv/rash I had no idea that existed. (in my defense, I did google "racket shell", "racket rash", etc before starting this) I'll have to look at it as well. -- 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] Racket Shell
Hello everyone, Being obsessed with shells and wanting very badly to have a racket shell, I've spent a good chunk of time over the last couple of weeks working on shell-related stuff for Racket. First is a library for shell pipelines (that may also contain racket functions). The interface is roughly like this (assuming `my-grep` is a racket function that implements grep): (run-pipeline '(ls -l) (list my-grep "foobar") '(wc -l)) The docs for that library are here [1]. Additionally, I've got a rough sketch of a line-based syntax for writing shell scripts or using a shell repl with embedded racket code. Right now its syntax looks like this: #lang rash ls -l | @my-grep "foobar" | wc -l ;; A line is not wrapped in a pipeline if it starts with & ;; You can get back into #lang rash syntax with @rash{} or @rash/out{} &@(define ttys @rash/out{ls /dev | grep tty}) I want to change the line syntax a lot (especially to not need &), but I decided to put it up (with some very rough documentation) here [2] to get some feedback on what people think of it. I'm really interested in people's thoughts about both parts and ways people think they could be improved. Thanks, William Hatch [1] http://docs.racket-lang.org/shell-pipeline/index.html [2] http://docs.racket-lang.org/rash/index.html -- 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] racket users fight for their right to colon keywords
On Fri, Oct 23, 2015 at 02:58:30PM -0400, Anthony Carrico wrote: On 10/23/2015 11:30 AM, Greg Hendershott wrote: If you touch type you use both left and right shift keys O_o. ...but only the right shift key in dvorak For greater keyboard layout awareness, here is a more complete assessment of the situation: Arensito, Qwertz, Hacker's Dvorak, and Maltron layouts: 3 keys (adding # is only one extra key because it is unshifted). Hatchak and Azerty layouts: 3 keys (although it's two for # and one for :) Dvorak and Capewell need them both shifted but only one side's shift key. Neo, Coleman, and Workman all take 4 keys like Qwerty. #: is onerous for both left and right versions of one-handed Dvorak, since both require shifting and are on opposite sides of the keyboard. And I assume you only use these layouts if you have to type one-handed. On the default AOSP touch keyboard, it take 3 touches to type #:, which is only 1 more than : alone. But seriously, I'm totally on the side of #:. In no layout is it such a burden to occasionally type #:, and if you worry about typing efficiency or ergonomics a better plan is to switch away from qwerty. Visually I think #: gives better emphasis to keywords' special purpose. - William -- 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] racket users fight for their right to colon keywords
On Fri, Oct 16, 2015 at 03:24:06PM +0200, Konrad Hinsen wrote: Matthias Felleisen writes: > > For me the strongest point of Racket is that it encourages linguistic > > diversity while maintaining (nearly enforcing) interoperability. My > > dream language environment would go one step further and provide a > > second more low-level interoperability layer for performance-oriented > > dialects (C/Fortran style). > > > Does the existing FFI provide you with enough efficiency when needed? Yes, but I have to write C code outside of Racket. I'd like to be able to define a #lang in Racket that operates at the level of C (i.e. machine-level data types, no GC, etc.), and I'd like to generate specialized code in that low-level language from my standard Racket code. FYI, I'm a grad student at Utah with Matthew, and my current project is a #lang pre-racket that compiles to C. It hasn't really gotten off the ground yet because I've been busy with classes and fellowship applications, but in the relatively near future we should have this. William P.S. On the point of keywords, I think having #lang colon-kw is the right approach. If people worry about living the dream of Haskell's Lens package, you could make another one that includes your common subset of add-on reader features together. -- 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] help please on git/github pull request
On Fri, Jul 03, 2015 at 12:38:26PM -0400, Greg Hendershott wrote: Being git, there are probably a variety of ways to go about this. What I might try (but haven't verified first-hand): One-time setup: - On master, `git pull --ff-only upstream`. - On master, create from master a new branch named "my-master" (or better name). - On my-master, merge your PR branch (get its commits on my-master). Going forward, periodically: - On master, `git pull --ff-only upstream`. - On my-master, `git rebase master`. In other words, replay your commits on top of the latest upstream master. I think?? Maybe there's a simpler way to do this. I'm a big fan of using `git remote update`, which pulls in new commits and updates the cursors of the remote branches, but doesn't change any of your local branches. You can do it safely without worrying what branch you are on. Then on your branch you can run `git rebase origin/master`. My two cents on a good way to do this. -- William -- 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] Emacs Lisp as a Racket Language?
I would also love to see a new emacs based on Racket. Is rmacs by Tony Garnock-Jones intended to be a small project or is he meaning for it to grow to be a serious contender with emacs, vim, etc? I agree with Greg that the ecosystem and momentum around emacs is its strongest point. I've written a couple small emacs packages, and in doing so I added myself to the watch list of the Melpa emacs package repository, and they probably average about 3 new packages per day. So rmacs would need a lot of momentum to be able to get many users. But I would love it. Just as long as doesn't try to throw out things like multiple frontends (IE runnable in both terminal and as an X window), and extensibility everywhere. (It's reasons like these that I believe Atom, Sublime, etc will never seriously compete) On Fri, Jul 03, 2015 at 11:39:38AM -0400, Greg Hendershott wrote: So I've spent a lot of time using both Racket and Elisp over the past couple years. My feeling: - Racket is much nicer. - Elisp is not nearly as bad as I first thought. Some other baseless opinions: 1. An "opposite" approach would be to put a more Rackety face on Elisp. But. I feel it's probably helpful (and interesting) to know the real deal. I was excited to discover the dash.el package, which puts a Clojure-ish face on some things. Having said that, I'm now using it less. For example, I love using Racket match to do combined conditional and binding. I started using if-let from dash to do the equivalent in Elisp. Then I realized Emacs already provides pcase; so I'm simply using that these days. (Although not as comprehensive as Racket match, pcase is a frequently-used subset.) For another example, although I wish it were named filter, I can use cl-remove-if-not from the standard cl-lib package. I feel I ought to know it exists, and if I do, I may as well just use it? 2. I think the desired trade-offs can be different. For example in Clojure if I rename a function, the old definition still exists under the old name, ready to cause confusion. That's "too dynamic" for my taste, outside Emacs. But that dynamism is part of what makes the Emacs environment special. And anyway most (of my) Elisp code is doing tactical UX grunt work. So the cost:benefit seems different. 3. My impression is that there's been somewhat of an Emacs renaissance the last few years. Probably due to the new package manager, as well as a cohort of fresh packages like dash.el from new, younger folks. That entire "ecosystem" is what makes Emacs special, I think. Before embarking for real on a new project, not only does there need to be a story about supporting that, I think it would need to be totally seamless. Which is maybe not impossible but probably non-easy. -- 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] help please on git/github pull request
On Fri, Jul 03, 2015 at 12:38:26PM -0400, Greg Hendershott wrote: Being git, there are probably a variety of ways to go about this. What I might try (but haven't verified first-hand): One-time setup: - On master, `git pull --ff-only upstream`. - On master, create from master a new branch named "my-master" (or better name). - On my-master, merge your PR branch (get its commits on my-master). Going forward, periodically: - On master, `git pull --ff-only upstream`. - On my-master, `git rebase master`. In other words, replay your commits on top of the latest upstream master. I think?? Maybe there's a simpler way to do this. I'm a big fan of using `git remote update`, which pulls in new commits and updates the cursors of the remote branches, but doesn't change any of your local branches. You can do it safely without worrying what branch you are on. Then on your branch you can run `git rebase origin/master`. My two cents on a good way to do this. -- William (sorry if anyone gets this twice -- I'm re-sending because I realized I used the old address of the mailing list) -- 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] terminal emulator
On Thu, Jun 04, 2015 at 07:20:27AM -0600, Matthew Flatt wrote: At Wed, 3 Jun 2015 16:46:09 -0600, William G Hatch wrote: Its main problem currently is that it spends a lot of time drawing. I am using a canvas% and I override its dc%'s on-paint to get the contents and then draw them on screen. I call the refresh method to queue a re-paint whenever I get new input. If I, say, start up vim and start writing in it, my input lags behind as it spends all its time repainting. Are there some good practices for drawing stuff quickly? I was also wondering, before I start searching and grepping all over, if someone who knows can point me to where I can see how drracket formats the contents of its text panes (IE adds color, etc). Whatever it's doing seems to be good, so perhaps I can leverage something there. FWIW, your terminal seems much more responsive to me if I remove the `on-paint` call in `on-char` (since the terminal callback queues a refresh if any is needed, I think). Aha! Thanks, I didn't realize that was there. I was sprinkled a few of them around when I was first figuring out where things needed to be redrawn, before I learned about 'refresh'. I missed that one when I was removing them. DrRacket uses the editor classes that are described here: http://docs.racket-lang.org/gui/editor-overview.html That editor refreshes only part of the window when it can. For example, it's often easy to repaint only the current line where editing is happening. Redrawing only part of the screen means not calling `refresh` and instead drawing into that part of the canvas directly (but always drawing the whole canvas in a `refresh`-triggered `on-paint`). Use `suspend-flush` and `resume-flush` to avoid flicker while drawing outside of `on-paint`. My other biggest issue right now is getting the child processes to register window size changes, and I'm not sure whether it's a problem with how I'm setting things up with the child or with how I'm sending the resize signals through the parent. It's all through FFI calls into the black box of ioctl, so it has nothing to do with racket, but if any of you have tips for that, I would also appreciate it. But related to that, I have some C constants hard coded right now in racket for the FFI. Is there a way for me to get them out of the C header file so it won't just break if/when the header changes? No idea on the ioctl issue, but you may have to run a C program to extract constants from header files. Probably you don't have to worry about numbers changing for a given platform, though, since the numbers get embedded in executables and OS changes usually avoid breaking existing binaries in that way. -- 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] terminal emulator
Hello racketeers, I'm pretty new to racket, so to get some experience with it I've been writing a terminal emulator. It's coming along nicely (it is one control code away from being able to nicely run vim), and is at https://github.com/willghatch/rackterm for your browsing pleasure. I have run into some difficulties that I would like some advice for: Its main problem currently is that it spends a lot of time drawing. I am using a canvas% and I override its dc%'s on-paint to get the contents and then draw them on screen. I call the refresh method to queue a re-paint whenever I get new input. If I, say, start up vim and start writing in it, my input lags behind as it spends all its time repainting. Are there some good practices for drawing stuff quickly? I was also wondering, before I start searching and grepping all over, if someone who knows can point me to where I can see how drracket formats the contents of its text panes (IE adds color, etc). Whatever it's doing seems to be good, so perhaps I can leverage something there. My other biggest issue right now is getting the child processes to register window size changes, and I'm not sure whether it's a problem with how I'm setting things up with the child or with how I'm sending the resize signals through the parent. It's all through FFI calls into the black box of ioctl, so it has nothing to do with racket, but if any of you have tips for that, I would also appreciate it. But related to that, I have some C constants hard coded right now in racket for the FFI. Is there a way for me to get them out of the C header file so it won't just break if/when the header changes? Thanks in advance, William Hatch -- 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.