Re: [racket-users] Re: note about parsing speed of xml vs sxml?

[Neil Van Dyke]

Is even 2x speedup helpful for your purpose?  3 seconds is one old magic 
number for user patience in HCI, so I suppose there's still a big 
difference between 4 seconds and almost 10 seconds?


For large (and absolutely massive) XML... SSAX can shine even better 
than in this comparison, since you can, say, populate a database *while 
you're parsing, without first constructing the intermediate 
representation* of xexpr or SXML.  GC-wise, with the database-populating 
scenario, you'll probably end up with small, little-referencing, local, 
short-lived allocations.  Besides GC costs, you'll also use less RAM 
(possibly lower AWS bill), and be less likely to push into swap (which 
would be bad for performance).


In addition to SSAX's current performance characteristics and 
opportunities... There might also be opportunity to optimize SSAX 
significantly for Racket.  Oleg is a famously capable Scheme programmer, 
but he was writing SSAX in fairly portable Scheme code, a couple decades 
ago, when he wrote SSAX.  I did an initial packaging of SSAX for PLT 
Scheme, Kirill Lisovsky later did many packagings of various SXML-ish 
tools (including his own), and then John Clements did more work to 
package Oleg's SXML-ish tools for Racket... But I don't know that anyone 
has had motivation to try to optimize Racket's SSAX port, using current 
Racket features, and tuning for current performance characteristics.


Side note regarding performance comparison... FWIW, SSAX might be doing 
some things `read-xml` doesn't, such as namespace resolution, entity 
reference resolution, and some validation.


--
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/828c5a26-0dec-a1d6-5ca3-04376113bf6c%40neilvandyke.org.

Re: [racket-users] Re: note about parsing speed of xml vs sxml?

[Neil Van Dyke]

If anyone wants to optimize `read-xml` for particular classes of use, 
without changing the interface, it might be very helpful to run your 
representative tests using the statistical profiler.


The profiler text report takes a little while of tracing through 
manually to get a feel for how to read and use it, but it can be 
tremendously useful, and is worth learning to do if you need performance.


After a first pass with that, you might also want to look at how costly 
allocations/GC are, and maybe do some controlled experiments around 
that.  For example, force a few GC cycles, run your workload under 
profiler, check GC time during, and forced time after.  If you're 
dealing with very large graphs coming out of the parser, I don't know 
whether those are enough to matter with the current GC mechanism, but 
maybe also check GC time while you're holding onto large graphs, when 
you release them, and after they've been collected.  At some point, GC 
gets hard for at least me to reason about, but some things make sense, 
and other things you decide when to stop digging. :)  If you record all 
your measurements, you can compare empirically the how different changes 
to the code affect things, hopefully in representative situations.


I went through a lot of these exercises to optimize a large system, and 
sped up dynamic Web page loads dramatically in the usual case (to the 
point we were then mainly limited by PostgreSQL query cost, not much by 
the application code in Scheme, nor our request network I/O), 
and also greatly reduced the pain of intermittent request latency spikes 
due to GC.


One of the hotspots, I did half a dozen very different implementations, 
including C extension, and found an old-school pure Scheme 
implementation was fastest.  I compared the performance of the 
implementation using something like `shootout`, but there might be 
better ways now in Racket. https://www.neilvandyke.org/racket/shootout/  
I also found we could be much faster if we made a change to what the 
algorithm guarantees, since it was more of a consistency check that 
turned out to be very expensive and very redundant, due to all the ways 
that utility code ended up being used.


In addition to contrived experiments, I also rigged up a runtime option 
so that the server would save data from the statistical profiler for 
each request a Web server handled in production.  Which was tremendously 
useful, since it gave us real-world examples that were also difficult to 
synthesize (e.g., complex dynamic queries), and we could go from Web 
logs and user feedback, to exactly what happened.


(In that system I optimized, we used Oleg's SXML tools very heavily 
throughout the system, plus some bespoke SXML tools for HTML and XML.  
There was one case in which someone had accidentally used the `xml` 
module, not knowing it was incompatible with the rest of the system, 
which caused some strange failures (no static checking) before it was 
discovered, and we changed that code to use SXML.)


--
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/68624c9a-df35-14a3-a912-df806799a7e0%40neilvandyke.org.

Re: [racket-users] xml vs sxml?

[Neil Van Dyke]

Hendrik Boom wrote on 6/27/20 8:33 AM:

But in section 4. Appendix there is one bit of pervasive confusion: you present several 
differences, but do not make it clear which way the difference goes.  When you say, for 
example, "The SXML keyword symbols may be lowercase", do you mean that SXML 
itseld allows this to be done to its keywords, or that it does not but that xexpr allows 
its SXML keywords to be lower case?


Thank you.  I didn't phrase that well.  In section "Appendix: 
SXML/xexp", that bulleted list is describing "SXML/xexp", relative to 
canonical SXML.


That first bulletpoint is something on which I think SXML was 
ambiguous.  (Some Scheme readers or symbol tables forced or disregarded 
case, but others thankfully didn't.  Although, IIRC, Oleg's code was 
consistent in how it used case, the ambiguity of the case of the symbols 
in SXML presented portability problems when other people wrote code, 
especially if they interpreted it differently, and exercised their 
preferences, then you tried to combine their code.  Many Scheme 
programmers emphasized personal preference, and we can imagine that a 
small language with powerful linguistic extension, and a convention of 
writing one's own interpreter, might attract rugged individualists.)  
"SXML/xexp" tried to mitigate that in a portable way, by saying both 
all-uppercase and all-lowercase were supported, and that no other mixing 
of case was permitted.


From this, and from the general drift of your sxml-intro, I surmise 
that the intent is for Racket to become fully SXML compliant, and new 
software should be written for SXML, not xexpr, if at all possible.


There's no policy that I know of.

I think switching would be better overall, but switching is a lot of 
work.  And, in a sense, there's less focus in practice on XML and HTML 
than there used to be, so less reason than before to invest in 
switching.  I suspect any switch won't happen wholesale, but telling 
people about the separate `sxml` package might result in some future 
projects choosing to use SXML.  I don't know how much activity future 
projects will be.


When I first started with Scheme, I was actually lucky in my timing, in 
avoiding fragmenting the XML/HTML representations even worse. The first 
Scheme code I wrote was an HTML parser, and, initially, I made my own 
obvious s-expression encoding of HTML, which turned out to be very 
similar to Racket's `xexpr`.  But I quickly saw Oleg's XML work, and so 
reworked my code to emit SXML, so that the fancy XML tools could also be 
used with real-world HTML.   The switch to SXML was trivial for me then, 
but the switch would've been hard for Racket (aka PLT Scheme), by the 
time SXML became a de facto standard for the Scheme community.



Finally, I seem to remember that one of the tools mentioned somewhere for 
handling xml turned out not to be findable.  I don't know any more if it was 
mentioned in your document or elsewhere, but it might be worth checking that 
the ones you mention are still available.


Are you thinking of Jim Bender's `sxml-match`?  I need to fix that dead 
link (can't release a new version at the moment), probably to point to 
the PLaneT package that the text mentions. 
http://planet.racket-lang.org/display.ss?package=sxml-match.plt=jim


--
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/9fa1be59-64af-c3dd-9f3f-d49cf693a0d8%40neilvandyke.org.

Re: [racket-users] note about parsing speed of xml vs sxml?

[Neil Van Dyke]

I think anyone using XML or HTML seriously with Racket should probably 
at least be told of the SXML family of tools.  And warned about the 
compatibility problems.


Though not tell them *everywhere* XML in the docs.  For example, I 
figure a tutorial for Racket Web Server shouldn't distract readers with 
that.


As you know, :) there are some useful tools using SXML, and Oleg's SSAX 
parser has some different properties than core Racket's XML parser.


Complication: The incompatibility between SXML and core Racket's 
representations of XML is an unfortunate accident of parallel 
invention, and I think will tend to be confusing to new people.  I once 
tried to address the confusion in the `sxml-intro` documentation 
package, "https://www.neilvandyke.org/racket/sxml-intro/;, and I'm 
unhappy with the result.  The details in my document say more than 
perhaps anyone will ever want to know, and, "optics"-wise, make the 
situation look worse than it actually is in practice.  I think you could 
do a more graceful job of this.


(Someday, someone might undertake the large task of SXML-ifying all the 
many non-SXML bits of Racket, and incidentally reunite Racket with the 
rest of the Scheme community in that regard.  I started, with one piece, 
but got interrupted. 
"https://www.neilvandyke.org/racket/rws-html-template/"  :)


--
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/79401c33-1468-d716-aa31-45e4cc018890%40neilvandyke.org.

Re: [racket-users] Re: Andy Wingo's fold

[Neil Van Dyke]

Catonano, I haven't yet studied that paper of Andy Wingo's (thank you 
for mentioning it), but a couple ideas for answering your questions...


If people in Guile are using that tree fold approach, you might ask 
about it on one of the Guile email lists.  Incidentally, Andy has long 
been a member of the community around Guile, as well as of the Scheme 
community in general.


If you want to use that tree fold approach in Racket afterwards, most 
Scheme code will still work in Racket.  And you could probably port or 
repackage most Guile utility libraries.  (The main tricky part that 
comes to mind, in porting RnRS Scheme code to Racket, is if the code 
uses mutable pairs.)


Another option to keep in mind is that, normally when you read an 
academic paper, once you've given it a close read, and made an effort to 
be reasonably conversant in at least one aspect of the background 
material, IMHO, it's perfectly proper to contact the author of the paper 
directly, with good comments/questions.  They might not be able to keep 
up with their email, nor always sort it perfectly, but reaching out 
about a paper is part of scholarly culture, so don't be too shy.


FWIW, here's another example of tree folding, which I did as an exercise 
while trying to understand some of Oleg Kiselyov's XML work better: 
https://www.neilvandyke.org/racket/json-parsing/  (If it doesn't 
immediately help at all, don't waste your time looking at it any more.  
I'd do the interface differently next time, and definitely not use 
`syntax-rules` in the implementation again, but it's an example.)


Neil

--
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/da82b74d-eb8f-e76b-e730-db98e3c56999%40neilvandyke.org.

Re: [racket-users] Should I stop sending packages to the catalog?

[Neil Van Dyke]

For an important production system, you probably want the source of any 
third-party packages on which you depend to be in Git (or another SCM 
system) that you control.


You might also want to audit those packages yourself, as well as audit 
any new version changes to them, before you push to production.


After you do those things in SCM, depending how you do it, you *might* 
find it's more convenient to simply load the third-party code you need 
using the module system `require` only, without an additional package 
system.


--
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/3abb676b-a9b2-7578-1246-5e58446faa8d%40neilvandyke.org.

Re: [racket-users] Why does this counter behave differently in different runtimes?

[Neil Van Dyke]

Compiler bugs have been so blessedly rare in Racket, maybe there should 
be a page on the Web, honoring those who found a compiler bug?


I would nominate Sage and Alexis for this one.

And Matthew, though we'd have to make sure he's not mis-incentivized by 
the glory of bug-finding, to start making bugs. :)


--
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/68d508ac-b702-10b8-1d04-e6afa79e0248%40neilvandyke.org.

Re: [racket-users] Re: current racket dynamic web performance in production?

[Neil Van Dyke]

Thanks for the info, Brian.

I'm getting the impression that Scheme/Racket Web production serving is 
sorta in same place it has been for the last couple decades: such that a 
really good and prolific developer can make a system work well in 
production, iff they can put in a lot of work beyond off-the-shelf 
components.


When deciding whether to to go Scheme/Racket, we consider the pros -- 
e.g., the linguistic power of Scheme, the ability to attract talent due 
to using a fringe language that people like or want to learn -- and 
weigh them against the greater amount of bespoke work, the necessity to 
then have non-commodity developers who are up to doing that well, and 
the greater risks/unknowns that might not be solved by throwing a larger 
AWS bill at a problem.[1]


For the server project I'll develop this week, it doesn't actually take 
advantage of Scheme, and the project also won't function as a good pilot 
project for scalability, so I'll probably just use Python this 
time.  I'll keep Scheme/Racket in mind for this, as a known-quantity 
backup plan, but probably Scheme/Racket will have to wait until later 
this year for a better opportunity to shine.


There is a GUI frontend project coming up that might be a better 
opportunity for Racket to be useful in production.  It would be 2nd 
generation replacement of a deployed specialized appliance frontend, 
which currently is done in JS in Chrome (no, not the horrifying 
touchscreen Web browser spaceship consoles we heard about the other day 
:), and some special hardware device interfacing.  I've prototyped 
replacing it with with Python Kivy,[2] but I happen to know that 
Racket's GUI library would be easier to use for this purpose, and result 
in more-solid UI operation.


After that, the next opportunity is probably 2nd generation of the 
entire server infrastructure, and we'll have to see what our needs and 
resources are like at that time.  We'll probably have that 2nd-gen work 
in mind if/when we do more engineering hiring later, and, in any case, 
I'd like to be able to hire the kinds of developers who are up to the 
challenges of doing bespoke work that works.[3]



[1] Though I think the risks/unknowns of a less-popular stack aren't 
what many developers are thinking when they flock to the most popular 
tools of the moment because a FAANG does it.  What tools work 
for a FAANG, with massive infrastructure, massive staffing, and the 
practice of routinely shutting down large numbers of projects (and 
making many multi-billion dollar acquisitions of competitors, when the 
FAANG still fails to outperform upstart competitors with their 
project)... aren't necessarily the tools a startup should use, 
with their handful of people who have to wear many hats, and actually 
have individual contributors understand the entire system, in order to 
make it work well enough and to troubleshoot problems rapidly, despite 
very limited resources.


[2] As I was evaluating GUI toolkits, there's ongoing 
bitrotting/abandonware of the desktop GUI space, as development flocked 
to adtech/VC-driven Web sites and smartphone apps, and people started 
favoring embedded massive browser engines (which have pros and cons).  
And it looks to be self-perpetuating, because the non-Web GUI toolkits 
get less attention.  Kivy was one of the few current non-abandoned 
toolkits.  Racket's cross-platform GUI toolkit remains supported for 
solid Win95-era desktop GUIs, and is currently looking better than 
Python and JS-framework-in-WebKit options, for the particular kind of 
(non-consumer) touchscreen appliance console we'll need to do. (For 
slick consumer-facing UIs, I'm currently going through the rapid mood 
swings experience of the SwiftUI DSL and related iOS stack. :)


[3] And I've long believed that using one of the less-popular but 
beloved platforms -- like Scheme/Racket, Common Lisp, Haskell, OCaml, 
Erlang, or Rust -- is a great way to find and attract some of the best 
developers.  FAANGs can say to some of those developers, "we'll pay you 
more money, and everyone else who aspires to make FAANG money will be 
impressed when they see us on your resume", but the toolset you get to 
use can be one of the significant selling points of a competing value 
proposition.


--
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/0d79e2bc-536c-a6da-5c15-3d84790864cc%40neilvandyke.org.

[racket-users] current racket dynamic web performance in production?

[Neil Van Dyke]

I'm now leading engineering at a startup with an established Python & 
Flask infrastructure, and happen to urgently need an additional dynamic 
Web service backend that's separate from the rest of our 
infrastructure...  While I could do it in Flask, I was thinking that 
this might also be an opportunity for a Scheme (Racket) pilot project 
for the company,[1] looking ahead to tech stack selection for some much 
larger infrastructure expected next year (if the startup survives the 
virus).


The problem with this as a pilot project is that this server will see 
only very light duty, and therefore not good for evaluating real world 
viability for the expected future high-traffic needs.


So I was wondering whether anyone (other than HN, and the bespoke 
framework stuff I worked on atop the `scgi` package) is currently using 
Racket for dynamic HTTP/S backend in a *high traffic* setup? And if you 
are handling high traffic, what kinds of performance are you seeing 
(e.g., request volume, simultaneous requests, latency, GC 
characteristics), and how have you built it (e.g., which HTTP libraries, 
what kind of server infrastructure)?



[1] A similar urgent new server in Racket has happened before. 
https://lists.racket-lang.org/users/archive/2009-October/036244.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.
To view this discussion on the web visit 
https://groups.google.com/d/msgid/racket-users/432ed847-1de9-3c89-8c77-d756ad376eff%40neilvandyke.org.

Re: [racket-users] Need advice on XML representation

[Neil Van Dyke]

Thank you, Tom.

This document might help answer some of the understandable confusion 
behind Hendrik's question: https://www.neilvandyke.org/racket/sxml-intro/


A clarification on credit where it's due: John Clements did considerable 
work to clean up and document Oleg Kiselyov's various SXML packages for 
modern Racket, and maintains those.


I wrote a few other SXML-based packages: https://www.neilvandyke.org/racket/

If anyone has a deep-pocketed commercial need for some new HTML or XML 
libraries for Racket, I might have some consulting time available, but 
haven't had time for pro bono work lately.


(I'm not normally on racket-users; if anything I should see, please 
email me directly.)


--
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/e8e5dd10-563f-17d2-0ecf-c1bcd285751d%40neilvandyke.org.

Re: [racket-users] xml library clarification - "" symbol parsing

[Neil Van Dyke]

Kira wrote on 11/22/19 10:15 PM:

So now I am moved to (match) solution.


Last I looked, `match` isn't great for XML, regardless of what 
representation the XML is in.


You might want to make a DSL that does exactly what you want.  Don't 
expect the off-the-shelf tools to be great -- all the neat ones I can 
think of were written by people who moved on to other things over a 
decade ago.


But if you're using SXML, and want to try some aging DSLs, two very 
useful DSLs to use in combination are Oleg Kiselyov's SXPath, and Jim 
Bender's `sxml-match`, and you could look at those for ideas.


One of my unreleased (sorry) XML DSLs was a variation on `sxml-match`, 
which supported things like matching unordered sets of sub-elements.


Automatic conversion to better Racket types (e.g., string, number, 
date), based on schema or DSL annotations, would've been a nice 
convenience.  Racket struct type definitions derived from an XML schema, 
in combination with a validating parser, would also be nice.  An 
interesting language design problem was for XML transformation DSLs, but 
there's less need of XML-to-XML transformation nowadays than was in the 
original vision.


If you want better XML tools, it's probably up to you.  And being 
empowered to make a DSL that works better for your needs than anything 
that exists is half the reason to use Racket or another Lisp.  I'm not 
doing any further work with Racket, and am just about to unsubscribe.


--
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/33b56af7-306e-b0ab-09bf-d687858c6faf%40neilvandyke.org.

Re: [racket-users] xml library clarification - "" symbol parsing

[Neil Van Dyke]

Kira wrote on 11/22/19 12:43 AM:
I am trying to understated what purpose it serves? Does this done 
intentionally, or this is just random side effect?


I suspect it's an implementation decision of the parser, done for 
reasons of implementation ease or runtime efficiency.  It's not-unusual 
in XML and HTML parsers I've seen.


For example, imagine a parser that has a fast way to scan an input 
stream for the next special character (including `&`), and then take 
that chunk of all the non-special characters as a string.  That string 
can then be used as-is in the parsed representation.  Then a different 
mode of the parser starts parsing from the `&`, and ends up adding a 
new, different string for the result of that, perhaps coming from a 
lookup table.


That hypothetical parser assembling the parsed representation *could* 
then concatenate sequences of 2 or more contiguous strings representing 
CDATA, but that could be expensive, and might not be needed.  Consider 
how large some XML and HTML documents can be, and how little information 
out of them is sometimes needed (e.g., price scraper) -- 
performance-wise, the concatenation might be best left up to whatever 
uses that parsed representation.


If you're using a DSL for XML querying, pattern-matching, extraction, 
transformation, etc., then you might have the DSL do that concatenation 
when worthwhile (e.g., when extracting the content of an element, with 
type-checking).  I've implemented such a DSL before.  Or you might do 
that concatenation in your application code, as needed.  Or you might 
not do the concatenation at all, because, even if you used query tools 
to narrow in on the information you wanted, you're streaming it out to 
somewhere else, or transforming it in some way that doesn't benefit from 
(and even might suffer from) an intermediate concatenation.


Anyway, that's just a quick explanation in answer to your question of 
*why* a parser might happen to do it the way you say.  But I agree that 
it's not intuitive, and you'd also like to have better off-the-shelf 
DSLs for working with that parsed representation.  XML processing is no 
nearly longer as popular as in the early days of Racket (PLT Scheme), 
which is when most all of the XML tools available for Racket were written.


