Re: [racket-users] Order of argument conventions, or ... conventions of argument ordering

[Eugene Wallingford]

> Eugene Wallingford wrote on 04/21/2016 11:18 AM:
> >  This also reminds me fondly of Smalltalk's separable message
> >  names.  They always felt more natural to me than more typical
> >  keyword arguments.
> 
> On a tangent, Smalltalk-like names weren't hard to implement just now, with
> `syntax-parse` and the modern `#lang` support:

 Nice!  Thanks, Neil.  My students may appreciate this almost
 as much as I do.

 Eugene
 
> #lang rase
> 
> (define:: (displayLabel: label withValue: val)
>   (display: label)
>   (display: " = ")
>   (display: val)
>   (newline))
> 
> (displayLabel: "Puppies" withValue: (add: 3 to: 39))
> ;;=output=> Puppies = 42
> 
> 
> Neil V.

-- 
You received this message because you are subscribed to the Google Groups 
"Racket Users" group.
To unsubscribe from this group and stop receiving emails from it, send an email 
to racket-users+unsubscr...@googlegroups.com.
For more options, visit https://groups.google.com/d/optout.

Re: [racket-users] Order of argument conventions, or ... conventions of argument ordering

[Neil Van Dyke]

Eugene Wallingford wrote on 04/21/2016 11:18 AM:

  This also reminds me fondly of Smalltalk's separable message
  names.  They always felt more natural to me than more typical
  keyword arguments.


On a tangent, Smalltalk-like names weren't hard to implement just now, 
with `syntax-parse` and the modern `#lang` support:



#lang rase

(define:: (displayLabel: label withValue: val)
  (display: label)
  (display: " = ")
  (display: val)
  (newline))

(displayLabel: "Puppies" withValue: (add: 3 to: 39))
;;=output=> Puppies = 42


Neil V.

--
You received this message because you are subscribed to the Google Groups "Racket 
Users" group.
To unsubscribe from this group and stop receiving emails from it, send an email 
to racket-users+unsubscr...@googlegroups.com.
For more options, visit https://groups.google.com/d/optout.

Re: [racket-users] Question about syntax properties and expansion

[Jack Firth]

> In the same way that properties can now be attached as preserved or
> not, we could and an option for specifying whether properties are are
> propagated/merged or not. If it's useful, we could even allow a
> combining function to be associated with with either a property value
> or a property key --- although a general combining function wouldn't
> work with a preserved property. Any thoughts on those details?

I don't think I want a general combining function in the `syntax-property` 
procedure. Ideally syntax properties don't know anything about combining and 
some external macro expansion parameter defines a syntax properties that should 
be expanded in this special combining way. That way I don't have to think about 
it - configuring the behavior of how all macros treat a certain syntax property 
seems like spooky action at a distance to me. I haven't used them enough to 
know how well that interoperates with other macros though.

> (FWIW, as I look back at the documentation, I think it needs
> clarification on the point that only properties of the immediate syntax
> object for the input and output of a macro are merged. Properties are
> not merged on any syntax object within the immediate syntax object.)

I strongly agree with this. The `syntax-property` procedure documentation 
should mention it.

-- 
You received this message because you are subscribed to the Google Groups 
"Racket Users" group.
To unsubscribe from this group and stop receiving emails from it, send an email 
to racket-users+unsubscr...@googlegroups.com.
For more options, visit https://groups.google.com/d/optout.

Re: [racket-users] Question about syntax properties and expansion

[Vincent St-Amour]

On Thu, 21 Apr 2016 15:55:34 -0500,
Matthew Flatt wrote:
> In the same way that properties can now be attached as preserved or
> not, we could and an option for specifying whether properties are are
> propagated/merged or not. If it's useful, we could even allow a
> combining function to be associated with with either a property value
> or a property key --- although a general combining function wouldn't
> work with a preserved property. Any thoughts on those details?

That's starting to sound a bit like attribute grammars.

Vincent

-- 
You received this message because you are subscribed to the Google Groups 
"Racket Users" group.
To unsubscribe from this group and stop receiving emails from it, send an email 
to racket-users+unsubscr...@googlegroups.com.
For more options, visit https://groups.google.com/d/optout.

Re: [racket-users] Order of argument conventions, or ... conventions of argument ordering

[Daniel Prager]

Great comments. Thank-you!

I think that for the purposes of remembering "take and drop family
functions are backwards / wrong" should suffice, or train myself to think
"from list L take n elements", etc.

Another point that occurred to me is that the common library naming
convention of object-fn (e.g. string-ref) is helpful in prompting the
object-first ordering.

