[racket-users] Re: define/contract for private functions

[Roman Klochkov]

I propose to use submodules like in 
https://github.com/Kalimehtar/binary-class/blob/master/binary-class/base.rkt

So you may in test module (require mod/safe) and in normal operation 
(require mod).

вторник, 23 июля 2019 г., 21:08:15 UTC+5 пользователь Ryan Kramer написал:
>
> I've found myself wanting to write contracts on private functions, but I 
> don't want to pay the performance cost during normal operation. What I've 
> been doing is making a `def/c` macro which looks exactly like 
> `define/contract` but is wired up to `define` and discards the contract. 
> When I want to enable these private contracts (e.g. when running tests or 
> debugging a problem) I simply change the source code of `def/c` so that it 
> is wired up to `define/contract` and the contract is checked. Here is an 
> example: http://pasterack.org/pastes/4224
>
> Manually changing the source code of `def/c` has worked fine so far, but I 
> would love to be able to do something like "raco test 
> -with-private-contracts (package1, package2) ./" instead.
>
> I prefer this approach over putting the contracts in comments, because 
> comments have less precise meaning and may become subtly inaccurate if the 
> implementation of the function changes.
>
> I wonder if other people want to write code the same way. If so, having a 
> standard, shared `define/contract/private` could be useful. This would 
> allow us to do things like
> 1) Build a contract-aware linter.
> 2) Build a "minimally intrusive type system." (This might also be called a 
> "linter"; I'm not sure if there is a definite line separating the two.)
> 3) Better IDE support
> 4) If I suspect a package I am using has a bug, I might be able to confirm 
> (but not deny) that suspicion by turning on private contracts for that 
> package and seeing if a violation is reported.
>
> So I guess if I'm the only one interested in this then just ignore me. If 
> there's already work in this area, great! Please point me to it. But if 
> there's interest and a need, I'd be happy to help however I can.
>

-- 
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/0d4acb7a-632c-44e1-beec-c2d4edbe151d%40googlegroups.com.

Re: [racket-users] Re: Using errortrace with repl-driven-development?

[Robby Findler]

In DrRacket, the "preserve stack trace" button actually corresponds to a
mode in the compiler that disables some optimizations [*]. The radio
buttons at the top (specifically the debugging one) control errortrace.

Robby

[*]
https://docs.racket-lang.org/reference/eval.html?q=Compile#%28def._%28%28quote._~23~25kernel%29._compile-context-preservation-enabled%29%29


On Wed, Jul 24, 2019 at 10:43 AM Alex Harsanyi 
wrote:

> If you are using DrRacket, you can go to the "Language/Choose Language..."
> menu, click on "Show Details", than make sure the "Preserve Stack Trace"
> checkbox is ticked.
>
> If you are using racket-mode in Emacs, you can evaluate the current buffer
> using "C-u F5" which will do the same thing.
>
> If you use racket from the command line, I think you can run it as:
>
> racket -l errortrace -l racket -i
>
> Hope this helps,
> Alex.
>
> On Wednesday, July 24, 2019 at 9:45:47 AM UTC+8, Anthony Quizon wrote:
>>
>> I've been trying to find a way to get better error messages in the racket
>> repl via the command line.
>> Specifically, better stack traces. At the moment, if you load a file in
>> the repl via ',enter' it doesn't give you any information about the line
>> number for errors.
>>
>> I've looked around in the users group but could only find:
>> racket -l errortrace -t .rkt
>>
>> This is pretty much what I'm looking for except that it only lets me use
>> this once and non-interactively.
>>
>> Is there an option in the (x)repl that lets me use errortrace
>> interactively for each input?
>>
> --
> 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/4cd2db48-0520-4d4b-b144-83b1e7badc1c%40googlegroups.com
> 
> .
>

-- 
You received this message because you are subscribed to the Google Groups 
"Racket Users" group.
To unsubscribe from this group and stop receiving emails from it, send an email 
to racket-users+unsubscr...@googlegroups.com.
To view this discussion on the web visit 
https://groups.google.com/d/msgid/racket-users/CAL3TdONYvPQ1qEOZ%3DK954wm1nAPGti1Fy8A53m1LmVE9B2o1Xg%40mail.gmail.com.

[racket-users] Re: Using errortrace with repl-driven-development?

[Alex Harsanyi]

If you are using DrRacket, you can go to the "Language/Choose Language..." 
menu, click on "Show Details", than make sure the "Preserve Stack Trace" 
checkbox is ticked.

If you are using racket-mode in Emacs, you can evaluate the current buffer 
using "C-u F5" which will do the same thing.

If you use racket from the command line, I think you can run it as:

racket -l errortrace -l racket -i

Hope this helps,
Alex.

On Wednesday, July 24, 2019 at 9:45:47 AM UTC+8, Anthony Quizon wrote:
>
> I've been trying to find a way to get better error messages in the racket 
> repl via the command line.
> Specifically, better stack traces. At the moment, if you load a file in 
> the repl via ',enter' it doesn't give you any information about the line 
> number for errors.
>
> I've looked around in the users group but could only find:
> racket -l errortrace -t .rkt
>
> This is pretty much what I'm looking for except that it only lets me use 
> this once and non-interactively. 
>
> Is there an option in the (x)repl that lets me use errortrace 
> interactively for each input?
>

-- 
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/4cd2db48-0520-4d4b-b144-83b1e7badc1c%40googlegroups.com.

Re: [racket-users] Re: Racket2 possibilities

[Philip McGrath]

I thought one of the most compelling parts of Matthew's proposal was at around
37:41 in the video ,
when he said,

I've seen students in my class genuinely struggle with just the syntax.

I think it would be very useful to hear more (from Matthew or others) about
the struggles people have with s-expressions, both to understand the
motivations for a potential new surface syntax and to evaluate concrete
design ideas.

As I've been reflecting over the last week, I realized that I have a fairly
deep knowledge of my own experiences learning new languages (or at least I
like to think I do …), and I know something about the experiences of
friends and colleagues, but my knowledge pretty quickly drops off after
that. Presumably, people who teach CS get to observe much larger samples.
Those in industry with experience on-boarding new employees might likewise
have useful perspectives.

If a major goal for Racket 2, and the potential syntax change in
particular, is to reduce obstacles, I think it would help to understand
what the obstacles are, for various groups of people.

(For example, I would speculate that people who have experience programming
with Algol-like syntax may stumble at different points than new
programmers, and those comfortable with notation from math class may have
different expectations than those who are not—but that is just speculation.
In any case, such answers wouldn't dictate a particular decision, but they
could provide context to inform the decision-making process.)

-Philip


On Tue, Jul 23, 2019 at 4:18 PM Atlas Atlas 
wrote:

> My personal big wish is "standard library" consistency and futures(like
> more extended date-time functions).
>
> Another big wish is typed system. Typed racket looks like a BIG step
> forward, and gives real benefits, it is shame it have not so much support.
>
> Another wish is more fluid transition between typed and untyped code. For
> now it feels painful.
>
> --
> 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/248536cd-bce7-4a49-ba29-f6a26de68459%40googlegroups.com
> 
> .
>

-- 
You received this message because you are subscribed to the Google Groups 
"Racket Users" group.
To unsubscribe from this group and stop receiving emails from it, send an email 
to racket-users+unsubscr...@googlegroups.com.
To view this discussion on the web visit 
https://groups.google.com/d/msgid/racket-users/CAH3z3gbU-SiTb6cMu%2BBOV%3D1zYTbELTL0fvHVJGy02J-NiziccA%40mail.gmail.com.

[racket-users] Re: Using errortrace with repl-driven-development?

[Anthony Quizon]

Would using 'racket/trace' be a valid way to do this?

(require racket/trace)

(define (foo) ...)

(trace foo)

;; in repl (foo) then ,bt


Would it be correct to say that the error traces functionality has been 
delegated to libraries in order to make things more flexible? (Rather than 
baked into the repl)




On Wednesday, July 24, 2019 at 11:45:47 AM UTC+10, Anthony Quizon wrote:
>
> I've been trying to find a way to get better error messages in the racket 
> repl via the command line.
> Specifically, better stack traces. At the moment, if you load a file in 
> the repl via ',enter' it doesn't give you any information about the line 
> number for errors.
>
> I've looked around in the users group but could only find:
> racket -l errortrace -t .rkt
>
> This is pretty much what I'm looking for except that it only lets me use 
> this once and non-interactively. 
>
> Is there an option in the (x)repl that lets me use errortrace 
> interactively for each input?
>

-- 
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/9c6e6883-f83d-4b6f-88d1-116af75af2be%40googlegroups.com.

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

[Brian Adkins]