If you wanted, you could make better tools.  Though be aware that I 
think the "market" for XML tools in Racket is even smaller now than it 
used to be.  So I suggest only making such for your own reasons, not out 
of altruism to help solve this problem for others, nor to "promote" 
Racket.  (Racket was promoted by some of the XML and HTML tools earlier, 
but not anymore that I'm aware of.)


--
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/55cd8570-6f17-8e9b-0620-569c3cc27333%40neilvandyke.org.

Re: [racket-users] Announcing Stripe Integration

[Neil Van Dyke]

Sage, thank you, this is great kind of package for Racket.

--
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/ecfd5d30-3dbd-97d9-b0c3-7c217f48b894%40neilvandyke.org.

Re: [racket-users] schism - scheme to wasm compiler

[Neil Van Dyke]

Correction: "see which Scheme implementations come out with *Wasm* backends"


--
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/8670e595-75e3-145a-2b70-d966284175df%40neilvandyke.org.

Re: [racket-users] schism - scheme to wasm compiler

[Neil Van Dyke]

caleb wrote on 9/21/19 11:27 AM

I'm a bit of a Racket noob--how extensive of a project is it to get Racket 
running on x R6RS scheme?


I think there's a number of ways to do that, and to scope it, and I want 
to just put some initial thoughts out there, rather than propose 
requirements and particular approach...


I mentioned the Schism thing as proof-of-concept, and to point people at 
Wasm standards questions they might want to get involved in.


If you're asking out of the idea of using a Racket layer/transplant over 
Scism specifically, I'd guess that's a ton of work.  I think it would be 
a ton of work even atop an R6RS, and Schism is still missing a lot of 
work to get to R6RS.


More generally, there are a variety of ways that one could plausibly 
bring Racket and other Schemes back together.  The 
technically-attractive approaches that come to mind would probably need 
funding, or someone who could afford to volunteer a programmer-year or 
more.  (If you instead wanted to distribute the work among multiple 
volunteers, you might need a very lucky matching of volunteers, or a 
manager-year just to try to coordinate that.)


(Software/Internet open standards development seems to tend to be hugely 
difficult.  In Schemes, there's very little money complicating things, 
and there's a nice historical willingness by most Scheme implementations 
to conform to the eventual standard. But going through all the 
interaction, especially broad academic and hobbyist community input, and 
very little production input, to get to the standard, and have it be a 
great standard wrt some goals of the standard and/or of yourself, seems 
likely to be a ton of work.)


(In some standards and open source projects (e.g., Web, Linux, other), 
those with the most funding tend to have more influence than others, 
because they can invest the most work in standards questions, and/or 
they do the most open source development that becomes de facto 
standards.  That dynamic can be better than some alternatives, such as 
things people need never getting done, because people are deadlocked in 
debate or don't have the funding, though of course it has risks or 
downsides, too.  Usually, the best-funded party is moderated by a desire 
for buy-in from other participants, who have other options.)


I'm not discouraging work like the above -- and I would like to see 
Racket and other Scheme implementations/descendants reunited in a good 
way -- only saying I think it's probably a ton of work, so don't assume 
it's something you can do in a month of evenings and weekends.  Unless 
you find a way to scope it to a smaller problem that still satisfies 
your particular hard requirements.


For people preferring to write in Racket, but who have a hard 
requirement to target Wasm, adding a Wasm backend to Racket might be the 
quickest viable way.  Or give up on the Racket requirement, see which 
Scheme implementations come out with Racket backends (or make your own), 
and start porting/adapting Racket features you need/want atop those 
implementations (and/or atop RnRS, but RnRS alone might not be 
sufficient primitives for what you need, to do it 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.
To view this discussion on the web visit 
https://groups.google.com/d/msgid/racket-users/26edc829-d2dc-74ac-0444-e3cf8868a369%40neilvandyke.org.

Re: [racket-users] Pitching use of Racket at work?

[Neil Van Dyke]

Sage Gerard wrote on 9/19/19 10:47 AM:

To add color: A prior supervisor said  "if it's famous, we should use it."

[...]

If you want to appear among the first results, just present your work using 
language that matches nothing else.


If I could briefly return the favor of color, by connecting the above 
two:  At one interdisciplinary lab, the stated tenure criteria was "be 
famous in your field", and one of the dominant strategies was... name a 
new field (and you'd automatically be famous in it). :)



Now, by "our own boats and airplanes" Are you referring to Racket2?


I was thinking instead that we haven't built much startups 
(boats/airplanes), ourselves.  Rather than almost cargo-culting, 
figuratively in the original sense of the term, to try to get other 
people to bring their boat/airplane of goodies here.


Early on, there was one really positive public-sector-ish Web data 
science startup, that a couple of superhumanly-productive PhD ancient 
astronauts managed to build (which I think wouldn't have been doable 
initially, had they not used a Lisp, and one of them happened to choose 
Scheme), and which I understand has been able to keep evolving, over the 
years.  There's currently a few smaller Racket-using startups emerging, 
and maybe some of them will have experience report writeups on HN, and 
be considered successes in that tough audience.  And of course, we have 
core Racket itself, which in many ways is a successful startup.


I don't suspect that things I've seen mentioned about Racket2 will have 
any net effect on adoption by other startups.  I'd like to see Honu 
tried for some things, maybe starting with dogfooding it for HtDP.  And 
Honu might incidentally, also be part of a larger DSL solution (e.g., 
alternative way, to the boring lex modules, as a better way to 
make some non-sexp DSLs for non-developer domain experts).  But I'd 
stick with leaving `#lang racket/base` as the canonical language for 
developers, and let people build upon that the things they find they 
need -- for core's research/teaching, and third-parties' work and hobby 
projects.


I hope we didn't lose any additional people/projects, over the recent 
commotion and uncertainty, besides what we already sadly know about.


Today, I *don't* recommend that people ask "What do we need to attract 
other developers?", but rather, "Do I want to do a startup/project, and 
if so, should I use Racket, and then what do I have to do, to launch my 
own minimum-viable-product, and then later grow it?"


My own top-level requirements are to do things that benefit society, do 
technically/craft-wise rewarding programming/engineering/research, have 
some sense of community/collaboration with good people, and make good 
money. (Money, so that I can continue to live in my HCOLA town, and 
focus my energy on the first three things.)  The next levels of my 
requirements might well involve Racket, and so might also involve 
contributing requirements like other people doing startups that use 
Racket.  We have yet to see what are the top-level and supporting 
requirements that will drive core Racket, and then individual people and 
organizations can try to see how that fits with their own respective 
requirements graphs.


--
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/ea874c46-7930-2955-4450-717dd9e6d2b8%40neilvandyke.org.

Re: [racket-users] Pitching use of Racket at work?

[Neil Van Dyke]

I'll assert that Racket is currently for a subset of the people who are 
allowed to choose whatever tools they want: academics, hobbyists, people 
developing small tools for individual use (like sysadmins did with 
Perl), and... some startups.  Most organizations, you can't choose any 
tools you want.


I currently suspect that startup successes are the most likely way 
Racket could become permissible for people who can't choose whatever 
tools they want, for reasons implied below.


Sage Gerard wrote on 9/18/19 6:25 PM:
I know there are not enough Racket programmers out there to justify 
many risks in maintaining large Racket projects in large firms,


This is something some people think, and there's some validity to it, if 
you want interchangeable commodity developers.  But using a fringe 
language with a cult following is arguably an advantage for attracting 
better talent than you otherwise could, with your pay or the initial 
appeal of your project.


For example, ITA Software wasn't able to hire a fleet of brainiacs and 
FAANG-employable fresh MIT grads by saying "uh, we're going to plug into 
a musty old mainframe network, and add that to your resume".  The pitch 
that attracted many was more like "We're going to use Lisp to do 
something big we don't think could be accomplished with mainstream 
languages, and you get to use Lisp and get paid for it, and, hey, did we 
mention Lisp".


There seem to be many more fringe language programmers than there are 
paying jobs for them.


Also, you can make more, rapidly.  I'm pretty sure I can teach a 
programmer modified-Pascal-style Racket in a day, and have them start 
coding on real product, and then incrementally build them up from there, 
in more idiomatic Racket and libraries, in parallel to them churning out 
programming work.  It's not difficult.


A related concern is to not want umpteen different languages within an 
organization.  More reuse, more flexibility in reassigning human 
resources, possibly ease of integrating, etc.


At least as big a concern as staffing is whether a fringe technology 
will do what you need.  We know what tools other companies are using 
successfully, and different tools tend to be considered unproven or 
inadequate.


so I emphasize the word "try" in my question. I'm hoping your stories 
might help me learn how to get more professionals to be at least 
curious about it.


The more I use Racket the more I wonder why so many other people 
/aren't, /even if only to learn more.[...] When I bring it up, people 
look at me like I'm that crazy guy yammering about veganism or Crossfit


Among Web developers, there seems to be what has the appearance of 
vegan/Crossfitter true-believing (and also evangelizing, once you're in 
on it), and a lot of it seems directed at constantly adding what you 
think is or will be the next big employable thing on your resume.  This 
valuable thing to add to your resume can be particular latest Web 
frameworks, cloud services and cloud architecture keywords, programming 
languages, etc.


I suspect hardly anyone currently thinks Racket will be the next big 
thing (as much as we like to use it).


Also remember a lot of developers are intentionally hopping jobs every 2 
years, which might've started as pursuit of the most promising dotcom 
IPO lottery ticket, but now seems to be institutionalized professional 
practice among employees, and, consequently, employers.  Which 
intuitively might lead to employees prioritizing resume-distinction, 
over their projects working well beyond when they're next hopping (e.g., 
when they hit their vesting cliff, in 5 months and 3 days).


Aside from that, there's also the genuine nerdy techie side among many 
developers, and they can get interested if you have something new and 
interesting to say, *but* a working adult probably won't be much 
interested in pursuing it themselves, unless it's a keyword they think 
is currently/imminently in-demand on resumes.


Sometimes genuine nerdy techies will do blog or social media posts on 
fringe things, which incidentally promote personal brands as smart 
people with breadth, and is something some employers/schools look for, 
without investing a funded project on any of the fringe things.


Promotion-wise, for a fringe technology, I see such posts and tutorials 
as messages put in bottles, tossed into the ocean, in the hopes that the 
bottle will be picked up by a passing boat halfway across the ocean, and 
it will be a happen to be a boat of a funded startup team, and they 
decide to use Racket, and plot a course for our pretty little island.


We've been tossing bottles after other people's distant boats that we 
couldn't even see, for well over a decade.  In that time, we hardly 
built any of our own boats and airplanes, which, in hindsight, might've 
been a more expedient way to reach those other people's boats.


I said nothing above about parentheses, which used to be a common thing 
for people to raise as 

[racket-users] rockstar and related languages (Was: Racket News - Issue 16)

[Neil Van Dyke]

On a light semi-PL note... One possible application or inspiration for 
the Rockstar language mentioned in this issue of Racket News 
("https://github.com/whichxjy/rockstar-rkt;), is for what could be 
called a thought exercise (among other things), like in the second 
paragraph of: https://en.wikipedia.org/wiki/DeCSS#Legal_response


(Note the three-leet "1337" reference in examples on 
"codewithrockstar.com", which had a lot of cultural overlap with things 
like DeCSS, at the time.)


If anyone wants to play around with ideas like this, in addition to this 
#lang, I'd suggest also quickly taking a look at the DeCSS haiku (which 
might also rate a #lang haiku), and maybe various old Perl languages (I 
recall people were playing with things like programming in Latin, when 
Perl introduced a feature somewhat like #lang).


You could also see how much of one of these languages you can implement 
mainly as Racket Honu grammar specification.


You could also try to map out the space of such languages, maybe 
including concepts like syntax translation, obfuscation, steganography, 
ciphers, semantics translation, riddles, other linguistics concepts, 
visualization, and even allegory.  Then, who can generate a language 
(human, machine, writer, designer, artist), who recognize it, who can 
interpret it (human, machine, AI-hard, and/or requires cautious literary 
critical theory), how reliably, is it ambiguous/lossy, what other 
information is required, etc.  Can DeCSS be expressed in a convincing 
style of Shakespeare or Kafka, by whom, and then who could interpret it 
as correct algorithm?


--
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/2d85fb1a-d3c4-3cb1-417e-52caeaa0fb68%40neilvandyke.org.

[racket-users] schism - scheme to wasm compiler

[Neil Van Dyke]

FYI, a proof-of-concept of compiling a good subset of Scheme to WebAssembly:

https://github.com/google/schism

It relies on two experimental(?) Wasm features, one of them for PITCH:

https://github.com/google/schism#schism-uses-experimental-webassembly-features

via https://news.ycombinator.com/item?id=20976927

--
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/2e5b2277-c9e5-9dd2-66b5-ecddb1368b3b%40neilvandyke.org.

Re: [racket-users] Is there a webview for Racket?

[Neil Van Dyke]

Hi, Andre.  For your RSS reader, you're only displaying the RSS items 
themselves, not browsing to arbitrary other Web pages within the same 
Racket window, right?


For very plain HTML, one thing I would hesitate to use is the *very old* 
and *possibly insecure* GUI thing, but it might work for your purpose 
(be sure to sanitize any untrusted input HTML): 
https://docs.racket-lang.org/browser/index.html


You might be better off using one of the heavier text components of the 
Racket GUI library (maybe 
"https://docs.racket-lang.org/framework/Editor.html;, unless it's 
overkill?).  This isn't an HTML/CSS/JS/DOM engine, but I'd think you 
could do an RSS item or feed view in it.


Another option, and maybe often the usual way, is to use the user's own 
Web browser (or a standalone one you provide), and you only provide the 
HTTPS server.


A final option, which could be a ton of work to support cross-platform, 
but might be viable if you're targeting a single platform and willing to 
support it, is to do FFI with one of the big off-the-shelf Web browser 
engines, like WebKit (such as through WebKitGtk).  There's recent work 
on Guile bindings for something like that, but Racket has a lot of other 
stuff that Guile doesn't yet have.


Separately, for navigating from an RSS reader running as a Racket GUI 
program, to view arbitrary Web pages in the user's main Web browser, 
see: 
https://docs.racket-lang.org/browser/index.html#(mod-path._browser%2Fexternal)


(I'm pleasantly surprised that people are still interested in Web 
"syndication", despite some browsers and various commercial forces 
moving away from that, for various reasons.  If you're making a 
general-purpose RSS reader, an additional protocol to consider also 
supporting is "https://en.wikipedia.org/wiki/Atom_(Web_standard)". If 
you later want to be even more general-purpose, look at how 
"https://en.wikipedia.org/wiki/Gnus; used the power of a Lisp to provide 
a sophisticated unified view from various messaging/syndication/etc. 
formats, including from Web-scraping.  In addition to threading 
features, it also had powerful scoring/ranking interfaces (both crafted 
rulesets and ad hoc).  Early research in automated collaborative 
filtering (what today we know as things like likes/upvotes, and perhaps 
recommendation systems) was also done atop Gnus. I'd say Gnus is 
probably still more powerful than any UI we're using today to access the 
same or analogous kinds of data sources, and it works on behalf of the 
user.  I don't know how much Gnu is developed lately, but it's worth 
looking at for ideas of what you can build, even better.)


--
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/c9be1a00-e9c3-91b5-ca2e-06b0ded2c35b%40neilvandyke.org.

Re: [racket-users] continuations for search

[Neil Van Dyke]

I don't recall seeing that implemented in Racket/Scheme, but, in class, 
years ago, Leslie Kaelbling mentioned using Scheme captured 
continuations for AI search backtracking, as I mentioned (and Matthias 
has good comments in that thread): 
https://groups.google.com/d/msg/racket-users/jHPtw3Gzqk4/AAqsc-x-AgAJ


That might've been in the class for which we were using a draft of the 
Russell text; I don't know whether it was mentioned in there.  
IIRC, Leslie at the time was coming from Stanford AI Lab tradition (West 
Coast tradition OG, to MIT's East Coast).


For most purposes, perhaps one would probably want to write a search two 
different ways: one that takes advantage of Scheme's first-class 
continuations, and one that doesn't; and compare them (both performance 
and ease of implementation).


I don't know how relevant to performance it would be that we almost 
never see first-class continuations being leveraged directly in users' 
code (outside of the implementation of a Scheme itself), and how that 
might have affected priorities in the Scheme implementation.  The 
implementor of a particular Scheme could say.


--
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/4ed3134c-54fd-5747-486d-c45ce93a99bb%40neilvandyke.org.

Re: [racket-users] Downloadable tutorials (e.g. on github)? Tutorial example source codes samples attached to DrRacket instalation?

[Neil Van Dyke]

You can find various Scheme code around the Internet, and various 
textbooks that use Scheme (sometimes with the code available for download).


The Racket code for much of core Racket itself is also available, and 
some of it will probably be installed already, though it's mostly not 
written as beginner tutorials.  (It represents particular styles, and 
can also get pretty obtuse, so grepping for how to do, say, GUI tabs, 
might not be very helpful.)  The first bundled code that comes to mind 
as possibly helpful might be on your system under 
"share/racket/pkgs/games/" (or something like that).


There are some good tutorials that people have written as blog posts and 
Racket manuals.


I agree that a set of code written specifically as "load these in 
Racket" tutorials would be useful for people who like to get started 
that way.  (Perhaps as "notebooks".)  I don't recall much of that 
specifically for Racket, but I've seen it for some other languages and 
frameworks/libraries.


A long time ago, there was a "Scheme Cookbook", IIRC, started by Noel 
Welsh, et al.(?), which emphasized what's now called Racket, but which 
seems to have disappeared.  It wasn't strictly tutorial of the language, 
but was perhaps inspired by a cookbook for Perl, and showed ways to 
accomplish tasks thought to be commonplace, which often meant runnable 
code samples, and one could learn some things just by reading those.



Aside, before I encourage people to work on all the above... We already 
have so many piles and piles and manuals and other trappings of big, 
popular platforms, wildly disproportionate to how much actual people and 
real-world uses we have.  I keep thinking of additional ways to promote 
Racket, but I don't want to inadvertently be "playing house".  I 
currently think that one of the most important things we're missing, at 
least for the goal of practical use promotion, is more actual deployed 
real-world success stories, probably from startups.  There's already 
more than enough ways to learn Scheme and Racket sufficiently, to deploy 
real-world systems. If someone is up to doing such a startup: find a 
startup CEO who can get funding, start coding with the copious 
information and community support available for Racket... and then feed 
back your success story, as well as feed back useful generic open source 
modules you'll probably have to write to get to launch.  (And if you can 
get enough funding for that startup, I could help with everything except 
the funding schmoozing.)


Of course, if one wants to make, say, tutorials, that's great, and they 
should.  But if they're starting with the goal of wanting to do big 
things in Racket, or wanting to have other people do big things in 
Racket for some reason, then making tutorials might not be the most 
effective way to achieve that.


(A humanities professor friend says that one of the biggest things she 
has to teach enthusiastic, woke new undergraduates is that they can't 
simply write to "raise awareness".  IIUC, she has them start with issues 
they care about, research and understand the issues objectively, learn 
about the structures in which changes they want can happen, and only 
then effectively communicate, to make actual progress, based on all that 
understanding.  I can't claim to know how for certain how to do this for 
some of the more popular goals of Racket people, including my own goals 
for Racket, but I'll try to keep that wisdom from outside STEM in mind.)


--
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/ca06c7bb-f9f7-d59d-0d53-87c6e72619d8%40neilvandyke.org.

Re: [racket-users] minor infelicities in style guide

[Neil Van Dyke]

Regarding the discussion of tests expected to fail, and moving 
expected-fail tests to different directories, I wonder whether you'd 
prefer using an expected-fail annotation per test case.


An annotation seems useful for my own work, and lightweight, but I don't 
know about core Racket (especially with the couple decades of legacy 
tests done various ways).


https://www.neilvandyke.org/racket/overeasy/#%28part._.Expected_.Failures%29

--
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/a16626c5-72c5-17ea-fdee-b84583cd6d0e%40neilvandyke.org.

Re: [racket-users] general mapping tools?

[Neil Van Dyke]

Josh Rubin wrote on 9/6/19 1:36 PM:


Google Earth (still available as a desktop application) uses
*Keyhole Markup Language* (KML) is an XML-based *markup language* 
designed to annotate and overlay visualizations on various 
two-dimensional, Web-based online maps or three-dimensional Earth 
browsers (such as Google Earth).


Has anybody been down this road in Racket?


Yes, IIRC, I used Racket-generated KML heavily, plus a bunch of 
animation behavior and sim readouts and controls in JS, for driving 
Google Earth Plugin, from data served from a Racket-backed Web server 
(fronted by Apache, due to other server requirements, via SCGI).It was 
for an animated and controllable visualization of particular real-world 
data. It was very practical for some purpose, and also crazy-cool to see 
working in a Web browser (much cooler than the Plugin demos).


(I was pushing the limits of what the Plugin could do.  For example, at 
the start scene, there's a quick animation, as we zoom in and pan around 
a central 3D object.  You might think it's to provide spatial context, 
or just to be slick, but it's actually to force the Plugin to not elide 
some added 3D graphics objects that it otherwise was.)


Nowadays, you might be able to do it portably in a Web browser , using 
GL, if you had all the geo data, and satellite imagery textures, but it 
would be a lot of work to do from scratch.


BTW, I recently heard Google might be reviving some kind of in-browser 
Google Earth, more like the Plugin, and that might be very practical for 
some projects.  Though, if you're depending on it, you have to be 
careful of things like poor-portability or massive-moat browser 
'standards' (moving back towards the walled-gardens that some early 
online companies tried), as well as it just being canceled 
("https://killedbygoogle.com/;).


--
You received this message because you are subscribed to the Google Groups "Racket 
Users" group.
To unsubscribe from this group and stop receiving emails from it, send an email 
to racket-users+unsubscr...@googlegroups.com.
To view this discussion on the web visit 
https://groups.google.com/d/msgid/racket-users/9f171a43-862a-2572-ad5c-dd18d51f51f0%40neilvandyke.org.

Re: [racket-users] [OT] Nostalgia

[Neil Van Dyke]

Last week on HN, a non-student was complaining about having to increase 
DrRacket's memory limit 3 times while they were playing with it, so I 
pointed out that DrRacket was designed for new students, and suggested 
that maybe that memory limit was a good thing for new students.


One of frequent complaints, from generation to generation, seems to be 
"kids these days got it too easy".  Which, in programming, is not 
necessarily grumpy, but concern that a lot of learning opportunity that 
comes from working with resource constraints is being missed. 
Personally, I think there's a balance, and there's also learning 
opportunity missed when you don't have lots of resources.  Ideally, a 
person gets both kinds of experiences.


As a C and C++ programmer who was then an early Java promoter, I was a 
bit concerned about that, at the time.  I figured we'd probably move to 
Java, and all the students already had use of powerful multiprocessor 
workstations.  That was one of the attractions of then playing with 
programming the Pilot PDA ("https://www.neilvandyke.org/t-map/;), and I 
promoted Pilot programming to other students specifically for the reason 
of learning to develop with tight resource constraints.


Other Racket relevance: the approach to fitting the toy "route planner" 
into a few KB was to use two little DSLs, with a Lisp as code generator 
to get around the limitations of macro preprocessing in C.  Between 
that, the crazy DSLs I made as sets of cpp macros for my compiler (C++) 
and robot (C) assignments, and an awful concurrent hierarchical state 
machines language that took way too much effort to implement in Java, I 
suppose it's not a surprise I later decided to move to Scheme/Lisp for 
my main research tools.


Also, copious computing resources becoming available to lots of people 
became a concern to some researchers, who no longer felt as privileged 
as before.  At the start of the dotcom boom, one of my grad school 
advisors was already spending most of their time on startups (and there 
was some truth to the joke about advisor only wanting MS+IPO students).  
They called an off-site retreat for our group, where a big part of the 
case was that the university research lab no longer had special 
advantages like supercomputers that other people didn't have.  (And I'd 
previously been horrified to see the storage array cabinet from a 
Connection Machine being used as a barkeeper counter, for the lab's posh 
sponsor events.).


Today, it's true: I have my own deep neural networks supercomputer in my 
living room, for a few hundred dollars, and it's just an ordinary 
consumer GPU like children have in their gaming PCs/consoles.  Which 
makes for "lots of resources" learning opportunities, complementing the 
"not enough resources (until you figure it out)" learning opportunities.


--
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/8458611a-0bd8-8af3-dab9-dba61b8c2c42%40neilvandyke.org.

Re: [racket-users] Re: third-party package tips and developer concerns (Was: New version of file-watchers)

[Neil Van Dyke]

Simon Schlee wrote on 9/1/19 3:28 PM:


Try not to make identifiers be simple generic terms, like `watch`


I strongly disagree with this statement.


I think what you say is valid, and I agree in some situations.

However, we're talking about reusable third-party packages, which are 
used pretty much the same as much of the "standard library" of Racket.


When I look at the Racket Reference, the standard library tends to use 
descriptive names, like `file-or-directory-permissions` rather than 
`permissions`.


A third-party package analog might be `watch-file-or-directory` (or 
whatever the rough purpose is) rather than `watch`.


The way racket does imports is one of the things I highly value 
because you can use modules to aggregate identifiers from different 
modules/packages,
resolve name conflicts by renaming / or not exporting the 2 
identifiers that clash.
This creates a lot of freedom to create specific sets of functionality 
exported by one simple module.
This way I can create my custom set of things which are most needed in 
the particular codebase.
Instead of having to write 40 lines of requires like you have to in 
other languages.


True, that kind of module coupling often happens, and a module to 
aggregate a class of exports used by a codebase can be very convenient.


That aggregating module might also, as you said, be an opportunity to 
fix the problems created by having all those modules export terse 
generic names rather than more descriptive ones.


BTW, one drawback to the exports-aggregating module for a codebase comes 
when any of the aggregated modules changes (or the exports change, 
depending on how simple the compiler's sense of dependencies and 
changes).  In a large system, for an aggregating module used widely, 
this can cause needing to recompile much of the codebase (which can be 
costly, in the size of system in which I think one would consider making 
an aggregating module like that).  Imagine the perhaps not-unusual 
situation of changing a module actually only used by 10% or 1% of the 
modules that import the aggregating module.  Coincidentally, the largest 
Racket system I worked on had a couple such aggregating modules, which 
initially made sense, until they were covering way too much stuff that 
got changed way too frequently, and it made the code base way more 
cumbersome to work with than just having the appropriate `require`s 
would be. (Auto-updating the `require`s would've been nice, though.)  
One of them actually made a lot of sense initially -- it was a logical 
whole that was unlikely to change -- until that thing got more things 
added to it, and until we needed to actively work on that thing while 
testing it integrated with the system (unit tests aren't always 
sufficient, or aren't always the most expedient).



Finding things in the documentation is a whole other technical issue.


I agree that could be improved.  One bit of obvious low-hanging fruit 
(with IDE integration) is having the context of your current #lang and 
requires as factors in search hit rankings.  (I'm not criticizing the 
current documentation search; it works surprisingly well for offline 
search, and with not that much resources, and was very clever in how it 
was implemented.  I think it might've been by Eli Barzilay.)


In the interim, a boost comes from descriptive names (which also happens 
to be idiomatic Racket, and idiomatic Racket).  That boost might be 
worse-is-better, but it works. https://en.wikipedia.org/wiki/Worse_is_better


Also, I don't think Web searches, such as of forum posts/messages, 
articles, code repos, etc., are sensitive to ad hoc import renaming.  So 
you might get better global search hits for "racket 
file-or-directory-permissions" than "racket file permissions".


*

Racket2 aside, since you might be looking for terseness in some 
regard... One of the higher-level (but not top-level) requirements for 
Racket2 might concern terseness.  Not just in naming, but in other 
things as well (e.g., does a mutating or definition form also produce a 
value, so that it can be embedded in, say, the condition of a loop; and 
perhaps somehow easing the burden of expressing big imports sets).  Base 
Scheme is one of the less-terse of languages I know, and that took a 
little getting used to, though eventually I decided it resulted in a 
good balance of overall readability (and I could layer over the base 
when that helped).  But maybe Racket2 decides to go more terse in the 
base, which might be reasonable.  In any case, that's a bit of language 
design space choices, which, in the context of Racket, I think should be 
traced back to top-level requirements (e.g., why is the language being 
made at all, for whom, for what purposes, and why that), and influence 
much of the other requirements below it.  (I'm saying "requirements" 
lately because it's a software engineering framework that should help us 
be clear about things we haven't yet been, though I 

Re: [racket-users] Re: third-party package tips and developer concerns (Was: New version of file-watchers)

[Neil Van Dyke]

Sage Gerard wrote on 8/31/19 10:38 AM:

You probably don't want to be slowing yourself down with offering people 
previews of new versions, lead times for input, etc.

I'm unknown in open source so


I think all of us in Racket land are pretty much unknown in open source 
(outside of Racket/Scheme). :)



creating as many opportunities as possible for feedback is valuable enough to 
be worth the effort.


OK, if you want the input, or are willing to do that extra work, that's 
great.  I only meant it as I said it: I wanted people considering being 
third-party package developers to know they weren't obligated to take on 
that extra burden if they don't want to.



Re: deprecation, I strongly believe that less code is better, and I hope that I 
can draw compromises with users on doing things like remove redundant 
functionality on my own.


That sounds reasonable to me, if that's how you want to do it for your 
packages.


If a third-party package developer expects to possibly break 
backward-compatibility in the future, it might make sense for them to 
indicate that near the top of their package documentation.  That makes 
the social contract more clear.


(I don't think there was much buy-in on that backwards-compatibility 
policy for third-party packages, which was handed down to replace the 
lost PLaneT version support.  It was core-centric, and burdensome to 
third-party developers who are doing rapid/agile 
research/move-fast-and-break-things, and/or open-sourcing parts of a 
system on which they do things like global refactoring, and want to be 
able to make backward-incompatible changes to their code.)



the style guide


That style guide applies only to the code of core Racket itself, not to 
third-party packages.  You can look at it for ideas, or adopt it as a 
bible, if you want, but do your own code however you like.



I think a general theme in these comments is to encourage important and 
sensible things for package developers (e.g., create package metadata 
and catalog entry, do a versioned release of some kind, consider 
including documentation and tests, consider naming things to work well 
with doc search and code readability), but not burdens that people will 
often either ignore or find too discouraging to do anything at all 
(e.g., you don't have to format your code a certain way, you don't have 
to preserve backward compatibility with each version, you don't have to 
Scribble).


--
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/2355bc5c-09da-5c46-b002-2ae03c69329f%40neilvandyke.org.

[racket-users] third-party package tips and developer concerns (Was: New version of file-watchers)

[Neil Van Dyke]

First, to Sage, thank you for going to the work to open source 
third-party packages like this.


Here are a few suggestions that came to mind from this post, which I'd 
like to mention to Racket third-party package developers in general. 
(Only suggestions, not presuming to tell anyone what to do; just 
avoiding real work this early Saturday morning. :)  Also, as I was 
writing this, I realized one of the points is an opportunity to give 
some context on recent governance concerns.


Note that some of these suggestions are biased to a development approach 
that encourages developing all software in such a way that there's often 
low friction to project/organization-internal component reuse, or even 
to selectively open-sourcing individual modules.


* Normally, you'll be developing your own large systems, and a given 
open source package will just be a small part of it, and you might have 
many such open source packages.  You probably don't want to be slowing 
yourself down with offering people previews of new versions, lead times 
for input, etc. -- when you're ready to push a new version, just do it.  
There are other mechanisms for not breaking users of your package.  Of 
course you can ask for input if you're contemplating big or breaking 
changes, and not sure what to do.


* Try not to make identifiers be simple generic terms, like `watch`, 
that might better be used for key language features, or in users' own 
programs.  (Note that, historically in Racket, there was an idea that 
modules might provide such simple generic identifiers, and then modules 
using them would add a prefix or otherwise transform them. But that had 
a couple problems: it was more work for the module user in practice, and 
it also meant that reading unfamiliar code or looking up unfamiliar 
identifiers in documentation/Google search was harder.  There will 
always be a lot of name collisions in Racket documentation search of 
core Racket and whatever third-party modules are installed, but 
non-generic names improves that in a worse-is-better kind of way.)


* Of course, you can name your identifiers however you want, and you 
might want to make them fairly descriptive, in the scope of all Racket 
packages.  One convention that sometimes (not always) seems good is to 
include the package name in each exported identifier, which helps search 
and recognizing which package an identifier comes from when reading 
code, and also reduces name collisions between packages.  For example, I 
think every identifier from the `roomba` package contains `roomba` in 
its name (and if you wanted shorter names for this package, to make it 
more like, say, Logo turtle graphics, that might be a `#lang`), 
"https://www.neilvandyke.org/racket/roomba/  That convention might not 
be appropriate for `file-watchers`, but I just wanted to mention it, 
because it seems to often help.


* Try not to remove deprecated interfaces from within a package, unless 
keeping them is a significant burden for you.  You can move the 
documentation for them to some dark corner of the manual (like the end 
of the manual, or end of a section), and use the `deprecated` Scribble 
procedure on them.  But if it's practical to keep them in, that reduces 
breaking users of your modules.  Think of a little deprecated API as 
like scars of a battle-tested and enduring package.


* When you do want to break the interfaces, there's currently no great 
way.  Racket's original PLaneT package system had a very simple yet very 
nice SemVer-like versioning system that some third-party package authors 
used,[1] and multiple versions of the same package could be installed at 
once.  That was particularly helpful for low-encumbrance third-party 
packages.  Users of the package could keep using the old version until 
they were ready to make changes to use the new one, and the package 
developer (usually altruistically releasing some part of their system 
that was their real job) wasn't unduly burdened.  And being able to have 
multiple versions of a package installed at once could often (though not 
always) let you move incrementally, of packages you control, and from 
the graph of interdependent third-party packages you use.  With the new 
package system, that version-related functionality was lost, and it was 
emphasized as policy that new package versions should always be 
backwards compatible, and if you wanted to break an interface, you 
should make a new package (with a new name).  Losing that various 
version-related functionality made sense for core Racket's policy change 
to support backward-compatibility, but I think it didn't make sense for 
the breadth of third-party developers for whom we'd like to encourage 
low-friction release and updating of their packages.[2]



[1] See 
"http://planet.racket-lang.org/display.ss?package=javascript.plt=dherman;, 
which was up non-backward-compatible version 9.  Dave Herman was able to 
keep doing his work, but also keep releasing new 

Re: [racket-users] Is there an expanded form of the Racket2 purpose declaration?

[Neil Van Dyke]

and everything is interoperable.


That it will be interoperable is something that must be committed to, 
unambiguously -- it is not something #lang implementors get for free.


(Based-on-a-true-story example of bad interoperability... Your Racket 
module naturally uses lists, the Racket language is then changed to make 
lists immutable (and let's say it gets a new #lang for that), your old 
module #lang still works, but now you can only use new modules in the 
new #lang with difficulty and bug-prone-ness, and then an old 
third-party package you use is moved to the new #lang, so you are stuck 
on an old version of that or have to modify your code, or give up and 
rework all your code in the new #lang. There are ways that could've been 
avoided, but it didn't come for free, and didn't happen.)


--
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/1fabc200-3815-63f6-0e32-c44991bb48f3%40neilvandyke.org.

Re: [racket-users] Is it possible to sell commercial use rights to an open source Racket package?

[Neil Van Dyke]

wrote on 8/28/19 11:45 AM:

Perhaps naively (IANAL), I am willing to be the guinea pig who [...]


I really would've expected the applied game theory civil disobedience / 
anarchism to kick in on a *different* Racket issue. :)


If someone violates (their non-lawyer interpretation of) the Racket 
license, in a conspicuous manner like you suggest, would they not expect 
the SFC to send them a nastygram -- perhaps if only for the SFC to show 
that they defend the copyright, if not for other reasons?


Racket core doesn't necessarily even have to be in the loop: 
https://www.itworld.com/article/2732025/gpl-enforcement-sparks-community-flames.html


That seems like it would be bad for Racket.

I look forward to a few different things getting straightened out in 
September, and then we all can look back, and blame The Racket Fugue on 
this summer's record heat, when no one knew what they were doing.


--
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/ddf1801f-a8fb-450a-3855-847b8c7540f8%40neilvandyke.org.

Re: [racket-users] Is it possible to sell commercial use rights to an open source Racket package?

[Neil Van Dyke]

'Joel Dueck' via Racket Users wrote on 8/27/19 12:17 PM:

On Friday, August 23, 2019 at 10:40:13 AM UTC-5, Alexis King wrote:

Distributing a closed-source, non-LGPL Racket application without
violating Racket’s licensing terms is likely to be very difficult
or impossible,


This was startling for me to read, as I have been contemplating doing 
that very thing.


Questions and confusion about software licensing come up all the time, 
when a conscientious person tries to interpret software licenses.


Open source licenses don't seem as adversarial as many closed software 
licenses do, but are still confusing. I think one needs the background 
of a lawyer to even have a credible sense of whether one understands it 
sufficiently.


If one is doing open source, the open source licenses are so well-worn, 
with so much precedent, it doesn't appear to be stopping massive amounts 
of open source work out there.


On the other hand, if one is doing closed software, again, there's a lot 
of precedent of this working out well, and also, presumably, one is 
going to be paying a lawyer to draft/vet their own licenses, in any case 
(regardless of whether one uses Racket, or anything else), which I 
imagine requires taking a look at licenses of the software one's own 
software uses.  (And that lawyer will be vastly better qualified than 
myself and most of us to say (I imagine), "OK, this, that, and the other 
open source license thing are well-accepted, and you're not doing the 
sneaky thing that causes most problems, so I just have a question about 
whether this other thing over here is the same thing as what already has 
a common interpretation".  Then, there might be a lawyerly question, 
that can then be answered in a lawyerly way.  But if I tried to ask a 
lawyerly question, it would be the wrong question, and how I asked it 
would be wrong 10 different ways.)


After some consideration, I hereby announce my intent to distribute a 
closed source non-LGPL Racket application sometime within the next 
year. If anyone with standing has a problem with that, please let me know.


I agree with what I think you're implying: that licensing is unlikely to 
be a problem.  The informality reminds me of a funny bit from "The 
Office": https://www.youtube.com/watch?v=EuZeff2y32M


--
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/b1572f4f-9731-5ba0-3639-98879dc14020%40neilvandyke.org.

Re: [racket-users] Is it possible to sell commercial use rights to an open source Racket package?

[Neil Van Dyke]

Hendrik Boom wrote on 8/24/19 8:48 AM:
The only problem I see is with the ue of macros in the propietary part 
of your software. They make it difficult to take your object code and 
link it with revised versions of the LGPL'd Racket code.


This seems much the same problem as doing the analogous thing with C 
libraries, not unique to Racket.


Racket macros in practice tend to do than C macros do, but the 
sensitivity of the mechanism seems much the same.


For example, if a C header changes even a single simple cpp-based 
`#define SOME_VALUE 7` "constant" between versions, that would probably 
get baked into compiled code, and one would probably be incorrect to 
relink (without recompiling) a new version of the library that changed that.


(Incidentally, the drawbacks of mixing in closed binary libraries and 
kernel modules with open source software are well-known in C and C++.  
This might plague you, for example, if you're trying to bring up new 
Linux on an old Linux-based device that used closed drivers, or are 
dependent on Nvidia closed drivers for your video display or your GPU 
compute engines.  Separate from not being able to inspect and improve 
the closed stuff, they tend to eventually stop working with newer 
software with which they link, with no practical recourse.)


--
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/277e5d62-b94b-e639-a6e8-f49ff43a58da%40neilvandyke.org.

Re: [racket-users] Is it possible to sell commercial use rights to an open source Racket package?

[Neil Van Dyke]

(Replying to 2 messages...)

Summary: I think there's probably no barrier for you with Racket's 
licensing and intentions, but you will need to talk with your lawyer 
about the unusual licensing you want to do for your own software. Also, 
a few related thoughts.


Sage Gerard wrote on 8/23/19 9:24 AM:
Has someone tried to release an /open source/ Racket project under a 
license that enforces paid commercial use of that project?


It's my impression that the Racket professors intend that you be able to 
do this, and would be happy to see you to do this.  And at least some of 
the third-parties, as well.


Separate from Racket professors, SFC might also have a bit different 
perspective, since it has some noteworthy FSF influences.  (FSF is 
well-known to be philosophically opposed to the approach I think you 
alluded to, and has suggested other ways to make money from software.)


You might get better answers in a few weeks.  (The US school year starts 
in about a week, and people are finishing up vacations, and a bunch of 
new things have been happening at once.)


and learning what other people are doing to earn money independently 
using Racket.


I think there are only a few people making any money at all with Racket, 
outside of academia.  (We're still waiting for a dotcom startup to 
strike it rich, and then say that Racket was the best tool for getting 
to launch.  Then more people will be willing to bet on it.)


BTW, because some discussions about startups and such can be sensitive, 
for various reasons, there's also a smaller, ephemeral email list: 
https://linki.tools/racket-money/  By default, `racket-users` should be 
used, but `racket-money` is there for some of the times `racket-users` 
won't work.



Sage Gerard wrote on 8/23/19 3:42 PM:
I wonder if I should just pick LGPL for safety and then move to 
multilicense if an opportunity presents itself. To add context, I aim 
to use a custom license.


Of course, once you LGPL a release, that particular release is LGPL 
forever.  If you intend to later institute licensing that "enforces paid 
commercial use", the earlier LGPL release might be a practical threat to 
that.  (That's happened.)


Also, you don't want to inadvertently bait users, by starting out 
as LGPL and then changing the license on them.  (That happens with some 
other projects, including some noteworthy ones in recent months, and 
many people react negatively to that.)


There have been a variety of ideas about how to do this, nothing 
specific to Racket.


If you *really* want to altruistically open source something, before 
you've figured out the paid commercial licensing you want to do, and 
some of your software is well-modularized... then consider polishing up 
some of the more-generic, low-tech pieces you had to write (e.g., module 
for routing HTTP requests), and releasing those as LGPL'd Racket 
packages.  Keep your less-generic, more-IP code closed, until you figure 
out the licensing for that.


When it comes to finding that opportunity; Does this thread provide 
enough information for me to retain an attorney and get candid advice 
on how to proceed, or would (s)he be unable to answer given the state 
of ownership?


I suspect that an attorney very familiar with open source licensing 
probably already has enough information to get started -- based on the 
standard licenses you see people putting on core Racket and any 
third-party packages you're using.


The attorney might then ask you technical questions about the nature of 
the use/integration (e.g., for all the separately licensed stuff are you 
using in some way, did you copy or modify any source code, and what is 
the technical nature of using these in Racket).


Then, if some of the important distinctions still seem muddy to the 
attorney (e.g., "linking" in the sense the license might use it, is 
syntax expansion different than function call, compiler output, runtime, 
etc.), then I suppose the attorney might want to discuss with a 
representative of core Racket (and maybe other copyright holders), 
and/or carefully craft questions for them.  That might be more 
productive than people trying to guess what's the attorney will consider 
muddy.


I'm going to guess, as a non-lawyer, that what's going to cost you the 
most billable hours of attorney time is figuring out a custom license, 
if you end up going that route.


The Racket side seems pretty straightforward (e.g., if you'll use things 
under their current LGPL license), once the attorney understands the 
nature of use/integration.


Aside: One thing I don't want is anyone new to Racket and open source 
licensing to get a chance drive-by impression that Racket has unusual 
"licensing problems".  I saw this concern multiple times recently.  I'd 
say Racket's standard licensing (for using it as a 
compiler/runtime/libraries) is pretty commercial-friendly, especially 
given the willingness (perhaps, desperation) of a lot of Racketeers to 
encourage 

Re: [racket-users] is there a list of racket relevant papers/thesis/posters/etc.?

[Neil Van Dyke]

AFAIK, the publication list is currently split up between the different 
universities.  If you scroll to the "PLT Research" section of either of 
the two below (near-identical?) pages, you can click through to the 
different research groups:


https://www.racket-lang.org/team.html
https://www.racket-lang.org/plt.html

If I may please humbly offer one suggestion: before making a centralized 
official-looking publications list, get buy-in from all the researchers, 
and make sure it's representative of how the researchers want to portray 
their work, and that it will be kept up-to-date in practice.


(Racket actually got ripped on by another professor, a couple weeks ago, 
who held up as evidence the paucity of items in one of the Racket wiki 
pages on github, which might've been incomplete.  A publication list 
seems even more important to get right, than most things.)



--
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/3f04d1f9-ea35-a059-949b-87d2cd4a718c%40neilvandyke.org.

Re: [racket-users] See expanded code?

[Neil Van Dyke]

One nice interactive way is with the Macro Stepper feature in DrRacket, 
which is easy to use once you know the button to start it.


Sometimes it helps to copy, into a new file, the minimal usage of 
a macro you're interested in, and just expand that.


Also:

https://docs.racket-lang.org/macro-debugger/index.html

https://docs.racket-lang.org/reference/Expanding_Top-Level_Forms.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.
To view this discussion on the web visit 
https://groups.google.com/d/msgid/racket-users/5133ad54-6c26-5aa8-44e7-53b69bb96342%40neilvandyke.org.

Re: [racket-users] Re: on-boarding new racketeers

[Neil Van Dyke]

Alexis, I appreciate the recent enthusiasm and efforts.

I helped build the current small Racket community (really starting when 
I moved to it exclusively, after developing portable open source for all 
the Schemes).  My name is still up there with yours on 
"https://www.racket-lang.org/team.html".  I recently proposed on 
racket-dev that a lot of additional people's contributions to building 
the Racket community should also be noted there (and I suppose that 
might wait for the Web site redesign work).


Lately, I haven't been able to justify investing more in writing new 
Scheme/Racket code that I can share, but I try to otherwise be helpful, 
to say things that I think should be said, and to preserve/further the 
investment I've already made in Racket.  I oops in what I say 
frequently, but that seems to be unavoidable in practice, and 
racket-users doesn't pay me enough to hire an editor/spokesperson.


As for industry and open source dynamics, probably we both know things 
about this topic that the other doesn't.  I'm sorry I can't get into 
extended discussion of this here, so I can only say I'd appreciate it if 
people consider my suggestions, in the context of their own experience 
and knowledge.


As for whether Racket is Free Software, I don't know, and it's 
low-priority distinction to me, but I suppose that the Software Freedom 
Conservancy might like it to be Free-as-in-FSF, and Racket did just 
choose to marry the Conservancy.  BTW, I've spoken with RMS on multiple 
occasions about how Racket covered bases he laid out in his early GNU 
roadmaps (including something like `#lang`).  Though recently Guile has 
seen new energy and movement towards its originally planned roles, and 
I'm happy to see that advance (and they can get another boost by 
borrowing a couple key features of Racket).


Amusingly enough, there's a connection to the current thread that might 
not be obvious: Guile (and, therefore, Scheme and Racket) was arguably 
sidelined years ago because GNU and various open source desktop energy 
consolidated behind Gnome (other than KDE), as it turned into a startup, 
by a couple very smart and very charismatic people, which startup then 
pushed the nascent MS C# and CLR for GNU desktop work, over Guile from 
the roadmap, which MS push many savvy industry people weren't buying, 
because fool-me-once, but then MS was able to point to an open source 
alternative, the development of which got funded, and which let MS 
suggest it therefore wasn't just an attempt to reestablish a ruthless 
monopoly stranglehold after the Web/Linux/Java/etc. disruption, and 
then, eventually, the startup united with MS, and then the co-founder 
was named head of the newly-acquired GitHub, which was a perfectly good 
call based on his understanding of open source and developer dynamics, 
and now we're back to where this thread started.


That's all public information that you might already know, and nothing 
necessarily wrong about it -- it's just an apropos example of the 
connectedness we often encounter, as we're understanding and reasoning 
about new situations in this business-y space, or trying to distill 
lessons and patterns from old ones.


I'd prefer to just build software systems, but software systems exist in 
a larger human system, affect it, and are affected by it. Hence, for 
example, why more people aren't using Scheme/Racket already, even when 
they want to, which is one reason why even we, in some narrow little 
niche, sometimes need to care about dynamics external to software.


None of us can know All The Things (I'll probably never know even 1% of 
what Matthias does about type theory, for one of many examples), but we 
try to combine what we know, and collaborate effectively, as we have 
time and interest.


I'm sorry I couldn't meet you and others at RacketCon this year, to help 
personalize more of these people who care about our shared community, 
but maybe next year.


--
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/160e446c-ef2e-4fd1-47a9-411a91134947%40neilvandyke.org.

Re: [racket-users] Re: on-boarding new racketeers

[Neil Van Dyke]

I know this particular one is a minor thing, but they add up, over time...

Please consider approaches that are open, rather than owned, and try not 
to increase lock-in by big-business plays.


It's pragmatic to keep using GitHub in limited ways right now, *but* 
part of that is being judicious about creeping lock-in, which is a 
pattern we've seen for decades (and the current owner of GitHub has been 
one of the most epic abusers).


To use GitHub as an example, though this is not specific to them: They 
are not your friend.  They used to seem like your friend, but that 
friendship was worth fewer than 7.5 billion dollars.


When you effectively partner with such a company, approach it as an 
temporary alliance, limit their power over you, and keep trying to 
increase your options/freedom.


Also, consider what you're promoting, especially to impressionable 
students around Racket.  Every use is effectively you endorsing 
something questionable.


Maybe it's time to poke the Conservancy.  It should be on their radar by 
now, and some of the solution applies to all projects.


(I suggested wait on moving the repos from GitHub, partly since it's 
unclear which competitors will sell out next for GitHub/Slack/etc.-type 
lock-in billions.  And I don't have time to see which non-profit ones 
are just an old PC under someone's dorm bed, and will disappear as soon 
as that person gets a job.  The Conservancy is in a better position to 
investigate, and to audit/fund to make sure whatever project has 
sustainable funding. In the meantime, that doesn't mean we have to keep 
increasing our non-repo feature dependence, and make it harder to move 
once we have a chance.)


--
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/0b7d6ef3-d47a-f629-c893-5244b4a635d4%40neilvandyke.org.

Re: [racket-users] Clarify project policy on racket2 syntax

[Neil Van Dyke]

Robby, I'm still not certain we all have a shared understanding of some 
of the concerns and where we all stand, so please let me try to get at 
that some of that:



As for adopting-new-syntax vs backwards-compatibility, does it help if I were to tell you 
that anything new will always be "opt in", in the sense that existing programs 
will continue to work completely unchanged with no special annotations or anything else 
like that required?


I suspect, to many industry software engineers, this phrasing sounds 
like "deprecated", which is something we understand.  It's not something 
anyone likes to hear, unless we've already moved away from it, and we 
think that deprecating that is a positive sign.



There are piles of lecture notes (in the form of slide presentations written in 
Racket) from the late 90s (so not in any continuous integration system 
anywhere, as far as I know) that still run fine in today's Racket for example.


I think this argument doesn't address the concerns of software engineers 
who know the history of Racket (and of countless possible parallels 
elsewhere).


For one example, from Racket specifically, how the change to pair 
mutability was done meant that some of those modules in "compatibility" 
dialects no longer interoperate well with modern modules.  That's a big one.


For a lesser example, which nevertheless was a problem in real-world 
practice: one of the changes to C extensions meant being locked to the 
old, non-default GC (missing out on enhancements, and concern it was 
more likely to break in the future, since most people had been pushed 
along to using the new thing, until that scary C extension code could be 
disturbed again).


Another example was people who were using PLaneT's 
multiple-installed-package versions and SemVer-like updating, when that 
was deprecated and the functionality lost.


From an engineering perspective, over the last couple decades, Racket 
has done a good job, overall.  And an outstanding job, as academic-led 
projects go.  But, at this point, I think software engineers should want 
a clear understanding of top-level requirements for Racket, so they have 
an idea of what to expect.


Some degree of trust factors into assessments of whether adopting or 
staying with such-and-such tech makes sense, and I'd think that arguing 
"some old CS101 lecture slides probably still work" is going to increase 
concern rather than reduce it. :)


Some people (here, and in other venues) are skittish or turned off by 
various recent commotion.  At this point I could allay some of their 
concerns by mentioning multiple mitigation/transition options to them, 
but I'd prefer to keep all the value of the community we've built around 
Racket.


Moving forward... Software engineers have learned to expect modern 
platform pitchers to often be disingenuous, or at least 
over-enthusiastic.  If core states, utterly unambiguously, and speaking 
as one, the top-level requirements that will guide Racket, and 
everything else clearly follows from those requirements, then I think 
that will increase confidence.  (Even if some of the articulated 
priorities are not ideal for our needs, we know what to plan with, with 
some confidence.)


--
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/35d7b52a-abd7-e593-bcec-7f25ecde8f8d%40neilvandyke.org.

Re: [racket-users] Clarify project policy on racket2 syntax

[Neil Van Dyke]

Atlas, I get the impression, from the impassioned discussion thus far, 
that a lot of the community really wants an s-expression syntax (and 
print form for data) to be not merely backwards-compatibile supported, 
*but to remain fully a "first-class citizen"*.


I suspect that the top-level requirements and the nature of community 
involvement will become more clear in a few weeks, after everyone 
returns from summer vacations, and has a chance to catch to catch their 
breath and discuss.


Racket has approx. a two-decade history of good stability and 
engineering, so I think we can have a little patience, while the various 
confusing new things -- the Conservancy, community relationship and 
process, Racket2, whatever happens now that the Chez backend is firming 
up -- all get figured out and get solid starts.



(Relevant aside: I want to mention that I'm also hoping to see Honu, in 
particular, promoted better in Racket.  Once I looked at the paper, the 
other day, I was surprised that it hadn't really been promoted already 
for practical use.  It's additional complexity beyond s-expressions, but 
the approach looks clever.  I'll be interested to see how people use it 
in practice.  That might start with a better Racket manual for Honu.  
And maybe one of the the textbooks ends up using Honu for a teaching 
language.  And maybe someone shows a DSL construction tutorial using 
Honu to do the parsing work.  That doesn't have to mean Honu bumps 
s-expression to "second-class citizen" status, such as in Racket manuals 
or ongoing development.  Nor does that have to mean that Honu becomes 
the form that might be displayed when data and syntax objects, such as 
when viewing the intermediate representation of Racket as a 
language-oriented programming platform or construction kit.)


--
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/6dbf1664-5154-2c9c-4b81-26739222ef42%40neilvandyke.org.

Re: [racket-users] tip for promoting racket on yc hacker news

[Neil Van Dyke]

This is a good writeup on HN: 
https://www.newyorker.com/news/letter-from-silicon-valley/the-lonely-work-of-moderating-hacker-news


--
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/4e0fc3fe-8db7-49ef-eb7a-26df02b71f5e%40neilvandyke.org.

Re: [racket-users] Re: Alternative UI toolkits

[Neil Van Dyke]

Stephen De Gabrielle wrote on 8/7/19 5:10 PM:

Mathematica uses QT!


There's a lot in Qt, just like there's a lot in GTK.  Occasionally, a 
noteworthy project goes to a lot of trouble to switch from one to the 
other (e.g., Wireshark).


Thankfully, Racket has meant I mostly don't have to pick GUI toolkits, 
and that (in theory) I could migrate an entire desktop suite of 
applications to a new toolkit backend, because Racket already has the 
seasoned cross-platform layer over multiple native toolkits.


https://github.com/servo/webrender/ 'experimental render backend for 
Servo, but it can also be used as such in a standalone application.'


Since you're looking at multiple Mozilla HTML-ish application/GUI 
toolkits, you might also consider WebKit (which originated in the Qt/KDE 
universe, and also spun off Safari and Chrome).  These all bring their 
own opportunities and burdens, but sometimes they're worthwhile.


https://doc.rust-lang.org/book/ch19-01-unsafe-rust.html#using-extern-functions-to-call-external-code 
- calling Rust functions from Racket and vice versa.


That might work, and could be just the thing for some purposes, but (for 
those on racket-users who don't already know) be judicious with FFI and 
same-process.  If you've never had the experience of debugging a crash 
in which you don't know whether it's in any of the native libraries 
(including unsafe Rust) you're pulling in, or a bug in Racket, or a 
strange interaction of one or more GCs, or a bug in your FFI/extension 
bindings, or a bug in how the Racket application code is using a 
somewhat-fragile interface... that's a much better learning experience 
to have with a hobby project, than in production.


In the past, I greatly improved both the stability and performance of a 
large Racket production system by rewriting some C parts in pure Racket 
(this can be faster), and isolating other C parts into separate Linux 
processes.


That said, sometimes you should just do FFI.  As an exercise, I made a 
character terminal library without FFI, and in hindsight, probably 
should've just done a little bit of FFI: 
https://www.neilvandyke.org/racket/charterm/


--
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/75c3acec-1963-272b-fb1c-0235aa9a3bb3%40neilvandyke.org.

Re: [racket-users] Re: Alternative UI toolkits

[Neil Van Dyke]

Since I mentioned the Qt GUI toolkit family (which you might also know 
as a foundation of KDE)...


* if anyone is looking at that for Racket for some reason, there's a new 
"technical vision" statement for the next major version:


https://blog.qt.io/blog/2019/08/07/technical-vision-qt-6/

I'm happy with Racket's current support for GTK2, GTK3, and other native 
toolkit backends, and so see no need for all the work to add a Qt 
backend, but it's nice to have backup plans in mind for unusual situations.


* Also, even if you have no interest in Qt right now, that blog post is 
a nice writeup on ongoing vision for an important set of software that's 
been evolving for a long time and is pretty popular.  So maybe worth a 
skim, for a feel of how they're thinking and communicating about that 
kind of thing.


--
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/528a6a04-9fbc-a64b-4bda-b2fce4d533fe%40neilvandyke.org.

Re: [racket-users] Re: gui widgets over canvas

[Neil Van Dyke]

Hendrik Boom wrote on 8/6/19 4:03 PM:

Be careful.  You might hit such limits, and your interfaces might behave in 
dangerous ways.


Thanks for the warning.  I've seen a lot of such limits in various GUI 
toolkits, and, when you have a cross-platform layer over it, you have to 
do a combination of both anticipating limits, and then testing on all 
the platforms to see if you missed anything.  That's in addition to 
testing for various non-limit quirks of the platform, which over time 
the cross-platform layer has gotten tweaked for, but you can still run 
into things that haven't already been exercised through the layer.


(Other ones most immediately in mind are any kind of large 
list/table/tree widget -- even if the layer offers some kind of 
model-view linking that looks like it can page in data from the model 
on-demand, the way the layer uses the underlying widget might just be to 
load the entire model into storage controlled by the native widget.  I'm 
also suspicious of letting every native toolkit do a large scrolling 
canvas on its own, and I expect some to have small limits there, and for 
it to also do things like buffering very large pixmaps for the entire 
coordinate system or bounding box, so I'd prefer it just gave me a 
viewport and drawing callbacks.  And, of course, perhaps most 
toolkits don't scale well to millions of widgets in a spreadsheet, even 
though there's no reason you couldn't make one that does scale, it was 
almost never a requirement.  We can guess what a lot of the things to 
test will be, and try to avoid them, but still have to test whatever we 
do write, on everything.)


--
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/454e15c6-4aa8-3abe-9803-a8bfd9ba1fd7%40neilvandyke.org.

Re: [racket-users] Re: gui widgets over canvas

[Neil Van Dyke]

Thank you, Alex.  I'll take another look at using `panel%` that way.  (I 
wasn't sure that would work well on all platforms, because its own 
implementation has special-cases for its stock subclasses, which 
conceivably might be necessary on some platforms.)


Regarding scrollbars, I might end up abusing the native ones, to look 
still native but make scrolling less jumpy on all platforms when there's 
a million rows.  We'll see how well it works without tweaking on various 
platforms in practice, and then what the priority is.


Regarding `pasteboard%`, that was the first promising-sounding thing, 
but I want native editing widgets if possible for this (`text-field% is 
just one example, there will also at least be some kind of 
select/combobox).  Also didn't want to pull in the Framework, if I 
didn't have to.


(BTW, I appreciate that cross-platform GUI toolkits that use the native 
look toolkits (as opposed to its own look, or emulating the 
native look) are always going to have some restrictions, and lots 
of subtleties in their implementation, so I'm not expecting this to be 
nearly as easy as targeting a single native toolkit.  I like that Racket 
went this route.)


--
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/5248cf91-49ab-bf4e-6cc6-123efb38fea4%40neilvandyke.org.

Re: [racket-users] Re: Alternative UI toolkits

[Neil Van Dyke]

XUL itself is deprecated/dead.  There might be an interesting (but 
niche) Racket opportunity with WebExtensions, and you might want to wait 
to see how they decide WASM fits into that, and what Racket's WASM story 
becomes.


Also, bit of gut-feel speculation... There's some odd noises/rumblings 
going on with browser extensions (and PR of same) in recent months, and 
a few I noticed in the last week.  Anyone contemplating a new project 
based on browser extensions should consider that the rules might be 
changing soon, more likely than in the past.  (Beyond Chrome 
anti-ad-blocking moves, which also was a gift to Mozilla when they 
needed it.  But possibly other restrictions, such as in what else 
extensions can do, and on who can effectively publish what extensions.  
And maybe an improved or new monetization option.)


--
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/9c08dff6-d504-87ac-f5dc-a1350389bd56%40neilvandyke.org.

[racket-users] gui widgets over canvas

[Neil Van Dyke]

For a million-rows spreadsheet GUI widget that's based on a canvas, and 
wants to overlay a single normal widget like a `text-field%` at a time, 
over the canvas, for cell value editing... what's the best way to get 
that overlay to happen in Racket `gui`?


One idea: in the implementation of `panel%`, looks like I can force it 
to be implemented as a canvas (`wx-vertical-canvas-panel%`).  If I could 
draw the spreadsheet viewport to that same canvas, as well as parent 
overlaid widgets to it, I suppose I could use panes to position and size 
the editing widget.  I don't know whether that would work at all, on all 
platforms, and in future Racket releases.


Or is there a better 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.
To view this discussion on the web visit 
https://groups.google.com/d/msgid/racket-users/ff0dc0e4-e387-5ab2-58c4-4a18d77c512b%40neilvandyke.org.

Re: [racket-users] Re: Alternative UI toolkits

[Neil Van Dyke]

Sorry, typo: I meant "HUD/AR" as in "head-up display and augmented 
reality" (and also VR).


--
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/62de5cce-0768-166d-920b-88b413efb8f0%40neilvandyke.org.

Re: [racket-users] Re: Alternative UI toolkits

[Neil Van Dyke]

Thank you, Roman.

For those who don't know, `gir` potentially lets people use many of the 
libraries behind the Gnome GUI desktop environment that's popular on 
GNU/Linux and other places.  It does FFI to the GObject object system 
that backs those libraries, and perhaps also uses the metadata now 
provided to making bindings easier.


The Racket cross-platform GUI API, such as is used in the implementation 
of DrRacket, already uses a subset of some of these libraries (from both 
GTK version 3 and 2 sets) on many platforms, *but* GObject bindings let 
you do a lot more than the cross-platform toolkit, on platforms that 
support it (though unfortunately you then run only on those platforms).


For related GObject/Gnome/GTK/etc. bindings work, the most active might 
be Guile (the GNU project's own Scheme dialect, which has some nice new 
work, if you haven't looked at it in a while), which has had a number of 
such attempts at GTK/etc. bindings, and a there's new work on 
GObject-based bindings: https://github.com/spk121/guile-gi


The other really popular GUI desktop toolkit family (other than 
HTML GUIs) is Qt.  This has always been the main competitor to 
GTK/Gnome, is even moreso now than it used to be, and is something I 
considered adding as a new backend for Racket's cross-platform toolkit, 
especially for handhelds.  Other than Qt, you might want to build a more 
lightweight toolkit, atop OpenGL ES and/or Vulkan, and make it friendly 
for handhelds, desktop/laptop, and HUD/HR (and preferably also hooked 
into Racket's cross-platform GUI API, but you might want to also provide 
a non-cross-platform API to 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/a9eb0d1a-4ef1-8d24-abce-ac73268bde4b%40neilvandyke.org.

Re: [racket-users] Re: Racket + Graphviz

[Neil Van Dyke]

Hadi, that looks great so far!

There are some adornments you can still add, such as to indicate which 
attributes are candidates for being keys (or are keys), but those can 
just be added to existing text strings.


One important thing still to do is labeling the relations.  You might do 
it with a name for each relation (which usually is read in one 
direction), and/or with with names for the respective role each entity 
plays in each relation.  One reason for this (just mentioning it for 
racket-users) is that, in practice, it's not-unusual to end up with 
relations for which the purpose is not obvious, and even multiple 
relations among the same pair of entities (and in the case of multiple 
relations, each expressing role cardinalities in your meta-model, which 
one is which).


Another reason for naming associations, which might be more semantics 
than you want to get into for your immediate purpose, is that there's 
richer semantics one might use in analysis, which might end up conflated 
in current implementation, *but* that can be useful to capture for 
documentation, and maybe also sometimes useful as a cognitive prompt 
while working through it.


For an old example, if you're modeling a system involving multiple 
companies and their employees, you might start with Company and Employee 
entities, and maybe label the many-to-many relation between them 
Employment.  But, when you go place a Salary attribute, you see it could 
be considered an attribute of the Employment named relationship between 
a Company and a Person (optional role names: Employer and Employee), and 
you realize that it's useful for other parts of your system to talk 
about a Person as distinct from being an Employee (e.g., for 
representing multiple employments of a person, and things about a person 
distinct from any employment). And maybe, in your analysis model, 
attributions of a relation is how it appears (if your ER meta-model 
supports that), which preserves the roles, even though, in the 
implementation, that ends up mapping to implementation the same as an 
entity does (to, e.g., a table or object class).


--
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/eb94edd2-4a8b-e5bf-967d-9a28dd53e323%40neilvandyke.org.

[racket-users] drracket notebook mode and ipython/jupyter (Was: DrRacket2?)

[Neil Van Dyke]

Prior racket-users discussion on a hypothetical DrRacket Notebook Mode 
and the existing IPython/Jupyter kernel include:


2018-12-20
https://groups.google.com/forum/#!topic/racket-users/MsAh2aBU5Sw

2019-06-26
https://groups.google.com/d/msg/racket-users/XQXYxtCM2-k/AbTTqMqlAgAJ

2019-07-24
https://groups.google.com/d/msg/racket-users/XQXYxtCM2-k/C97eRavaBQAJ

Someone with funding or a person-month of volunteer time should do 
DrRacket Notebook Mode, something like described in that first thread.  
It will be a good thing.  And then other people will be inspired to make 
more language support progress on the data science and blogging/sharing 
possibilities.


--
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/a547a3bd-5ccd-45b9-2db8-8c24495c114c%40neilvandyke.org.

Re: [racket-users] Symex: a DSL for symbolic expressions

[Neil Van Dyke]

Hendrik Boom wrote on 8/1/19 6:36 AM:

On Wed, Jul 31, 2019 at 06:40:05PM -0400, Neil Van Dyke wrote:

For structured editing related work in sexp, of course there's Emacs structural 
operations that have been in there forever (not well-known,



Here's where some of them are listed in the current manual:

https://www.gnu.org/software/emacs/manual/html_node/elisp/List-Motion.html#List-Motion

In addition to those movement ones: backward-kill-sexp, kill-sexp, 
mark-sexp, raise-sexp, transpose-sexps, indent-sexp, indent-pp-sexp.  
And others, such as for evaluation and macro expansion.


You can find some of them with the Emacs command:

    M-x apropos RET sexp RET

The manuals for Emacs and Emacs Lisp are also available through Emacs's 
ancient (but still surprisingly productive) Info hypertext system.  For 
example, you can pull up the Emacs Lisp manual, and press `i` for an 
index search with autocomplete, or `s` for a full-text search (followed 
by the comma key for paging through the search hits).  There are also 
one-key commands for going left/right/up/down through pages, navigating 
to subtopic table of contents entries, etc.


For approximating some of that for the Racket (PLT Scheme) manuals, when 
I made Quack, I used the Emacs frontend to the `w3m` text mode Web 
browser, and added a few Info-mode-like keybindings: 
https://www.neilvandyke.org/w3mnav/


Incidentally, people could also work through SICP in this Info format, 
on underpowered computers that couldn't run a Web browser at the time, 
or even on dumb terminals, thanks to Emacs: 
https://www.neilvandyke.org/sicp-texi/


I ate a little of my own underpowered computer dogfood (it wasn't just 
for developing nations and underserved domestic communities), since much 
of my early Scheme code was written on this little computer, on battery 
power, while sitting against a tree in a park in Harvard Square (tip: 
dim the CCFL display backlight, and angle for the LCD to passively catch 
ambient light), and there was no way I was going to let Firefox kill my 
battery: https://www.neilvandyke.org/linux-thinkpad-560e/


(I actually made my original Scheme embedded API documentation system 
generate that same TexInfo source format, which targeted both Info and 
TeX like the GNU manuals do, and spent quite a while on TeX typographic 
tweaking for article-like API PDFs for small Scheme packages, but 
eventually switched to Scribble as the native format, to work better for 
Racket.  Though, I never got Scribble as visually concise as TexInfo 
`@result{}` for tight code evaluation examples, nor as fast to navigate 
as Info mode.)


--
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/1d4be9fc-216c-1b92-5749-c8e7f5a31691%40neilvandyke.org.

Re: [racket-users] Re: Racket + Graphviz

[Neil Van Dyke]

Hadi Moshayedi wrote on 8/1/19 4:14 PM:
On Thu, Aug 1, 2019 at 12:23 PM Ryan Kramer > wrote:


This looks interesting! I have thought about trying to generate
Entity Relationship diagrams given a database schema, but assumed
that laying out the boxes would be a hard problem. Looks like
GraphViz might do a decent job at this. I'll try it out and let
you know how it goes.

Yesterday I learnt that also PlantUML can be used using stdin/stdout 
interface and it can generate SVG, which can be converted to Pict 
using rsvg. I was thinking spending some time on trying to have some 
kind of Racket library for that too. It might be a better tool for 
generating ER diagrams. See http://plantuml.com/ie-diagram


I tend to use UML's notation for "static object modeling" when doing 
what's essentially entity-relationship modeling.  (There's other UML 
models, but usually people just mean the main diagram, and often just to 
show only attributes and inheritance and nothing else.  Few people might 
do rigorous state modeling, protocol event traces, etc.)


Your DB schema is relational?  If you're willing to represent DB 
relational tables and columns as UML classes with attributes, the UML 
notation might be more compact and understandable than an ER one you'd 
use, but you have to decide how much of the DB semantics you want to 
represent, and how.  For example, if you want to talk about DB joins you 
use, you might just use only attribute annotations for candidate keys, 
*or* you might use much more visual UML associations that are in 
addition to the attributes.  (For target implementations *without* joins 
like that, you'd probably instead use association roles, without 
attributes at all, and indicate navigability directions of the 
associations.)


Regarding laying out the boxes, that particular UML notation might be 
modeled as a constraint satisfaction problem, but it's a tricky one.[1]  
For example, in practice, you might usually want your generalization 
associations to have a high priority for super being above sub, usually 
less so for aggregation assemblies, link attributes (if you have those) 
tending to come off a horizontal edge, etc.  Then you get into things 
like edge routing for reducing crossings and bends, while still spacing 
out your vertices, plus the various adornments on edges that complicate 
things.  And maybe you want stability of layout between changes to also 
be a factor... One of the several methodologists' camps that went into 
UML (and from which that particular UML notation largely came), Rumbaugh 
et al.'s OMT, developed an interactive diagramming tool that was more 
limited than real CASE systems, but did the best job of constraint-based 
interactive editing that I'd seen (but not enough constraints to do 
automatic layout): OMTool, from a GE lab.[2]


[1] For a similar visual language, my industry R group once hired a 
very smart PhD student in computational geometry graph drawing to tackle 
it, and they made some progress, but it still wasn't entirely a solved 
problem afterwards.


[2]  Racket aside: I actually used OMTool, until I no longer had access 
to it, and kludged up a simple but practical Java generator/updater for 
it, "https://www.neilvandyke.org/jomtool/;. You'll notice Jomtool was 
written in Emacs Lisp, rather than Java, even though I was an early Java 
expert and advocate, and working in Java.  When I went looking for a new 
platform for rapid R work, especially in PL and symbolic Web 
processing, I admitted that a Lisp was more productive than my beloved 
Java for many things, and I ended up choosing Scheme.  Even though 
Scheme didn't have basic OO features, and I'd been working very heavily 
in OO architecture/design/OOP/methodology, and had been invited to be on 
a UML committee -- it still looked like a win.  Scheme turned out to be 
a good choice for those R purposes, but industry is a much longer and 
more complicated story, and there are disruption opportunities close on 
the horizon.


--
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/f36020f9-acbd-d126-3013-ebe8eb2655af%40neilvandyke.org.

Re: [racket-users] [ANN] Racket implementation of magic language

[Neil Van Dyke]

Jonathan Simpson wrote on 7/31/19 9:54 PM:
#lang magic is my implementation of the mini language used by the Unix 
file command.


Nice.  In addition to the practical merits, and the craft, it's also an 
example of a useful legacy DSL we can point to (like lex, yacc, make), 
and which Racket now implements.


You might want to make API documentation for it in Scribble.  (Your 
racket-users post contains helpful information that's not currently with 
the code in GitHub.  Also, we're currently having trouble with 
racket-users Google Groups often inexplicably not showing up in Google 
searches, which is yet another reason to try to consolidate 
documentation with the code in a simple way.)


Besides API documentation helping others to use some code, as well as 
establishing an API of *what* as distinct from *how*... the 
documentation is also a well-deserved chance to show off your work in 
different way than the code itself, and with Scribble slickness. Or 
Markdown.


--
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/c8589e2e-8c91-7817-cb73-f10590f75acf%40neilvandyke.org.

Re: [racket-users] Symex: a DSL for symbolic expressions

[Neil Van Dyke]

Siddhartha Kasivajhula wrote on 7/29/19 3:41 PM:
generalization of modal user interfaces that has a "language-oriented 
programming" flavor.


Applying traditionally-sexp structural-based editing to non-sexp 
languages seems relevant to non-sexp Racket2 syntax (e.g., Honu), and 
other non-sexp languages.


And maybe these structured interactive editing models could be derived 
from the same specifications of syntax/language, such as used by Honu, 
or other new existing/new grammars and syntax-transformation DSLs.  Like 
syntax coloring could, as well.


For structured editing related work in sexp, of course there's Emacs 
structural operations that have been in there forever (not well-known, 
and at one point I tried to popularize them in Racket with a copy 
set of modern keybindings for some of them). Taylor Campbell seemed to 
push this forward quite a bit with paredit.el (which the semex writeup 
cites), and then there was various other work in Emacs.  There was also 
also some work on DrRacket (nee DrScheme): 
http://www.cs.brown.edu/research/plt/software/divascheme/


In addition to deriving structural editing from language descriptions, 
there's also opportunity for DSL/macros/learning additional 
language-sensitive structural transformations (I couldn't see whether 
symex.el tackles these).  I did some hard-coded ones in the early 
quack.el (named as a poor substitute for DrScheme), but didn't get to 
making a DSL for it (and it would be better to do it with Racket syntax 
objects than with Emacs).  Simple old examples from Scheme include 
toggling a `define` form between explicit `lambda`, swapping branches of 
an `if` while modifying the condition to preserve the logic, toggling 
between `if` and `cond`, `cond` and `case`.  More modern would be 
toggling between Racket `for`* forms and more traditional code, such as 
for the better abstraction for a current need.  All these are based on 
encoded rules about useful syntactic equivalences (though I suppose some 
could also be derived, and then prioritized in an interactive editor 
with reinforcement learning, though maybe merely hardcoded gets all the 
useful ones in practice).  There might still be a bit of research 
opportunity here, including not just interactive editing conveniences, 
but also some kinds of style advice/checking and automated style 
improvements.


(Let me know if anyone would like to collaborate towards publishable 
research on any of 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.
To view this discussion on the web visit 
https://groups.google.com/d/msgid/racket-users/aa75d97c-f9a8-d95e-4834-87e2a0d35b0a%40neilvandyke.org.

Re: [racket-users] Re: Racket2 possibilities

[Neil Van Dyke]

If anyone wants to collaborate on doing something novel related to 
visual programming, I've previously done industry R work on that, and 
am open to serious academic or commercial efforts.


Atlas Atlas wrote on 7/28/19 6:53 PM:
Found this interesting video on GopherCon 
https://www.youtube.com/watch?v=Ps3mBPcjySE 

Speaker raises questions about what a program code is and how it 
should look


--
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/941cc321-b948-8e5b-d6af-10695b3772ed%40neilvandyke.org.

Re: [racket-users] Racket2 on a ubiquitous platform [was the case, and a proposal, for elegant syntax in #lang racket2]

[Neil Van Dyke]

A lot of interesting ideas, stewart.  For now, I'll just highlight this 
one, and a few bulleted comments:


stewart mackenzie wrote on 7/25/19 3:03 PM:

If you want to Racket2 popular make it easy for users to get the programmer's 
responsive applications and programmers will come in droves. Drop Chez, 
reimplement the Racket interpreter in Rust and target it at WASM.



* I continue to trust Matthew Flatt, et al.'s judgment and direction on 
that, for the core group's goals (which I'm still fuzzy on). There've 
been signs of diligence throughout.



* You mentioned a conditional, and I think re-emphasized that we all 
need to have a really-super-clear shared understanding of Racket's 
goals, and how people's various needs fit into that:


https://www.mail-archive.com/racket-users@googlegroups.com/msg41757.html

https://www.mail-archive.com/racket-users@googlegroups.com/msg41799.html

I still don't know how "popular" fits into the goals, for example.


* Regarding WASM, I started mentioning it almost 2 years ago (I've done 
various kinds of Web development):


https://www.mail-archive.com/racket-users@googlegroups.com/msg35803.html

https://www.mail-archive.com/racket-users@googlegroups.com/msg36362.html

https://www.mail-archive.com/racket-users@googlegroups.com/msg41716.html

As I said in the last message, I think WASM would almost immediately be 
very valuable, but my initial gut feel is to not bet the farm on WASM 
alone.  It might simplify that question for me, if I had a 
really-super-clear understanding of Racket's current goals.



* I want to reiterate the importance of really-super-clear shared 
understanding of at least the top-level requirements.


I've been through industry requirements elicitation and rigorous 
requirements analysis before, and it's much more difficult than I 
would've thought, but also much more helpful than I would've thought.  
(And when it's painful, it can be because they're getting down to things 
you don't know, or getting into things some people don't want to admit 
or agree to.  For example, various team members are separately excited 
about 10 different possibilities and you have to choose 1-3, customer's 
actual needs and priorities are very different than what anyone wants to 
build or thinks they should build, you get into culling features that 
the product manager and executives have already been talking about, and 
various imperfect alignments between organization and individual goals, 
etc.)


That's not quite the situation with Racket, but I suspect the Racket 
community would still very benefit surprisingly well from merely trying 
to unambiguously articulate top-level requirements.


Racket has always been guided first by the goals of the core group, 
which is fine.  But as we, as a community, try to have more community 
involvement, I think we need a really-super-clear articulation and 
shared understanding of the top-level requirements.  Then we'll see how 
that focuses all the discussion for how those top-level requirements are 
accomplished.


--
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/414a661a-e350-bb55-bbc3-421f09edeb5b%40neilvandyke.org.

Re: [racket-users] on reducing barriers in the Racket community

[Neil Van Dyke]

Atlas, I will have to think more about your message, but I think you're 
right to suggest that FAANGs might be part of a problem.  For example, 
see yesterday's outreach email from a FAANG (quoted at end of this 
email), posted as an apparent diversity initiative, to students of a 
big-name CS department, inviting them to a "10-week workshop series", to 
prep for (IMHO: submit to, and game by playing to the metrics) the 
company's recruiting hazing process and supposed metrics.


(Such hazing processes were not a thing when I got my first software 
engineering internship, before FAANGs.  Perhaps coincidentally, half the 
engineers at my internship were women, and they were all highly-skilled 
and accomplished, doing impressive things, and had the same prestigious 
responsibilities and recognition as the men did (though executive, 
marketing, and field sales were very different stories, unfortunately).  
Later, in grad school, in a "gender issues in CS" interest group, I 
learned there were some problems other places.  Then I started to see 
various kinds of unwelcoming and barriers in academia, after I switched 
universities (regrettably, moving from a school known for being 
warm-fuzzy, to one known for egos and sharp elbows).  At the start of 
dotcoms, the only software company I recall being known for things like 
puzzle interviews was also the company that was later most cited by 
female interns for sexism among employees.  Just at that time, the 
dotcom gold rush started, and IPO-driven VCs and 20yo founders seemed to 
institute brogramming culture.  It seemed a Californian veneer variation 
on the infamous 1980s coked-up Wall Street culture, which needed 
aggressive worker drones for their earlier version of dotcoms' "move 
fast and break things" -- which has turned out to be a euphemism for 
grabbing money and power, by being the most irresponsible. Fortunately, 
individuals are better than the aggressive worker drones some companies 
have seemed to want, but individuals can only do so much about a 
top-down culture, so I'm criticizing the companies here, not the 
individuals trapped in it.)


In what I see as some degree of contrast, the Racket community overall 
(including at the top) seems to care genuinely about being thoughtfully 
constructive, we already have some diversity of perspectives (and some 
of the talk, including my own, sometimes sounds unfamiliar, and maybe 
wrong, to some others, perhaps *because* of that diversity), and I get 
the impression we want more diversity.  Collectively and individually, 
we still have many things to figure out, in how to welcome and support 
people, but we seem to have genuine and good intentions, and have made 
some progress already.  Still, I'm sure people can point to some 
problems that are obvious to them, but that others of us (including 
myself) didn't really notice or appreciate as much as we should.


Maybe Racket needs a better channel for talking about such things, and 
figuring out how to get good movement on them.  Maybe starting with a 
different email list, with some guidelines?



As possible "comic relief" (I try to have a sense of humor about 
upsetting things), here's yesterday's FAANG hazing outreach:



Want to boost your readiness for [Company] technical interviews?

This Fall, we're expanding our Above & Beyond Computer Science (ABCS) 
program to Atlanta, Boston, New York City, San Francisco, and 
Washington D.C. to build a diverse pipeline of future software engineers.


Participants collaborate with peers and [Company] software engineers 
in a 10-week workshop series to help increase their competitiveness 
for their coding interviews. You’ll gain in-depth and applied practice 
on common interview topics, learn interview best practices, and 
collect rigorous preparatory materials to unlock their full potential.


Hear from one of our past participants:

“The ABCS program gave me the extra nudge that I needed to strengthen 
my technical interview skills. The program was an absolute success and 
coincidentally, I will be starting at [Company] later this year as a 
Software Engineer Intern and I can directly say that it was a result 
from the lessons and valuable skills I learned at ABCS.” - Lauren L, 
ABCS Boston, 2018


Last fall, 76% of our program participants landed competitive summer 
internships or jobs in tech.


Are you ready to apply to a software engineering internship or 
full-time job and want to go above and beyond to set yourself up for 
success?


Apply for an ABCS program near you: [...]


--
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/cf733b40-1630-8e31-b03e-cdb692a09e9c%40neilvandyke.org.

Re: [racket-users] racket notebooks (Was: Language-Specific Plugins: Toolbar button functionality to call drracket:eval:expand-program)

[Neil Van Dyke]

HN is currently commenting on one attempt to increase sharing of 
notebook-oriented programming:


"Show HN: A tool to convert Jupyter notebooks to beautiful blogs"
https://news.ycombinator.com/item?id=20515880


Neil Van Dyke wrote on 6/26/19 2:31 AM:

Arie Schlesinger wrote on 6/26/19 1:55 AM:

Are there racket notebooks like jupyter or swish for prolog ?


There's work on an IPython/Jupyter kernel for Racket, but I'd also 
like to encourage someone to follow through on also adding a 
(separate) good notebook mode to DrRacket, as discussed in this thread 
from December: 
https://groups.google.com/forum/#!topic/racket-users/MsAh2aBU5Sw


A notebook mode is potentially a mostly-fun thing to implement, and 
opens up a new way of using Racket.  (Imagine, for example, using a 
notebook mode to explore what can be done with some language features 
or in some domain, and then rapidly cleaning it up and fleshing out 
the Markdown/Scribble bits, to turn it into a blog post and shareable 
notebook.  This isn't especially new, but the conveniences of a 
notebook mode could make a big difference in what you do, whether and 
how you share it, and whether people see and play with 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/5e3b70bd-566a-9ffb-a863-ea8d03fed34b%40neilvandyke.org.

Re: [racket-users] Message in the meantime?

[Neil Van Dyke]

I want to take a further step back, and say it would help for everyone 
to be really-super-clear on what's motivating Racket2, and what we 
really want to accomplish.  (I know a good effort has already been made, 
but I get the impression not everyone has the same idea yet, and I think 
even more is needed.)


Putting on my software engineering hat... If we ever did a really 
rigorous requirements analysis, inevitably percolating up to and refined 
at the top would be what are the root goals (not far below general 
happiness and truth) that everything else ultimately served.  If we know 
this, we can skip the (absolutely grueling) full analysis, and focus on 
the root goals.


It might turn out that things like "improve basic education and CS 
education", "advance PL research", "have greater impact on industry 
practice", and "career development"... are a few steps above "needs of 
the current developer community", and so, in a sense, the current 
community would only be a resource in service of those other, higher goals.


In that case, the current non-core developer community would certainly 
remain useful for promotion/buzz, impact validation including on grant 
proposals, sounding board and useful input (Aaron Turon mentioned this 
sometimes happened), and potentially labor. But the requirements 
decomposition would be clear that the relationship was *not* like city 
councilors representing the interests of the current constituents, *but* 
more like a volatile network of mutually-beneficial relationships among 
independent companies.


Were it a network of multually-beneficial relationships, then, given 
that this is Racket, I think we can safely soften it a bit with some of 
those independent interests being altruistic 
for-the-greater-good-of-humanity, but I doubt those are the community 
member's only interests.


Or maybe the needs of the current/legacy community are a top requirement 
(truly separate from how that would serve those other goals), and we 
should be clear on why, and what importance that has relative to the 
other top requirements, and then maybe ask why again, to be sure that 
makes sense.  (I emphasize the why, because, as a "community member" 
most of the time since PLT v103, I'd have difficulty arguing that my own 
interests should be a consideration to anyone else at this point.)


In any case, this might be a little time for everyone to reflect on 
their interests, and then we could try to be really-super-clear that we 
all have identical shared understanding about what's motivating Racket2.


--
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/beda5eda-7dab-1d4c-6a44-0c48a0dd9f67%40neilvandyke.org.

Re: [racket-users] Re: Racket2 possibilities

[Neil Van Dyke]

Dexter Lagan wrote on 7/23/19 3:32 AM:

Like the first HN comment said,


Currently 71 comments: https://news.ycombinator.com/item?id=20490423

FWIW, due to how the HN post was done, I don't know how representative 
the comments are of professional developers.  The link was posted around 
5pm California time last night, and got 92 points, but had fallen off 
the front page by early this morning Boston time.  (It could reappear 
this morning on the front page, and get more representative comments, 
iff it organically gets voted back up as Californians wake up.  But 
please no "brigade" voting, as that's against the rules, bad form, and 
the admins can tell.)


--
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/6099bb78-7b2e-2749-0ed2-d19585a2f28b%40neilvandyke.org.

Re: [racket-users] on reducing barriers in the Racket community

[Neil Van Dyke]

Matthew Butterick wrote on 7/21/19 4:46 PM:

But as was true for a lot of kids like me during that era, computers were a 
refuge. They never judged me. They rewarded my curiosity.


There's a complementary acceptance component to the microcomputer 
revolutions, which I think are relevant to Racket/tech community 
inclusiveness...


As people first started to get online, and find social-heavy topical 
interest circles, it disproportionately attracted people who were 
diverse in ways that weren't accepted as much in "real life".


For example, in some techie social circles, that we knew of, there were 
quite a lot of people who were eventually open online about being gay 
(when that wasn't OK where they lived), or being transgender (before 
most of society even knew that existed), and it was fine -- whether 
people were there for the topic/socializing alone, or because they felt 
drawn to an Island of Misfit Toys themselves.


Right now, most of the world is running software some of those people 
helped write, when society didn't accept them at the time. And one of 
them, a person who seemed to have a bit of anxiety, and perhaps was 
socializing online because of that, turned out to start a groundbreaking 
technology most of the world is now using.  Another one, who was a very 
nerdy girl who sought out other nerds, has since become a celebrated 
entrepreneur you've probably heard of.  And another woman, who was a 
serious math nerd, who is currently giving tech industry conference 
talks on big things.  And people all over the world, including at least 
one who later turned out to be nobility in their original country, but 
was somewhat restricted due to being female.  (Younger people with early 
online access were often children of university employees or computer 
industry people, or of wealthy classes who could go all-out on the 
child's home computer, mixed in with adult computer nerds.)  And one 
child actor would occasionally drop by one group, as a typical nerdy 
computer kid in real life, before most people could Tweet at 
celebrities' PR personae.  Fortunately, for parochial me, everyone spoke 
English.


There was also not yet things like Facebook presences (perpetuating 
primary/high school looks/popularity contests well into adulthood), so 
we often didn't even know what people looked like, and just took people 
on the merits of what they said.  Which resulted in some funny 
revelations, like the person you visualized like another stereotypical 
computer nerd, who turned out to be very conventionally attractive and 
charismatic (and who, of course, became an executive at a prominent 
dotcom).  Or the exceptionally kind and thoughtful person, who it turned 
out looked like what one might've thought (with one's real-world 
prejudices and stereotypes) was some scruffy metalhead.  (Which makes me 
think contemporary social media would be healthier and more beneficial, 
if people didn't post photos of themselves, compete for "influencer" 
funding, etc.)


Today, now that I'm in my 40s, it turns out that half of the American 
techies I socialize with frequently identify as some flavor of 
conservative -- which I would've found alarming years ago (I identify as 
very liberal/progressive, in the American sense).  One, for example, is 
very smart and thoughtful, seems like a great family person, and seems 
implicitly totally comfortable with gay/trans/whatever, but will 
frequently rant about what he sees as progressive grandstanding in the 
news.  I still don't agree with him on a lot of what's a problem and 
needs to be said in society right now, and what doesn't, but it turns 
out that conservatives overall are not so bad.


In pre-"social media" online, we sometimes made mistakes (including 
inadvertently being very unwelcoming in some ways, including by myself 
sometimes, I'm still embarrassed to recall), and of course there are 
always human conflicts and dramas, but we learned a lot about what 
communities can be, and that a lot of dumb real-world prejudices outside 
our community exist, and don't have to be 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.
To view this discussion on the web visit 
https://groups.google.com/d/msgid/racket-users/3c08818f-8177-27a8-54d5-3cdab42ff2ab%40neilvandyke.org.

Re: Backing up [was: Re: [racket-users] The case, and a proposal, for elegant syntax in #lang racket2]

[Neil Van Dyke]

Brian Adkins wrote on 7/22/19 1:28 PM:
Being unfamiliar with some of Racket's unique benefits, I initially 
felt it was simply the best Scheme I could choose for professional 
development.


Same here.  (Long-timers have heard my story too many times... After I 
picked Scheme for my new super-productive R language (I'd mostly been 
using Java for research, and a couple urgent research prototypes in 
Emacs Lisp for bizarre reasons, after using mainly C and C++ 
professionally), I started writing missing libraries (`html-parsing` 
includes my first Scheme code, and it shows).  I originally wrote 
portable Scheme, and tested it on *many* Schemes, but later decided I 
couldn't turn down the advantages of Racket (nee PLT Scheme), and so 
moved to it primarily.)


I still keep certain other Schemes in mind, for their particular 
strengths, and who knows when someone will come up with another one with 
a from-scratch implementation (e.g., targeting GPU/TPU, or 
groundbreaking scalability in some regard).  And also seeing how RnRS 
develops, though sadly I don't currently have time/funding to contribute 
directly to it myself.)


Being 8 months into a large project in Racket, and seeing some of 
Racket's unique benefits more clearly now, I already know there are no 
other lisps that could currently lure me away,


Racket is my overall favorite Lisp, too (maybe someday Racket2 will 
be).  I also have to acknowledge fondness of the Scheme foundation, the 
legendary greatness of Common Lisp, the innovations of Clojure, etc.  
Lisp is a big community, all with our own charming accents and mixes, 
and we don't talk as often as we should.


how someone who is primarily interested in using #lang racket should 
feel about continuing with #lang racket


Perhaps it will also continue to blossom, during the Racket2 linguistic 
Renaissance.  (For example, there are a few quality-of-life extensions 
one might propose to `#lang racket`, to little opposition, when everyone 
is focused on the new thing.)


--
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/42718b82-14f9-df3e-7d5c-5b18a73870b2%40neilvandyke.org.

Re: [racket-users] #lang something // infix, optionally indentation-sensitive experimental Racket syntax

[Neil Van Dyke]

The shell demo is great.  I can't look closely at `#lang something` 
quite yet, and I hope someone will include it in a list of the most 
interesting prior work for everyone interested in new syntax to look at.


--
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/dfc442cb-a7e3-9d86-2016-f72a51b58d18%40neilvandyke.org.

Re: [racket-users] Re: Racket2 possibilities

[Neil Van Dyke]

Maria Gabriela Guimarães wrote on 7/22/19 10:52 AM:
> I experimented with various scheme in browser intrepred via 
JavaScript and compiled to wasm both are not good enough.


Insufficient implementations I suppose, or wasm misses features 
important for a Scheme ...


What Maria said.  WASM (not JS) now seems the place for us to focus, for 
performance.  It's a little early for Schemes in WASM, and I don't know 
whether the best WASM methods for Schemes/Racket have yet been 
attempted, and if they'd have all the support in WASM they might want.


Once WASM is all ready, JS presumably will remain in the standards and 
in some use, but might actually become unpopular.  The browser 
developers have their own favored non-JS languages, and also heavily 
influence Web standards, so they might eventually make it so that JS can 
be all but eliminated.  And then, given that technical possibility, 
there's Web development culture: a hottest framework can become shunned 
within a year or two (and there's also rampant age discrimination, so 
many industry-savvy people truncate their older experience), so, 
half-seriously, I wouldn't be too surprised if JS becomes uncool to even 
admit knowing.


i don't know whether someone has yet dug into making a really performant 
WASM backend for Racket, and I'd guess people might want to wait for any 
interfaces/models from the Chez backend work to be about finalized first.


In the meantime, hopefully someone who needs the same WASM features such 
backend for Racket will want, has eaten or will eat the beetle grubs, in 
time: 
https://www.mail-archive.com/racket-users@googlegroups.com/msg36362.html


A little earlier context on WASM for Racket: 
https://www.mail-archive.com/racket-users@googlegroups.com/msg35803.html


There are pros about WASM, Web standards, influences, etc., and I 
suggest we want to keep cross-platform (not just Web browser, nor 
primarily Web browser) focus, for long-term reasons.  But it would be 
immediately very useful for many of us, if/when Racket gets a good WASM 
backend.  And, given the possible disruption of JS that I speculate 
about above, maybe that will also be an opportunity to bring Racket 
goodness to a lot more people.


--
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/e573db75-573e-f99a-d191-df1e6a944df8%40neilvandyke.org.

Re: [racket-users] web develpment

[Neil Van Dyke]

Job H wrote on 7/21/19 1:46 PM:

hello friends,

how do you generate the frontend of a website with Racket?


There are many ways.  You might want to start with a tutorial on one way 
-- "https://docs.racket-lang.org/continue/index.html; -- and then decide 
what you like and don't like about that, and then go from there.


Quick comments on some of my Web frontend/fullstack work in Racket...

I have some complicated Racket Web projects in production that, for 
historical reasons, use SCGI 
("https://www.neilvandyke.org/racket/scgi/;), and they generate HTML of 
various kinds (including a full HTML5 Offline app that pushes some 
limits) using something similar to 
"https://www.neilvandyke.org/racket/html-writing/; as well as generating 
JS, using handwritten CSS and JS, and using some off-the-shelf JS 
toolkits, and then uses JSON-based and other kinds of Web services 
implemented in Racket for when the app is online.


That HTML of that HTML5 Offline app is actually generated and updated 
(and cached in the usual HTML5 Offline way) automatically, and can 
change dramatically, during running of the server, based on some changes 
in "meta" schema (for a typically large and complicated data model) that 
can change dynamically.  (Which is not something that many frameworks 
can handle, but it was doable in Racket, because we understand and 
control the Web stack, and can make it do what we want, and apparently 
with a dramatically smaller amount of human resources than such a 
product would normally take.)  Also, certain handheld companies that 
like controlling app stores seemed to have mixed feelings about how well 
they want W3C standards for more Web-ish apps to work, but, with the 
power of Racket and way too much JS wrangling and polyfilling, we made 
it work. :)


On the side, I have an unreleased Web site software in Racket, for 
incrementally publishing a series of topical book chapters as more like 
blog posts, with a kind of table of contents navigation in addition to 
the temporal one.  It uses a bit of an inline DSL that translates to 
SXML for `html-writing`.  It also uses the ancient 
"https://www.neilvandyke.org/racket/uri-old/; (because I wanted 
anti-resolve for the framework, and didn't want to get distracted by 
rethiking the URI library like I really want to).  The HTML and CSS are 
designed carefully, to work on both desktop and handheld, for reading 
long-ish form text, and no off-the-shelf frameworks that time.


I've also used the `html-template` package for small static HTML 
generation tasks, though the intention was to use it for just-in-time 
HTML serving, and to have site-specific structural/semantics macros 
layered on it (at the cost of losing some of the dynamic flexibility of 
the `html-writing` approach): 
https://www.neilvandyke.org/racket/html-template/


Of course these can work with most off-the-shelf slick frontend 
frameworks, as well, with Racket code generating some of the input to 
those frameworks, or simply doing Webservice backend.


There are a lot of other valid ways to do Web frontends in Racket, and 
I'll let the people with experience in those talk about them.


--
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/f13dbb2d-3f1e-9d86-8fe0-578dc01a1eba%40neilvandyke.org.

[racket-users] dogfood a simple structured discussion forum in racket

[Neil Van Dyke]

If someone wants to do a useful and doable Web application in Racket...

You could make threaded discussion Web forum (or email) software.

(Implementation suggestions... Use Racket `db` interface, and deploy in 
PostgreSQL by default.  Consider storing each threaded comment in its 
own row (with IDs for things like parent comment), and keeping a cache 
representation of each threaded topic as a blob in a separate 
table/memory/file, so save you from some nasty querying every time you 
want to show someone the topic.  The cache for each topic can be 
s-expression/objects (which lets you someday apply user-specific 
personalization on the server before sending), HTML that's later pasted 
into a page (traditional), or (less-traditional-Web-friendly, but 
more-Webservice-friendly) JSON that's then turned into DOM/HTML by JS on 
the client.  You might have multiple caches per topic, such as for 
different sorting criteria, if that's a thing.)


After the basic threaded Web forum is done, you can make an email 
gateway/notifications for it, and/or RSS/Atom, to keep people engaged 
rather than them having to keep monitoring and going to a Web site.


There's also a dogfooding aspect.  A basic threaded Web forum should be 
able to be doable enough in Racket to be suitable for a book example 
project, and maybe a tutorial.


An alternative to the above would be to reverse the priorities, and the 
order in which you build it: make a discussion email server that mirrors 
to a Web archive/reader (and maybe the Web archive permits posting 
comments).


Bonus: Racketeers will get warm-fuzzies from using something homegrown 
in Racket (compared to feverish indigestion, from having to use certain 
other things).


--
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/6f364c1b-c153-3d53-f092-c09f1b1fe574%40neilvandyke.org.

Re: [racket-users] Racket2 possibilities

[Neil Van Dyke]

Matthew Flatt wrote on 7/20/19 2:49 PM:

We need concrete examples to discuss the possibility of changing syntax, 
potential roadmaps to see whether there's anywhere we want to go, and so on.


Procedural suggestions people might want to do:

* There's a lot of prior work, and it might really help discussion if we 
all have a shared baseline awareness of it.  Does someone have a 
comprehensive list of links (or want to assemble such a list) of the 
noteworthy attempts at non-paren syntax in Lisps?  (Offhand, but I know 
there's more: Honu, Shriram's work, the SRFI one, Python (which Norvig 
called a Lisp), Dylan's change, M-expressions, and some of the countless 
others, especially in CL.)  Also, maybe there's also some separate work 
in good syntax transformers for non-sexp that we should all know about 
at this point?


* With that shared baseline, would people like to highlight on 
"racket-users" promising ideas from that prior work, as well as post 
their own ideas (informed by prior work)?


* In group creative brainstorming, there's a procedural thing that's 
sometimes really helpful.  Basically, there's a phase/mode in which the 
top goal is to elicit ideas, and no critical commentary is permitted.  I 
don't presume to suggest any rules, and probably shouldn't be a hard 
rule in this case, but maybe many people will just tend to lean towards 
that, organically, initially.  Then, a little later, get more into 
critiquing, and see what new ideas/insights that then generates.  (Where 
this idea comes from, there's also a bunch of other modes and roles, and 
ways to be aware of and explicitly signal what kind of contribution 
you're making, but, to start with, I just wanted to toss out this one 
very simple idea.)


--
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/3dd5f0ea-5a65-5cd5-258d-f5c466bba2a7%40neilvandyke.org.

Re: [racket-users] Re: Gui editable grid/table

[Neil Van Dyke]

FWIW, I *might* very soon be making such an editable table/spreadsheet 
widget that scales to large data and supports various types, and in a 
cross-platform way.  (Without hitting various limits of some platform 
native widgets as used by Racket's GUI layer.  I recently looked at a 
few related packages for Racket, and some of the core glue code backing 
them, and unfortunately none could practically be modified to do what 
was needed in this case.) This work for large data might also turn out 
featureful for small data.  If this goes forward, I can at least post 
about what I learned, and perhaps those who'd be funding it will decide 
to open source it as a widget.


What I'm currently thinking builds on some earlier comments 
("https://lists.racket-lang.org/users/archive/2014-July/063303.html;), 
and I first have to feasibility check that some of the current GUI 
widgets behave like I suspect they do, on all current platforms. (If so, 
then we'll probably either also be good on hypothetical future 
iOS/Android/browser-based/etc. backends, and/or have the human resources 
at that time to make them work in core Racket.)


Of course, everyone should be encouraged to play with ideas like this on 
their own, for our own different 
requirements/priorities/curiosity/learning.  And always consider 
packaging up some of the artifacts of such work, as open source reusable 
components/libraries.

https://pkgs.racket-lang.org/
https://docs.racket-lang.org/pkg/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.
To view this discussion on the web visit 
https://groups.google.com/d/msgid/racket-users/415ab1b9-c915-7500-bbd4-34566edd530e%40neilvandyke.org.

Re: [racket-users] (ninth RacketCon) videos

[Neil Van Dyke]

Just to be clear, YouTube is clearly a very pragmatic way to make the 
RacketCon videos most accessible to people, and I'm very glad it's done.


Many people will stream the videos through YouTube, and (thanks to 
"youtube-dl.org") it's currently also an easy way to distribute the data 
to various offline copies people make.


Those offline copies might be for watching on trains and airplanes, for 
being accessible to people who don't normally have high-speed Internet 
access, for archiving in advance of the day that the dotcom alters the 
agreement, for finding on-principle ways to view without n different 
kinds of corporate spying and control and shoddiness going on[*], and... 
for indoctrinating captive houseguests in the teachings of Racketism, 
when they discover the TV can't screencast or play anything else 
(muahahaha).



[*] Seriously, CS people should learn about the current extent and 
impact of this (unless you are actively studying it, it's almost 
certainly much worse than you think), and take an on-principle stand 
against it, while we still can.  Understanding it should be part of 
basic education about technology, and there should be a more 
detailed technical treatment for preparing STEM students for industry.



wrote on 7/20/19 2:34 AM:

On Jul 20, 2019, at 01:37, Neil Van Dyke  wrote:

(My living room airgapped Blu-ray player delights houseguests, with a curated 
collection of fine videos on Racket and other CS topics.)

We get the message, Neil—we’ll steer clear of your lawn.



--
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/d54cb7da-2503-dd21-d32a-a1a1667ddba9%40neilvandyke.org.

Re: [racket-users] (ninth RacketCon) videos

[Neil Van Dyke]

If you want to youtube-dl the videos, this script might work: 
https://www.neilvandyke.org/racket/download-racketcon-2019-videos.sh


(My living room airgapped Blu-ray player delights houseguests, with a 
curated collection of fine videos on Racket and other CS topics.)


--
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/86bb57bb-1ab7-a55d-3efa-6c28a3daf702%40neilvandyke.org.

Re: [racket-users] Building "#lang dungeon"

[Neil Van Dyke]

If you want to solve problems like how to handle user conceptual models 
of permissions, consider putting "UX" aside for a moment.


UX gets confused by conflicts of interest, which the earlier disciplines 
of HCI and human factors engineering did not much have.


HCI comes from a human factors tradition of goal alignment with the 
human -- everyone wanting the user to be more effective at their tasks 
(whether it's operating a Macintosh, or a fighter jet).


UX is influenced more by the traditions of graphic design (especially 
for marketing brochures and the like), and in practice is usually 
burdened by motivations to manipulate the user to serve the interests of 
someone other than the user, even aggressively against the interests of 
the user.


Consider the GUI design for a smartphone/tablet -- do you want its 
visual cues, notifications, and other affordances to be for effective 
use of the device (HCI), or do you want to combat users' ability to 
perceptually filter-out ads, use notifications to aggressively keep the 
user engaged with addictive low-value "content", us more-blatant "dark 
patterns" to discourage users from selecting options that are likely the 
user's intent and in user's best interest, while looking slick (UX).


So, as an engineer/scientist/designer/educator of goodwill, consider the 
exercise of trying to think like an HCI person, and being suspicious of 
anything labeled UX.


--
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/cd9c307d-96b7-2eb8-5cd7-3d10b75f7e0a%40neilvandyke.org.
For more options, visit https://groups.google.com/d/optout.

Re: [racket-users] Re: The case, and a proposal, for elegant syntax in #lang racket2

[Neil Van Dyke]

Wesley Kerfoot wrote on 7/15/19 2:28 PM:

Has anyone considered http://shriram.github.io/p4p/ as an alternative?


This might represent Shriram's current thinking (and is what I was 
alluding to before): https://www.pyret.org/


I'll wait for the official community process to commence, before I get 
deep in discussion.


--
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/173ee913-ebb9-6f48-f758-d58f60938dea%40neilvandyke.org.
For more options, visit https://groups.google.com/d/optout.

Re: [racket-users] The case, and a proposal, for elegant syntax in #lang racket2

[Neil Van Dyke]

While we're all still figuring out how to best welcome and support 
everyone in CS-ish things, maybe it should be mentioned that Racketeers 
have some awareness and appreciation of familiar concerns, including 
from a research perspective (starting at least 15 years ago):


High school teachers who implement HTDP report similar success stories 
as colleges but in a less measurable manner. Still, the HTDP 
curriculum has had an interesting measurable effect concerning female 
students. Several instructors reported that female students like the 
HtDP curriculum exceptionally well. In a controlled experiment, an 
HTDP-trained instructor taught a conventional AP curriculum and the 
Scheme curriculum to the same three classes of students. Together the 
three classes consisted of over 70 students. While all students 
preferred our approach to programming, the preference among females 
was a stunning factor of four. An independent evaluator is now 
investigating this aspect of the project in more depth.
  -- Matthias Felleisen, Robert Bruce Findler, Matthew Flatt, Shriram 
Krishnamurthi, ``The Structure and Interpretation of the Computer 
Science Curriculum,'' Journal of Functional Programming, 2004. 
http://www.ccis.neu.edu/racket/pubs/jfp2004-fffk.pdf


--
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/518ef92e-045d-b152-5c92-5fc79268213e%40neilvandyke.org.
For more options, visit https://groups.google.com/d/optout.

Re: [racket-users] Re: Racket2 and syntax

[Neil Van Dyke]

I look forward to the syntax discussion, within whatever process is 
determined.


(BTW, I've said similar to what Gabriel do, as recently as last 
week [1], but I'm open to rethinking syntax.  Especially if it might 
mean we can entice Shriram to resume working more directly on Racket. :)


[1] https://news.ycombinator.com/item?id=20376377

--
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/09ee9ca5-5ff8-ac21-5849-69f94652c5b0%40neilvandyke.org.
For more options, visit https://groups.google.com/d/optout.

[racket-users] Skolelinux / Debian Edu & Racket

[Neil Van Dyke]

It looks like Skolelinux (aka Debian Edu) is used in hundreds of 
schools.  Has anyone looked into making sure it includes a good Racket 
version, in a turn-key way?


https://en.wikipedia.org/wiki/Skolelinux

I haven't used Skolelinux, but I can say that Debian was an early 
innovator in GNU/Linux distributions (e.g., network package system, 
multiple release channels for different stability preferences), has most 
everything packaged for it, is a basis for some other distros (including 
Ubuntu), and does unusually good watchdogging about various openness / 
libre principles.  For these reasons, I almost always use Debian Stable 
on my personal workstations and servers, even though some other distros 
also have some appealing other merits.


Below is a new Skolelinux press release, corresponding to the new Debian 
Stable release.


8

Re: [racket-users] resources on PL design

[Neil Van Dyke]

That entire famous Smalltalk issue of Byte magazine is now online, as 
good-quality scans, so you can read all the articles, and juxtaposed 
with ads of a magazine of the time:


https://archive.org/details/byte-magazine-1981-08

This was before my time, and, when I was reading this issue recently, I 
was struck by the effort that PARC made to reach out to mainstream 
industry practitioners and enthusiasts.


This was shortly before the home microcomputer explosion, when everyone 
ended up getting BASIC instead of Smalltalk.  (Though you could see a 
lot of interest in education, even with some of the nice BASIC books 
some vendors bundled with each computer, but not all the various PARC 
goodness.)


We did get the Macintosh a few years later, though it was out of the 
budgets of many people, and it didn't adopt a lot of the PARC thinking.


--
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/e9f64383-a795-9ead-fdf9-42e2c53e74db%40neilvandyke.org.
For more options, visit https://groups.google.com/d/optout.

Re: [racket-users] Re: resources on PL design

[Neil Van Dyke]

(This is a resend.)

Lots of earlier HOPL papers are experience writeups relevant to the 
question of PL design.  (For example, Alan Kay did a great history of 
Smalltalk, which talks about more than just the language design itself, 
and the language design was influenced by the other things.)


Separate from what's in HOPL, there are other related writeups floating 
around.  Most recently, I saw Kent Pitman did an interesting one on 
Common Lisp standardization (you'd also want look at whatever Guy Steele 
says about that, John McCarthy's HOPL on Lisp in general, and various 
other Lisp people's reports): 
http://www.nhplace.com/kent/Papers/cl-untold-story.html


Closer to home, there's Scheme.  I don't know all that's currently 
written up about Scheme history (and it's ongoing, including with RnRS 
and various implementations), but most of the players are still around, 
and they should probably be encouraged to write if they haven't 
already.  Olin Shivers wrote an account of T: 
http://www.paulgraham.com/thist.html


Then there's various papers and writeups on other Lisps (Clojure, Arc, 
Dylan, more researchy), which might be interesting in what they chose to 
change (not just added features), and why.


Separate from PL histories, and various models of computation, I think 
we start to get into human issues like linguistics and aesthetics, and I 
don't think that's well-understood in PL, nor does it seem to be the 
same for everyone.  (For example, simply from looking at how people use 
Racket syntax, put roughly, it looks like some people seem to use visual 
while others seem purely verbal or mathematical; what happens when 
someone from one of those categories tries to design an intuitive or 
convenient language for everyone, but everyone isn't processing the 
language the same 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.
To view this discussion on the web visit 
https://groups.google.com/d/msgid/racket-users/c56674e0-d5a7-c128-383c-1f88531d635a%40neilvandyke.org.
For more options, visit https://groups.google.com/d/optout.

Re: [racket-users] Re: resources on PL design

[Neil Van Dyke]

Lots of earlier HOPL papers are experience writeups relevant to the 
question of PL design.  (For example, Alan Kay did a great history of 
Smalltalk, which talks about more than just the language design itself, 
and the language design was influenced by the other things.)


Separate from what's in HOPL, there are other related writeups floating 
around.  Most recently, I saw Kent Pitman did an interesting one on 
Common Lisp standardization (you'd also want look at whatever Guy Steele 
says about that, John McCarthy's HOPL on Lisp in general, and various 
other Lisp people's reports): 
http://www.nhplace.com/kent/Papers/cl-untold-story.html


Closer to home, there's Scheme.  I don't know all that's currently 
written up about Scheme history (and it's ongoing, including with RnRS 
and various implementations), but most of the players are still around, 
and they should probably be encouraged to write if they haven't 
already.  Olin Shivers wrote an account of T: 
http://www.paulgraham.com/thist.html


Then there's various papers and writeups on other Lisps (Clojure, Arc, 
Dylan, more researchy), which might be interesting in what they chose to 
change (not just added features), and why.


Separate from PL histories, and various models of computation, I think 
we start to get into human issues like linguistics and aesthetics, and I 
don't think that's well-understood in PL, nor does it seem to be the 
same for everyone.  (For example, simply from looking at how people use 
Racket syntax, put roughly, it looks like some people seem to use visual 
while others seem purely verbal or mathematical; what happens when 
someone from one of those categories tries to design an intuitive or 
convenient language for everyone, but everyone isn't processing the 
language the same 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.
To view this discussion on the web visit 
https://groups.google.com/d/msgid/racket-users/8cab8e8a-593e-a7d2-fa56-ef9b163503c5%40neilvandyke.org.
For more options, visit https://groups.google.com/d/optout.

Re: [racket-users] Racket SIGSEGV during FFI call

[Neil Van Dyke]

If FFI for this particular library gets to be a headache, a backup 
option might be to separate the Linux processes: make a small C program 
that links in libhackrf, and provides some kind of channel (e.g., Unix 
domain socket) for a separate Racket process to talk with it.  Over the 
channel, you can use s-expressions, Unix-ish line protocol, protobufs, 
or something else.  You'll have to check whether the communication 
overhead of this is viable, but maybe it helps, in the balance, if 
Racket is on its own core, and GC is not potentially interfering with a 
time-sensitive thread of libhackrf.


FWIW, separate from the FFI difficulty, consider how much trust you have 
in the perfection of all the additional memory-unsafe C code you'd be 
pulling in via FFI, and how much you'd want to try to crash/corruption 
of that (C, pthreads, separate VM, GC, large amounts of unfamiliar 
complicated code...).  That could be great educational experience, 
especially in a hobby project, but probably not something you want to 
risk in production if you don't have to.


--
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/9a019c92-1db2-aa4d-9d3c-8735fbad2355%40neilvandyke.org.
For more options, visit https://groups.google.com/d/optout.

[racket-users] racket notebooks (Was: Language-Specific Plugins: Toolbar button functionality to call drracket:eval:expand-program)

[Neil Van Dyke]

Arie Schlesinger wrote on 6/26/19 1:55 AM:

Are there racket notebooks like jupyter or swish for prolog ?


There's work on an IPython/Jupyter kernel for Racket, but I'd also like 
to encourage someone to follow through on also adding a (separate) good 
notebook mode to DrRacket, as discussed in this thread from December: 
https://groups.google.com/forum/#!topic/racket-users/MsAh2aBU5Sw


A notebook mode is potentially a mostly-fun thing to implement, and 
opens up a new way of using Racket.  (Imagine, for example, using a 
notebook mode to explore what can be done with some language features or 
in some domain, and then rapidly cleaning it up and fleshing out the 
Markdown/Scribble bits, to turn it into a blog post and shareable 
notebook.  This isn't especially new, but the conveniences of a notebook 
mode could make a big difference in what you do, whether and how you 
share it, and whether people see and play with 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/5434f24b-ca6a-316d-cd36-81e89b72ae7a%40neilvandyke.org.
For more options, visit https://groups.google.com/d/optout.

Re: [racket-users] how to uninstall Racket 5.3.6?

[Neil Van Dyke]

Quick notes on both installing a new version, and then cleaning up the 
old one...


INSTALLING NEW VERSIONS

Assuming you're not just using a Debian package, and want a 
non-Debian-package install (such as for more rapidly picking up new 
Racket versions, having multiple versions installed at once)...


One way to build and install the latest Racket is with 
"https://www.neilvandyke.org/racket/install-racket-versioned.sh;, which 
will install to a directory like "/usr/local/racket-7.3/". Then you'll 
want to put "/usr/local/racket-7.3/" ahead of "/usr/local/" in your 
shell's executable search path (such as by editing your "~/.bashrc" 
file, if that's where that's set).


You don't have to use that script -- the main thing is that you 
self-contain a Racket install (or run-in-place source tree) in its own 
directory tree, somewhere.  Preferably name that directory tree 
descriptively, for what release version, build variant, or Git 
branch/changes, like "racket-7.3", "racket-git-master", 
"racket-branch-colon-keywords", etc.


CLEANING UP THE OLD MESS

"/usr/local" sounds like it wasn't from a Debian package.  Which still 
leaves a few possibilities for how it was unfortunately installed to 
"/usr/local".


I don't know offhand what uninstall was provided for 5.3.6 (though you 
could download a source tree, and see if they have an uninstall script 
or a `make uninstall` target).  Even if such a script/target exists, 
there's a small chance it might not work for how those files got into 
"/usr/local/".


If you have to *manually* clean up remnants of old Racket in 
"/usr/local/", IIRC, there's more than one possible directory tree 
layout it might be using, so it's harder to say exactly what filenames 
remove, but something like this...


1. Make a directory like "/usr/local/racket-deleted" into which you'll 
move the old files.


2. Look in your new 7.3 install tree for the kinds of file names you'll 
want to move from the old "bin" and "lib" into "racket-deleted", and 
move them.  Be conservative: if you're not sure whether a file is for 
Racket, leave it where it is, or you might break some other program, or 
even not be able to boot your computer and log in.


3. Then move files/directories from "include", "share", and "etc" (which 
might all just be subdirectories named "racket").


4. Optionally rename "racket-deleted" to be more descriptive, like 
"racket-5.3.6-deleted-manually-20190621".


5. "chmod 0 racket-deleted" or whatever you renamed it to.

6. Confirm that you can still reboot your computer and log in. Rebooting 
should also cause the 7.3 path you previously added to the shell 
executable search path environment variable to take effect everywhere, 
even for your login process and desktop processes, so those might work 
better.


Good luck.

--
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/7563a39b-38e3-42c4-b1f0-46843390ae20%40neilvandyke.org.
For more options, visit https://groups.google.com/d/optout.

[racket-users] doing a "show hn" of your racket project

[Neil Van Dyke]

If you make something in Racket, such as a microstartup Web site, or 
something that HN readers can otherwise use, you can publicize it with a 
"Show HN" post, and possibly also promote Racket as a side effect.


For example, here's one making the front page of HN right now:

"Show HN: A star map creation tool with Common Lisp (thestarmaps.com)"
https://news.ycombinator.com/item?id=20231328

Other recent examples at:
https://news.ycombinator.com/show

Here's how to do it (HN has reasoned rules):
https://news.ycombinator.com/showhn.html
https://news.ycombinator.com/newsguidelines.html
https://news.ycombinator.com/newsfaq.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.
To view this discussion on the web visit 
https://groups.google.com/d/msgid/racket-users/259c0cc0-b7ba-6ea0-f293-5f0130ca96d7%40neilvandyke.org.
For more options, visit https://groups.google.com/d/optout.

Re: [racket-users] leetcode

[Neil Van Dyke]

Matthias Felleisen wrote on 6/16/19 12:30 PM:

Of course, good companies know by now that these “puzzle” questions are bad at 
identifying good (as in above-average) sw devs. Only the average companies 
still use this method because they are way behind. You want people who think 
systematically and leav code behind that others comprehend down the line.


Just to define my terms, I distinguish Leetcode-style "coding tests" 
from the old MS-style "puzzles" that Google later adopted for a while -- 
Leetcode-style is more more undergrad Algorithms and Data Structures 
homework problems that most people never use again.


AFAICT, the vast majority of dotcoms still do Leetcode-style 
new-college-grad "coding tests" for software jobs at all levels -- the 
FAANGs, the non-FAANGs, and all the fresh-out-of-school startups who 
mimic what they heard everyone else does.


(There's a longer discussion about the various reasons this is done; and 
it seems sometimes not only for evaluation, but also for 
hazing/pledging/posturing.  And an imbalanced dynamic, possibly arrogant 
-- note that it's always only one-way, with no opportunity to evaluate 
the person who's making you do the whiteboard dance for their 
amusement.  Cartman of South Park demonstrated this dynamic with a 
variation on the game Roshambo.)


If you mean that your undergrad students aren't pretty much always 
getting Leetcode-style undergrad coding tests for pretty much any 
software job, maybe your program has an exceptionally good reputation 
with some employers, perhaps in combination with an coop/internship 
program trial period.  I'd be pleasantly surprised if Google, for 
example, doesn't insist on the hazing ritual battery for every single 
one of them, however.


And fwiw, we have anecdotes where places such as Amazon accepted 
students who coded their solutions in BSL or ISL+.


This is great.  And it makes sense.  A particular language is only a 
small part of what a new grad or coop/intern needs to ramp up to being a 
good software developer, and can be picked up like everything else, so 
focusing on that one thing doesn't make sense. A lingua franca for 
interviewing is convenient, but not necessary.


Now I'm wondering even more, whether should try to get leetcode.com to 
add Racket or Scheme to its menu.



I looked at the solutions for the first problem (’sum’). I think idiomatic 
full-fledged Racket will look fine. I use d-s-r because I hate repeated 
patterns.


That's an interesting way of doing it, and I'll have to ruminate on it, 
but you're hurting my advocacy argument on HN yesterday, about when 
macros are best used in Racket. :) 
https://news.ycombinator.com/item?id=20191406



It includes a “test”. But yes, I can see how plan R5 would look very bulky 
here, except if you can figure out ‘do’. (This has been a iong running argument 
with a local colleague here who loves R5.)


I think an R5RS style fits, for example, an early phase of a particular 
pedagogic approach I have in mind.  Big quick paragraph, in case anyone 
cares...  I'd poach experienced programmers into Racket, possibly 
learning on-the-job, by starting with the more familiar algorithmic bits 
of R7RS, while telling them that unfamiliar stuff is coming next, but 
they can start working with this (hopefully not like a movie villain 
telling the hero, "we are not so different, you and I").  With unit 
tests from the very start, starting with exposing/understanding the 
language, rather than designing and validating their code.  Then, after 
a little practice with that, have them try an exercise of writing 
without mutations (maybe heavy on recursive with named-`let`).  And only 
after experience with that, show them things like the Racket `for` 
family (once they know how to get their recursive algorithms exactly 
right without those, before they get into a habit of shoehorning).  
(Well, maybe I can show `for` early, for immediate productivity and 
appeal, and then tell them to stop using it for a while, as an 
exercise.) Then some experience with that, before we get into syntax 
extension (so had a sense of how to do things without syntax 
extension).  And never introducing `eval` (for perhaps at least a year, 
until people already know how to solve most every problem without it).  
In parallel with this, convey a particular school of thought about 
various higher-level software development stuff, which will be at least 
slightly different than what they already know.  I think this might make 
for very solid Racket/Scheme developers, and a doable progression that 
has them able to start being productive within a day (of course they'll 
probably want to rewrite that code later, once they're not writing 
Pascal in Scheme syntax, but the code will probably still work until 
they get around to that), and mixing together progression of abilities 
with modest exercises that shouldn't slow productivity much (e.g., the 
no-mutations exercise).


Thanks for your comments.

[racket-users] leetcode

[Neil Van Dyke]

Anyone have thoughts on whether there's anything Racket can/should do 
involving Leetcode?


If you're not familiar, Leetcode is a site with bunch of coding 
interview problems that huge numbers of CS students and professionals 
work through.  For doing the problems on the site, there's several 
popular programming languages to choose from (Racket and Scheme not 
among them).  https://leetcode.com/problemset/all/


I just did three of the most popular problems tonight, in Racket/Scheme, 
offline.  (Incidentally, in the official solutions writeups of all 
three, I ended up finding what appears to be one outright incorrect 
algorithm, and had nits to pick in each, over the discussion and 
sometimes needlessly inefficient coding.  And they strangely provide 
little-to-no test cases in the official solution writeups I've seen so 
far, when I'd say that figuring out good test cases should be a 
fundamental part of every solution process.)


One thing I found with my code[1] is that it's probably not good for 
*selling* people on Racket.  If you don't know a Lisp, and you look at 
this Racket/Scheme code as well as the Java or C++ official solution, I 
suspect this code looks bulkier and less familiar. Though, for example, 
one of their solutions, if you tried to really understand an 
optimization they were doing, their coding style actually obscured that, 
and the Scheme code could've done that same approach in a way that was 
easier to step through exactly what's going on.[2]


Also, I suspect that going to a lot of trouble to publish better 
solutions, and crits of the official ones, won't impress many. Although 
I saw one of the official solutions go into excessively detailed big-O 
analysis, and I suspect most everyone doing Leecode has Intro Algorithms 
as an accomplishment they can rightly be proud of, I suspect that the 
majority of people just want to survive the all-important whiteboard 
hazings, and the self-image/aspiration after that is more "I get it 
done".  I suspect that Racket will already be assumed to be for 
academics, so academic-ing Leetcode problems harder won't change that, 
and these contrived whiteboard problems I've seen so far don't really 
lend themselves to Racket's relative practical strengths.


I suppose one possibility might be to get Racket or Scheme considered an 
official language for Leetcode.  Simply having it appear on the menu on 
leetcode.com is a boost of credibility.  I doubt many employers will 
want to see Racket/Scheme in any case right now (and schools I've seen 
seem to be targeting a popular language, for internships and whiteboard 
interviews), but students and professionals will see it.  Maybe: not 
being on that list says we're definitely not relevant; being on the list 
says we might be. Plus a few "what's this new Racket/Scheme thing?" leads.


Other ideas for involving Racket and Leetcode?


[1] Style-wise, for this exercise, I did pure-functional (which was easy 
and efficient for all of the 3 problems thus far), and in only R5RS plus 
Racket hashes and my unit testing library, and favoring named-`let`.  
FWIW, for the constant factor details, I also assumed a modestly good 
compiler, I micro-optimized a bit more than I had to (e.g., avoiding 
redundant branching in imagined target code), and I didn't assume 
allocations/GC were free.


--
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/7c80122b-6157-f75e-3994-d5e5d0503f90%40neilvandyke.org.
For more options, visit https://groups.google.com/d/optout.

[racket-users] same-project language comparison opportunity

[Neil Van Dyke]

If someone has time to write a Java-subset-to-x86 compiler in Racket, 
with certain restrictions, they can make a partly-scientific blog post 
or paper that compares it to these:


http://thume.ca/2019/04/29/comparing-compilers-in-rust-haskell-c-and-python/

https://news.ycombinator.com/item?id=20192645 (where Racket was mentioned)

--
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/012d2814-1c00-d9a4-5b01-bb7f1bf23a98%40neilvandyke.org.
For more options, visit https://groups.google.com/d/optout.

[racket-users] nannou

[Neil Van Dyke]

A platform for multimedia artist programmers is using Rust.  I think 
it'd be interesting to see how what has been and could be done in Racket 
(including DSLs) could compare.  https://nannou.cc/


--
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/1a021325-e808-2362-32ac-d3bdb6a04b0f%40neilvandyke.org.
For more options, visit https://groups.google.com/d/optout.

Re: [racket-users] requirements for streaming html parser

[Neil Van Dyke]

Greg Hendershott wrote on 6/6/19 9:51 PM:

Although I don't think I currently /need/ a streaming parser for speed or space 
reasons, I can imagine using one.


I'm not certain I immediately need the performance boost either. But a 
Web proxy idea I'm toying with would need at least one great DSL, to 
encourage casual distributed development among large numbers of people, 
and it seems a shame to do all the work to implement the somewhat 
performance-sensitive DSLs atop an inefficient interface. (And I suspect 
that such DSLs would need to be almost totally rewritten if later moving 
to a streaming interface.  This isn't a startup, in which we have at 
least subsistence funding initially, and the expectation of more 
resources for rewriting later.)


For an approximately real time HTTP proxy application, being efficient 
means typical responsiveness of page loads, and minimizing GC burps.  
For a different application, of actively Web crawling, or processing 
billions of pages from a pre-crawled Web corpus, on a tight 
research/non-profit/startup budget, performance of the parser might mean 
you can use a smaller or fewer servers (though your "cloud" 
infrastructure traffic and transfer costs would probably remain the 
same), and also reduce your GC time.



I'd suggest making something where the user supplies an "on-element" "callback", which is 
called with each element -- plus the "path" of ancestor elements. The user's callback can do 
whatever it wants.


That sounds like one good interface.  It would probably be implemented 
atop a more flexible fold interface, somewhat like in Oleg Kiselyov's 
SSAX, or in my `json-parsing` experiment.  And other interfaces would 
also be implemented atop that.  I'd do the underlying fold interface a 
bit different, and have to analyze the actual performance.

http://okmij.org/ftp/Scheme/xml.html
https://www.neilvandyke.org/racket/json-parsing/

Some of the SXML transformation languages are also worth looking at, for 
inspiration.  Oleg did one, and Jim Bender's `sxml-match` is another.  I 
did one like Oleg's, tried to do an improved one (that might've been the 
scariest `syntax-rules` example ever), and did an unfortunately 
closed-source one similar to `sxml-match` but with some additional 
features.  There's also probably places for using modern Racket `match`.

https://planet.racket-lang.org/display.ss?package=sxml-match.plt=jim

There's also Xpath and CSS selectors, as you said, and (in my scraping 
experience) you sometimes start with `sxpath`, to find a desired chunk 
of the page, and then switch to other methods to process that chunk.



I think it would be good if you host Racket packages on GitHub, GitLab, or 
similar other site


I agree, and I'd probably start with new packages.  (And I *almost* 
moved old packages to GitHub, right before the acquisition was 
announced.  And ever since then, there's a question mark over how 
investors will cash out of GitLab, or whether they'll do something like 
signal reassuring intentions by switching to being a social benefit 
corp.; they just got another $100M of investment last September.)  The 
main barrier, though, is time and priorities, when not making 
money/career off this.  And if I had time to disrupt workflow, there are 
some other workflow changes I'd do first.


Thank you for your comments.

--
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/a1e753e2-0ab0-9f4f-e575-99b269eccbf5%40neilvandyke.org.
For more options, visit https://groups.google.com/d/optout.

[racket-users] requirements for streaming html parser

[Neil Van Dyke]

If anyone has a use for a *streaming* permissive HTML parser (i.e., one 
that calls your specific bits of code while it's parsing, rather than it 
constructing some kind of representation of the entire page for your 
code to process afterwards), I'd be interested in what specifically 
you'd like it to do.


(For example, in a simplifying/security Web proxy, in which you want to 
reduce memory requirements on the proxy host, and perhaps also response 
latency, by transforming as you go.  Or in a Web scraper for large query 
results, in which, say, you want to be sending a large amount of 
extracted data to as rows to a different database without buffering up a 
huge page and/or the rows.  Or for scraping a small part of a large page 
without allocating a parsed representation of the entire page.  Or maybe 
you'd like the performance properties of streaming, and the convenience 
of a pattern-based scraper or transformation language atop that.  )


--
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/d2f9c369-31fc-5e8d-1bb4-1751e84c6793%40neilvandyke.org.
For more options, visit https://groups.google.com/d/optout.

Re: [racket-users] New Package: Dynamic FFI - Write C Code Inline

[Neil Van Dyke]

This looks neat.

I'm glad you noted upfront in the documentation about things it can't 
handle automatically (e.g., allocations/lifetimes that need special 
management).


In your discussion relating this to other work/approaches, you might 
want to contrast with SWIG (e.g., you work from the original headers, 
when SWIG not available).  And, as a practical measure, maybe consider 
using some of the information from SWIG when available.


If you or someone later someone wants to do work with C code in 
pure-Racket (without the Clang dependency), I recall some earlier work 
on C parsing, and you might find some packages for that (also check 
PLaneT), maybe including by Dave Herman.  A C parser is a lot harder 
than one might initially think (it's not just the fairly straightforward 
standard grammar with type-based ambiguities, but also getting all the 
preprocessing correct while (for some tools needs) retaining 
pre-preprocessing information, such as the names of macro uses and fine 
source position information), but you can do neat things once you build 
it.  One of my past employers used such a fancy C parser for "reverse 
engineering" C code into a full CASE system (which included other neat 
toys, like a high-level structured systems analysis, 
network-based in-circuit emulator, embedded system code instrumentation 
for path coverage, static complexity analysis, test case generation).


