Re: [racket-users] Multiple namespaces in Racket

[Alexis King]

> 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 the problem?

Theoretically, yes. It still doesn’t solve the shadowing problem, but
that seems essentially impossible to do in a totally transparent way.
The main unfortunate thing, however, is that `#%module-begin` doesn’t
know what its module language is. One could theoretically export a
different `#%module-begin` from each of hackett/private/kernel,
hackett/base, and hackett (the three module languages Hackett provides),
each of which introduces a different unhygienic `require`. The downside
to this is that a user extending `#lang hackett` to make a new `#lang`
would likely reuse Hackett’s `#%module-begin`, and they’d be in for a
real surprise when they discovered their types weren’t available in
their new `#lang`!

(It will also probably do strange things when interacting with module*
submodules with #f for the module path, but that can be hacked around —
the implementation of namespaces already does plenty of that.)

-- 
You received this message because you are subscribed to the Google Groups 
"Racket Users" group.
To unsubscribe from this group and stop receiving emails from it, send an email 
to racket-users+unsubscr...@googlegroups.com.
For more options, visit https://groups.google.com/d/optout.

Re: [racket-users] Multiple namespaces in Racket

[Philip McGrath]

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), instead of doing it with the reader, solve at least
this part of the problem?

Furthermore, making this change in the reader causes serious issues when
> using `hackett` as a module language explicitly, not as a `#lang`. This
> is not common when writing most modules, since modern Racket style is to
> always use `#lang`, but module languages still crop up when defining
> submodules. This means a user defining a submodule with `hackett` as the 
> module
> language with have to manually insert the `require`, since there is no
> reader control to introduce it implicitly. This is a wart I have not yet
> been able to resolve.

-- 
You received this message because you are subscribed to the Google Groups 
"Racket Users" group.
To unsubscribe from this group and stop receiving emails from it, send an email 
to racket-users+unsubscr...@googlegroups.com.
For more options, visit https://groups.google.com/d/optout.

Re: [racket-users] Multiple namespaces in Racket

[Alexis King]

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! The solution involved a
 change to splicing-syntax-parameterize[1] that improves how it
 handles submodules, plus using make-syntax-delta-introducer instead
 of make-syntax-introducer to preserve the scope across module
 instantiations (thanks to Matthew for that).

  3. Scribble is going to be hard. Hackett builds and the tests pass
 (though the code isn’t the prettiest), and I can even get the docs
 to render, but all the cross-references are broken for types.

 This is hard, because in Hackett, there is a syntactic distinction
 between which pieces of syntax need to be in which namespace.
 Consider expanding the type annotation form:

   (:  )

 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 information of the source syntax.
 If a `Tuple` type has a data constructor that is also named
 `Tuple`, there is no way for Scribble to know which binding to use.

 I don’t know that this is fixable, not without actually performing
 expansion as part of rendering documentation, and that isn’t
 possible in general because not every piece of typeset code is a
 self-contained program. It seems that the simple solution, to avoid
 needing to reinvent half of Scribble right now, is to annotate
 which bindings are types.

 I’ve managed to get *almost* there by prefixing all the type
 imports with `t:` and binding them to an element transformer
 produced by `make-element-id-transformer` that typesets them
 without the prefix. The trouble is that this doesn’t work with
 scribble/example, since, as far as I can tell, there are not any
 “eval/example transformers” that allow me to tell scribble/example
 to use a symbol without the prefix for evaluation. I’m not sure if
 there’s a better way, and if there isn’t, I’m not sure how hard
 that would be to add.

Those issues aside, multi-namespace Hackett works decently. Again, there
are some unsolved subtleties around the user interface for
hiding/renaming types, but I think those are entirely solvable with
custom require transformers. Check Syntax has no trouble understanding
the more complex binding structure of multi-namespace programs. Interop
with Racket is awkward, since Racket requires flattening the two
namespaces, but this is also solvable by prefixing types when importing
them into a Racket module (and I imagine this will be much less of a
problem once Hackett has a real FFI, so less needs to be done in Racket
to wire the two sides together).

Those interested in the guts of how this works can check out the
“namespaces” branch of the Hackett repo[2]. Of course, that branch will
eventually go away, so that link will eventually break, but my hope is
that it will go away because it has been be merged into Hackett, not
because I’ve given up. In the meantime, any thoughts are appreciated,
especially if you have any suggestions on solving the Scribble problem.

Alexis


[1]: 
https://github.com/racket/racket/commit/1e38918aa9719d212534d2027aa1a3a8b46462dd
[2]: https://github.com/lexi-lambda/hackett/tree/namespaces