On Tuesday, July 23, 2019 at 9:28:53 PM UTC-4, Alex Harsanyi wrote:
>
>
> On Wednesday, July 24, 2019 at 12:55:40 AM UTC+8, Greg Hendershott wrote:
>>
>> Although I'm still skeptical that changing the surface syntax will be a 
>> sufficiently big net gain, and ought to be the next, highest priority? 
>> I'm running with that idea for the following. 
>>
>
> I had a look at the proposals at 
> https://github.com/racket/racket2-rfcs/issues, and they seem reasonable 
> changes which, in my opinion, would improve the Racket language.  Most of 
> these changes, if they are implemented, would also allow a relatively easy 
> transition of existing Racket code.
>
> I can see only one proposal for changing the syntax and it is no more 
> radical than "#lang at-exp", which is already part of Racket, and seems to 
> be popular.
>
> On the other hand, anyone who is reading the posts on racket-users list, 
> would think that the Racket is a risky language to learn and use at this 
> time.  Perhaps it is time to stop the speculation and comment on the actual 
> proposals being made?
>
> Alex.
>

Alex:

Given that options being considered include converting official 
documentation over to the as-yet-to-be-defined new syntax and relegating 
#lang racket to a similar status as #lang mzscheme or #lang scheme, I don't 
think it's unreasonable to feel there is some risk as things stand 
*currently*. 

I expect more clarity to come which may reduce the risk, but it does seem 
like the majority of people who are downplaying the risk (or the perception 
of risk) are those in favor of the proposed changes. I suppose that's a 
natural response.

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/56faf557-a627-4856-b030-effca5700fee%40googlegroups.com.

[racket-users] Using errortrace with repl-driven-development?

[Anthony Quizon]

I've been trying to find a way to get better error messages in the racket 
repl via the command line.
Specifically, better stack traces. At the moment, if you load a file in the 
repl via ',enter' it doesn't give you any information about the line number 
for errors.

I've looked around in the users group but could only find:
racket -l errortrace -t .rkt

This is pretty much what I'm looking for except that it only lets me use 
this once and non-interactively. 

Is there an option in the (x)repl that lets me use errortrace interactively 
for each input?

-- 
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/ce5ec261-8e1e-4a24-b4bb-08f28cfae215%40googlegroups.com.

Re: [racket-users] Interoperability between Racket & Chez Scheme

[Matthew Flatt]

At Tue, 23 Jul 2019 18:08:46 -0700 (PDT), Brian Adkins wrote:
> For example, if I wrote a Chez Scheme library, how would I use that
> from w/in some Racket code I wrote?

After you get Chez Scheme's `eval`, you can do whatever you need at the
Chez Scheme level. That includes loading Chez Scheme libraries and
evaluating Chez Scheme expressions that produce functions. When you get
a function back from Chez Scheme's `eval`, you can call it from Racket.

Now that I think about it more, you'll have to take some care running
Chez Scheme functions from Racket, because there are lots of ways to
break Racket's assumptions at the Chez Scheme level. Perhaps the most
significant requirement that is you should call Chez Scheme functions
only under `call-with-system-wind` (which you'd have to get via
`get-primitive`), because Racket threads and exceptions do not by
default work with Chez Scheme's `dynamic-wind`.

There are probably other things to pin down, and some of it could be
packaged into a better FFI for calling Chez Scheme from 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/5d37b51e.1c69fb81.198ad.7a52SMTPIN_ADDED_MISSING%40gmr-mx.google.com.

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

[Alex Harsanyi]

On Wednesday, July 24, 2019 at 12:55:40 AM UTC+8, Greg Hendershott wrote:
>
> Although I'm still skeptical that changing the surface syntax will be a 
> sufficiently big net gain, and ought to be the next, highest priority? 
> I'm running with that idea for the following. 
>

I had a look at the proposals at 
https://github.com/racket/racket2-rfcs/issues, and they seem reasonable 
changes which, in my opinion, would improve the Racket language.  Most of 
these changes, if they are implemented, would also allow a relatively easy 
transition of existing Racket code.

I can see only one proposal for changing the syntax and it is no more 
radical than "#lang at-exp", which is already part of Racket, and seems to 
be popular.

On the other hand, anyone who is reading the posts on racket-users list, 
would think that the Racket is a risky language to learn and use at this 
time.  Perhaps it is time to stop the speculation and comment on the actual 
proposals being made?

Alex.

-- 
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/3aea6a05-1c10-4b70-b942-88583080f43d%40googlegroups.com.

Re: [racket-users] Interoperability between Racket & Chez Scheme

[Brian Adkins]

On Tuesday, July 23, 2019 at 8:52:36 PM UTC-4, Matthew Flatt wrote:
>
> At Tue, 23 Jul 2019 17:14:56 -0700 (PDT), Brian Adkins wrote: 
> > With the Racket on Chez Scheme implementation, how interoperable are 
> Racket 
> > and Chez? Is it possible for Racket functions to call Chez functions (or 
> > vice versa) directly w/o using a FFI? If so, can you point me to some 
> > documentation? If not, how difficult would it be to make this happen? 
>
> Chez Scheme functions work as Racket functions. A Racket function works 
> as a Chez Scheme function unless it accepts keyword arguments, is an 
> impersonator, or is an instance of a structure type that implemented 
> `prop:procedure`. 
>
> The easiest way to get a Chez Scheme primitive is to use the 
> `get-primitive` function from Sam's `get-primitive` package: 
>
>  https://github.com/samth/get-primitive 
>
>
> Racket pairs, symbols, etc., are Chez Scheme pairs, symbols, etc., so 
> you can get Chez Scheme's `eval` and easily start evaluating Chez 
> Scheme expressions. 
>

Thanks. I just realized I wasn't very clear. 

I was primarily referring to user defined functions. For example, if I 
wrote a Chez Scheme library, how would I use that from w/in some Racket 
code I wrote?

-- 
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/68ae09e0-7f39-41cd-9c44-77d222b560c0%40googlegroups.com.

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

[Brian Adkins]

On Tuesday, July 23, 2019 at 12:55:40 PM UTC-4, Greg Hendershott wrote:
>
> Although I'm still skeptical that changing the surface syntax will be a 
> sufficiently big net gain, and ought to be the next, highest priority? 
> I'm running with that idea for the following. 
>
> It seems like there are at least two "flavors" or "strengths", of giving 
> Racket a non-sexpr syntax someday: 
>
> 1. The new syntax will be a choice, fully co-equal with sexprs. Both are 
>"first class", "forever". Any great new Racket features work with 
>either. 
>
> 2. The new syntax will become the preferred syntax, used in 
>documentation and advocacy. ("Change the culture" is the phrase I 
>thought Matthew used initially -- but I welcome him 
>clarifying/correcting/revising.) Sexprs and #lang racket will get a 
>status that's not as weak as "deprecated", but not really as strong 
>as co-equal with the new syntax. 
>

Option #1 is the only viable option from a community perspective. And I 
think it will demonstrate the value of language oriented programming more 
clearly.

I chose Racket for many reasons, but one important reason was that the age 
of the language allowed me to examine the history of how the community 
operated over a *long* period of time to get an idea of what I might expect 
in the future. I didn't even consider languages that I felt were too young.

If anything other than option #1 is our course of action, then any 
(current, or hypothetical future) users would be right in assuming the 
possibility that sometime later, the new official language might also be 
deprecated for something very different than what they expect. This is how 
*not* to build a community.

I'm sure people disagree with this line of reasoning, and I respect your 
different perspective, but hopefully we can all at least agree that 
expectation management is important, and that expectations a currently a 
bit muddled.

If the core team and/or community wants something other than option #1, I 
would much prefer to know sooner rather than later. It would make me sad, 
disappointed, frustrated, etc., but I suppose I would then reluctantly take 
a cue to consider Chez Scheme given it was chosen by Racket people I 
respect to be their foundation, just as I considered (and eventually chose) 
Racket, via PLT Scheme, when I discovered Paul Graham chose it for the 
foundation of Arc (after he abandoned his language community).

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/e286c725-0f3e-4a94-ab89-589667d0cf3b%40googlegroups.com.

Re: [racket-users] Interoperability between Racket & Chez Scheme

[Matthew Flatt]

At Tue, 23 Jul 2019 17:14:56 -0700 (PDT), Brian Adkins wrote:
> With the Racket on Chez Scheme implementation, how interoperable are Racket 
> and Chez? Is it possible for Racket functions to call Chez functions (or 
> vice versa) directly w/o using a FFI? If so, can you point me to some 
> documentation? If not, how difficult would it be to make this happen?

Chez Scheme functions work as Racket functions. A Racket function works
as a Chez Scheme function unless it accepts keyword arguments, is an
impersonator, or is an instance of a structure type that implemented
`prop:procedure`.

The easiest way to get a Chez Scheme primitive is to use the
`get-primitive` function from Sam's `get-primitive` package:

 https://github.com/samth/get-primitive


Racket pairs, symbols, etc., are Chez Scheme pairs, symbols, etc., so
you can get Chez Scheme's `eval` and easily start evaluating Chez
Scheme expressions.

-- 
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/5d37abd2.1c69fb81.3c40d.2941SMTPIN_ADDED_MISSING%40gmr-mx.google.com.

Re: [racket-users] Re: Racket v7.3.0.900 is available for testing

[Matthew Flatt]