BTW, that's a clever use of `at-exp` for embedded C code in your 
example.  For cases in which that doesn't work as cleanly, people can 
also use Racket `#<<`...`#>>` "here strings" (or you can make a simple 
special embedded reader, which could also be a cue to an editor/IDE to 
treat as C code).


--
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/ab1f4127-7a49-a59d-10ce-4d2f0202a91a%40neilvandyke.org.
For more options, visit https://groups.google.com/d/optout.

Re: [racket-users] Re: R7RS

[Neil Van Dyke]

Thank you, amz3.  This is exactly what I needed.  (I should've realized 
that same question would've been on the minds of the R7RS writers, and 
read the friendly manual.)


--
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/bfaab12d-684b-32f5-614f-eb1bbea49817%40neilvandyke.org.
For more options, visit https://groups.google.com/d/optout.

[racket-users] outreach reddit /r/learnprogramming

[Neil Van Dyke]

If you want an interesting place to do outreach for Racket, 
`/r/learnprogramming` has almost a million subscribers, and a search 
suggests that questions about Racket (and criticisms) tend to go unanswered:


https://old.reddit.com/r/learnprogramming/

https://old.reddit.com/r/learnprogramming/search?q=racket_sr=on

https://old.reddit.com/r/learnprogramming/search?q=htdp_sr=on