-- 
You received this message because you are subscribed to the Google Groups 
"Racket Users" group.
To unsubscribe from this group and stop receiving emails from it, send an email 
to racket-users+unsubscr...@googlegroups.com.
For more options, visit https://groups.google.com/d/optout.

[racket-users] Re: code reflection

[George Neuner]

On Mon, 16 Oct 2017 17:11:53 -0400, Matthias Felleisen
 wrote:

>> On Oct 16, 2017, at 2:17 PM, George Neuner  wrote:
>
>> Lisp's macros are ... I won't say easier to use correctly, because
>> they aren't ... but IMO they are easier to understand and think about
>> because the input is just a tree of normal Lisp objects that can be
>> manipulated using normal Lisp functions.  No dichotemy of "this is
>> syntax" vs "that is data", and no bridges to cross between two
>> different representations.
>
>
>Lisp macros are easier than Racket’s in the same way that it 
>was so much easier to write procedures in ASM than in Pascal. 
>It was so much easier to manipulate bit patterns directly, 
>why bother calling some Integer and others Chars. 

I think maybe you overlooked where I said "use correctly".
Non-hygienic macros are much easier to write ... but they are also
much easier to f_ up and do something unexpected when used.

In any case, it was not my intent to start a religious war here.
Scheme's macros work as they do for a reason [and yes! I do know the
reason].  I don't necessarily have to like it though, nor do I have to
say that I do.

I have read "Fear of Macros".  Long ago in fact.  I don't fear macros
at all ... I'm a [getting old] compiler geek and what I fear is to
lack understanding of what's going on under the hood.  Lisp is pretty
transparent about it's IR internals ... Scheme not so much.

George

-- 
You received this message because you are subscribed to the Google Groups 
"Racket Users" group.
To unsubscribe from this group and stop receiving emails from it, send an email 
to racket-users+unsubscr...@googlegroups.com.
For more options, visit https://groups.google.com/d/optout.

Re: [racket-users] code reflection

[Matthias Felleisen]

> On Oct 17, 2017, at 1:35 PM, Alexis King  wrote:
> 
> 
> I agree that it would be nice to have a better introduction to Racket’s
> macro-writing facilities that starts with basics and scales to advanced
> topics (the syntax-rules/syntax-case/syntax-parse duplicity is
> confusing, and a lot of useful utilities are tucked away in the syntax
> collection), and maybe the fact that no such resource exists is an
> indication that Racket’s macro system is too complicated. But that
> conclusion confuses me, since I know myself and others have been able
> to pick things up with a little bit of tinkering, so surely that same
> learning process can be captured somehow, right? I’m not sure.



I think what we’re really seeing here is that backwards compatibility
sometimes smothers elegant solutions.  I firmly believe that in this 
case we should simply throw out syntax-rules and syntax-case 

;; - - - 

The fact that no proper introduction to our syntax system is a chicken
and egg problem. We need to cut away the crud and settle on what 
to describe. And it is a personnel problem. 

When Ryan studied with me, I seriously hoped that he would write
down his vast volumes of insights as a book. I proposed several 
different forms and I think he wants to do it. So it’s hard to jump in.

Matthew does not believe in books. 

Other Matthew has written a book from a particular angle. It’s
beautiful but clearly leaves an unsatisfied need behind. 

Stephen should do it. But he doesn’t even have time for coffee. 

I have no time and my macro thinking is too sporadic. 
So I have decided to develop yet another course next
semester .. and it is called “Hack Your Own Language.” 
Perhaps this will help. 

— Matthias

-- 
You received this message because you are subscribed to the Google Groups 
"Racket Users" group.
To unsubscribe from this group and stop receiving emails from it, send an email 
to racket-users+unsubscr...@googlegroups.com.
For more options, visit https://groups.google.com/d/optout.

Re: [racket-users] Multiple namespaces in Racket

[Matthias Felleisen]

> 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 the Google Groups 
"Racket Users" group.
To unsubscribe from this group and stop receiving emails from it, send an email 
to racket-users+unsubscr...@googlegroups.com.
For more options, visit https://groups.google.com/d/optout.

Re: [racket-users] code reflection

[Alexis King]

I’ve noticed that the Racket macro system seems to have a reputation for
being impenetrably complicated, which I do not fully understand. Hackett
has, indeed, exposed a great deal of complexity, but Hackett is not an
ordinary macro, and I found writing macros with syntax/parse to be quite
pleasant long before I had any real idea of what was happening under the
hood.

