> On Oct 25, 2019, at 7:28 AM, Thomas Dickerson
> wrote:
>
> For reasons that are unclear to me, hash-keys and dict-keys both return a
> list? instead of a set?(frankly, this seems like a bug in the API...).
A dict doesn't guarantee unique keys. So `dict-keys` returns a list, not a set.
#l
I don't know of a more efficient way to convert, but depending on what
operations you want, you might be able to compute it directly on the
hash, e.g., see hash-has-key?, hash-keys-subset?, hash-union, etc. (I
didnt know about some of the functions until recently.)
On Fri, Oct 25, 2019 at 4:21 PM
Oh -- forgot to mention: if you're using an immutable hash, then
`in-immutable-hash-keys` is significantly faster than `in-hash-keys`.
I mean:
(for/set ([k (in-immutable-hash-keys h)]) k)
On Fri, Oct 25, 2019 at 4:37 PM Jon Zeppieri wrote:
>
> From a little test I just ran, building a set of ha
>From a little test I just ran, building a set of hash keys, using a
hash with 100,000 k/v pairs and generating the key set 100 times each:
"list->set"
cpu time: 3147 real time: 3148 gc time: 1137
"apply"
cpu time: 3205 real time: 3206 gc time: 1146
"in-hash"
cpu time: 2791 real time: 2791 gc ti
It also might be worth trying `(for/set ([(k v) (in-hash h)]) k)`.
On Fri, Oct 25, 2019 at 1:19 PM David Storrs wrote:
> On Fri, Oct 25, 2019 at 10:28 AM Thomas Dickerson
> wrote:
> >
> > For reasons that are unclear to me, hash-keys and dict-keys both return
> a list? instead of a set? (frankl
On Fri, Oct 25, 2019 at 10:28 AM Thomas Dickerson
wrote:
>
> For reasons that are unclear to me, hash-keys and dict-keys both return a
> list? instead of a set? (frankly, this seems like a bug in the API...).
>
> Is there a something I can do that's more efficient than just calling
> list->set?
On Fri, Oct 25, 2019 at 1:27 PM wanderley.guimar...@gmail.com <
wanderley.guimar...@gmail.com> wrote:
> On Fri, Oct 25, 2019 at 9:28 AM Alexis King wrote:
>
>> Unlike eq? on symbols, eq?’s behavior on quoted lists is unspecified …
>> Is there a reason you would like the answer to be #t?
>
> Not s
On Fri, Oct 25, 2019 at 9:28 AM Alexis King wrote:
> Unlike eq? on symbols, eq?’s behavior on quoted lists is unspecified, so I
> do not think there is a significantly deeper reason than “that isn’t what
> the current implementation chooses to do.” Whether the answer is #t or #f
> could change to
Den fre. 25. okt. 2019 kl. 16.35 skrev wanderley.guimar...@gmail.com <
wanderley.guimar...@gmail.com>:
> Why (eq? (quote a) (quote a)) is #t but (eq? (quote (a)) (quote (a)))
> is #f? I would expect that if (quote (a)) was a mutable pair but it
> is not since (quote (a)) returns #f. It seems tha
> On Oct 25, 2019, at 11:34, David Thrane Christiansen
> wrote:
>
> I'm not sure why Guile returns #t for this. If pairs are mutable there, then
> it could lead to aliasing problems.
The Scheme standard has historically left the behavior of mutation on quoted
values unspecified to permit prec
Hello,
eq? decides object identity, or pointer equality. Symbols are interned,
which means that there's a table mapping symbol names to underlying
objects, such that using the name twice results in the same allocated
symbol object being returned.
Pairs are not interned. Each time a new pair is co
Typo: Meant (let ([l (quote (a))]) (eq? l l))
~slg
‐‐‐ Original Message ‐‐‐
On Friday, October 25, 2019 12:28 PM, Sage Gerard wrote:
> By https://docs.racket-lang.org/reference/symbols.html, Two interned symbols
> are eq? to each other.
>
> But in the other example, you are comparing
Unlike eq? on symbols, eq?’s behavior on quoted lists is unspecified, so I do
not think there is a significantly deeper reason than “that isn’t what the
current implementation chooses to do.” Whether the answer is #t or #f could
change tomorrow, on a different VM, on a different architecture, or
By https://docs.racket-lang.org/reference/symbols.html, Two interned symbols
are eq? to each other.
But in the other example, you are comparing two lists each containing a single
symbol. A new list is created in each expression, and eq? is comparing the
object references and not the content. Fo
Why (eq? (quote a) (quote a)) is #t but (eq? (quote (a)) (quote (a)))
is #f? I would expect that if (quote (a)) was a mutable pair but it
is not since (quote (a)) returns #f. It seems that guile returns #t
as I was expecting.
--
You received this message because you are subscribed to the Google
For reasons that are unclear to me, hash-keys and dict-keys both return a
list? instead of a set? (frankly, this seems like a bug in the API...).
Is there a something I can do that's more efficient than just calling
list->set?
--
You received this message because you are subscribed to the Goog
On 8/17/19, Philip McGrath wrote:
> This contest is a bright idea, so here's a standard lightbulb:
> [image: default-lightbulb.png]
> The code is at
> https://gist.github.com/LiberalArtist/4d0059f5af23043515a3cc74bd4928c2
>
> -Philip
I used standard-lightbulb in a slideshow [1].
Thank you Phil f
Hi!
If you right click on an identifier in drracket you get “jump to binding
occurrence” and “jump to definition” (if it’s defined in another file). Don’t
those do what you want?
Regards,
Niklas
> 24 okt. 2019 kl. 17:46 skrev Hendrik Boom :
>
> What tools are there to help understand large R
No problem, I’m glad you asked. It’s not included, and it’s not planned:
I’d rather leave this to some other package to keep things modular. There
already is a kind of paredit-y package for VS code, but it hasn’t seen an
update in a while (I believe). I think the author focuses more on his
exte
Yep! That was it. Thanks.
On Fri, Oct 25, 2019 at 2:43 AM Eric Griffis wrote:
>
> Maybe pipe ports?
>
> https://docs.racket-lang.org/reference/pipeports.html
>
> Eric
>
>
> On Thu, Oct 24, 2019, 11:28 PM David Storrs wrote:
>>
>> I saw something in the Reference about bi-directional {pipes |
>
20 matches
Mail list logo