You can answer things, and point documentation, packages, etc., and also 
suggest that all the action is on `racket-users`.


I was reminded of `/r/learnprogramming` when it was mentioned as as a 
venue for sneaky influencing, in this:


https://www.nemil.com/musings/hack-an-engineer.html

You can also promote Racket there in non-reactive ways, with posts and 
such, but don't take the sneaky bits in the article above as 
prescriptive, and repeat the mantra: Don't Be Evil (Really).


--
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/0bf3eba2-abc2-fe06-6c03-b51364460852%40neilvandyke.org.
For more options, visit https://groups.google.com/d/optout.

[racket-users] R7RS

[Neil Van Dyke]

Does anyone know of a summary of R7RS-Small changes relative to R5RS 
(not relative to R6RS)?


(I'm aware of 
"http://andykeep.com/SchemeWorkshop2015/papers/sfpw1-2015-clinger.pdf;, 
which addresses a different question.)


--
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/4a206754-e6f8-b44d-e40f-544fcb1fe6fc%40neilvandyke.org.
For more options, visit https://groups.google.com/d/optout.

Re: [racket-users] tip for promoting racket on yc hacker news

[Neil Van Dyke]

I love n-gate, and part of the amusement is the mix of a bit of truth 
and being over-the-top harsh.


HN has some merit, and I might also be seeing some positive shift in HN 
zeitgeist within the last couple months (or maybe I'm just getting 
desensitized to the worst, and perceptually biased to see the best :).