My macro style has evolved considerably as I’ve grown accustomed to all
the bells and whistles of syntax/parse, but even when I was beginning,
I never had any real desire to fall back to stx-car, stx-cdr, and
friends. I agree with Matthias that syntax-parse seemed like an obvious,
objective improvement over syntax-case — in the simplest case, if you
avoid all its features, it is identical to syntax-case with slightly
better error messages — and the features it provided were declarative
and easy to use. Things that were obnoxious with syntax-case become
trivial with syntax-parse without needing to learn anything of great
complexity, especially things like ~optional.

My early macro code[1] was certainly not beautiful, tending to use a lot
of define/with-syntax and never really using syntax classes at all.
Still, I think that’s intrinsic to learning any new thing, and I’d
imagine it’s the case for traditional Lisp macros as well. (It’s
unfortunate that things like syntax-local-introduce are necessary for
certain macros, since I found syntax-local-introduce highly confusing
before I understood more about Racket’s hygiene model, but it isn’t
necessary for the vast majority of small macros.)

I agree that it would be nice to have a better introduction to Racket’s
macro-writing facilities that starts with basics and scales to advanced
topics (the syntax-rules/syntax-case/syntax-parse duplicity is
confusing, and a lot of useful utilities are tucked away in the syntax
collection), and maybe the fact that no such resource exists is an
indication that Racket’s macro system is too complicated. But that
conclusion confuses me, since I know myself and others have been able
to pick things up with a little bit of tinkering, so surely that same
learning process can be captured somehow, right? I’m not sure.

Alexis

[1]: 
https://github.com/lexi-lambda/racket-alexis/blob/0268afb688231e0d6d76ded3291538dd5d3db37c/alexis-util/alexis/util/struct.rkt

-- 
You received this message because you are subscribed to the Google Groups 
"Racket Users" group.
To unsubscribe from this group and stop receiving emails from it, send an email 
to racket-users+unsubscr...@googlegroups.com.
For more options, visit https://groups.google.com/d/optout.

Re: [racket-users] European Racketeers and conferences

[Ben Greenman]

I just changed the map settings so anyone can edit it.

If you'd like to add your city to the map:

1. Look for "racketeers.csv" in the menu
2. Click the "vertical dots" to the right of "racketeers.csv". (If you
hover the mouse over these dots, it should say "Layer Options")
3. Click "Open Data Table"
4. Right-click any row, choose "Add Row"
5. Add yourself, hit enter

Here's the link again:
https://drive.google.com/open?id=1i3zN11e_6te5ytduAiv1cidrIi4=sharing

-- 
You received this message because you are subscribed to the Google Groups 
"Racket Users" group.
To unsubscribe from this group and stop receiving emails from it, send an email 
to racket-users+unsubscr...@googlegroups.com.
For more options, visit https://groups.google.com/d/optout.

Re: [racket-users] code reflection

[Matthias Felleisen]

> On Oct 17, 2017, at 2:36 AM, Konrad Hinsen  wrote:
> 
> On 16/10/2017 23:11, Matthias Felleisen wrote:
> 
>> Lisp macros are easier than Racket’s in the same way that it
>> was so much easier to write procedures in ASM than in Pascal.
> 
> Having used both, I fully agree, but I also wonder if it is possible to 
> restore *some* of the simplicity of Lisp macros in Racket.
> 
> A major point for me is that in Lisp, I use the same language and library 
> functions in macros and in plain data-munging functions. In Racket, I have to 
> remember a completely different set of library functions for working with 
> syntax objects. I write much fewer macros than plain functions, so every time 
> I work on a macro, I end up looking up much of the basic syntax-object 
> manipulators again.
> 
> A related point is the extensive use of pattern matching and pattern 
> variables in syntax-parse. It's not hard to see their advantages, but for 
> someone who uses them twice a year, it's a cognitive burden rather than a 
> helpful tool.
> 
> I have played with the idea of writing an interface layer that lets me apply 
> plain list manipulations to the datum layer of syntax objects. I never got 
> around to work on this seriously, both because of the 24-hour-per-day limit 
> that I cannot seem to get rid of, and because I expect to get stuck in some 
> subtleties of the macro system as so often before.
> 
> Does this idea sound doable to the Racket macro masters? It would allow 
> people to trade efficiency in macro writing for a more gentle learning curve, 
> as opposed to syntax-rule that offers simplicity in exchange for restrictions 
> in what can be done.

