All,
Thanks for help debugging and explaining this.
FYI, with Matthew's bug fix merged, and help from Alexis, I've managed to work
around my issue. It was pretty much the same issue described in thread linked
to by Dupéron,
https://groups.google.com/forum/#!topic/racket-users/TGax2h8dVxs, and
> What are the implications of this for the Types as Macros/Turnstile
stuff?
As William mentioned, he's also working on a language using the Types
as Macros approach. Alex and I have run into the same issue, but it's
always with compiled files (without compiling, requires and provides
appear to
Le jeudi 15 décembre 2016 00:48:13 UTC+1, Alexis King a écrit :
> without much issue, modulo an issue I asked about on this mailing
> list a month or two back
Here's (what I suspect is) the thread Alexis mentions, for those who feel
curious:
On Wed, Dec 14, 2016 at 03:50:28PM -0800, Alexis King wrote:
> What are the implications of this for the Types as Macros/Turnstile
...
>
> (Obviously, I have a personal motive for asking this question, since
Based on the names of functions in my example, you'd never guess how I ran into
this
> On Dec 14, 2016, at 7:14 AM, Matthew Flatt wrote:
>
> To summarize, don't try to attach syntax objects as property values
> like that. I know this advice sounds ironic, given that the original
> use of properties was for syntax-valued keys like 'origin. Properties
> like
At Wed, 14 Dec 2016 10:43:34 -0700, Matthew Flatt wrote:
> But right now, as Sam well knows
I'd like to clarify that this is because Sam has been very helpful in
making things better --- not that he's been asking for new things.
--
You received this message because you are subscribed to the
Yes, it's obviously easier to implement this new feature with the new
expander.
But right now, as Sam well knows, I'm open to patches only as long as
they make things no slower and no bigger. :) The current implementation
is reliably within a factor of 2 of the old one, but we're still
working to
> On Dec 14, 2016, at 10:23 AM, Sam Tobin-Hochstadt
> wrote:
>
> On Wed, Dec 14, 2016 at 10:14 AM, Matthew Flatt wrote:
>> More generally, changes to the scope of a
>> syntax object are not propagated to property values that happen to be
>> themselves
On Wed, Dec 14, 2016 at 10:14 AM, Matthew Flatt wrote:
> More generally, changes to the scope of a
> syntax object are not propagated to property values that happen to be
> themselves syntax objects. When you put a syntax object into a
> property, then you get whatever that
I think there are two problems in this example.
The first problem is that preserved syntax properties were not actually
preserved in bytecode for a syntax object that has no source location.
(I'm assuming that Alexis's tests were run in DrRacket in it's default
mode of compiling bytecode for
> On Dec 13, 2016, at 11:23 AM, 'William J. Bowman' via Racket Users
> wrote:
>
> Notice that #'x is not the same identifier as x, and thus does not
> have the same syntax-properties.
I’m not convinced this is correct.
If you insert println statements in the body
11 matches
Mail list logo