The main reason I first recommended some Racketeers try HN was to bridge 
to people interested in doing startups, like Paul Graham started with YC 
(back when he was encouraging people to interrupt college to do a 
startup).  I currently suspect that a successful startup using Racket 
get to launch ("Rocket") is the most likely way that we'll now have 
credible commercial adoption now (the kind in which job posts ask for 
Racket experience).  For whatever reason, we haven't seen startups out 
of Racket-using universities write success stories about how Racket 
helped them launch, so I looked to places like HN to reach the 
startup-inclined directly.


(Racket History: When PG first started summer(?) funding startups, a few 
of us PLTers/Racketeers applied as a team, and I figured we had a 
chance, given how PG was also singing the praises of Lisp for startups, 
and we were accomplished in Lisps.  We didn't even get a response, I was 
miffed for years, and it's only recently that time healed the wounds of 
betrayal, and I was willing to try HN. :)


--
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/56dc0b6d-ec66-67bf-8fe0-1e0686202aa2%40neilvandyke.org.
For more options, visit https://groups.google.com/d/optout.

[racket-users] racket email lists need sysadmin skills volunteer

[Neil Van Dyke]

If any Racketeer has a bit of sysadmin-type skills, and can commit to 
volunteering... it looks like there's a new problem with Google Groups, 
and a somewhat urgent need for sysadmin work on the email list hosting 
and archive, and then for maintaining whatever changes are made.