In terms of designing functions another thing I've learned to appreciate
from the standard libraries is the use of keyword arguments with sensible
defaults. Loosely speaking, anything beyond "what reads naturally"
(typically 2 or 3 arguments) seems to work better when tagged with a
keyword.

For example:

(define test-scores '((math 84) (english 77) (comp-sci 106) (physics 68)))
(sort test-scores < #:key second)


This is friendlier to the reader / author than a more concise e.g. (sort
test-scores < second), so  I've learned to follow a similar convention in
designing my own functions.

Is this mentioned explicitly somewhere, e.g. in HTDP? [Perhaps I'm missing
other helpful conventions.]

Dan

-- 
You received this message because you are subscribed to the Google Groups 
"Racket Users" group.
To unsubscribe from this group and stop receiving emails from it, send an email 
to racket-users+unsubscr...@googlegroups.com.
For more options, visit https://groups.google.com/d/optout.

Re: [racket-users] Question about syntax properties and expansion

[Matthew Flatt]

At Thu, 21 Apr 2016 11:45:08 -0700 (PDT), Jack Firth wrote:
> The documentation for syntax properties states that if a macro sets a syntax 
> property during expansion then instead of the expanded syntax having only the 
> set value, it has a cons tree containing that value and any previous values 
> set for that same property. As I understand it, this means it's impossible 
> for 
> macros to remove syntax property values during expansion. Why is that? I 
> don't 
> understand the purpose of it, and it makes working with custom syntax 
> properties a bit unpleasant API-wise.

The original intent was to relieve a macro implementor of the burden of
appropriately propagating properties such as 'origin and
'disappeared-use.

Since that very early decision, the role and potential uses of
properties have expanded. I can see how it would make sense to not
propagate and merge some properties.

In the same way that properties can now be attached as preserved or
not, we could and an option for specifying whether properties are are
propagated/merged or not. If it's useful, we could even allow a
combining function to be associated with with either a property value
or a property key --- although a general combining function wouldn't
work with a preserved property. Any thoughts on those details?


(FWIW, as I look back at the documentation, I think it needs
clarification on the point that only properties of the immediate syntax
object for the input and output of a macro are merged. Properties are
not merged on any syntax object within the immediate syntax object.)

-- 
You received this message because you are subscribed to the Google Groups 
"Racket Users" group.
To unsubscribe from this group and stop receiving emails from it, send an email 
to racket-users+unsubscr...@googlegroups.com.
For more options, visit https://groups.google.com/d/optout.

[racket-users] Question about syntax properties and expansion

[Jack Firth]

The documentation for syntax properties states that if a macro sets a syntax 
property during expansion then instead of the expanded syntax having only the 
set value, it has a cons tree containing that value and any previous values set 
for that same property. As I understand it, this means it's impossible for 
macros to remove syntax property values during expansion. Why is that? I don't 
understand the purpose of it, and it makes working with custom syntax 
properties a bit unpleasant API-wise.

-- 
You received this message because you are subscribed to the Google Groups 
"Racket Users" group.
To unsubscribe from this group and stop receiving emails from it, send an email 
to racket-users+unsubscr...@googlegroups.com.
For more options, visit https://groups.google.com/d/optout.

Re: [racket-users] Limiting memory for raco

[Matthew Flatt]

At Thu, 21 Apr 2016 08:45:13 -0700, Jordan Johnson wrote:
> Is it possible to limit the memory that raco uses for running builds (beyond 
> whatever reduction I might get by using the -j option to reduce the number of 
> parallel jobs)?
> 
> If so, how?

Mostly, a build with a given sets of packages an a given number of jobs
will take a specific amount of memory. You can set a process memory
limit at the OS level, at least on Unix variants, and that will
influence Racket's GC to a limited extent --- but probably not enough
to be useful.


Besides adjusting `-j`, if you don't need documentation, you can use
`-D` to reduce peak memory use somewhat. Or, if you're running the
current Racket release, depending on the packages you need to build and
which ones you're developing, you might be able to pull already-built
packages from the catalog at

 https://pkg-build.racket-lang.org/server/built/catalog/


If we're talking about a main-distribution build, you can get an idea
of what parts of the build use the most memory from

 http://build-plot.racket-lang.org/


None of that is much help if you're starting with an installation and
`raco setup` for your own collections uses too much memory. In that
case, `-j` is probably the only useful control.

-- 
You received this message because you are subscribed to the Google Groups 
"Racket Users" group.
To unsubscribe from this group and stop receiving emails from it, send an email 
to racket-users+unsubscr...@googlegroups.com.
For more options, visit https://groups.google.com/d/optout.

[racket-users] Limiting memory for raco

[Jordan Johnson]

Hi all,

Is it possible to limit the memory that raco uses for running builds (beyond 
whatever reduction I might get by using the -j option to reduce the number of 
parallel jobs)?

If so, how?

Thanks,
jmj

-- 
You received this message because you are subscribed to the Google Groups 
"Racket Users" group.
To unsubscribe from this group and stop receiving emails from it, send an email 
to racket-users+unsubscr...@googlegroups.com.
For more options, visit https://groups.google.com/d/optout.

Re: [racket-users] Custodian/Will question

[Deren Dohoda]

Thanks,  Matthew.  There's safety and then there's safety. I'm mostly
concerned with and application-level soft reset. I can add some thread
messaging to make sure the thread dies on its own, then shut down
everything. I was hoping to avoid this plumbing.

Deren
On Apr 21, 2016 10:40 AM, "Matthew Flatt"  wrote:

> At Tue, 19 Apr 2016 10:39:57 -0400, Deren Dohoda wrote:
> > I have a thread that can only be shut down during certain points:
>
> In general, you can't implement that safety in Racket, in much the same
> way you can't implement that in Unix or Windows process.
>
> As long as the thread might get shut down through
> `custodian-shutdown-all` (like a Unix process might get terminated with
> SIGKILL), there's nothing the thread can do about it --- at least not
> safely.
>
> There's also no way to register arbitrary code to run in the event that
> a thread gets killed (in the same way that there's no API for
> registering code to run if your process is killed in Unix). If there
> were such a feature, then a thread could just put all of its work in
> that callback, and there would be no way to reliably terminate a
> thread's computation.
>
>
> > [...] it does
> > some writing operations on a port and this write must finish under normal
> > circumstances. I worry that if this thread is managed by a custodian and
> > custodian-shutdown-all is called that the thread may die in the middle
> of a
> > write operation on a port. Is this where I would use a will?
>
> Wills are unlikely to help. It depends on your situation, but in a
> typical case where a thread might get shut down through a custodian, a
> thread that's acting as a will executor can also get shut down.
>
> There is an unsafe function, `register-finalizer`, which lets you
> register a will that has an executor thread that can never get killed
> (unless the whole Racket process is killed). That's probably not what
> you want, but I mention it for completeness.
>
>
> Using a particular pattern, you can use to make something "kill safe"
> in the following sense: if multiple clients are using an object, and if
> one of them is killed while manipulating the object, a later use by a
> different client can pick up where the previous thread left off to
> restore the object to usability. See the paper "Kill-Safe
> Synchronization Abstractions" for more on that pattern.
>
> Along those lines, if there's some thread X that won't get killed
> relative to another set of threads, you can have X run the action or
> have it start a new thread with X's custodian to ensure that the action
> will complete. At least, it will complete relative to the threads that
> might get killed. Whether you can arrange for such an X depends on how
> much your program is in control from the start.
>
>
> If you have something where you need an action to complete atomically
> --- even if no future client touches the relevant object and you don't
> have access to a thread that will definitely continue --- then it's not
> possible to implement that safely. In the grand scheme of things, it's
> not possible to implement at all, at least for an arbitrary action; the
> Racket process might get killed, the power might go out, and so on.
>
> If termination external to Racket run-time system is not a concern,
> then you can implement atomic actions unsafely. See
> `ffi/unsafe/atomic`. Please be aware that atomicity really is unsafe;
> you need to know the full affect of any function called in atomic mode
> to make sure that it cannot lead to deadlock or similar problems.
> Generally, that's how actions like shutting down a custodian can be
> implemented atomically relative to the rest of the Racket runtime
> system; those primitives are implemented (carefully!) to run in atomic
> mode.
>
>

-- 
You received this message because you are subscribed to the Google Groups 
"Racket Users" group.
To unsubscribe from this group and stop receiving emails from it, send an email 
to racket-users+unsubscr...@googlegroups.com.
For more options, visit https://groups.google.com/d/optout.

Re: [racket-users] Order of argument conventions, or ... conventions of argument ordering

[Eugene Wallingford]

On Thu, Apr 21, 2016 at 08:07:36AM -0700, Jordan Johnson wrote:
> 1) With many of these functions, there's usually an imaginary preposition 
> there, when I read most of them functions:
> 
> sort ls by >
> cons X onto ls
> remove X from ls
> map f over ls

 I think this way when I design a function, too.  "What will
 users be thinking when they use this operation?"

 This also reminds me fondly of Smalltalk's separable message
 names.  They always felt more natural to me than more typical
 keyword arguments.

 Eugene
 
> 2) Any "-ref" function — list-ref, vector-ref, hash-ref — has the object 
> first. Longstanding Scheme/lisp convention, and it resembles array/object 
> dereferencing in C-style languages.
> 
> 3) Most of the higher-order list functions — folds, maps, and filters — take 
> the function first and the list last.
> 
> 4) The only ones that trip me up repeatedly are the take and drop family of 
> functions. Putting the list first clashes with the obvious (to me) 
> imaginary-preposition reading — "take n from ls" is wrong, as you said — and 
> also is opposite to how Haskell does it (and Haskell is where I first used 
> take and drop). Otherwise, they've all seemed intuitive to me.
> 
> Best,
> Jordan
> 
> > On Apr 21, 2016, at 3:04 AM, Daniel Prager  
> > wrote:
> > 
> > Does anyone else struggle to remember the order of arguments for some of 
> > the common functions?
> > 
> > There seem to be two extant conventions, roughly:
> > object-first: (function obj other)
> > object-last: (function other obj): e.g.
> > Object-first: take, drop, list-ref, add-between, sort
> > Object-last: cons, member, remove, map, filter, foldl, foldr
> > 
> > (remove v lst) means "remove the first instance of v from lst" and reads 
> > ok..
> > 
> > OTOH (take lst n) means "take the first n items from lst", which 
> > occasionally trips me up, possibly guided by the flipped order in the 
> > English interpretation.
> > 
> > Am I missing some sort of principal or mnemonic?
> > 
> > How do others cope? Do you make heavy use of the "blue box" in DrRacket?
> > 
> > Dan
> >  
> > -- 
> > You received this message because you are subscribed to the Google Groups 
> > "Racket Users" group.
> > To unsubscribe from this group and stop receiving emails from it, send an 
> > email to racket-users+unsubscr...@googlegroups.com.
> > For more options, visit https://groups.google.com/d/optout.
> 
> -- 
> You received this message because you are subscribed to the Google Groups 
> "Racket Users" group.
> To unsubscribe from this group and stop receiving emails from it, send an 
> email to racket-users+unsubscr...@googlegroups.com.
> For more options, visit https://groups.google.com/d/optout.

