Re: [racket-users] Re: A language for command line interfaces

[Siddhartha Kasivajhula]

Good call, I'll add a note to the effect. Btw in case it wasn't clear from
my response, using #lang cli shouldn't affect the existing workflows that
you mentioned, although, you would probably want to define the command line
component of your code as a separate #lang cli module, rather than in a
module+ main.


On Sun, Jul 25, 2021 at 12:21 PM D. Ben Knoble  wrote:

> > Right, thank you for bringing that up. I should have mentioned that the
> #lang provides all of racket/base at the module level, so you can write
> normal Racket code (including `require`), and any imports at the module
> level would be available within the `program` body since it compiles down
> to a normal function.
> >
> > You can also use `provide`, so once you define your command using
> `program`, you can provide it the same as any function. The client module
> requiring your command would need to be a #lang cli module (at least at the
> moment) so that it can actually run the imported command using `run`.
>
> That would be good to add to the docs in my opinion.
>

-- 
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/CACQBWFmbq1bPs4-66mkxCVVC9Ob6EJ7ovw-3%3D%2B%3DuBd2ZexGBcA%40mail.gmail.com.

Re: [racket-users] Can I get the behavior of `overment` followed by `augride` with a single class?

[Alexis King]

On Mon, Jul 19, 2021 at 11:08 AM Matthew Flatt  wrote:

> Are there other useful variants that are not currently supported (at least
> directly)?
>

I think the answer to this is “no.” My reasoning follows.

>From the perspective of subclasses, superclass methods come in three sorts:
overridable, augmentable, and final. The existing method declaration
keywords support all possible transitions between these sorts, which
suggests the current set is complete. However, my original email shows that
compositions of these transitions can affect *dispatch* in different ways
from the existing keywords, even if they result in methods belonging to the
same sort.

This fundamentally hinges on the fact that overment has an unusually
significant impact on dispatch behavior. overment switches from
subclass-first dispatch to superclass-first dispatch, which means overment
followed by augride effectively breaks a chain of Java-style methods into
two sub-chains. In contrast, the other keywords provide no such utility:

   -

   override and augment on their own do not change dispatch characteristics
   at all from the perspective of other classes.
   -

   augride followed by overment creates a local chain of Java-style methods
   before switching back to Beta-style inheritance. Since this chain is wholly
   self-contained, it does not change the overall dispatch structure in any
   way, and it could be replaced by completely static dispatch with no loss of
   expressiveness.

The main interesting thing about overment followed by augride is that it
allows something reminiscent of the CLOS :around method combination, since
it allows a class to receive control on both the way down *and* the way up
through method dispatch. Since override already provides the “on the way
up” part, a hypothetical interface for this would make most sense as
something that could be present on its own *or in addition to* an ordinary
override declaration, like

(define/override (m x)
  (super m x))
(define/around (m x)
  (inner/around m x))

where inner/around is like inner, but it doesn’t take a default-expr, since
it always has a Java-style method to dispatch to. I don’t know if these
names are the best—around doesn’t really seem right to me—but I don’t know
what else to call it.

Alexis

-- 
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/CAA8dsadsniyVBv%3De2NGFEUgk3EGzNmzvBcsECw8xFgAizOSUiA%40mail.gmail.com.

Re: [racket-users] Re: A language for command line interfaces

[D. Ben Knoble]

> Right, thank you for bringing that up. I should have mentioned that the #lang 
> provides all of racket/base at the module level, so you can write normal 
> Racket code (including `require`), and any imports at the module level would 
> be available within the `program` body since it compiles down to a normal 
> function.
>
> You can also use `provide`, so once you define your command using `program`, 
> you can provide it the same as any function. The client module requiring your 
> command would need to be a #lang cli module (at least at the moment) so that 
> it can actually run the imported command using `run`.

That would be good to add to the docs in my opinion.

-- 
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/CALnO6CAsxaJ%3DHsPJE1ZnOJXs9yVobiRiSBOj9UV4cxC%2BLRqiiw%40mail.gmail.com.

Re: [racket-users] Re: A language for command line interfaces

[Siddhartha Kasivajhula]

Right, thank you for bringing that up. I should have mentioned that the
#lang provides all of racket/base at the module level, so you can write
normal Racket code (including `require`), and any imports at the module
level would be available within the `program` body since it compiles down
to a normal function.