This is separate from any problems with lists.racket-lang.org you 
might've heard of.


It seems like a heroic volunteer from the community is really needed.

If you can volunteer, there's a bit of discussion in "racket-dev" 
today.  You can volunteer to the core Racket people directly.


(Sorry if this is already well-known, but I was unsubscribed for a 
while.  I also regret I can't commit to this work myself right now.)


--
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/cfd4358f-a95e-753b-6f55-0edd5fbeb9c2%40neilvandyke.org.
For more options, visit https://groups.google.com/d/optout.

[racket-users] tip for promoting racket on yc hacker news

[Neil Van Dyke]

If you're posting Racket-related stuff in recent months to YC's 
startup-oriented Hacker News (HN) site:


1. Thank you!

2. It seems important to time the posts so that they hit "new" or the 
front page during US morning/afternoon work hours.  I've seen some posts 
that gain a lot of traction with comments (most recently, one on a 
section of Matthew Butterick's book), but other deserving posts that 
appear while the bulk of HN users aren't reading.


(Apologies for the US-centrism, but YC is a US-based organization, and 
HN users seems to be weighted that way.)


Also, for everyone else, if you're interested in US startups/dotcoms, 
getting some feel for HN seems important, and you can also help out in 
the comments on Racket posts.  (I've been doing a bit of this.  There 
seems to be a lot of scattered enthusiasm for Racket, a lot of 
curiosity, and some misconceptions.) https://news.ycombinator.com/


(As always, racket-users is the canonical forum for Racket, and things 
like HN are outreach outposts.)


--
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/e210fa65-f048-cd1b-f77f-ccf8ae6d0b49%40neilvandyke.org.
For more options, visit https://groups.google.com/d/optout.

Re: [racket-users] Re: Little language design/implementation guidance

[Neil Van Dyke]

George Neuner wrote on 2/7/19 12:43 PM:
No offense to Herman, but I think the problem with consulting experts 
is that there are relatively few language experts who are available to 
consult.


I suspect there's so very little *market* for such little language 
experts.  Some non-exhaustive suggestions of why:


* Reasons like you suggest.  (Is this person going to be sufficiently 
engaged to do it well.)


* Egos/opinionatedness/fun.  (What developer thinks they can't design a 
language and doesn't have some ideas about that?  And possible morale 
hit to team if pushed by manager?)


* How do you even evaluate skill in little language design, to find the 
expert.  (This doesn't seem to be as easily objective as "have added a 
new target architecture to GCC or LLVM".  It's soft/vague, and industry 
even has trouble vetting developer candidates for skills that supposedly 
the organization does understand, like basic software development.)


We can talk all day about how industry people should value some 
intellectual niche for consultants, but it might just be easier to just 
get a professorship instead (also nontrivial). :)  If you solve the 
consulting market problem, "https://www.neilvandyke.org/racket-money/; 
wants to know.


(Also, if someone has expertise in some niche technical 
(non-management-consulting) area, do they really want to be running a 
niche technical consulting business, or would they rather focus on doing 
great work in those technical areas, and just have gobs of money appear 
in their bank account (without dividing attention to constantly drumming 
up business, invoicing and work reports, tax accounting, professional 
insurance, sector compliances, solo 401k, etc.).)


I think every *serious* developer should read at least an introductory 
text on compilers.  Even if you never try to implement your own 
language, understanding what happens to your code when its compiled 
makes you a better programmer.


Definitely.  (Do pretty much all CS undergrad curricula currently 
include some kind of compilers/translation-to-arch?  And it's accessible 
to all CS undergrads, not an elective, nor a hated weedout?)


Separate from compilers and underlying architecture, and perhaps 
especially with "little languages" and DSLs, there's also the 
linguistics or even HCI side.  Which (depending on the language intent) 
is possibly entirely orthogonal to implementation.  What makes a good 
language for a purpose.  One thing that I suspect helps with this is 
experience with many different languages and approaches, so you have a 
breadth from which to draw, and some insight into them (not just 
book-learnin').  I assume it also helps to understand users of your 
language, what they know and want to do, and what you can convey


For the linguistic side, evaluation criteria might be hard.  (Do people 
qualitatively like using it?  What's the adoption, and how is that 
involved in merit or telling us what's good or bad about it? Controlled 
productivity/maintainability/defect metrics?  Does a particular employer 
use it, for whatever reason?   Does some quality of formal semantics or 
syntax say people should like this little language, and if they don't, 
they don't deserve such a fine language?  etc.).


--
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] Little language design/implementation guidance

[Neil Van Dyke]

Stephen De Gabrielle wrote on 2/6/19 11:25 AM:


Dave Herman recently tweeted


BTW, Dave Herman was a great contributor of Racket (PLT Scheme) 
packages, and has been missed, though I understand the attraction of 
Mozilla at the time.


More generally, can you recommend resources a developer (without a 
background in language design) should refer to if they are building a 
simple templating system, application configuration file, etc. - that 
may grow into a little language?


If I could offer a few quick general guidelines instead:

* Consider whether declarative or imperative is better.  Declarative can 
let you do more static reasoning (even though you might implement by 
syntactic transformation to imperative Racket), and is often the thing 
to do.  However, sometimes imperative is what you want even when 
initially it looks like declarative, especially when you get into the 
next guideline...


* If you ever find yourself writing bits of an imperative language, 
consider just exposing a real language, like Scheme.  Even if you don't 
go for Emacs-like extensibility, there is a long-long history of 
everyone almost always reinventing a half-butted language when they 
would've been in a much better position by taking a real language off 
the shelf.  Perhaps a real language with extensions (like, if you really 
want a prototype object system, go Scheme with a small layered prototype 
object system).


* Consider whether your DSL, in which the the two previous guidelines 
might have you do as a mix of declarative with scattered bits in an 
off-the-shelf real imperative language... is even better as the 
off-the-shelf imperative language at the top level, with a couple really 
well-chosen syntax extensions or procedures.


* Don't be overinfluenced by the above guidelines.  Often, the less we 
know, the easier it is to make blanket generalizations. :)


Sorry I have to run and can't give a more thoughtful brain dump right 
now, but quick anecdotes of my own (criticize oneself first) from 
Racket: two non-public DSLs I made, one for high-performance XML 
transformation, and one for processing some cool and big tabular data, 
both make me cringe -- partly because of how I implemented them 
(`syntax-rules` rather than `syntax-parse` or `syntax-case`), and 
partly, with the latter, a bit less contrived declarative would've been 
more flexible yet looked about the same.


Another DSL, I might be the only one who likes it, but I really wanted 
to make it as part of rethinking Web development a bit, and you can see 
that I used the DSL only where I got benefit (moving some trivial 
computation and checking to syntax expansion time), and I expressly (see 
"By design...") avoided doing things like inventing my own declarative 
iterators, or reinventing a half-butted Scheme. There are some static 
checking things that I can't do this way (e.g., full HTML5 validation), 
but it seemed a good tradeoff, and I could always *layer* that crazy 
static checking later, if I really wanted to do things like make 
declarative language for mapping database results.  One DSL decision I 
made was to sacrifice the S-expression representation as data accessible 
to the programmer, in favor of emphasizing writing the byte stream as 
you go (yes, I've seen this get massive, in practice), and also using 
normal Racket ports, so that it could be combined with other Racket 
ways, for flexibility (again, not reinventing or restricting the 
language when it didn't benefit me). 
https://www.neilvandyke.org/racket/html-template/


BTW, related, a few places in the list archives, I talk about an 
alternative to configuration files, like thinking of the application 
instead as a framework, and the configuration file is actually an 
instantiation of the framework.  And some simple practical startup 
mechanics for doing that (e.g., executable that falls back to the 
default instantiation if no config file available, and maybe writes a 
"config file").  You don't have to do all that way, but you see how this 
could be powerful.  If you do it right, in a lightweight (in the 
developer burden sense) way, and, together with other factors, you could 
also encourage an ecosystem and culture of very casual extension of your 
application (like was part of what made Emacs so loved and powerful).


--
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] Guide and reference

[Neil Van Dyke]

James Geddes wrote on 2/6/19 6:33 AM:

but in general I’ve not found elsewhere this tasteful combination of clarity 
and completeness. (Well, except RnRS, so maybe my prejudices are showing 
through.)


I mostly like RnRS.  For one practitioner reason, you can hand many 
programmers the canonical R5RS spec, with the formal semantics and 
first-class continuations bits redacted,[1] :) they can read it for an 
hour on the train, and, at the end, there's a good chance they're 
thinking they could figure out how to use this, and it's kinda 
interesting.  (Idiomatic use of it is a whole 'nother deal, such as how 
to really use recursion and tail calls, and minimize mutations, and how 
to use and take avantage of syntax extension-- but they could 
immediately sit down and start building a Pascal-with-parentheses 
program in less-idiomatic Scheme, which runs, and from there start 
learning idioms and power.)


Core Racket is *much* bigger than RnRS.  If you just want to get day-one 
gist of "...and it has good-enough regexps... check!", you could squeeze 
all of those into a terse 1-hour read.  But when you go to the manual to 
do work with core Racket on a daily basis, you often need more 
specification and explanation than fits in the brochure, preferably 
where you can confidently find it immediately.



I find other languages point me to books about the language that take too long 
to get a handle on the basics; and exhaustive references that seem to contain 
both more than I want and less than I need.


For everyone who is past the first day of Racket, and for every day 
after that, I'd ideally like for Racket to have the well-organized 
exhaustive Reference for the cor language and library, which includes 
the "For example..." inline that currently is in the Guide (and the 
Guide would be deleted).  Separate tutorials can give gentle overviews 
and nudges towards the thinking, but afterwards, all a Racket 
practitioner usually needs is the Reference and the documentation for 
various non-core packages.


Imagine day-to-day working confidently from such a Reference of the 
core, not going first to Web searches and Stack Overflow because you 
don't trust that you can easily find it in the documentation.



[1] I strongly suspect that the first-class continuations or scary 
formal bits of RnRS cost it some adoptions at some opportunity 
junctures.  For example, I was in charge of the extension/application 
language for a new workstation OO CASE system (this was when some other 
top workstation applications like AutoCAD and Interleaf were extensible 
in Lisp dialects), and Scheme was one of the candidates.  I didn't know 
Scheme at the time, but was a new PL person, and Scheme appealed as a 
small and pretty clean Lisp with the power I wanted.  Unfortunately, I 
got overruled by the Fellow technical cofounder of the company 
(otherwise a top engineer and in some ways role model :), who instead 
recommended a particularly nice string-based language that would be more 
friendly-looking to end users.  (Unfortunately, that language was very 
poor for nontrivial data structure graphs like our application had, for 
starters, though it did have a neat spin on syntactic extension.)  I 
think RnRS came across as "too academic", like "Holy crud!  A function 
return is a call!  OMG, we're all, like, cosmically connected, man...  
And a return is... a first class object?!  WTH!"  And the formal 
semantics -- which a PL grad student might interpret as rigor in 
underpinnings, could also just be intimidating and inaccessible to most 
practitioners, or give the impression of an impractical academic 
exercise -- that might've been the lethal finishing move, blocking 
earlier mainstream adoption.


--
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: Some concern about ChezScheme...

[Neil Van Dyke]

I appreciate the engineering diligence behind Alex's and Paulo's concerns.

Given the exemplary track record on Racket, I'm comfortable putting 
faith in Matthew's assessments (like a trusted engineering colleague, 
beyond the quantifiable like interim benchmarks), and there's at least 
some obvious goal alignment, and there's also been a good amount of 
transparency and conspicuous methodical work on the Chez work.