-- 
You received this message because you are subscribed to the Google Groups 
"Racket Users" group.
To unsubscribe from this group and stop receiving emails from it, send an email 
to racket-users+unsubscr...@googlegroups.com.
For more options, visit https://groups.google.com/d/optout.

Re: [racket-users] Order of argument conventions, or ... conventions of argument ordering

[Jordan Johnson]

1) With many of these functions, there's usually an imaginary preposition 
there, when I read most of them functions:

sort ls by >
cons X onto ls
remove X from ls
map f over ls

2) Any "-ref" function — list-ref, vector-ref, hash-ref — has the object first. 
Longstanding Scheme/lisp convention, and it resembles array/object 
dereferencing in C-style languages.

3) Most of the higher-order list functions — folds, maps, and filters — take 
the function first and the list last.

4) The only ones that trip me up repeatedly are the take and drop family of 
functions. Putting the list first clashes with the obvious (to me) 
imaginary-preposition reading — "take n from ls" is wrong, as you said — and 
also is opposite to how Haskell does it (and Haskell is where I first used take 
and drop). Otherwise, they've all seemed intuitive to me.

Best,
Jordan

> On Apr 21, 2016, at 3:04 AM, Daniel Prager  wrote:
> 
> Does anyone else struggle to remember the order of arguments for some of the 
> common functions?
> 
> There seem to be two extant conventions, roughly:
> object-first: (function obj other)
> object-last: (function other obj): e.g.
> Object-first: take, drop, list-ref, add-between, sort
> Object-last: cons, member, remove, map, filter, foldl, foldr
> 
> (remove v lst) means "remove the first instance of v from lst" and reads ok..
> 
> OTOH (take lst n) means "take the first n items from lst", which occasionally 
> trips me up, possibly guided by the flipped order in the English 
> interpretation.
> 
> Am I missing some sort of principal or mnemonic?
> 
> How do others cope? Do you make heavy use of the "blue box" in DrRacket?
> 
> Dan
>  
> -- 
> You received this message because you are subscribed to the Google Groups 
> "Racket Users" group.
> To unsubscribe from this group and stop receiving emails from it, send an 
> email to racket-users+unsubscr...@googlegroups.com.
> For more options, visit https://groups.google.com/d/optout.

