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

[Atlas Atlas]

четверг, 25 июля 2019 г., 22:03:15 UTC+3 пользователь stewart mackenzie 
написал:

> 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. Easily said that done I know. Right, let's not 
> pretend Honu is going to bring users by the droves, it might bring a 
> few, but if you're really serious about bringing in new users aplenty 
> this is the path to mass adoption - if you're lucky. 
>

I don't share enthusiasm about web thing, because uncontrollable 
downloading and executing random code from internet is conceptually bad 
idea.

But I do share the concern regarding ChezSheme. Will it stay maintained for 
long time? What about ARM support? What about new architectures, like 
RISC-V?
What about different OS support?

-- 
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/2bfd2513-e130-43fa-aabf-d897d8cbb702%40googlegroups.com.

[racket-users] a question related to bound-identifier=?

[Yongming Shen]

Hi there,

Based on my understanding, (bound-identifier=? id-a id-b) only returns true 
if id-a would bind id-b AND id-b would bind id-a. Also based on my 
understanding, id-a will bind id-b doesn't imply that id-b will bind id-a. 
So, if I only want to check whether id-a will bind id-b, which function 
should I use?

Thanks,
Yongming

-- 
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/b9e98764-1505-4bf9-a8d3-df5d8d2d72b5%40googlegroups.com.

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

[Greg Hendershott]

> I've taught the exact same material at the start of a 3rd year CS PL
> course, and the students there didn't find the syntax as easy as one would
> hope for students with that much CS “experience”. In fact, unsurprisingly,
> many find the syntax as hard as expected for having trained on very
> different syntaxes (especially when they are unclear about the semantics
> that were attached to those syntaxes). Although the switch to teaching the
> start of the course with literally the same materials, with the students
> knowing that, seems to have reduced resistance substantially (presumably
> they don't want to be seen as complaining about something 1st year
> humantities students are fine with).

This makes me wonder if some experienced programmers dislike simple
syntax, not just because it is unfamiliar to them, but also because it
is too simple to serve as an effective in-group filter. If humanities
students are comfortable, we must raise the barrier to entry. ;)


p.s. I just now stumbled across the Iron Ring obtained from the Ritual
of the Calling of an Engineer. Probably everyone has heard of this
except me, but if anyone hasn't:

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

-- 
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/87a7d1mv0t.fsf%40greghendershott.com.

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

[Atlas Atlas]

If we want more women, or any other group of people, involved in Racket, 
the only way to achieve this is to explain to this groups of people why do 
they need Racket.

*(And openness and honesty is a great way to do it)*

And try to answer this question for ourselves.
What Racket can offer to this social group?
And if there is no answer, then perhaps no point in marketing something 
that this group of people does not need or want.

What my experience says, any social groups based on general 
similarities(gender, skin color) as a groups interested not in many things 
at all.
They also act very aggressive not so to other groups but to individuals of 
any king.
Because individual is what conceptually opposes to any group.

And I honestly believe that it is individuals who are interested in Racket.
It is individuals to whom Racket can offer something.

Therefore, I believe that to individuals we need advertise Racket, not to 
groups.

Individuals may face different barriers, but I imagine very rarely 
associated with they gender.
The main barrier is they a not yet a part of Racketeers group, if we a 
talking about community.

It is crucial for small projects to have place where newbies can go, ask 
silly questions, write stupid things, and get wise guidance.
And mailing list is something that younger generation even don't know to 
exist.
So it will be nice to have at least community forum in this regard.


четверг, 25 июля 2019 г., 21:10:49 UTC+3 пользователь Neil Van Dyke написал:

> but I think you're right to suggest that FAANGs might be part of a 
> problem. 
>

-- 
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/670885bc-3a35-40c2-9429-55db07961a62%40googlegroups.com.

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

[Atlas Atlas]

It is crucial to understand that "lowering barriers" can mean different 
even opposite things.
You can lower barrier by helping someone to learn.
And you can actually "lower barrier" by diminishing the goal.


And when we talking about social interaction we must acknowledge that 
people a different, and the is at lest three ways to deal with this 
difference, respect it, try to make everyone the same, or respect only some 
differences of some groups.
For example men in general more aggressive then women, they also pursue 
different social goals. You cannot ignore this, or blame the men for what 
they are. You also cannot ignore the fact that people in general driven by 
their sexuality.
My personal answer, first step after nip off violence is to educate people 
on their differences so they can build respect for each other.
But this is not of course task for programming language community, it is 
just something that must be taken in to account.