At Tue, 23 Jul 2019 17:47:35 -0700 (PDT), Alex Harsanyi wrote:
> I installed the windows version of the Racket CS build and, when trying to 
> run DrRacket I get the following error in a console:
> 
> variable force-unfasl is not bound

This is a build problem that we're investigating. Thanks for the
report!

> As a separate note, this pre-release build tries to install itself as 
> "Racket", which will replace the main Racket installation, I would prefer 
> if pre-release builds would install in versioned directories (i.e. 
> Racket-7.3.0.900), this was the case with past pre-releases.  I could tell 
> the installer to use a versioned directory though, so this is not a big 
> issue.

Snapshot installers suggest a version number for the installation
directory, but my memory of release candidates is that they don't
include a version in the default path for Windows, because they're
meant to act like a release. It's possible that I misremember they way
that we've configured things in the past, though.

-- 
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/5d37ab73.1c69fb81.81cad.0a8cSMTPIN_ADDED_MISSING%40gmr-mx.google.com.

[racket-users] Re: Racket v7.3.0.900 is available for testing

[Alex Harsanyi]

I installed the windows version of the Racket CS build and, when trying to 
run DrRacket I get the following error in a console:

variable force-unfasl is not bound
  context...:
   condition->exn
   body of data
   dynamic-wind
   body of data
   compiled-module->dh+h+data-instance+declaration-instance
   eval-module8
   standard-module-name-resolver
   module-path-index-resolve5
   namespace-module-instantiate!96
   for-loop
   for-loop
   run-module-instance!125
   perform-require!78
   namespace-require+
   #%for-each

I get the same error if I try to run racket.exe in a console.

As a separate note, this pre-release build tries to install itself as 
"Racket", which will replace the main Racket installation, I would prefer 
if pre-release builds would install in versioned directories (i.e. 
Racket-7.3.0.900), this was the case with past pre-releases.  I could tell 
the installer to use a versioned directory though, so this is not a big 
issue.

Alex.



On Tuesday, July 23, 2019 at 11:48:48 PM UTC+8, johnbclements wrote:
>
>Version 7.3.0.900 is now available for testing from 
>
>   https://pre-release.racket-lang.org/ 
>
> (Note that this is not available from the usual download site.) 
>
> If all goes well, we will turn this version into a v7.4 release 
> within a couple of weeks. 
>
> This release is the first one to include Chez-Scheme-based builds 
> (labeled “Racket CS” on the pre-release page), and we’d be interested in 
> hearing about any issues you encounter with these builds. 
>
> Your help and feedback in testing this new release candidate would be 
> much appreciated. 
>
>
>
>

-- 
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/99e25a5e-f6c2-4a6c-b97b-6f56e6fda856%40googlegroups.com.

[racket-users] Interoperability between Racket & Chez Scheme

[Brian Adkins]

With the Racket on Chez Scheme implementation, how interoperable are Racket 
and Chez? Is it possible for Racket functions to call Chez functions (or 
vice versa) directly w/o using a FFI? If so, can you point me to some 
documentation? If not, how difficult would it be to make this happen?

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/260df3d6-f6f8-4bec-a653-a3bef82ae6c9%40googlegroups.com.

[racket-users] On Fire and Brimstone, Gnashing of Teeth, and the Death of All that is Holy

[Michael Myers]

This is getting out of hand. There is a lot of misinformation swirling 
around, sparking a lot of unnecessary panic and misunderstanding.

Changing surface syntax, even for something as invasive as infix notation, 
is not synonymous with abandoning s-expressions.

Let me repeat this, for emphasis: changing the surface syntax, even to 
introduce infix notation, does *NOT* require abandoning s-expressions.

Let me assert a stronger point: even if, for the sake of calming people's 
nerves, we were to make the following restrictions:

   1. Racket2 cannot use any reader other than the standard racket reader.
   2. Racket2 is not even allowed to be a #lang, the most it can do is be 
   an optional (require racket2) after #lang racket/base.

...we could still significantly alter racket's surface syntax, even to 
introduce infix expressions.