-- 
You received this message because you are subscribed to the Google Groups 
"Racket Users" group.
To unsubscribe from this group and stop receiving emails from it, send an email 
to racket-users+unsubscr...@googlegroups.com.
For more options, visit https://groups.google.com/d/optout.

Re: [racket-users] custodians & wills (FAQ?)

[Matthew Flatt]

At Wed, 20 Apr 2016 20:58:34 -0400, "'John Clements' via Racket Users" wrote:
> I feel like this must be a FAQ. I have a server process that I’m starting 
> with 
> process*, and I’d like to try to make sure that it gets killed when the 
> “program halts.” (Presumably, this corresponds to process end at the 
> command-line, or (more relevant to me) a click on “Run” in DrR, which AFAIK 
> means “custodian-shutdown-all” on the user’s program’s custodian.

Subprocesses in Racket have primitive support for termination on
custodian shutdown. See `current-subprocess-custodian-mode`.

If subprocesses didn't have primitive custodian support, then there
would be no safe solution to your problem. Any kind of primitive
resource allocation, such as creating a subprocess, should have
custodian support built in primitively, 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.
For more options, visit https://groups.google.com/d/optout.

Re: [racket-users] Order of argument conventions, or ... conventions of argument ordering

[Jay McCarthy]

I believe the actual principle is, "Scheme did this" and "LISP did
this" so "We do this." I don't think that's necessarily a good reason
though. :)