And teaching is whole another problem.

1. For different people learning something takes different effort, 
sometimes crucially different.

So different people require different teaching approaches. And the metric 
is more complex then just easy/hard duality.
But even this simple metric emerge a lot of problems.


2. Some people unable to learn some things no matter how hard they try.

So the goal must be described in honest way. So people do not build false 
expectations.


четверг, 25 июля 2019 г., 20:51:01 UTC+3 пользователь Atlas Atlas написал:
>
> I never said that lowering barriers is lying or insulting.
>
>

-- 
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/bac69c64-ebf4-4451-b398-fc6f42f44001%40googlegroups.com.

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

[stewart mackenzie]

I want expand on and make sure Maria's point doesn't get lost in that
firestorm over at  [the case, and a proposal, for elegant syntax in
#lang racket2] . Maria is bang on the money imho (her email is copied
below mine)

JVM got popular because programmers didn't need to program C.
Javascript and BEAM on the other hand became popular for entirely
different reasons: content dissemination.

BEAM is a soft-realtime vm with concurrent light-weight language
threads suitable for high up-time systems. In other words switches.
Yes, Erlang runs the Internet. This deluge of high bandwidth and
up-time communication infrastructure opened up more than enough space
for kitten photos and porn videos, then later your banking and market
trading. A new niche has opened, to be filled by the HTTP browser.

Enter Javascript, it rode the coat tails of another beast. Content
dissemination over an Erlang point-to-point communication system. We
no longer use TCP/IP to primarily connect to other machines to do
resource sharing such as printing off a document, we use the internet
to do content dissemination en mass. The HTTP browser is the gateway
to getting pictures of our children, emails from our family and
friends. Javascript rode this wave, not because of language purity,
nor blind luck, it was created to solve a problem of enabling a fat
server thin client model.

In this light, one might see it as Javascript over Erlang. But
Javascript is warty and annoying and coming to an end, a new niche is
to open and be filled. Rust is quite likely going to take this cake.
If you want to get Racket2 popular target WASM beat Rust to the finish
line. Currently only C, C++ and Rust do a good job of this.

 Currently the browser enables a user to point to a domain and the
application gets reproduced on their machines executing [a game, email
client, etc]. Programmers are looking to easily get their programs
into users hands. Users buy things which pay their salaries. I know,
quite likely you're having a knee jerk at anything to do with the web.
Nasty stuff that mishmash of JS, CSS and HTML. Some good engineers *in
advantageous positions* have looked at this problem and have designed
WASM. Advantageous, I say, because their code currently ships with
every major browser, on hundreds of millions of machines right now and
is begging for someone to target it.

Opening up Racket2 to the browser, an environment such that we 1) get
a good user interface via html 2) get dissemination of our application
to users who don't need to install yet-another-vm 3) can express damn
near any syntax via honu [0] 4) create fat clients in a decentralised
environment is a clear winner.

Sadly at the moment, WASM doesn't fit well with a dynamic language
like Racket. Things like continuations in WASM and a GC would go far.
Two things that Rust doesn't need.

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. Easily said that done I know. Right, let's not
pretend Honu is going to bring users by the droves, it might bring a
few, but if you're really serious about bringing in new users aplenty
this is the path to mass adoption - if you're lucky.

Lastly, what I appreciate about this mailing list is the focus on the
individual. Groups cannot be held accountable, only individuals can. I
really and truly hope we can keep focusing on each and every
individual's technical ideas and questions. For example when we first
started using Racket, Matthias Felleisen made a pull request to our
project doing a simple code formatting. That's when I knew this
mailing list and programming language was the bee's knees. Hearts and
minds won, end of story.

[0] 
https://groups.google.com/forum/?utm_medium=email_source=footer#!msg/racket-users/HiC7z3A5O-k/t3IRVgLTCQAJ


Maria Gabriela Guimarães 

Thu, Jul 18, 7:52 AM (8 days ago)
to Racket
Hello, community!

Let me tell a few words about the idea of transitioning Racket to a
traditional syntax to gain popularity: I think this idea is a fallacy.
Racket is not popular due to its s-expression syntax, because Clojure
has such a syntax, and still, it seems popular. So I don't think such
step will raise the adoption of Racket.