It’s quite doable but I think this misses the point (and I am especially 
surprised that a master of types would bring this up). 

Let me record in public  a couple of steps of the evolution of macro concepts 
and the motivation behind these steps. This is basically an excerpt from a 
proposal I recent wrote for the Racket core team. 

Here is a Lisp-style macro for the well-know let form (this has basically been 
the same from the 60s till now): 

;;  S-expression -> S-expression
;; ASSUME (A)
;;  e == 
;;  (let ((lhs rhs) ...) body ...)
;; PRODUCE (P)
;;  ((lambda (lhs ...) body ...)
;;   rhs …)
;; ASSUME:
;; (A1) lhs ... are identifiers 
;; (A2) rhs ..., body ... are expressions 
(define-macro (let e)
  (define decl (cadr e))
  (define lhs  (map car decl))
  (define rhs  (map cadr decl))
  (define body (cddr e))
  ;; return 
  `((lambda ,lhs ,@body) ,@rhs))

Notice that none of the assumptions are checked: neither A nor B nor A1 nor A2. 
It is not hard to add this code but it is equally easy to see that this kind of 
checking code shows up over and over again. You want __abstraction__ (eliminate 
repeated code) and __type classification__ (code vs S-expressions). if you are 
a Racketeer or any developer who’s breathing in the 2010s. 

So here we go: 

(define-syntax (let stx)
  (syntax-case stx ()
[(let ((lhs rhs) ...) body ...)
 #'((lambda (lhs ...) body ...) rhs …)]))

Notice that this still does not check A1 and A2. Again, you can add the rules 
that catch bad patterns and whatever, and when you have all of let covered you 
have like 40 or 50 lines. 

So you want more abstraction: 

  (define-syntax (our-let stx)
(syntax-parse stx
  [(let ((x:id rhs:expr) ...) body:expr ...)
   #'((lambda (x ...) body ...) rhs ...)])) 

As you can see every step lifts the level of language to a new level. And just 
like we don’t teach kids ASM first to study bad PL design from that angle 
(anymore), we don’t really want to fall back to syntax-car and syntax-cdr (even 
though we could). 

Does this help with why going back to MACRO ASM is possibly not the right 
thing? — Matthias






-- 
You received this message because you are subscribed to the Google Groups 
"Racket Users" group.
To unsubscribe from this group and stop receiving emails from it, send an email 
to racket-users+unsubscr...@googlegroups.com.
For more options, visit https://groups.google.com/d/optout.

Re: [racket-users] European Racketeers and conferences

[Matthias Felleisen]

Well I am sure glad we reached two dozens :-) 


> On Oct 17, 2017, at 11:35 AM, Ben Greenman  
> wrote:
> 
> Here's a map to some cities where some Racket users are located:
> 
> https://drive.google.com/open?id=1i3zN11e_6te5ytduAiv1cidrIi4=sharing
> 
> -- 
> You received this message because you are subscribed to the Google Groups 
> "Racket Users" group.
> To unsubscribe from this group and stop receiving emails from it, send an 
> email to racket-users+unsubscr...@googlegroups.com.
> For more options, visit https://groups.google.com/d/optout.

-- 
You received this message because you are subscribed to the Google Groups 
"Racket Users" group.
To unsubscribe from this group and stop receiving emails from it, send an email 
to racket-users+unsubscr...@googlegroups.com.
For more options, visit https://groups.google.com/d/optout.

Re: [racket-users] European Racketeers and conferences

[Ben Greenman]

Here's a map to some cities where some Racket users are located:

https://drive.google.com/open?id=1i3zN11e_6te5ytduAiv1cidrIi4=sharing

-- 
You received this message because you are subscribed to the Google Groups 
"Racket Users" group.
To unsubscribe from this group and stop receiving emails from it, send an email 
to racket-users+unsubscr...@googlegroups.com.
For more options, visit https://groups.google.com/d/optout.

Re: [racket-users] Re: code reflection

[David Storrs]

On Tue, Oct 17, 2017 at 2:36 AM, Konrad Hinsen
 wrote:
>  I never got
> around to work on this seriously, both because of the 24-hour-per-day limit
> that I cannot seem to get rid of,

When you figure that one out, don't forget to open source your
solution, okay?  Or, at the very least, patent it and sell licenses.
I'll be first in line.

-- 
You received this message because you are subscribed to the Google Groups 
"Racket Users" group.
To unsubscribe from this group and stop receiving emails from it, send an email 
to racket-users+unsubscr...@googlegroups.com.
For more options, visit https://groups.google.com/d/optout.