> https://lexi-lambda.github.io/blog/2017/10/27/a-space-of-their-own-adding-a-type-namespace-to-hackett/
Nice summary. Whoever writes the great macro programming book in the sky
would do well to review this post. Good work as usual Alexis.
--
Anthony Carrico
--
You received this message becaus
This is now merged, and I ended up managing to simplify the
implementation somewhat, though the bulk of the changes were still
necessary. I’ve written up the details of how it works in a blog post
here:
https://lexi-lambda.github.io/blog/2017/10/27/a-space-of-their-own-adding-a-type-namespace-to-h
> On Oct 18, 2017, at 1:08 PM, Matthias Felleisen
> wrote:
>
> What I imagined was that you’d define @h-examples, which would
> translate the former into the latter. — Matthias
I finally did this and got everything working, mostly. I have opened a
pull request with the current state of the names
> On Oct 18, 2017, at 4:04 PM, Alexis King wrote:
>
>
>@(examples
> (: (Tuple 42 "hello") (#,t:Tuple Integer String)))
>
> That’s because the `examples` form doesn’t allow escaping, which makes
> sense, since there would be no way to know what `#,t:Tuple` should mean
> when performin
> On Oct 18, 2017, at 8:09 AM, Matthias Felleisen
> wrote:
>
> Wouldn’t something like this work for Hackett?
I don’t think so. Perhaps it would be better illustrated with an
example.
First, consider the Hackett definition of, say, the `Maybe` type:
(data (Maybe a) (Just a) Nothing)
This
> On Oct 17, 2017, at 11:02 PM, Alexis King wrote:
>
>It’s obvious that should be in the value namespace and
> should be in the type namespace. When expanding code, this
> makes things easy, but Scribble doesn’t expand its code examples,
> it merely looks at the lexical informa
> On Oct 17, 2017, at 20:11, Philip McGrath
> wrote:
>
> It wouldn't solve the problem with shadowing `require`d identifiers,
> but would having `#%module-begin` introduce the `require` (with proper
> lexical context information), instead of doing it with the reader,
> solve at least this part of
On Tue, Oct 17, 2017 at 10:02 PM, Alexis King wrote:
>
>
> 1. The issue with module language imports still seems hopeless.
It wouldn't solve the problem with shadowing `require`d identifiers, but
would having `#%module-begin` introduce the `require` (with proper lexical
context information), i
I’ve been continuing to work on this for the past two days, and I’ve
managed to get a lot more working. I figured I’d write a (somewhat
shorter) summary of what I have and haven’t solved.
1. The issue with module language imports still seems hopeless.
2. I managed to solve the submodule issue
> On Oct 16, 2017, at 2:00 PM, Alexis King wrote:
>
> Apologies for the very long email, but this issue has ended up being much
> more nuanced than I had hoped
Thank you for taking the time to write this up. Fascinating — Matthias
--
You received this message because you are subscribed to
I ended up spending the majority of my weekend working on this, and even
after two days, it still doesn’t work quite right. My verdict is that
it seems impossible to do perfectly seamlessly, but it seems possible
(but maybe hard) to get 85% there. Here’s a (rather long) overview of
what I tried and
On Sun, Oct 15, 2017 at 03:43:42PM -0400, David Christiansen wrote:
> > It would probably cause trouble iif we ever were to generalize to
> > dependent types.
>
> Sure, but those same problems will be there anyway if the compile-time
> and run-time bindings live in separate namespaces and are allo
> Ultimately, though, that would mean that it would separate the runtime
> value and type namespaces, but now types and users’ phase 1 bindings
> would share the same namespace, which is still probably confusing and
> unintuitive. Maybe that’s okay? Again, I feel like I’d need to
> understand bette
> It would probably cause trouble iif we ever were to generalize to
> dependent types.
Sure, but those same problems will be there anyway if the compile-time
and run-time bindings live in separate namespaces and are allowed to
bind the same identifier to different things, as is done in languages
l
On Sun, Oct 15, 2017 at 11:59:47AM -0400, David Christiansen wrote:
> Hi Alexis,
>
> What about keeping type bindings separate from program bindings as a
> matter of phase? This seems to me to fit in with the Hindley-Milner
> program, where types exist only at compile time only, and programs
> exi
> On Oct 15, 2017, at 08:59, David Christiansen
> wrote:
>
> What about keeping type bindings separate from program bindings as a
> matter of phase? This seems to me to fit in with the Hindley-Milner
> program, where types exist only at compile time only, and programs
> exist at run time only.
I
Hi Alexis,
What about keeping type bindings separate from program bindings as a
matter of phase? This seems to me to fit in with the Hindley-Milner
program, where types exist only at compile time only, and programs
exist at run time only.
/David
--
You received this message because you are subs
> On Oct 13, 2017, at 18:52, Geoffrey Knauth wrote:
>
> Maybe do undisputedly?-evil name-mangling now to get things working,
> then become a saint with a better solution down the road. Sometimes
> I don't realize how to do something the "good" way until I've traveled
> down the path of doing it
On Friday, October 13, 2017 at 1:06:15 PM UTC-4, Alexis King wrote:
>
> At this point, though it is indisputably evil, it seems more feasible
> to use some name mangling scheme than to expand to a submodule. That
> would be, of course, deeply unsatisfying, so I would very much like to
> have a b
This is a cool demo! Unfortunately, I have been thinking about the
problem you describe since last night, and I am still totally stumped.
This is something that seems difficult or impossible to paper over with
more macros because #%require and #%provide are, ultimately, given
special treatment by t
> On Oct 12, 2017, at 6:31 PM, Alexis King wrote:
>
>> On Oct 12, 2017, at 1:46 PM, Matthew Flatt wrote:
>>
>> You could put all the type exports in a submodule. Then, you do need
>> your own variant of `require`, but that variant can mostly just check
>> for the presence of a type submodule,
> On Oct 12, 2017, at 1:46 PM, Matthew Flatt wrote:
>
> You could put all the type exports in a submodule. Then, you do need
> your own variant of `require`, but that variant can mostly just check
> for the presence of a type submodule, much the way that TR or
> `plai-typed` do. If the submodule
At Thu, 12 Oct 2017 12:59:17 -0700, Alexis King wrote:
> An alternative approach that
> I have considered (and discussed briefly with some people) is to
> introduce a “value” scope using make-syntax-introducer in
> #%module-begin, then use a separate “type” scope when parsing types to
> keep the tw
In discussions with some people at (seventh RacketCon), I managed to
solve a few open problems I had in my implementation of Hackett. One
thing I didn’t get a good answer for, however, is implementing a
language with multiple namespaces. Hackett is not dependently-typed, so
it is pointless and inco
24 matches
Mail list logo