There is nothing new in having a traditional syntax language with
Lisp-like macros. There is one, it's Elixir. Note that I have lots of
experience writing complex macros in Elixir, and I expect writing
macros in an s-expression language to be much easier, simply because
in such a language, its notation and its AST are isomorphic, i.e.,
they share the same syntax. Let me explain this: in Elixir, sometimes,
the way to verify if a macro generates the code we want, is to see
what this code's AST looks like, which in Elixir is a kind of
s-expression (yes!), and from this, infer how to build the AST inside
the macro using the Elixir notation; this effort is totally

Re: [racket-users] Criteria for selecting Chez Scheme as the runtime for Racket

[Brian Adkins]

On Thursday, July 25, 2019 at 12:45:36 PM UTC-4, Matthew Flatt wrote:
>
> Reordered slightly: 
>
> At Thu, 25 Jul 2019 09:04:29 -0700 (PDT), Brian Adkins wrote: 
> > I know Chez had a reputation for being a fast implementation - was 
> > performance the main criteria? 
> > [...] 
> > Were there other factors, in addition to 
> > performance, that uniquely qualified Chez? 
>
> Good performance was an enabler. The way that Chez Scheme is put 
> together --- a minimal C kernel and otherwise written in Scheme --- was 
> important, and several Scheme implementations share that approach. A 
> native-code compiler and especially good support for delimited 
> continuations were important, and those requirements would rule out 
> some candidate Schemes. Finally, the core constructs of Chez Scheme are 
> the closest fit for Racket among Scheme implementations, because Racket 
> has historically taken cues from Chez Scheme. 
>
> > Were other Scheme implementations considered & rejected? If so, why? 
> > [...] 
> > If Chez was not open sourced, 
> > would another implementation have been considered instead, or would we 
> have 
> > stayed with the C runtime? 
>
> If Chez Scheme were not available at the time that we were ready to 
> consider big changes, we would have looked at other options. But most 
> likely we would have built the same Racket layers (threads, I/O, 
> regexp) as for Racket-on-Chez and used them to reduce the amount of C 
> in the old runtime system. We would also have modified or rewritten 
> parts of the runtime system to use different internal calling 
> conventions, a Chez-like implementation of continuations, and better 
> back-end compilation; that's what we got by using Chez Scheme. Also, it 
> would have taken us much longer to move those parts out of C. 
>

Awesome - thanks! 

-- 
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/ecdb7033-fb8b-4e68-922b-ee8989505617%40googlegroups.com.

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] on reducing barriers in the Racket community

[Atlas Atlas]

I never said that lowering barriers is lying or insulting.

I say that lowering barriers by lying (by making an impression instead of a 
reality 
demonstration) is really bad way to go.

If there is actual barriers, the work must be putted to improve on them, 
and not to improve on showing that this barriers don't exist.

There is also some barriers that you newer should break, for example people 
must be actually interested in writing computer programs in some way at 
least.
And regarding to this message must(this is just my opinion) be clear - "we 
welcome anyone who want to learn". 
- "This is how Racket looks like"  
- "This is how community looks like"
- "This is how contribution is happening"
- "This is main people behind the project"
Openness is helping a lot.

People clearly can see when what showed to them is real deal or marketing.
I really like RacketCon videos in this regard, they a honest. And honesty 
is the way to build social relations.

Unfortunately, I cannot up this discussion to scientific proof level 
because this is not practical for me (It takes big 
effort for me to write in English).
And perhaps will be impropriety thing to do.

My personal wish is to see some way to internationalize Racket...
If someone will want to translate site or documentation to other languages, 
what 
it might look like?



четверг, 25 июля 2019 г., 20:02:01 UTC+3 пользователь Matthew Butterick 
написал:
>
> Mr. Atlas, since this seems to be only your second contribution to the 
> racket-users list (the first was yesterday) I'm reluctant to impute much 
> weight to your views, since I can't verify that there's a sincere human 
> behind them. 
>
> In any case, I can agree with you on the value of education. But the idea 
> that lowering barriers is equivalent to "ruining community", "lying to 
> people", and "insult[ing] people who are already in the project" — no, I 
> don't agree, and those ideas are inconsistent with everything I've learned 
> about how Racket operates.
>
>
> On Jul 25, 2019, at 8:58 AM, Atlas Atlas  > wrote:
>
> 1. To increase inclusiveness of some group of people, you educate people 
> from this group on the subject of lisp racket computer science etc.
> 2. By lowering "barriers" you just welcome someone who doesn't care for 
> the project and ruining community from inside.
> 3. By making a show about what project is NOT, you lying to people you 
> want to attract, and insult people who are already in the project.
>
>

