> 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,
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
> 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
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
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
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
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
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
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
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
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
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,
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
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
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
15 matches
Mail list logo
