Assuming that the lookup function for type environments is isolated and in one
place, it looks to me like the effort is equivalent: create one function.
But since we have an expensive way of forging these identifiers, we could also
argue we should get a cheap one, just in case someone else nee
Adding an operation to construct the identifier directly makes sense to
me, and I can see how it might be more convenient to construct an
identifier instead of changing the comparisons.
At Thu, 23 May 2013 18:08:09 -0700, Eric Dobson wrote:
> Right, but why cannot we forge an identifier easily? I'
Right, but why cannot we forge an identifier easily? I'm happy getting
an armed identifier. What are the reasons for preventing such a
construction?
On Thu, May 23, 2013 at 6:04 PM, Carl Eastlund wrote:
> Essentially yes. It doesn't do anything else, but it needs an identifier to
> do it. Curre
Essentially yes. It doesn't do anything else, but it needs an identifier
to do it. Currently, TR starts with a module and a symbol, goes through an
expensive process to forge an identifier from them, just to call
free-identifier=? to compare based on the module and the symbol after all.
Doing the
Isn't that exactly what free-indentifier=? is checking for on
identfiers with a module level binding? Or is there something else it
does?
On Thu, May 23, 2013 at 3:13 PM, Carl Eastlund wrote:
> On Thu, May 23, 2013 at 4:13 PM, Ryan Culpepper wrote:
>>
>> On 05/23/2013 01:57 AM, Eric Dobson wrote
On Thu, May 23, 2013 at 4:13 PM, Ryan Culpepper wrote:
> On 05/23/2013 01:57 AM, Eric Dobson wrote:
>
>> Some modules have macros which expand into identifiers that are not
>> exported, as they want to protect those bindings. TR currently has the
>> following code which allows it to generate an i
On 05/23/2013 01:57 AM, Eric Dobson wrote:
Some modules have macros which expand into identifiers that are not
exported, as they want to protect those bindings. TR currently has the
following code which allows it to generate an identifier which is
free-identifier=? to what would appear in the out
This sounds like the right solution to me too.
Robby
On Thursday, May 23, 2013, Matthias Felleisen wrote:
>
> +1
>
>
> On May 23, 2013, at 9:42 AM, Carl Eastlund >
> wrote:
>
> >
> > On Thu, May 23, 2013 at 9:39 AM, Matthias Felleisen <
> matth...@ccs.neu.edu > wrote:
> >
> > On May 23, 2013, at
On May 23, 2013, at 9:42 AM, Sam Tobin-Hochstadt wrote:
> Given that we're currently working on splitting the entire system to
> make this dependency impossible, I don't think this is a viable option
> currently.
Perhaps that's a mistake.
_
Racket Developers list:
+1
On May 23, 2013, at 9:42 AM, Carl Eastlund wrote:
>
> On Thu, May 23, 2013 at 9:39 AM, Matthias Felleisen
> wrote:
>
> On May 23, 2013, at 9:34 AM, Sam Tobin-Hochstadt wrote:
>
> >> 2. Is it possible that we could solve the problem via a bootstrapping-only
> >> violation of our poli
On Thu, May 23, 2013 at 2:39 PM, Matthias Felleisen
wrote:
>
> On May 23, 2013, at 9:34 AM, Sam Tobin-Hochstadt wrote:
>
>>> 2. Is it possible that we could solve the problem via a bootstrapping-only
>>> violation of our policy that you can add types to Racket w/o modifying
>>> existing modules
On Thu, May 23, 2013 at 9:39 AM, Matthias Felleisen wrote:
>
> On May 23, 2013, at 9:34 AM, Sam Tobin-Hochstadt
> wrote:
>
> >> 2. Is it possible that we could solve the problem via a
> bootstrapping-only violation of our policy that you can add types to Racket
> w/o modifying existing modules?
>
On May 23, 2013, at 9:34 AM, Sam Tobin-Hochstadt wrote:
>> 2. Is it possible that we could solve the problem via a bootstrapping-only
>> violation of our policy that you can add types to Racket w/o modifying
>> existing modules?
>
> No. We can't specify types inside `racket/base` without maki
On Thu, May 23, 2013 at 2:29 PM, Matthias Felleisen
wrote:
>
> 1. At some point, we had a macro that opened up modules and made all
> module-level identifiers available. Wouldn't a flavor of this macro work here
> and, if so, wouldn't it be cheaper? Or is this what you call dumpster-diving,
> t
1. At some point, we had a macro that opened up modules and made all
module-level identifiers available. Wouldn't a flavor of this macro work here
and, if so, wouldn't it be cheaper? Or is this what you call dumpster-diving,
traversing the expansion and extracting ids from there?
2. Is it pos
On Thu, May 23, 2013 at 1:54 PM, Matthias Felleisen
wrote:
> Can you raise the level of discourse one level and perhaps figure out whether
> this is needed at all? I.e., find a different way to solve the problem? (What
> is the real problem?)
This is important, and it's the second implementatio
Felleisen
To: Eric Dobson
Cc: dev
Sent: Thu, 23 May 2013 08:54:36 -0400 (EDT)
Subject: Re: [racket-dev] Constructing an identifier to an unexported binding
This has a scary feeling to it.
Can you raise the level of discourse one level and perhaps figure out whether
this is needed at all? I.e
This has a scary feeling to it.
Can you raise the level of discourse one level and perhaps figure out whether
this is needed at all? I.e., find a different way to solve the problem? (What
is the real problem?)
On May 23, 2013, at 1:57 AM, Eric Dobson wrote:
> Some modules have macros whi
Some modules have macros which expand into identifiers that are not
exported, as they want to protect those bindings. TR currently has the
following code which allows it to generate an identifier which is
free-identifier=? to what would appear in the output of the macros.
define (make-template-ide
19 matches
Mail list logo