-- 
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/022e97ed-2278-4d3b-9a01-0520219ff5c7%40googlegroups.com.

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

[Matthew Butterick]

Mr. Atlas, since this seems to be only your second contribution to the 
racket-users list (the first was yesterday) I'm reluctant to impute much weight 
to your views, since I can't verify that there's a sincere human behind them. 

In any case, I can agree with you on the value of education. But the idea that 
lowering barriers is equivalent to "ruining community", "lying to people", and 
"insult[ing] people who are already in the project" — no, I don't agree, and 
those ideas are inconsistent with everything I've learned about how Racket 
operates.


> On Jul 25, 2019, at 8:58 AM, Atlas Atlas  wrote:
> 
> 1. To increase inclusiveness of some group of people, you educate people from 
> this group on the subject of lisp racket computer science etc.
> 2. By lowering "barriers" you just welcome someone who doesn't care for the 
> project and ruining community from inside.
> 3. By making a show about what project is NOT, you lying to people you want 
> to attract, and insult people who are already in the project.
> 

-- 
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/1B7D03BF-DB5F-4A1C-83EE-93E0A21CA76C%40mbtype.com.

Re: [racket-users] Criteria for selecting Chez Scheme as the runtime for Racket

[Matthew Flatt]

Reordered slightly:

At Thu, 25 Jul 2019 09:04:29 -0700 (PDT), Brian Adkins wrote:
> I know Chez had a reputation for being a fast implementation - was 
> performance the main criteria? 
> [...]
> Were there other factors, in addition to 
> performance, that uniquely qualified Chez?

Good performance was an enabler. The way that Chez Scheme is put
together --- a minimal C kernel and otherwise written in Scheme --- was
important, and several Scheme implementations share that approach. A
native-code compiler and especially good support for delimited
continuations were important, and those requirements would rule out
some candidate Schemes. Finally, the core constructs of Chez Scheme are
the closest fit for Racket among Scheme implementations, because Racket
has historically taken cues from Chez Scheme.

> Were other Scheme implementations considered & rejected? If so, why?
> [...]
> If Chez was not open sourced, 
> would another implementation have been considered instead, or would we have 
> stayed with the C runtime?

If Chez Scheme were not available at the time that we were ready to
consider big changes, we would have looked at other options. But most
likely we would have built the same Racket layers (threads, I/O,
regexp) as for Racket-on-Chez and used them to reduce the amount of C
in the old runtime system. We would also have modified or rewritten
parts of the runtime system to use different internal calling
conventions, a Chez-like implementation of continuations, and better
back-end compilation; that's what we got by using Chez Scheme. Also, it
would have taken us much longer to move those parts out of C.

-- 
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/20190725164530.CDE9D650164%40mail-svr1.cs.utah.edu.

[racket-users] Criteria for selecting Chez Scheme as the runtime for Racket

[Brian Adkins]

I'm curious about the process that resulted in selecting Chez Scheme as the 
runtime for Racket. 

I know Chez had a reputation for being a fast implementation - was 
performance the main criteria? Were other Scheme implementations considered 
& rejected? If so, why? Were there other factors, in addition to 
performance, that uniquely qualified Chez? If Chez was not open sourced, 
would another implementation have been considered instead, or would we have 
stayed with the C runtime?

Thanks,
Brian

-- 
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/f5d1fbf2-c4ce-4423-b8de-f0b8003a92cb%40googlegroups.com.

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

[Alexander Shopov]

To whoever will implement a new syntax forRacket, may I give the following
resources. I really hope they are widely known and I am just stating the
obvious common knowledge.

There have been previous attempts of using an alternative syntax:
 * M-expresisons - dating to the original McCarthy Lisp paper
http://www-formal.stanford.edu/jmc/recursive.pdf,
https://en.wikipedia.org/wiki/M-expression#cite_note-3
 * I-expressions - https://srfi.schemers.org/srfi-49/srfi-49.html

On a semi related note: I would also recomment this recent (2017) lecture
by Guy Steele: It's Time for a New Old Language
https://www.youtube.com/watch?v=dCuZkaaou0Q on the most popular programming
language in computer science (definitely not Scheme as it has no compiler,
interpreter or specification)

Kind regards:
al_shopov



На ср, 24.07.2019 г. в 22:47 ч. Hendrik Boom 
написа:

> On Wed, Jul 24, 2019 at 08:06:18AM -0700, Will Jukes wrote:
> >- On the other hand, parenthesized syntax is a natural way of
> conveying
> >the difference between statements and expressions, and that's lost in
> >moving away from parenthesized syntax, so there's some trade-off
> there.
>
> Is there a difference between statements and expressions?  Other than
> statements returning a data type that takes no space to represent?
>
> -- hendrik
>
> --
> 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/20190724204753.dwvr6ji5nzbfd7jr%40topoi.pooq.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/CAP6f5M%3Dnc41vLTqT9z-Rz%2B2AZgLrMfZNfLHUhJg6ta9o_fyfAw%40mail.gmail.com.

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

[Atlas Atlas]

1. To increase inclusiveness of some group of people, you educate people 
from this group on the subject of lisp racket computer science etc.
2. By lowering "barriers" you just welcome someone who doesn't care for the 
project and ruining community from inside.
3. By making a show about what project is NOT, you lying to people you want 
to attract, and insult people who are already in the project.

4. The is no possible reason to counterbalance the inequality, people a not 
equal, from the moment of conception. Society must acknowledge this 
inequality and build hierarchy of competence.
If you want to help uneducated people - educate them. This is the only way 
to fight poverty unemployment and other social problems.
IT communities never was biased on gender and skin color, by "fighting" 
imaginary unfairness you insulting every single programmer in the world. 
And actually creating ground for real racism and chauvinism.

When I first watched RacketCon videos I was surprised by diversity of 
people interested in Racket, this is wonderful people united by they 
passion, and not they genitalia or skin color problems. This is how it 
should be. So I don't think racketeers need such kind of help.

I think that optimization must begin from slowest parts, so, there is 
highly chauvinistic IT corporation like Google Apple Amazon, they 
desperately need such kind of help.
I believe that all social justice forces must be immediately thrown at this 
Real Big problems. You will be able to cure millions of small projects as 
Racket when you get rid of the main problems in Google and Amazon.

среда, 24 июля 2019 г., 12:00:32 UTC+3 пользователь Jérôme Martin написал:

> In my personal life, I'm involved a lot into improving the inclusion of 
> women, black people and other often excluded communities into the 
> technology field.
> From my experience, I'd say one of the most important point is not saying 
> "we are open, just come", but showing it through visual and overall public 
> communication.
> Examples:
> - Show the faces of speakers in conferences, in which we can clearly see 
> that some are black, some are women..etc
> - Explicitly create some Racket events/workshops dedicated to women (this 
> is NOT so called "reverse sexism", please)
> - This is more of a personal feeling, but I think embracing functional 
> programming as "a more feminine way" (because you let the program flow 
> naturally) compared to "imperative programming" (which sound very 
> masculine, in control, by shouting orders to a computer) can also be a way 
> to show Racket is different.
>
> My point is: Since our society is inherently biased and unequal, simply 
> saying you are open is not enough. To really counterbalance the inequality, 
> we need to *actively* reach a different audience.
>

-- 
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/53fa2ae5-2d5c-466a-9b4c-7023a4164dbc%40googlegroups.com.

[racket-users] Re: The elegance of tail-nesting recursive syntax

[rocketnia]

On Wednesday, July 24, 2019 at 7:46:11 PM UTC-7, Hendrik Boom wrote:
>
> Too bad we have to use #/ instead of / in ordinary Racket because / is 
> already used for division.  There are a lot more #/'s then divisions in 
> a typical Racket program. 
>
> Redefining div to mean division isn't a really elegant solution.   
> Probably not orthogonal to existing code. 
>

It wouldn't be hard to set it up to use / as the readtable entry, and I'd 
like to add an option like that if that's what people think would be a 
better experience. I think it just means the division operator would have 
to be written |/| to be read as a symbol, as would any other symbols that 
started with the / character.



> Another parenthesis-avoiding trick I use back then was to use 
> (let a whatever stuff) 
> to mean what Racket expresses as 
> (let [[a whatever]] stuff) 
> and then repeating /let gives the iterated sytactically non-nesting 
> let with fewer parentheses. 
> But this is incompatible with Racket. 
>

It can always be named something else. :) A lot of my Parendown-based code 
uses

(w- a whatever
#/w- b whatever
#/w- c whatever
  stuff)

using the `w-` I put Lathe Comforts 

.

-Nia

-- 
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/6550d6cc-f044-40c8-8505-c88df1b4bef2%40googlegroups.com.