Right: it's the known unknowns that I'm worried about :)
On Sat, Mar 5, 2016 at 5:29 PM, Vincent St-Amour
wrote:
> Right, I understand that.
>
> Are any syntax properties used as heavily as source locations, though?
>
> Vincent
>
>
>
> On Sat, 05 Mar 2016 17:23:01 -0600,
> Robby Findler wrote:
>>
At Sat, 5 Mar 2016 17:20:55 -0600, Robby Findler wrote:
> What would happen if you add a property as ephemeral and then add it
> again as non-emphemeral? It would just change modes? I guess we could
> add a "is this property added to this syntax object ephemerally or
> not?" predicate?
Yes.
> I f
As a concrete example, I think 'origin tracking should be ephemeral.
Why would an 'origin property end up on quoted syntax? I'm not entirely
sure, but I tried adding check on bytecode writing for a fresh `raco
setup`, and it apparently happens, even in the bootstrapping phase.
At Sat, 05 Mar 2016
Right, I understand that.
Are any syntax properties used as heavily as source locations, though?
Vincent
On Sat, 05 Mar 2016 17:23:01 -0600,
Robby Findler wrote:
>
> Our experience with the source location change suggests that there are
> many places where code is implicitly relying on syntax
Our experience with the source location change suggests that there are
many places where code is implicitly relying on syntax properties not
being preserved in byte code. This entire thread is inspired by one
such (errortrace performance), and I know that I fixed several
lingering bugs like this in
What would happen if you add a property as ephemeral and then add it
again as non-emphemeral? It would just change modes? I guess we could
add a "is this property added to this syntax object ephemerally or
not?" predicate?
I feel like this variant is more error prone (as you can forget one
syntax-
What would be use cases for ephemeral properties?
I agree that most properties wouldn't need to be preserved, but I can't
think of a case where we would want to explicitly not have a property be
preserved.
That, and having two kinds of syntax properties would be potentially
confusing. Your third
Your characterization suggests another possibility: an optional
argument when setting a property to indicate whether the setting is
ephemeral.
That is, we would still have one function for ephemeral or not, but the
difference would be selected by an extra argument, instead selected by
the shape of
I like your third option best, too. It makes sense to me to think of
this as two separate, but related operations (add ephemeral property,
add preserved property) and to avoid adding a new primitive function,
but just generalize one of the arguments for the existing one. That
is, the code that choo
I agree that both of those are potential issues. I'd expect problems,
but I don't know how common the problems would be.
I think we would probably end up wanting ephemeral properties, anyway,
so it makes more sense to be to leave ephemeral as the default and add
a non-ephemeral option.
At Sat, 5
Is avoiding the change to preserve of all properties a backwards
compatibility concern or a performance one? (I wouldn't ask, except
there were a surprising number of bugfixes for the source location
change.)
Robby
On Sat, Mar 5, 2016 at 8:09 AM, Matthew Flatt wrote:
> At Thu, 03 Mar 2016 11:00
At Thu, 03 Mar 2016 11:00:23 -0600, Vincent St-Amour wrote:
> On Wed, 02 Mar 2016 22:23:29 -0600,
> Matthew Flatt wrote:
> > Instead of using the existence of a source location to determine where
> > to add instrumentation, debugging should be based on the details of the
> > source location. I'm no
12 matches
Mail list logo