Now, which of the following are real s-expressions?
x 
(+ x y)
(x + y)
x 
(+ x y)
(x + y)
'x
('x ,y '(x y z) ('x'y'z)(x,y,z))
(parse-sexpr '(f (x,y) = 2 x ^ 2 + 3 x - 4))
(#%parse f (x,y) = 2 x ^ 2 + 3 x - 4)
The answer, of course, is all of them.

In fact, the last one is a macro I use fairly often, though I tend to give 
it the shorter name $. 
Consider the following: 
https://github.com/mromyers/infix-syntax/blob/master/infix-syntax/test/core/base-test.rkt

Now, consider the following possible programs:

(def (abs x)(if (< x 0) (- x) x))

def abs(x) = if x < 0 then - x else x

def abs(x) = @(if (< x 0) (- x) x)

(def (abs x)($ if x < 0 then - x else x))

def sign(x) =
  @(cond [($ x > 0)  'positive]
 [($ x = 0)  'zero]
 [($ x < 0)  'negative])

If we treat $ as a macro that recursively parses its contents, and @ as a 
unary operator that treats the expression to its right as a normal 
s-expression, it is possible for all of the above to coexist with the 
standard racket reader, with nothing more invasive than a redefined #%app 
or #%module-begin.

An 's-expression' does not have an inherent order of evaluation associated 
with it. An 's-expression' does not have an inherent evaluation context, or 
namespace, or semantics associated with it. What mflatt is proposing isn't 
"abandoning s-expressions", it's just introducing some amount of parsing 
and interleaving into the process of expansion, in a flexible and 
extensible way, which doesn't even require modifying the expander in the 
slightest. It doesn't inherently require changing the reader. It doesn't 
inherently require changing anything about the syntax of fully-expanded 
programs. It's likely that the reader would be tweaked a bit in the 
process, but at the end of the day, 'read' will still turn strings into 
s-expressions.

If what you're worried about is that you won't be able to write programs 
that look the way you want, you have nothing to fear. With this approach, 
it is trivial to allow seamlessly switching between standard prefix style 
lisp, and infix expressions, even in the exact same program. In Honu, the 
equivalent of the @ operator above is a macro called racket_syntax. Now, 
granted, it's not 100% automatic that switching and interop between these 
will be painless and smooth. So the solution, if you're feeling scared, is 
not to panic, but to stick around, and voice your preference for such 
interoperability as a priority. Racket is a big tent, and so long as you're 
friendly and willing to express your needs and constraints in a civil 
manner, there's a lot of room to make something that appeals to many 
different sensibilities.

Lastly, if what you're worried about is that this somehow makes racket 'no 
longer a true lisp', whatever that means, have no fear. The techniques Honu 
uses are a development and refinement of techniques deeply tied to the 
history of Lisp, originally implemented as a similar, but less 
sophisticated reader macro for Maclisp. By sheer history it's lispier than 
lexical binding! If that's not enough, and you have some reservation about 
'losing homoiconicity' or somerthing, I'd recommend reading the following: 
http://calculist.org/blog/2012/04/17/homoiconicity-isnt-the-point/

-- 
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/25b3868f-41e2-43ff-afe8-d7c1c8a8253d%40googlegroups.com.

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

[Robby Findler]

On Tue, Jul 23, 2019 at 11:35 AM Thomas Dickerson
 wrote:
> Yes - the architecture we eventually settled on is a main submodule that does 
> roughly this to get a black-box value which we can pass back to a rendering 
> function to produce a gl-bitmap, and stick it in a snip.
>
> By the way - it seems you weren't the only person who doesn't use OpenGL very 
> often from Racket, because gl-bitmap had bit-rotted somewhat, compared to a 
> 'gl-styled canvas, but my PR got merged, and gl-bitmaps now support core 
> contexts.

Thank you!

Robby

-- 
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/CAL3TdOM9b90ojBpJZaS%3DpaFVZ6het6Nk54U-DXjn4L_2UZki8w%40mail.gmail.com.

[racket-users] Re: Racket2 possibilities

[Atlas Atlas]

My personal big wish is "standard library" consistency and futures(like 
more extended date-time functions).

Another big wish is typed system. Typed racket looks like a BIG step 
forward, and gives real benefits, it is shame it have not so much support.

Another wish is more fluid transition between typed and untyped code. For 
now it feels painful.

-- 
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/248536cd-bce7-4a49-ba29-f6a26de68459%40googlegroups.com.

Re: [racket-users] Scribble timing

[Hendrik Boom]

On Thu, Jul 18, 2019 at 12:25:22PM -0600, Matthew Flatt wrote:
> > At Thu, 18 Jul 2019 12:28:53 -0400, Hendrik Boom wrote:
> > > Did some measurements.
> > > 
> > > 800K of text, represented as 80 scribble files each of 10K bytes,
> > > each included using @include-section from one file:
> > >   7 seconds.
> > > 
> > > 800K of text, represented as one scribble file (the concatenation of
> > > the 80 files used above):
> > >   4 minutes and 29 seconds.
> > > 
> > > Not immediately prohibitive, but it's painful to repeatedly make a 
> > > correction in scribble source, recompile, and view the result of the 
> > > change in an interactive session.
> 
> I've pushed a repair that corrects the kind of behavior illustrated
> above, at least for my own example. I think there's a good chance that
> it will correct performance for your specific example. (The repair is
> pushed to the development repo, so it should be available in the next
> round of snapshots in a little under 24 hours from now).

New timing, using the snapshot I downloaded and installed today, 
racket-7.4.0.1-x86_64-linux-precise.sh

80 scribble files of 10K each: one or two seconds
One 800K file: four or five seconds

Much improved, even for the many smaller files case.

Thank you.

-- 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/20190723190153.avifginlgz6pdyze%40topoi.pooq.com.

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] The case, and a proposal, for elegant syntax in #lang racket2

[Arie Schlesinger]

Hi,
I would appreciate any advice  with combining and using Racket and Jupyter
Notebook, if somebody has used these two.
Thanks,
Arie

On Sun, Jul 21, 2019 at 3:58 PM Matthew Flatt  wrote:

> At Fri, 19 Jul 2019 08:54:41 -0700 (PDT), Brian Adkins wrote:
> > This may seem like a nitpick, but I think there would be a *huge* shift
> in
> > attitudes if the suggestion for an infix syntax was framed in a similar
> > manner to Typed Racket as opposed to Racket 2. The latter seems to imply
> a
> > premature conclusion, where the former proposes a question to be
> answered
> > by the community i.e. if people do flock to #lang infix, then the people
> > will have spoken. Let #lang infix win by merit, not by decree!
>
> I agree that the process would have to be something like that. Compared
> to projects like Typed Racket, a syntax change in Racket2 probably
> requires more people. Also, Typed Racket took on the design constraint
> that it should fit Racket as-is as much as possible, while a syntax
> change would come with more expectation of migration. It's maybe just a
> difference of degree, though.
>
> --
> 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/5d34617a.1c69fb81.383c7.0155SMTPIN_ADDED_MISSING%40gmr-mx.google.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/CAMJd8C5E0HnN-b8QE6QtC4aOx%3DWLq-VOovyN1LHa4o8GvRMzpg%40mail.gmail.com.

[racket-users] Message in the meantime?

[Greg Hendershott]

Although I'm still skeptical that changing the surface syntax will be a
sufficiently big net gain, and ought to be the next, highest priority?
I'm running with that idea for the following.

It seems like there are at least two "flavors" or "strengths", of giving
Racket a non-sexpr syntax someday:

1. The new syntax will be a choice, fully co-equal with sexprs. Both are
   "first class", "forever". Any great new Racket features work with
   either.

2. The new syntax will become the preferred syntax, used in
   documentation and advocacy. ("Change the culture" is the phrase I
   thought Matthew used initially -- but I welcome him
   clarifying/correcting/revising.) Sexprs and #lang racket will get a
   status that's not as weak as "deprecated", but not really as strong
   as co-equal with the new syntax.

Regardless of how it might turn out, years from now -- it seems to me
there are some pretty big gotchas with the latter choice in the
meantime. Especially for "advocacy" or "marketing" during the N years
until the new thing is ready.

TL;DR: How would we promote Racket in the meantime??

Example worry: Something similar to an "Osborne Effect".

- Effectively we'd be telling not-yet users, "You're right not to like
  sexprs! Go away and come back in N years after we've fixed that flaw."
  We're "validating the objection" -- justifying any inclination not
  even to try Racket, yet, despite everything it offers, already.

- As for existing users, they might hear, "Yes, some of you might not
  like this change. Or even if you don't hate it, might be disappointed
  we're changing that instead of doing something else you feel is a
  higher priority. We realize we might lose some of you. But we feel we
  have so little to lose, it's worth that risk." So, yeah. Effectively
  telling existing users they're "little to lose" isn't great. (Even if
  that's not the intent, that's what some people will hear/feel. There
  will be somewhat greater attrition.)

- During the years' wait, who would invest time doing more tutorials and
  books and advocacy, using the old syntax? Some might. Many would say,
  why bother; I'll wait.

In short, it seems like the "strong" version would freeze advocacy and
adoption during the N year transition.

Whereas I think something like the first version -- fully co-equal
syntaxes -- would be easier to talk about and minimize short-term harm.

---

Ignoring the implementation difficulty (which I realize is a ridiculous
thing to ignore, but just for a thought experiment): I've seen some SDK
or API docs with a "choose your language" UI that changes function
signatures and code examples.

- Could there be some reasonably good mechanical two-way enforestation /
  deforestation? Maybe I'm misusing those terms. I mean, convert
  documentation between the two syntaxes, on the fly.

- Even better, could this work well enough not just to display usable
  documentation, but to transform actual source code? (I don't know if
  this would need to impose something like the Go printer, to "enforce"
  coding styles, for acceptable round trips. I don't even know if that
  would be unfortunate or fortunate.)

If any of this is feasible, then talking about it now and during the
long wait, would help send a more positive message:

People could keep on keeping on, knowing that someday there will be
tools to help them convert (or not convert, as they wish). As opposed to
worrying they're investing time on something scheduled for cultural
deprecation.

---

Again, I'm still skeptical whether new syntax is the most effective,
highest priority. At the same time, I'm trying to contribute
constructively to refining that plan, in case it is chosen. In
particular I'm concerned about what happens to the community in the
meantime.

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

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

[Thomas Dickerson]

On Tuesday, July 23, 2019 at 12:35:27 PM UTC-4, Thomas Dickerson wrote:
>
>
> Yes - the architecture we eventually settled on is a main submodule that 
> does roughly this to get a black-box value which we can pass back to a 
> rendering function to produce a gl-bitmap, and stick it in a snip.
>

Sorry for the double email, but for posterity I want to be slightly more 
specific here: our main submodule uses dynamic-require for all of the 
graphics/rendering functionality, to avoid saddling our embedded Racket 
used by C++ applications with extra dependencies.

-- 
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/a9a2868d-a3c8-475e-9968-1a6c57db0e5b%40googlegroups.com.

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

[Thomas Dickerson]

On Tuesday, July 23, 2019 at 2:34:47 AM UTC-4, Robby Findler wrote:
>
> Sorry for letting this thread lapse. Wrt to your third option 
> mentioned below, would it work to make that option accessible via the 
> FFI? If so, then maybe you could make the "essentially phase shifted 
> everything" into "actually phase shifted everything" and then when you 
> get the result program have your #%module-begin call into the FFI to 
> actually run the program. Does that seem like a viable option? 
>

Yes - the architecture we eventually settled on is a main submodule that 
does roughly this to get a black-box value which we can pass back to a 
rendering function to produce a gl-bitmap, and stick it in a snip.

By the way - it seems you weren't the only person who doesn't use OpenGL 
very often from Racket, because gl-bitmap had bit-rotted somewhat, compared 
to a 'gl-styled canvas, but my PR got merged, and gl-bitmaps now support 
core contexts.

-- 
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/48abec2f-ff48-4360-ab8d-7115056d349e%40googlegroups.com.

Re: [racket-users] Re: Racket2 possibilities

[Thomas Dickerson]

A couple thoughts, not particularly well-organized, but in a more 
accessible form here than just tweeting at Alexis.

In all this discussion of "parens-less LISP", I find it slightly odd that 
nobody has mentioned Logo yet. I'm ambivalent about surface syntax, but 
it's not like this is a revolutionary idea.

Since people are talking about running on different "VM" architectures, an 
LLVM backend would be lovely and gives WebAssembly for free.
JVM support, on the other hand, seems like a particularly poor time 
investment, since (1) there is no shortage of options for functional 
programmers, and (2) the only real advantage of running on JVM is if you 
can provide interoperability with the massive Java ecosystem, but that's 
essentially incompatible with working around the JVM's bad architectural 
decisions.
The elephant in the room for any Scheme running on the JVM is that (a) 
cross-function tail call elimination is incompatible with the security 
model; (b) trampolining everything is bad for performance and, more 
importantly, makes interoperability miserable (have fun writing all your 
Java code that calls Racket code in manual CPS-style); and (c) throwing 
everything into a massive state machine while-loop with gotos is both a 
static analysis nightmare and breaks the JIT optimizer due to single-method 
bytecode size restrictions.

As someone who loves the Racket philosophy and 
language-oriented-programming, but who is also very interested in building 
large-scale practical systems, the single biggest obstacle to me using 
Racket over other functional languages (mostly Scala/Dotty) for personal 
projects is the lack of static typing (Typed Racket feels very much like a 
second-class citizen in the ecosystem).
My deepest dream would be for Racket2 to have static type-checking as the 
default, with opt-in Rust-like affine types for programs that need precise 
resource management.
Essentially any other outcome is "fine, I guess".

-- 
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/0e71f4c5-da98-4fcc-aed9-03a2bd547994%40googlegroups.com.

Re: [racket-users] define/contract for private functions

[Bogdan Popa]

> When I want to enable these private contracts (e.g. when running tests or
> debugging a problem) I simply change the source code of `def/c` so that it
> is wired up to `define/contract` and the contract is checked. Here is an
> example: http://pasterack.org/pastes/4224

You can run arbitrary code in macros so you could use environment
variables to achieve this.  For example:

(define-syntax-rule (def/c head contract body ...)
  (if (getenv "PRIVATE_CONTRACTS")
(define/contract head contract body ...)
(define head body ...)))

And then run your code with

env PRIVATE_CONTRACTS=x racket some-module.rkt

The drawbacks to this approach is it makes compilation significantly
slower and, once code is compiled (via raco setup, raco make or raco pkg
install), the flag stops having any effect -- the code is compiled
according to whatever the environment looks like at compile time and
then maintains that behavior until it is recompiled.

-- 
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/m2r26gk9oa.fsf%40192.168.0.139.

[racket-users] define/contract for private functions

[Ryan Kramer]

I've found myself wanting to write contracts on private functions, but I 
don't want to pay the performance cost during normal operation. What I've 
been doing is making a `def/c` macro which looks exactly like 
`define/contract` but is wired up to `define` and discards the contract. 
When I want to enable these private contracts (e.g. when running tests or 
debugging a problem) I simply change the source code of `def/c` so that it 
is wired up to `define/contract` and the contract is checked. Here is an 
example: http://pasterack.org/pastes/4224

Manually changing the source code of `def/c` has worked fine so far, but I 
would love to be able to do something like "raco test 
-with-private-contracts (package1, package2) ./" instead.

I prefer this approach over putting the contracts in comments, because 
comments have less precise meaning and may become subtly inaccurate if the 
implementation of the function changes.

I wonder if other people want to write code the same way. If so, having a 
standard, shared `define/contract/private` could be useful. This would 
allow us to do things like
1) Build a contract-aware linter.
2) Build a "minimally intrusive type system." (This might also be called a 
"linter"; I'm not sure if there is a definite line separating the two.)
3) Better IDE support
4) If I suspect a package I am using has a bug, I might be able to confirm 
(but not deny) that suspicion by turning on private contracts for that 
package and seeing if a violation is reported.

So I guess if I'm the only one interested in this then just ignore me. If 
there's already work in this area, great! Please point me to it. But if 
there's interest and a need, I'd be happy to help however I can.

-- 
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/5e8ece69-bbb7-4dbf-933f-52cc097291d2%40googlegroups.com.

Re: [racket-users] Scribble reinstallation

[Hendrik Boom]

On Mon, Jul 22, 2019 at 09:25:35PM -0400, Ben Greenman wrote:
> You should be able to keep the current Racket,
> download a snapshot build,
> and run the `/bin/drracket` inside the snapshot
> 
> https://www.cs.utah.edu/plt/snapshots/

So I would install one of the snapshots and use it instead of my 
installed Devuan package.  And that presumably means I won't need the 
Devuan package and can urge it.

Assuming of course that the Ubuntu build is comatible with my system.

Which I'll find out by trying it.

-- 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/CAFUu9R7mnyoeUwP%2B%3DmAFDJv%2BgCZ_OQ7UHDDA80zErrSo_mzQGw%40mail.gmail.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/20190723160507.3rgiimrp7vtuxocu%40topoi.pooq.com.

[racket-users] Racket v7.3.0.900 is available for testing

['John Clements' via Racket Users]

Version 7.3.0.900 is now available for testing from

  https://pre-release.racket-lang.org/

(Note that this is not available from the usual download site.)

If all goes well, we will turn this version into a v7.4 release
within a couple of weeks.

This release is the first one to include Chez-Scheme-based builds (labeled 
“Racket CS” on the pre-release page), and we’d be interested in hearing about 
any issues you encounter with these builds.

Your help and feedback in testing this new release candidate would be
much appreciated.



-- 
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/088c5255-2375-483a-8fe7-494528e24876%40mtasv.net.

Re: [racket-users] https://github.com/racket/racket2-rfcs/blob/master/prior-art.md

[Annaia Berry]

Thanks, will look into doing that when I get home maybe.

As for Heresy2, it's not off the cards, but I kinda want to see how the
Racket version shakes out because I might just be duplicating effort for
something that won't actually be very fun for me. We'll see what happens.

On Tue, Jul 23, 2019 at 1:33 PM Stephen De Gabrielle <
spdegabrie...@gmail.com> wrote:

> No problem :)
>
> > Not sure where to submit this to that list,
>
> Just submit a PR - that’s what I did.(I’m not in the Racket team - I just
> submitted a PR and it was quickly approved by a member of
>
> There are many relevant issues, but maybe this one in the first instance;
> https://github.com/racket/racket2-rfcs/issues/14
>
> Please don’t let the discussions about Racket2 put you off working on
> ‘Heresy2’ :(
>
> Kind regards
> Stephen
>
>
> On Tue, 23 Jul 2019 at 10:01, Annaia Berry  wrote:
>
>> Forgot to send this to the actual list (sorry Stephen!).
>>
>> Some other thoughts that come to mind are WebAssembly, which has an
>> S-expr syntax but is targeted by lots of different non-Lisp langs. As well
>> I think GCC at least used to have some internal S-expr-like intermediate
>> forms for ASTs.
>>
>> I had plans for a "Heresy2" but ... given the controversy (and more
>> seriously, the extensive writing over the last week about the challenges of
>> making the switch), I think I might put a pin in that ...
>>
>> -- Forwarded message -
>> From: Annaia Berry 
>> Date: Tue, Jul 23, 2019 at 11:55 AM
>> Subject: Re: [racket-users]
>> https://github.com/racket/racket2-rfcs/blob/master/prior-art.md
>> To: Stephen De Gabrielle 
>>
>>
>> Not sure where to submit this to that list, but Heresy contains a few
>> infix forms. The m-block math syntax, and the do notation syntax, both use
>> infix expressions.
>>
>> Monad/do notation is here:
>> https://docs.racket-lang.org/heresy/monad-do.html
>>
>> M-blocks are still somewhat undocumented but you can find some examples
>> in the tests:
>> https://github.com/jarcane/heresy/blob/master/tests/infix-math.rkt
>>
>>
>> On Mon, Jul 22, 2019 at 10:31 PM Stephen De Gabrielle <
>> spdegabrie...@gmail.com> wrote:
>>
>>> FYI
>>>
>>> https://github.com/racket/racket2-rfcs/blob/master/prior-art.md
>>>
>>> --
>>> 
>>>
>>> --
>>> 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/CAGHj7-LKb%3DbbYw7HEOSpDhkQgj8ePZcyksOJyguBwqeM6Y32jA%40mail.gmail.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/CA%2BHVF0AM2eDwfOifY_Y8%2B08CDxG_6LOb_cifQBQY%2BQSTq9xe-A%40mail.gmail.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/CA%2BHVF0A%3DP3%3Db9HvjQGr8FkaDHq2MA5XScJufpaS4fkTSSMUFww%40mail.gmail.com.

Re: [racket-users] Re: Racket2 possibilities

[Dexter Lagan]

  The second comment by slaymaker1907 is more progressive and closer to the 
truth no doubt. I merely meant to say that it does feel odd to take off parens 
off such a great scheme/lisp. But if there’s an elegant way to do it while 
maintaining all its power AND making it more approachable, all the better. If 
we could have the best of both worlds, Racket could appeal to a much wider 
audience.

  Like others have said, it also takes time for people to understand the 
potential, like it took me years to warm up to the idea of lisp in general, and 
months before I began really seeing a difference in my projects after picking 
Racket up. No matter what the outcome, this is exciting. 

  Simply contemplating the prospect of the evolution of such a powerful 
abstraction tool is exciting, and inspiring.

Dex

> On Jul 23, 2019, at 3:21 PM, Neil Van Dyke  wrote:
> 
> 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.

-- 
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/CD94ED47-9423-4348-9F97-560C4B9DAF69%40gmail.com.

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] https://github.com/racket/racket2-rfcs/blob/master/prior-art.md

[Stephen De Gabrielle]

No problem :)

> Not sure where to submit this to that list,

Just submit a PR - that’s what I did.(I’m not in the Racket team - I just
submitted a PR and it was quickly approved by a member of

There are many relevant issues, but maybe this one in the first instance;
https://github.com/racket/racket2-rfcs/issues/14

Please don’t let the discussions about Racket2 put you off working on
‘Heresy2’ :(

Kind regards
Stephen


On Tue, 23 Jul 2019 at 10:01, Annaia Berry  wrote:

> Forgot to send this to the actual list (sorry Stephen!).
>
> Some other thoughts that come to mind are WebAssembly, which has an S-expr
> syntax but is targeted by lots of different non-Lisp langs. As well I think
> GCC at least used to have some internal S-expr-like intermediate forms for
> ASTs.
>
> I had plans for a "Heresy2" but ... given the controversy (and more
> seriously, the extensive writing over the last week about the challenges of
> making the switch), I think I might put a pin in that ...
>
> -- Forwarded message -
> From: Annaia Berry 
> Date: Tue, Jul 23, 2019 at 11:55 AM
> Subject: Re: [racket-users]
> https://github.com/racket/racket2-rfcs/blob/master/prior-art.md
> To: Stephen De Gabrielle 
>
>
> Not sure where to submit this to that list, but Heresy contains a few
> infix forms. The m-block math syntax, and the do notation syntax, both use
> infix expressions.
>
> Monad/do notation is here:
> https://docs.racket-lang.org/heresy/monad-do.html
>
> M-blocks are still somewhat undocumented but you can find some examples in
> the tests:
> https://github.com/jarcane/heresy/blob/master/tests/infix-math.rkt
>
>
> On Mon, Jul 22, 2019 at 10:31 PM Stephen De Gabrielle <
> spdegabrie...@gmail.com> wrote:
>
>> FYI
>>
>> https://github.com/racket/racket2-rfcs/blob/master/prior-art.md
>>
>> --
>> 
>>
>> --
>> 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/CAGHj7-LKb%3DbbYw7HEOSpDhkQgj8ePZcyksOJyguBwqeM6Y32jA%40mail.gmail.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/CA%2BHVF0AM2eDwfOifY_Y8%2B08CDxG_6LOb_cifQBQY%2BQSTq9xe-A%40mail.gmail.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/CAGHj7-%2BCQ-to478WFScBJyR0MtZmostqxh_dCmc374W9Eeubhg%40mail.gmail.com.

Fwd: [racket-users] https://github.com/racket/racket2-rfcs/blob/master/prior-art.md

[Annaia Berry]

Forgot to send this to the actual list (sorry Stephen!).

Some other thoughts that come to mind are WebAssembly, which has an S-expr
syntax but is targeted by lots of different non-Lisp langs. As well I think
GCC at least used to have some internal S-expr-like intermediate forms for
ASTs.

I had plans for a "Heresy2" but ... given the controversy (and more
seriously, the extensive writing over the last week about the challenges of
making the switch), I think I might put a pin in that ...

-- Forwarded message -
From: Annaia Berry 
Date: Tue, Jul 23, 2019 at 11:55 AM
Subject: Re: [racket-users]
https://github.com/racket/racket2-rfcs/blob/master/prior-art.md
To: Stephen De Gabrielle 


Not sure where to submit this to that list, but Heresy contains a few infix
forms. The m-block math syntax, and the do notation syntax, both use infix
expressions.

Monad/do notation is here: https://docs.racket-lang.org/heresy/monad-do.html

M-blocks are still somewhat undocumented but you can find some examples in
the tests:
https://github.com/jarcane/heresy/blob/master/tests/infix-math.rkt


On Mon, Jul 22, 2019 at 10:31 PM Stephen De Gabrielle <
spdegabrie...@gmail.com> wrote:

> FYI
>
> https://github.com/racket/racket2-rfcs/blob/master/prior-art.md
>
> --
> 
>
> --
> 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/CAGHj7-LKb%3DbbYw7HEOSpDhkQgj8ePZcyksOJyguBwqeM6Y32jA%40mail.gmail.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/CA%2BHVF0AM2eDwfOifY_Y8%2B08CDxG_6LOb_cifQBQY%2BQSTq9xe-A%40mail.gmail.com.

Re: [racket-users] Re: Racket2 possibilities

[Paulo Matos]

On 22/07/2019 22:42, Breck Yunits wrote:
> Aloha folks,
>
> I had to miss RacketCon this year as we have a new 6 month old at home
> and couldn't make the trek out.
>
> But I would love to lend my efforts to support the initiative to
> explore a Racket universe without parens. If folks out there are
> working on this, shoot me an email (bre...@gmail.com or
> yun...@hawaii.edu) and let me know how I can best help.
>
> I've been working on such a research effort since 2012. I call the
> notation Tree Notation http://treenotation.org/. Basically what I
> propose is splitting things up into 2 concepts: the base Tree Notation
> (which is 80% similar to I-Expressions), and then languages on top of
> that (which is where the #lang could come in).
>
> This syntax is less fragile
> (https://twitter.com/breckyunits/status/1153016840769007616) and makes
> 3 things much easier: program synthesis, data science, and visual
> programming.
>
> I think dropping parens would make a big difference and would be a
> great move for "Racket2"!
>
Thanks for the reference to your tree notation work.

Discussion is proceeding at a breath-taking pace. You might want to
enable notifications ('Watch') for
https://github.com/racket/racket2-rfcs, or you might not depending if
you want your like consumed by the #racket2 hash tag. ;)


> -Breck
>
>
>
> On Saturday, July 20, 2019 at 8:49:13 AM UTC-10, Matthew Flatt wrote:
>
> This message is intended as a prose form of what I said at RacketCon,
> but it includes some extra explanation triggered by the discussion so
> far. Where that happens, I apologize that it isn't in the form of a
> more direct response in the original thread.
>
> The Racket2 Idea
> 
>
> Racket's design and implementation is on solid ground, and from this
> point, it can continue to evolve and improve in many ways. No matter
> how Racket evolves, the community is committed to preserving what we
> have achieved: today's `#lang racket` programs will run in the
> future,
> and today's `#lang racket` modules can be used in future Racket
> programs. At the same time, the current language design may be
> close to
> a local maximum, and it's not in the nature of the Racket
> community to
> be satisfied with a local maximum.
>
> By starting all programs with `#lang`, we have created a path to leap
> from one peak of design to a different, higher peak without
> sacrificing
> the old one and while staying Rackety. Roughly, that's what we
> mean by
> "Racket2". The name "Racket2" stands for some language that builds on
> the current Racket technology and implementation, but that may not
> directly accommodate the same bindings and expression forms that
> appear
> in the body of a `#lang racket` module.
>
> Although we could literally write `#lang racket2` for modules in the
> new language, "Racket2" is normally understood as a placeholder for a
> more distinct name. As a matter of branding, perhaps the language
> would
> be called "Racket X" for some good X --- shortened to "X" in some
> contexts --- and Racket X program would be written with `#lang X`
> line
> at the top. Maybe the name depends on how different Racket2 turns out
> to be from Racket, so it makes sense to pick a name later.
>
> Venturing out from Racket's current peak opens a large space of
> possibilities, so the first step is to agree on a set of goals to be
> met by the next peak. The goals can serve as a starting point for
> developing roadmap for deciding on technical details in a follow-up
> process.
>
> Possible Language Changes
> -
>
> The Racket community has long discussed possibilities for Racket2.
> Here
> are a few potential changes from the wish list:
>
> * Rename functions to make the conventions more uniform, and make
>   better use of keyword arguments to reduce names and increase
>   consistency.
>
> * Change structures types to have more or fewer features.
>
> * Use generic datatypes (such as streams) pervasively, instead of
>   writing code that expects a particular concrete representation
> (such
>   as lists).
>
> * Make strings immutable by default (e.g., result of `format` or
>   `string-append`).
>
> * Adjust the semantics of common syntax forms, such as raising an
> error
>   on fall-through for `cond` or `match`, and change the meaning of
> some
>   primitives, such as making `integer?` mean "exact integer".
>
> * Make pattern matching more pervasive and available by default.
>
> * Change module, evaluation, and loading callbacks (e.g., protocol
> for
>   `current-module-name-resolver`) to improve errors and
> extensibility.
>
> More changes have been suggested, and no doubt many other changes
> would
> make sense. As a first 

Re: [racket-users] Directory-specific installation of packages?

[Tom Gillespie]

I have periodically investigated installing racket packages via gentoo in a
dev-racket/package way that matches how python packages are installed (a
far saner experience than any of python's native packaging tools). I always
hit roadblocks because raco wants to hit an sqlite database that is outside
the build sandbox. I usually attempt to do this via raco, but perhaps there
are other ways, which might apply in this case as well. If your colleagues
just need the compiled program and do not need the underlying code, why not
use raco exe and distribute the standalone binary? Best,
Tom

On Tue, Jul 23, 2019 at 12:17 AM Stephen De Gabrielle <
spdegabrie...@gmail.com> wrote:

> Hi James
>
> Did you have any luck with using homebrew to package and distribute your
> Racket program?
>
> I thought Bottles might be the way to go but I’m not sure:
> https://docs.brew.sh/Bottles
>
> I have two ideas
> a) add installing racket from homebrew to a bash script that launches your
> prog
> b) using the create executable function in DrRacket (or raco) to build a
> stand-alone version that can be modified to distribute via homebrew
>
> Kind regards
>
> Stephen
>
> PS I think this is a great idea that I’m sure others will use.
>
> On Mon, 22 Jul 2019  at 14:05, James Geddes 
> wrote:
>
>> Dear All,
>>
>> For reasons (explained below, possibly foolish reasons) I am trying to do
>> the following:
>>
>> 1. Have `raco pkg install` install a package X to a specific directory,
>> including, in the same directory, all of the dependencies of X, but
>> excluding those dependencies that are already present in the current
>> installation's collections; and
>>
>> 2. Have `raco exe myprok.rkt` look in that custom directory for `(require
>> X)`?
>>
>> I tried the `--scope-dir` option to `raco pkg install` but that installed
>> what looks like the entire racket standard library (see below).
>>
>> Many thanks,
>>
>> James
>>
>>
>>
>> PS. What I'm /really/ trying to do is distribute a little command-line
>> programme that I wrote in Racket to my colleagues using the homebrew
>> package manager. My programme depends on the gregor library.
>>
>> Most of my colleagues don't have Racket. Homebrew likes to compile from
>> source, so I will need to have homebrew download the dependencies I need
>> for compilation. But now, homebrew really doesn't like you to write outside
>> a very small set of directories during the installation process, and those
>> don't appear to include the standard Racket collections directories.
>>
>> (I could well have misunderstood this. I don't understand at all how
>> homebrew interacts with language-specific package managers like raco, pip,
>> cabal, and so on. My sense is that the non-raco ones install dependencies
>> in project-specific directories and I suspect homebrew has specific support
>> for Python libraries.)
>>
>> Anyway, my program depends on the gregor library, so I tried this:
>>
>> $ raco pkg install --scope-dir tmp gregor-lib
>>
>> $ ls tmp
>>
>> 2d-lib pict-doc
>> at-exp-lib pict-lib
>> base   pict-snip-lib
>> cext-lib   pkgs.rktd
>> class-iop-lib  plai-lib
>> cldr-bcp47 planet-doc
>> :
>> [ ~100 rows omitted]
>> :
>> net-docweb-server-doc
>> net-libweb-server-lib
>> option-contract-libwxme-lib
>> parser-tools-doc   xrepl
>> parser-tools-lib   xrepl-doc
>> pconvert-lib   xrepl-lib
>> pict   zo-lib
>>
>>
>>
>>
>>
>>
>> --
>> 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/2C6D9102-2F63-4A0E-A033-C7FECC5F9CF8%40gmail.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/CAGHj7-%2BqQLRNVf3_EntEsyS8uYofgHo3DMz_%2B0WdFMuN7uk0cw%40mail.gmail.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/CA%2BG3_PMrh%3D%2BJhYgxoy9nm5%3DhUFpw7GhYxbNC5qovvWt3xZa%2B9g%40mail.gmail.com.

Re: [racket-users] Re: Racket2 possibilities

[Dexter Lagan]

  Agreed, parentheses make manipulating code blocks a breeze. Also, I just 
realized I had confused Crystal with Julia in my initial rant. Made a fool of 
myself (again). I played with Julia when it reached 1.0 and liked the no-parens 
yet functional approach. It felt like a lisp in disguise, a bit like Python, 
but much cleaner. What I initially meant to say, apologies to Mr. King, is that 
a parent-less Racket2 would remind me of Julia. On the surface, at least! 
Crystal does have macros but that’s all it has in common with Julia and Racket.

  I did read the Honu paper and I agree: if there’s a way to transition, that’d 
be a very elegant one. Parentheses absolutely are a barrier of entry, and this 
would go a long way to make Racket less intimidating to non-lisp users. But is 
it worth the effort? Like the first HN comment said, ‘best way to break a good 
lisp is removing the parentheses’. I don’t think it’s that black, but 
there’s certainly some truth there.

Dex

> On Jul 23, 2019, at 12:17 AM, Zelphir Kaltstahl  
> wrote:
> 
> I just want to give one thought as input to this discussion and will admit, 
> that I did not read every (but some) of the posts above.
> 
> When I write code in Racket or Scheme, I mostly like the parentheses, as they 
> make writing the code easy. I can very easily select a block and move it 
> around, without introducing any syntax errors. I can also quickly see what 
> the scope of something is, what other expression it is in. I don't get these 
> things from languages without this many parentheses or without s-expression 
> syntax. I need my parentheses as markers for my cursor to quickly jump 
> around. It is the most pleasant code typing experience I've ever had. So when 
> considering to move away from parentheses, please also consider the burden 
> that those parentheses take away from the person writing the code. When I 
> edit for example Python code, things are not clear when moving around code. 
> This is worse in Python than in other languages, which at least have curly 
> braces (but usually some other annoying deficiencies). If there was a move 
> away from this many parentheses (read markers for my cursor), it would have 
> to provide equal editability, for it to be attractive to me. A design based 
> on indentation or something like that is not going to cut it for me. And what 
> else would be used as start and end markers for expressions? Wouldn't that in 
> essence just be another form of "parentheses", just looking different? How 
> would any editor know, where an expression starts and ends for easy selection 
> and moving around, if there were no such markers? So far I got no idea how 
> that could be done without introducing loads of new constraints about how you 
> can nest expressions into the language. So it beats me. Maybe my imagination 
> in this area is still somewhat limited.
> 
> Just my 2c.
> -- 
> 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/bf0b5dd1-8802-4c78-af7a-4231ae30ad60%40googlegroups.com.

-- 
You received this message because you are subscribed to the Google Groups 
"Racket Users" group.
To unsubscribe from this group and stop receiving emails from it, send an email 
to racket-users+unsubscr...@googlegroups.com.
To view this discussion on the web visit 
https://groups.google.com/d/msgid/racket-users/6994654B-255A-4A0A-AF63-2702EFD67B75%40gmail.com.

Re: [racket-users] Directory-specific installation of packages?

[Stephen De Gabrielle]

Hi James

Did you have any luck with using homebrew to package and distribute your
Racket program?

I thought Bottles might be the way to go but I’m not sure:
https://docs.brew.sh/Bottles

I have two ideas
a) add installing racket from homebrew to a bash script that launches your
prog
b) using the create executable function in DrRacket (or raco) to build a
stand-alone version that can be modified to distribute via homebrew

Kind regards

Stephen

PS I think this is a great idea that I’m sure others will use.

On Mon, 22 Jul 2019  at 14:05, James Geddes  wrote:

> Dear All,
>
> For reasons (explained below, possibly foolish reasons) I am trying to do
> the following:
>
> 1. Have `raco pkg install` install a package X to a specific directory,
> including, in the same directory, all of the dependencies of X, but
> excluding those dependencies that are already present in the current
> installation's collections; and
>
> 2. Have `raco exe myprok.rkt` look in that custom directory for `(require
> X)`?
>
> I tried the `--scope-dir` option to `raco pkg install` but that installed
> what looks like the entire racket standard library (see below).
>
> Many thanks,
>
> James
>
>
>
> PS. What I'm /really/ trying to do is distribute a little command-line
> programme that I wrote in Racket to my colleagues using the homebrew
> package manager. My programme depends on the gregor library.
>
> Most of my colleagues don't have Racket. Homebrew likes to compile from
> source, so I will need to have homebrew download the dependencies I need
> for compilation. But now, homebrew really doesn't like you to write outside
> a very small set of directories during the installation process, and those
> don't appear to include the standard Racket collections directories.
>
> (I could well have misunderstood this. I don't understand at all how
> homebrew interacts with language-specific package managers like raco, pip,
> cabal, and so on. My sense is that the non-raco ones install dependencies
> in project-specific directories and I suspect homebrew has specific support
> for Python libraries.)
>
> Anyway, my program depends on the gregor library, so I tried this:
>
> $ raco pkg install --scope-dir tmp gregor-lib
>
> $ ls tmp
>
> 2d-lib pict-doc
> at-exp-lib pict-lib
> base   pict-snip-lib
> cext-lib   pkgs.rktd
> class-iop-lib  plai-lib
> cldr-bcp47 planet-doc
> :
> [ ~100 rows omitted]
> :
> net-docweb-server-doc
> net-libweb-server-lib
> option-contract-libwxme-lib
> parser-tools-doc   xrepl
> parser-tools-lib   xrepl-doc
> pconvert-lib   xrepl-lib
> pict   zo-lib
>
>
>
>
>
>
> --
> 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/2C6D9102-2F63-4A0E-A033-C7FECC5F9CF8%40gmail.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/CAGHj7-%2BqQLRNVf3_EntEsyS8uYofgHo3DMz_%2B0WdFMuN7uk0cw%40mail.gmail.com.

Re: [racket-users] Racket2 possibilities

[Samuel Ainsworth]

As a former Racket user but not a current member of the Racket community, I 
thought I might toss in my 2c. My reasons for not using Racket are 
essentially,
1. Parentheses make my head hurt.
2. DrRacket is slow, and VSCode integration is weak.

I've heard the "surface syntax doesn't matter" arguments before, and 
frankly I find them to be condescending oftentimes. "Oh, you find this 
parenthetical syntax confusing? That's cute." The reality is clear: syntax 
is the user interface to a programming language. And anyone who claims that 
user interfaces don't matter is simply delusional. Although parentheses 
have a religious following, it should be noted that members of the Racket 
community have an understandable selection bias on this issue. The rest of 
the programming world just doesn't seem to feel the same way. 

I sense that many of the parenthistas among you may discount my experience 
as coming from one of the "unenlightened," a lesser soul trapped in a desk 
job writing Java for the last 10 years who has not yet been shown the 
light. But in fact I was trained in Racket by one of its creators. I'm also 
a PhD student in computer science and an early adopter of languages. I am 
aware of and admire much of the research that's gone into the Racket that 
exists today. I see the beauty in language's foundations. I've even 
attended RacketCon. Still, I dread having to work in Racket. It's not lost 
on me that Racket is a "better" language than Python in many respects. It's 
just that Python offers a much, _much_ better user experience in terms of 
its package ecosystem, developer experience and, yes, syntax.

As an outsider it seems clear to me that if the Racket community wishes to 
spread the gospel of language-oriented programming, it must shed its 
historical attachment to parentheses. I see Pyret as being the first domino 
to fall in this regard.

Just my 2c,
Samuel

On Monday, July 22, 2019 at 8:20:55 PM UTC-7, Andrew Gwozdziewycz wrote:
>
> On Mon, Jul 22, 2019 at 7:15 AM Alexis King  > wrote: 
> > 
> > On Jul 22, 2019, at 14:16, Dexter Lagan  > wrote: 
> > To say that Racket is so defined by its syntax that it will cease to be 
> distinguishable from any other language if it is changed is absurd, and 
> it’s frankly insulting to all the people who have put so much effort into 
> every part of Racket. 
>
> You have an advantage of being well invested in the Racket ecosystem 
> already. How do you convince someone _else_, perhaps in industry, that 
> Racket is interesting? It's pretty hard to say: "Look! Scribble and 
> Typed Racket, and contracts, and 10 other things make up this really 
> awesome ecosystem all running on a single VM, and they can all share 
> code!" Why? Because it's a _lot_ to digest, a _lot_ to try to 
> understand / invest in, and we live in a world where Go, a language 
> that effectively contains only 1970s language technology, is 
> dominating because of its simplicity and distinct lack of features. 
>
> On the other hand, people look at parens, think Lisp, completely 
> discount it because they heard "parens were really annoying to read," 
> or had a bad experience in college, and then move on anyway. People 
> judge a book by its cover, and they judge a language by its syntax. 
>
> Growing a language community is _really, really, really hard_, and is 
> only going to get harder as Racket grows in complexity, and other 
> languages come up that have immediately familiar syntax, and a simple 
> to understand core. A new syntax might checkmark the first point, but 
> I kind of think that the #lang ecosystem, _might actually be doing a 
> disservice_ to Racket. It's all the traditional complaints about 
> macros "you have to learn the original author's DSL" mixed with "you 
> have to learn the original author's half broken / buggy parser / 
> syntax and quirks, the new semantics it adds on, _and_ the library 
> that goes along with it, too." Oh, and "it's all mixed in with this 
> other stuff written in #lang racket, with these silly parens. I AM 
> CONFUSED!" 
>
> Not sure how to resolve all this, and I'm sorry for lacking a central 
> thesis in my reply, except to say that "syntax matters" and "Racket 
> isn't easy" ... 
>
> -- 
> http://www.apgwoz.com 
>

-- 
You received this message because you are subscribed to the Google Groups 
"Racket Users" group.
To unsubscribe from this group and stop receiving emails from it, send an email 
to racket-users+unsubscr...@googlegroups.com.
To view this discussion on the web visit 
https://groups.google.com/d/msgid/racket-users/6db41009-cc9b-4129-b2d1-18007eec650f%40googlegroups.com.

Re: [racket-users] Re: i18n / srfi-29

[Bogdan Popa]

> Is it OK to wrap declare-bundle! + store-bundle inside (begin-for-syntax
> ...) to make side effect during raco setup? If not, what is preferred way
> to do it?

Is there any reason not to do it at runtime?  This[1] is what I do in
forms-lib.  Other modules depend on that module so the bundles are
declared the first time it is loaded.  It's not optimal for versioning,
but it gets the job done.


[1]: 
https://github.com/Bogdanp/racket-forms/blob/master/forms-lib/private/l10n.rkt#L27-L33

-- 
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/m2v9vtjkvw.fsf%40192.168.0.139.

[racket-users] Re: i18n / srfi-29

[Roman Klochkov]

Is it OK to wrap declare-bundle! + store-bundle inside (begin-for-syntax 
...) to make side effect during raco setup? If not, what is preferred way 
to do it?

понедельник, 22 июля 2019 г., 15:56:13 UTC+5 пользователь Roman Klochkov 
написал:
>
> Hello!
>
> I'm trying to use srfi/29. As far as I understand, it provide 
> declare-bundle! + store-bundle to make a localization and load-bundle! to 
> use it.
> But I cannot find, how to use raco pkg install to run declare-bundle! + 
> store-bundle. Or is there any other way to run post-install command in 
> Racket?
>
> P.S. Why DrRacket doesn't use srfi/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/3a189add-4a0f-4e98-8852-ffceb514e13c%40googlegroups.com.

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

[Robby Findler]

Sorry for letting this thread lapse. Wrt to your third option
mentioned below, would it work to make that option accessible via the
FFI? If so, then maybe you could make the "essentially phase shifted
everything" into "actually phase shifted everything" and then when you
get the result program have your #%module-begin call into the FFI to
actually run the program. Does that seem like a viable option?

Robby

On Mon, Jul 1, 2019 at 3:35 PM Thomas Dickerson
 wrote:
>
> On Mon, Jul 1, 2019 at 2:23 PM Philip McGrath  
> wrote:
>>
>>
>> I believe the main submodule will still be compiled the enclosing module is 
>> loaded from source, but that should be trivial: it really only needs a 
>> `require` and a function call. If the file has already been compiled to 
>> bytecode, the bytecode for the main submodule won't be loaded, nor for any 
>> of its transitive dependencies.
>>
>> Depending on how you are distributing your code, you may or may not want to 
>> add an indirection via `dynamic-require` to prevent the distribution 
>> building tools from shipping graphics libraries that you only need for the 
>> main submodule. (Basically this would be the reverse of what 
>> `racket/runtime-path` does.) I haven't done much with the tools for 
>> distributing built artifacts beyond toy experiments, but I think some of 
>> them may be able to do that stripping automatically or with e.g. a 
>> command-line flag, without needing a `dynamic-require`. At the maximum, you 
>> could put the graphics modules in their own package, analogous to the 
>> `foo`+`foo-lib`+`foo-doc`+`foo-test` convention: in that case, the support 
>> library for your main submodule (what I called 
>> `hypothetical-lanugage/private/render`) would just be a stub to 
>> `dynamic-require` the `render` function or do something useful if the 
>> graphics package isn't installed, like print a message to standard error.
>
>
> I'll chew on this, but if the dependencies for the main submodule need to be 
> available at the time that it is compiled, then the easiest thing may just be 
> doing a dynamic-require.
>
>>
>>  I haven't used OpenGL, from Racket or otherwise, but it might be possible 
>> to use a bitmap from `make-gl-bitmap` as a buffer for your OpenGL drawing 
>> and copy it to the canvas via `draw-bitmap`. If you have an existing foreign 
>> library that does the actual drawing, you can get a platform-specific 
>> pointer via `gl-context<%>`.
>
>
> That's an interesting possibility, and I shouldn't actually need the 
> gl-context pointer, just to make it current before calling the foreign 
> rendering code.
>
>>
>>  I suspect, though, that a solution would involve your support library 
>> cooperating with an extension set up by your #lang.
>
> Right, this is what we originally hand in mind.
>
>>
>> On the whole, though, either returning a snip or creating a new `frame%` 
>> would probably be easier. Using a new `frame%` would also be entirely 
>> independent of DrRacket: I expect it would work with racket-mode for Emacs, 
>> for example.
>
> frame% is portable, but also not a very nice UI. I'll see what can be done 
> with a snip.
>
> On Mon, Jul 1, 2019 at 2:56 PM Robby Findler  
> wrote:
>>
>> I think I'm missing a bit more context so I'll continue this line of
>> questions. The path that you seem to be heading down seems to be one
>> where you'll duplicate a lot of work that's already gone into
>> DrRacket, and it seems unlikely to me that it is the most productive
>
>
> Perhaps you could elaborate on the mechanisms you think we would be 
> duplicating, because those may provide either the entry points we're looking 
> for, or clarify a potential miscommunication on our end.
>
>>
>> Can you say a little more about what you want to do with DrRacket?
>
>
> Currently, most of our DSL programs are constructed automatically from 
> inferred geometry, and it's fine, because an artist/programmer doesn't need 
> to do any design work.
> Going forward, we would like to also be able to model reusable parametric 
> object classes that we can plug in to our scenes, and here it would be very 
> helpful to be able to visualize the geometry generated by our DSL programs 
> interactively.
> Rather than reinventing the wheel, and writing our own editor, we would like 
> to bend DrRacket to our will for that purpose; however, the current "Run" 
> button doesn't seem like quite the right UI for that.
>
>> Do you expect to be able to run these programs? If so, does it
>> make sense to run them when you aren't in the
>> embedded-in-the-huge-C++-code-base mode? How about compilation of the
>> programs (i.e. macro expansion)?
>
>
> We've essentially phase shifted everything, so that Racket's Phase 0 is 
> really Phase 1 in a DSL library implemented with C++, which provides our 
> "core language", so the result of "running" the Racket program is a pointer 
> to an opaque C++ type which represents the fully expanded syntax for our 
> program, ready to be evaluated by