[racket-users] terminal emulator

[William G Hatch]

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.

Re: [racket-users] terminal emulator

[William G Hatch]

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.

Re: [racket-users] help please on git/github pull request

[William G Hatch]

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] Emacs Lisp as a Racket Language?

[William G Hatch]

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

[William G Hatch]

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] racket users fight for their right to colon keywords

[William G Hatch]

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

[William G Hatch]

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] Racket Shell

[William G Hatch]

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.

[racket-users] Racket Shell

[William G Hatch]

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 Shell

[William G Hatch]

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.

Re: [racket-users] udelim package -- more parens than you can shake a stick at

[William G Hatch]

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

[William G Hatch]

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,

[racket-users] udelim package -- more parens than you can shake a stick at

[William G Hatch]

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] udelim package -- more parens than you can shake a stick at

[William G Hatch]

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] Re: udelim package -- more parens than you can shake a stick at

[William G Hatch]

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

[William G Hatch]

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 

Re: [racket-users] udelim package -- more parens than you can shake a stick at

[William G Hatch]

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] Printing Quickly

[William G Hatch]

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] Boot To Racket

[William G Hatch]

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] Replacing multiple characters in a string?

[William G Hatch]

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] Forwarding syntax or srcloc

[William G Hatch]

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] Re: Readers and Namespaces

[William G Hatch]

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] Readtable extensions and syntax coloring in DrRacket

[William G Hatch]

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] GUI for ffmpeg and mrlib/terminal

[William G Hatch]

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] Rackterm error

[William G Hatch]

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] switching to an alternate syntax using a lang extension: binding issues

[William G Hatch]

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

[William G Hatch]

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

[William G Hatch]

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] Re: Concise way to get completions for Racket code?

[William G Hatch]

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.

[racket-users] LOP cultural anthropology, phases

[William G Hatch]

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] Escaping strings for the shell

[William G Hatch]

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.

Re: [racket-users] make extensions or replacements

[William G Hatch]

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] [ANN] Transducers library

[William G Hatch]

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.

[racket-users] [ANN] Xsmith 2.0

[William G Hatch]

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.

[racket-users] [package announce / RFC] Extenor

[William G Hatch]

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?

[William G Hatch]

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.