Thanks to Alex, I just realized that I don't recall the plans for 
performance at switchover time, and going from there.  It'd be good to 
get an update/reminder on the current thinking, as people have to plan 
for long-term.


(My experience with a Racket production server farm is that we often 
didn't pick up each new Racket version immediately, and one time I 
backported a Racket enhancement across multiple versions when we had to 
be especially conservative, but we wanted to keep the option to move to 
use the latest version at any time, and we liked to know that we're on a 
good track for long-term.)


(BTW, some of us run Racket on ancient Intel Core 2 and older smartphone 
ARM, plus have Racket on a beefy new dedicated real-metal compute 
server, and we use 
"https://www.neilvandyke.org/racket/install-racket-versioned.sh;... so 
we will know if anyone tries any funny-stuff! :)


--
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] Some concern about ChezScheme...

[Neil Van Dyke]

I had a related (but different and small) concern about the new 
dependency a while ago (this was off-list), but it sounded like that 
risk was covered, and also that Matthew has really gotten into the Chez 
code.


BTW, sometime around when the move to Chez settles, it would be good if 
many people were somewhat familiar with current Racket internals.  
(Personally, I know a little of it, from writing C extensions, and from 
occasional intense optimizing, but I should take a fresh look, and the 
Chez move seems like a great time.)


BTW, students, especially: if you've not yet been on a few projects in 
which you've looked at diffs for every single change (maybe by having 
them emailed), it's a learning experience, giving you a better feel for 
the system and its evolution and the process, and Racket might be a good 
one for that.  Discussions around changes, too, if you have access to 
those.  I might soon do this myself, for Racket and/or Chez upstream, 
although it feels suspiciously like work. :)


P.S., Yay, RISC-V! :)

--
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.