You can also use `provide`, so once you define your command using
`program`, you can provide it the same as any function. The client module
requiring your command would need to be a #lang cli module (at least at the
moment) so that it can actually run the imported command using `run`.


On Sun, Jul 25, 2021 at 11:23 AM D. Ben Knoble  wrote:

>
> The language is composed of 5 forms - help, flag, constraint, program,
>> and run. With these 5 forms, you get all of the functionality of the
>> built-in parse-command-line form, and with syntax that's much simpler.
>> In fact, the nontrivial forms of the language simply use Racket's normal
>> function definition syntax, so there's very little to learn -- you
>> basically write normal functions and they are implicitly wired to accept
>> their inputs via the command line.
>>
>
> Could we add require? I can think of two compelling reasons:
>
> 1. What else is available in the program form? All of racket, or just
> racket/base? And either way, what if I want to use procedures from other
> packages?
> 2. What if I want to write a bunch of library code, and expose some of it
> in a CLI script? I do this now in different ways: a module+ main that uses
> code defined in the enclosing module, or a script that requires auxiliary
> modules. Often the "body" of the program form isn't more than a call to a
> "main" procedure: this enables me to provide that procedure as part of the
> library, too.
>
> --
> 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/a0a0ffba-b8a5-4b57-8fc1-b24a821de85cn%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/CACQBWF%3DQS%3DKu%3DZ-NfSLqmeOq8fb6FOcnA0GkL1xh-kT8WXw0-A%40mail.gmail.com.

[racket-users] Re: A language for command line interfaces

[D. Ben Knoble]

> The language is composed of 5 forms - help, flag, constraint, program, 
> and run. With these 5 forms, you get all of the functionality of the 
> built-in parse-command-line form, and with syntax that's much simpler. In 
> fact, the nontrivial forms of the language simply use Racket's normal 
> function definition syntax, so there's very little to learn -- you 
> basically write normal functions and they are implicitly wired to accept 
> their inputs via the command line.
>

Could we add require? I can think of two compelling reasons:

1. What else is available in the program form? All of racket, or just 
racket/base? And either way, what if I want to use procedures from other 
packages?
2. What if I want to write a bunch of library code, and expose some of it 
in a CLI script? I do this now in different ways: a module+ main that uses 
code defined in the enclosing module, or a script that requires auxiliary 
modules. Often the "body" of the program form isn't more than a call to a 
"main" procedure: this enables me to provide that procedure as part of the 
library, too.

-- 
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/a0a0ffba-b8a5-4b57-8fc1-b24a821de85cn%40googlegroups.com.

[racket-users] Re-entrant parameterize modification isolation when using shift/reset

[Greg Rosenblatt]

I'm using dynamic binding while also using delimited control operators such 
as shift and reset.  When shift captures the context of a `parameterize`, 
I'd like to be able to resume that continuation in the same context 
multiple times without observing modifications caused by other resumptions.

I was surprised that subsequent re-entries can observe modifications from 
the earlier ones, since my mental model of dynamic parameters was that 
their values were retrieved from a fresh dynamic calling context, whose 
frames are copied each time the delimited continuation is invoked.  But it 
looks like dynamic parameters actually rely on a shared mutable cell, in 
this case a thread cell.

Knowing this, I have a strange workaround using a wrapping thread to force 
a distinct thread cell to be created for each resumption, providing 
isolation.  Is there a better way to do this?

I'm also interested in the reasons behind the current design.  Is there a 
downside to storing parameter bindings directly on the stack, rather than 
in a thread cell pointed to by the stack?


Here is an example, including a demonstration of the workaround:

```
#lang racket/base
(require racket/control)

(define P (make-parameter #f))
(define (show) (displayln (P)))
(define (inc) (P (+ 1 (P

(define (re-enter k)
  (define result (void))
  (define t (thread
  (lambda ()
(set! result (k (void))
  (thread-wait t)
  result)


(define K (reset (parameterize ((P 0))
   (show)
   (inc)
   (shift k k)
   (show)
   (inc)
   (P

;; The behavior that surprised me:
(displayln "without threads:")
(K) ; 2
(K) ; 3
(K) ; 4

;; The behavior I would like:
(displayln "with threads:")
(re-enter K) ; 5
(re-enter K) ; 5
(re-enter K) ; 5
```


Program output:

0
without threads:
1
2
2
3
3
4
with threads:
4
5
4
5
4
5

-- 
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/ae64e2cf-c3fb-4acd-95c0-1239dd98a9f8n%40googlegroups.com.