I generally prefer object-first, but sometimes not. If I were to dig
down to when, I would say that I want the expression that is likely to
be longest to come last. It makes the formatting look nicer. So,
`member` is likely to have a complicated expression to generate the
list, not to generate the element, so that one goes last. `map` is the
same IF the function is a named function, otherwise, I generally think
the function is going to be longer --- which is one of the weird
benefits of `for/list`. And so on...

Jay

On Thu, Apr 21, 2016 at 6:04 AM, Daniel Prager
 wrote:
> Does anyone else struggle to remember the order of arguments for some of the
> common functions?
>
> There seem to be two extant conventions, roughly:
>
> object-first: (function obj other)
> object-last: (function other obj): e.g.
>
> Object-first: take, drop, list-ref, add-between, sort
> Object-last: cons, member, remove, map, filter, foldl, foldr
>
> (remove v lst) means "remove the first instance of v from lst" and reads
> ok..
>
> OTOH (take lst n) means "take the first n items from lst", which
> occasionally trips me up, possibly guided by the flipped order in the
> English interpretation.
>
> Am I missing some sort of principal or mnemonic?
>
> How do others cope? Do you make heavy use of the "blue box" in DrRacket?
>
> Dan
>
>
> --
> You received this message because you are subscribed to the Google Groups
> "Racket Users" group.
> To unsubscribe from this group and stop receiving emails from it, send an
> email to racket-users+unsubscr...@googlegroups.com.
> For more options, visit https://groups.google.com/d/optout.



-- 
Jay McCarthy
Associate Professor
PLT @ CS @ UMass Lowell
http://jeapostrophe.github.io

   "Wherefore, be not weary in well-doing,
  for ye are laying the foundation of a great work.
And out of small things proceedeth that which is great."
  - D 64:33

-- 
You received this message because you are subscribed to the Google Groups 
"Racket Users" group.
To unsubscribe from this group and stop receiving emails from it, send an email 
to racket-users+unsubscr...@googlegroups.com.
For more options, visit https://groups.google.com/d/optout.

[racket-users] Order of argument conventions, or ... conventions of argument ordering

[Daniel Prager]

Does anyone else struggle to remember the order of arguments for some of
the common functions?

There seem to be two extant conventions, roughly:

   1. object-first: (function obj other)
   2. object-last: (function other obj): e.g.

Object-first: take, drop, list-ref, add-between, sort
Object-last: cons, member, remove, map, filter, foldl, foldr

(remove v lst) means "remove the first instance of v from lst" and reads
ok..

OTOH (take lst n) means "take the first n items from lst", which
occasionally trips me up, possibly guided by the flipped order in the
English interpretation.

Am I missing some sort of principal or mnemonic?

How do others cope? Do you make heavy use of the "blue box" in DrRacket?

Dan

-- 
You received this message because you are subscribed to the Google Groups 
"Racket Users" group.
To unsubscribe from this group and stop receiving emails from it, send an email 
to racket-users+unsubscr...@googlegroups.com.
For more options, visit https://groups.google.com/d/optout.