Re: [racket-users] udelim package -- more parens than you can shake a stick at

[Eli Barzilay]

On Sun, Sep 25, 2016 at 4:21 PM, William G Hatch  wrote:
>
>> Yes, and you can do all of that with just a string, which you can
>> still get from an @-form -- just throw a syntax error if it's not all
>> strings.  And with just that you get the *benefit* of ignoring
>> indentation which makes it possible to use your syntax in a sane way.
>
> I was doing that before, and I just didn't see that as a benefit.

This is even more confusing.  You started by saying that you *don't*
want nested expressions, just strings -- and now you don't see the
benefit of erroring on that, and furthermore:

> I do get runtime expressions.  I'm parsing the inner strings into
> syntax objects at macro expansion time, and some of those end up being
> themselves macro calls, and some of them are just normal expressions
> that are evaluated at runtime.

which means that you *do* want nested expressions after all--?

And you repeat this:

>> Yes, and you can get the same with any string, and
>>
>>(rash "stuff
>>   in a different
>>   language")
>
> Yeah, if you look at the rash docs you'll see that I have examples
> that do exactly that.  It's kind of the point that the macro can just
> use any string.  All the nestable string delimiters bring to the table
> for these macros is that it makes it easier to nest them without crazy
> escapes.

which makes me cringe yet again...  Given all of that, you basically are
using all of the features that @-expressions have.  If you could just
squint for a bit so that wherever it uses "{}"s you'd pretend it's
"«»"s, and wherever it uses "@" you'd pretend that you see a "$", you'd
see that you are going down the same path.  Only you choose to keep a
bit more parens on the way.

> Yes, I'm aware, but any character you choose ends up being a magic
> character through each nested level unless you use |{}|, which I
> didn't want.

Right -- but those are just different ways to write string delimiters
(and "@" too) -- so continue squinting and read "|{}|" as "“”" and "|@"
as "¢", and maybe "|={}=|" and "|=@" as "⌜⌝" and "♯" etc.  Same exact
idea, only (a) you're not limited to a choice from a few chosen
delimiters and instead can make up new ones, and (b) the syntax is
uniform at all levels so you (the end programmer) are not at the mercy
of the specific macro when it comes to deciding what delimiters to use.
That's, BTW, a *huge* win: uniformity at the *concrete* syntax level is
>>EXTREMELY<< important.  That's the main reason sexprs are so great,
and the main problem with the wild world of tex (not latex which uses
conventions more; tex -- where any character can mean anything).


> ;; starting in normal racket syntax, but with «» for convenience
> (filter foo?
>(python-ish-list-comprehend
> «thing for x in sqlish(«select * from foo») where some_pred(x)»))
>
> The example again is silly, but syntactically it needs neither $ nor @
> nor any other magic character.  The «» nesting quotes are just
> convenient to avoid \" nonsense (and \\", " if there were more
> nesting).

Sure it does!  The "@" is implicit in the fact that
`python-ish-list-comprehend` is a macro that parses its textual body;
the "{}" are replaced by their squinted versions; and there's something
(python-ish-list-comprehend, probably) that decides that a nested
parenthesized-string following an "sqlish", which is another implicit
"@".  It's all there, only implicit, which is not making your user's
lives any easier.


> As for $ in rash, I chose $ because I'm giving it *some* similarities
> to eg. bash.

Yes, I know.  Read my paper: I go into much more details on quasi-
strings with some unquote characters in contrast to @-forms where "@" is
serving a double purpose which makes traditional string interpolation
*unnecessary*.


> To escape just an identifier in rash (as opposed to a larger
> expression in parens), you can use $id, which you'll see if you look
> at the examples in theh rash docs.

... and then you need to face the question of what happens with
«...$blah...» given that "." is a valid character in a racket
identifier.  And a bunch of other little things.  (Rhetorical; No need
to reply with what you do with such things.)


> As an aside, eventually I plan on changing it so it creates a macro
> that will do different things than just escape, eg. $CAPS looks up
> environment variables rather than normal variables, and maybe $«*.ext»
> expands globs, etc.  But my point is that the $ is a feature of the
> rash language that I want, not some added complexity that I would want
> to avoid.

(Ha!  The idea that $... behaving in different ways is *reducing*
complexity is amusing.  Really.)


> So I'm not saying I want a different @-like character for each level
> down, but rather that I don't need any @-like character in the general
> case (just string delimiters, either normal or preferably nestable),
> and for rash in particular I want a magic character that does
> something 

Re: [racket-users] udelim package -- more parens than you can shake a stick at

[Eli Barzilay]

On Sun, Sep 25, 2016 at 2:19 PM, Matthew Butterick  wrote:
>
> On Sep 25, 2016, at 2:10 AM, Eli Barzilay  wrote:
>> *Don't* confuse scribble-the-documentation-system with the syntax --
>> the syntax is useful for many other cases, and designed to make sense
>> in other cases.  See my description (specifically section 4, which is
>> very relevant here), and the scribble/text and scribble/html
>> languages.
>
> To be fair, the documentation invites this kind of confusion. All the
> material about the at-reader is within the Scribble docs. This makes
> it look like it's dependent on Scribble, when really it's a separate
> thing.

Yes, I know, and yes, it could very much use a restructuring.


> In general, I think the word "Scribble" is misleadlingly overloaded
> within Racket. IMO "Scribble" should refer only to the family of
> languages that use the Scribble document model, including Racket
> documentation.

Well, it started with "scribble" being the name of the syntax, which
came first.  Then Matthew built the documentation system on top of it,
and that was also named "scribble".  When we realized that this is going
to be confusing, it was already clear that the latter meaning is already
"winning", so the syntax turned into @-forms, @-expressions etc -- I'm
probably the only one who still uses the first meaning from time to
time.  And yes, that's not a good name since it can be customized too,
but I don't see a good way out of it...


> At some point the docs for "Scribble as a Preprocessor" were broken
> out from the main Scribble docs — I'm guessing to emphasize that
> they're conceptually separate from Scribble. But AFAICT what they
> really have in common is the at-reader, not the document
> model. Because they don't use the Scribble document model, I'm unclear
> why they're called `scribble/text` and `scribble/html`.

That also made more sense in the early days, since `scribble` was
supposed to be the place for all scribble (the syntax) related things.


> Meanwhile, I'd argue that the at-reader — itself an obsolete name,
> since one can swap out the @ for any Unicode char — deserves to have
> its documentation broken out into a separate top-level section, which
> would more accurately reflect its status within Racket.

At some point I intended to take the paper I wrote about it and make it
into a separate documentation about the syntax, but I never got to
actually do it.


> + String splitting within {...} delimiters: I agree this is the right
>   default behavior, but it doesn't seem unreasonable to wish for
>   shorthand for when you really do want things concatenated into a
>   single argument, given that Racket is full of cognates like
>   let/let*, for/for*, list/list*, etc. That said, I don't have a good
>   idea what the notation would be.

For plain single-string use, I always encouraged using
`@string-append{...stuff...}`, but since this is horribly long, some
simple shorthand like (define ~ string-append) can be used.  For cases
when you want to look at the result of some @-expression as a single
value but not pay the huge price of accumulating intermediate strings, a
plain old `list` does fine -- and that's what `scribble/text` is doing.
With that, it's very useful not only to @list{...stuff...} but also to
just quote it with '@{...} -- or the equivalent @'{...}, and, of course,
everything that comes out of throwing @`{...} into the mix.


> + I wish at-expressions could use multiple [...] and {...} parts, in
>   any order.

Yeah, I considered it at some point, but decided to go with a more
restricted (but maximally useful) syntax to avoid possible problems and
maybe extended it later when needed.  The idea of what we ended up with
is that you can always tell where the @-expression ends by looking at
the {}s, or putting them yourself to avoid getting things mixed up with
the following text.

-- 
   ((x=>x(x))(x=>x(x)))  Eli Barzilay:
   http://barzilay.org/  Maze is Life!

-- 
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] udelim package -- more parens than you can shake a stick at

[William G Hatch]

On Sun, Sep 25, 2016 at 01:50:51PM -0700, Dupéron Georges wrote:

If I understand you well, the intended use of your nested delimiters can be 
more or less described as syntactic sugar for #reader, with auto-detection of 
where the string ends:

(filter foo?
   (python-ish-list-comprehend
«thing for x in sqlish(«select * from foo») where some_pred(x)»))

could be rewritten as:

(filter foo?
   #reader"python-ish-list-comprehend.rkt" thing for x in #reader"sqlish.rkt" select * 
from foo where some_pred(x)



That seems like a very reasonable way of looking at it I it.

Here is a little step through of what my rash macro does:

(define pwd-var "pwd")
(rash «ls $(rash/trim «dirname $(rash/trim «$pwd-var»)»)»)

;; after one step of expansion, this looks something like this:
(rash-line-parse 'ls (rash/trim «dirname $(rash/trim «$pwd-var»)»))
;; rash-line-parse would expand to (run-pipeline ...) or (begin ...) if
;; there were multiple lines, but if we pretend that the inner macro
;; would expand first, it would be
(rash-line-parse 'ls (
 (rash-line-parse 'dirname (rash/trim «$pwd-var»
;; then
(rash-line-parse 'ls (
 (rash-line-parse 'dirname
  (
   ;; the $ in rash keeps pwd-var from 
being quoted
   (rash-line-parse pwd-var)

So each rash macro reads another layer of string (each one needing a $
due to the syntax specifics of the rash language), but nested strings
will still become strings after applying the reader again, while other
things will become symbols, s-expressions...  So you could also use \"
and \\" instead of «», «» is just nicer.

So it is very much like your #reader example above.

William

--
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] udelim package -- more parens than you can shake a stick at

[Philip McGrath]

I second the idea that the documentation could be clearer on the difference
between "#lang scribble/base" and friends and what can be done with the
at-reader in general, as shown in languages like "scribble/text" and
"scribble/html". Despite having used both "scribble/base"-family languages
and tools like "make-at-readtable", I didn't realize until reading this
thread that "scribble/text" may be a better basis for several things I've
been trying to do.

On a related note, make-at-readtable accepts options for
"#:command-readtable" and "#:datum-readtable", but not for reading the body
of the @-form — though as I think about it, I guess that could be done
using "#:syntax-post-processor", right?

I'm still not 100% clear on what is supposed to happen at read-time vs.
expand-time vs. runtime in this example:
(filter foo?
(python-ish-list-comprehend
 «thing for x in sqlish(«select * from foo») where some_pred(x)»))
but I think those options might be able to construct something closer to
the udelim goal than plain at-epressions.

On Sun, Sep 25, 2016 at 3:50 PM Dupéron Georges 
wrote:

> If I understand you well, the intended use of your nested delimiters can
> be more or less described as syntactic sugar for #reader, with
> auto-detection of where the string ends:
>
> (filter foo?
> (python-ish-list-comprehend
>  «thing for x in sqlish(«select * from foo») where some_pred(x)»))
>
> could be rewritten as:
>
> (filter foo?
> #reader"python-ish-list-comprehend.rkt" thing for x in
> #reader"sqlish.rkt" select * from foo where
> some_pred(x)
>
> --
> Georges
>
> --
> 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] udelim package -- more parens than you can shake a stick at

[Dupéron Georges]

If I understand you well, the intended use of your nested delimiters can be 
more or less described as syntactic sugar for #reader, with auto-detection of 
where the string ends:

(filter foo? 
(python-ish-list-comprehend 
 «thing for x in sqlish(«select * from foo») where some_pred(x)»))

could be rewritten as:

(filter foo? 
#reader"python-ish-list-comprehend.rkt" thing for x in 
#reader"sqlish.rkt" select * from foo where 
some_pred(x)

-- 
Georges

-- 
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] udelim package -- more parens than you can shake a stick at

[William G Hatch]

On Sun, Sep 25, 2016 at 05:10:27AM -0400, Eli Barzilay wrote:

To be clear, no offense taken


That's good.  After I read "Eli bait" my mind took the rest as having
an annoyed tone, probably from reading too many online flame wars.
It's hard to tell people's emotions in text.

I think ultimately we just disagree on what features we want, but I'd
like to clarify a few misunderstandings:


Yes, and you can do all of that with just a string, which you can still
get from an @-form -- just throw a syntax error if it's not all strings.
And with just that you get the *benefit* of ignoring indentation which
makes it possible to use your syntax in a sane way.


I was doing that before, and I just didn't see that as a benefit.


Yes, and you can get the same with any string, and

   (rash "stuff
  in a different
  language")



Yeah, if you look at the rash docs you'll see that I have examples that
do exactly that.  It's kind of the point that the macro can just use any
string.  All the nestable string delimiters bring to the table for these
macros is that it makes it easier to nest them without crazy escapes.


using @-forms would be a tiny delta for the implementation -- basically
just a string-append (actually, not even a delta since your macro
already allows multiple strings), and the use is more convenient:

   @rash{stuff
 in a different
 language}


Well, my current macro doesn't allow multiple strings as you state,
but my previous macro when I was using at-expressions was exactly like
what you have there.


The only tricky bit here is that if you want to deal with only strings
and at the same time maintain a syntax-time parsing of strings, then you
need to do this whole multi-level collapsing as a macro thing, which
means no runtime expressions.


I do get runtime expressions.  I'm parsing the inner strings into
syntax objects at macro expansion time, and some of those end up being
themselves macro calls, and some of them are just normal expressions
that are evaluated at runtime.


Maybe the languages have very different views on which characters do
something special (or specifically should not do something special),
including flag characters like @ (or any one you choose at the top
level or a higher level up in the nesting).


Note that the scribble syntax uses "@" by default, but it's easy to
change, as Matthew B. did with pollen.


Yes, I'm aware, but any character you choose ends up being a magic
character through each nested level unless you use |{}|, which I
didn't want.



For example, something like this could happen:

(define some-output
 (rash/out
  «some-query $(first
(python-ish-list-comprehend
 «machine for i in machine-list where should-i-query(i)»))
  $(make-query
«this is a bogus example that I'm really stretching
 for, but maybe this is some nice syntax for some
 sort of query producing dsl? And maybe it has some
 macro in it in whatever its syntax is to
 (go-a-level-deeper «in this nonsense ...»)
 But importantly, no top-level reader has to know or
 care what the syntax here is, nor the rash reader,
 nor any reader in between, aside from simply
 preserving it as a string, which I can hopefully do
 in most any language.»)»))


And here you're falling into the trap I mentioned above.  You're trying
to use "$" as an escape, but, for example, what happens if you want to
escape a single identifier and not an expression?  Anyway, here's the
same thing using the scribble syntax:


The $ is an escape that rash has due to its design (because it
essentially quotes everything that doesn't have $), and is not
something that's generally necessary for any nested language that just
uses strings.  For example:

;; starting in normal racket syntax, but with «» for convenience
(filter foo?
   (python-ish-list-comprehend
«thing for x in sqlish(«select * from foo») where some_pred(x)»))

The example again is silly, but syntactically it needs neither $ nor @
nor any other magic character.  The «» nesting quotes are just
convenient to avoid \" nonsense (and \\", " if there were more
nesting).

As for $ in rash, I chose $ because I'm giving it *some* similarities
to eg. bash.  To escape just an identifier in rash (as opposed to a
larger expression in parens), you can use $id, which you'll see if you
look at the examples in theh rash docs.  As an aside, eventually I
plan on changing it so it creates a macro that will do different
things than just escape, eg. $CAPS looks up environment variables
rather than normal variables, and maybe $«*.ext» expands globs, etc.
But my point is that the $ is a feature of the rash language that I
want, not some added complexity that I would want to avoid.  So I'm
not saying I want a different @-like character for each level down,

Re: [racket-users] A Racket talk in Rubyconf Brazil

[Vincent St-Amour]

I agree! Nice overview.

Vincent


On Sun, 25 Sep 2016 13:31:59 -0400,
Matthias Felleisen wrote:
> 
> Looks like a cool talk. Thanks for sharing. 
> 
> On Sep 25, 2016, at 11:53 AM, Ronie Uliana 
> wrote:
> 
> 
> 
> 
> Hi, there!
> 
> 
> I gave a talk about Racket in Rubyconf Brazil yesterday (saturday
> 24).
> 
> 
> Here are the slides translated to English and here the original in
> Portuguese :)
> 
> 
> Not sure I gave the right importance to the right points, but people
> liked it a lot.
> 
> 
> Thank you all for the amazing job in the Racket!
> 
> 
> []s
> Ronie
> 
> 
> -- 
> 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.

-- 
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] Adding libraries to the student language search

[Spencer Florence]

When the current language is one of the student languages searching the
documentation from DrRacket limits the search to a subset libraries
installed. Is there any way to add a new library to this subset?

--Spencer

-- 
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: [ANN] New package: live-free-or-die

[Linh Chi Nguyen]

let its spirit live on,
for jay's big heart ^^

On Thursday, 22 September 2016 04:33:32 UTC+2, Jay McCarthy  wrote:
> I've just put a new package on the server: live-free-or-die
> 
> This package lets you escape from Typed Racket's contracts.
> 
> --
> 
> Here's a little example:
> 
> Suppose that "server.rkt" is:
> 
> ```
> #lang typed/racket
> 
> (: f ((Listof Float) -> Float))
> (define (f l)
>   (cond
> [(empty? l)
>  0.0]
> [else
>  (+ (first l)
> (f (rest l)))]))
> 
> (provide f)
> ```
> 
> And that "client.rkt" is:
> 
> ```
> #lang racket/base
> (require live-free-or-die)
> (live-free-or-die!)
> 
> (require "server.rkt")
> (f (vector 1 2 3))
> ```
> 
> Then this is what you get when you run the program:
> 
> $ racket "client.rkt"
> zsh: segmentation fault  racket "client.rkt"
> 
> For your convenience, `live-free-or-die!` is also aliased to
> `Doctor-Tobin-Hochstadt:Tear-down-this-wall!`
> 
> --
> 
> Enjoy!
> 
> -- 
> Jay McCarthy
> Associate Professor
> PLT @ CS @ UMass Lowell
> http://jeapostrophe.github.io
> 
>"Wherefore, be not weary in well-doing,
>   for ye are laying the foundation of a great work.
> And out of small things proceedeth that which is great."
>   - D 64:33

-- 
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] post racketcon '16: simulation of population playing PD game in Racket

[Linh Chi Nguyen]

Hello everyone,
So I thank again Matthias for the opportunity and everyone for the incredible 
hospitality.

I write down the script of my presentation, add notes, add the extra parts 
(that i said i didnt have time to show), link to code parts on github, and 
append a final part to answer Ben's question: why it drops? (turns out he is 
asking a bigger question he didnt know)

https://drive.google.com/file/d/0B-ReBF4UIaa9NlU4aUhjd3FISkU/view?usp=sharing

for other concerns, as i said, this project continues and is a very long way to 
go. so for now, with the help of Vincent and Jay :) i would continue to work 
and update github repo:

https://github.com/ayaderaghul/fsm-pd2

i dont know any way better to do this, so i write notes in slides and export 
them to pdf. if you know a better way so that the content can be read easier, 
please do tell me.

cheers,
chi

-- 
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] udelim package -- more parens than you can shake a stick at

[Matthew Butterick]

On Sep 25, 2016, at 2:10 AM, Eli Barzilay  wrote:
> *Don't* confuse scribble-the-documentation-system with the syntax -- the
> syntax is useful for many other cases, and designed to make sense in
> other cases.  See my description (specifically section 4, which is very
> relevant here), and the scribble/text and scribble/html languages.

To be fair, the documentation invites this kind of confusion. All the material 
about the at-reader is within the Scribble docs. This makes it look like it's 
dependent on Scribble, when really it's a separate thing.

In general, I think the word "Scribble" is misleadlingly overloaded within 
Racket. IMO "Scribble" should refer only to the family of languages that use 
the Scribble document model, including Racket documentation.

At some point the docs for "Scribble as a Preprocessor" were broken out from 
the main Scribble docs — I'm guessing to emphasize that they're conceptually 
separate from Scribble. But AFAICT what they really have in common is the 
at-reader, not the document model. Because they don't use the Scribble document 
model, I'm unclear why they're called `scribble/text` and `scribble/html`.

Meanwhile, I'd argue that the at-reader — itself an obsolete name, since one 
can swap out the @ for any Unicode char —  deserves to have its documentation 
broken out into a separate top-level section, which would more accurately 
reflect its status within Racket.



>  So maybe phrase this as a challenge: see if you can come up with an actual 
> example where the scribble syntax won't do what you want,

When I started out with at-expressions, I too resisted some of the conventions. 
But as I worked with more complicated cases, I came to understand the wisdom of 
Eli's design choices. At this point I have two lingering wishes:

+ String splitting within {...} delimiters: I agree this is the right default 
behavior, but it doesn't seem unreasonable to wish for shorthand for when you 
really do want things concatenated into a single argument, given that Racket is 
full of cognates like let/let*, for/for*, list/list*, etc. That said, I don't 
have a good idea what the notation would be.

+ I wish at-expressions could use multiple [...] and {...} parts, in any order.

-- 
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] A Racket talk in Rubyconf Brazil

[Matthias Felleisen]

Looks like a cool talk. Thanks for sharing. 


> On Sep 25, 2016, at 11:53 AM, Ronie Uliana  wrote:
> 
> Hi, there!
> 
> I gave a talk about Racket in Rubyconf Brazil yesterday (saturday 24).
> 
> Here  are the slides 
> translated to English and here 
>  the original in Portuguese :)
> 
> Not sure I gave the right importance to the right points, but people liked it 
> a lot.
> 
> Thank you all for the amazing job in the Racket!
> 
> []s
> Ronie
> 
> -- 
> 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.

[racket-users] A Racket talk in Rubyconf Brazil

[Ronie Uliana]

Hi, there!

I gave a talk about Racket in Rubyconf Brazil yesterday (saturday 24).

Here  are the slides
translated to English and here
 the original in Portuguese
:)

Not sure I gave the right importance to the right points, but people liked
it a lot.

Thank you all for the amazing job in the Racket!

[]s
Ronie

-- 
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] udelim package -- more parens than you can shake a stick at

[Alex Knauth]

> On Sep 25, 2016, at 3:55 AM, William G Hatch  wrote:
> 
> On Sat, Sep 24, 2016 at 05:33:18PM -0400, Alex Knauth wrote:
>> The way racket already does this is with a 'paren-shape syntax property, 
>> which you can ignore if you want to use ｢｣ as a normal visually distinctive 
>> paren type *without* needing a special macro with a weird name.
> 
> I hadn't thought about the 'paren-shape property.  I should put that on.
> I hadn't thought as much about these paren shapes being used to be
> distinguished in other macros (eg. macro foo will do something different
> if its argument is wrapped in bold brackets or in moon faces), but had
> thought more about either just having them be normal parens or making
> them be transformers for a fancy macro shorthand - eg. 〘+ _ 3〙might be
> a shorthand lambda wrapper or something.  

The usual way to do this is with #%app, but you would be right to point out 
that it shouldn't be #%app's job to handle fancy lambda shorthands, and it 
wouldn't work properly if it was a macro call.

Here's an idea, what if the macro expander introduced just one more #%app-like 
form in front of every expression? It's called #%group here but a better name 
would be better.

(+ 1 2)
--->
(#%group + 1 2)
--->
(#%app + 1 2)
--->
(#%app + (#%datum . 1) (#%datum . 2))
--->
(#%app + (quote 1) (quote 2))

The #%group macro would be able to look at the 'paren-shape property and decide 
either to expand to #%app, to expand to a lambda shorthand, or delegate to some 
other macro, based on which character it sees as the value of the property.

This introduces one new macro-that-needs-to-be-defined instead of the dozens of 
different ones you would need for the different delimiters, but it gives the 
#%group macro the power to dispatch on the 'paren-shape property of the syntax 
object. This dispatching could delegate to macros like #%braces when the 
'paren-shape property is #\{, giving Remix what it wants, but these 
special-cases would be handled by the #%group macro at expansion time instead 
of by the reader.

I think it needs to be at expansion time because otherwise {1 2 3} looks like a 
4-element list before expansion. These would seem to have very weird behavior 
under quote, and it will look weird to any other macro that doesn't explicitly 
look for the #%braces, #%brackets, #%cjk-corner-quotes, etc. symbols.

To have add the #%group macro would require either extending the macro expander 
or having the #%module-begin macro introduce it by simulating a macro expander. 
I might be misunderstanding, but does Remix already do the latter?

Alex Knauth

> But at the same time, I don't
> see how matching on the 'paren-shape property is any better or worse
> than matching funky #%paren-shape lists.
> 
> So... yeah.  I should definitely add the 'paren-shape property, and I'll
> make that change.  And I don't want all paren shapes to create a
> #%paren-shape wrapper.  But I found #%braces part of Jay's talk to be
> persuasive, at least in that I definitely want it on some of my parens.
> So maybe some unicode paren turned on by #lang udelim should have the #%
> wrapper and others not.
> 
> Thanks for your thoughts.
> 
> William

-- 
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] udelim package -- more parens than you can shake a stick at

[Eli Barzilay]

On Sun, Sep 25, 2016 at 3:34 AM, William G Hatch  wrote:
> First of all, I really didn't mean any offense.  I think the at-reader
> and my nestable string delimiters are trying to solve slightly
> different problems, and I didn't really convey that well.  I didn't
> mean for it to be "Eli bait".  Let me explain my use case a little,
> and maybe my earlier mail will seem less baiting in the context I had
> intended, albeit poorly communicated.

To be clear, no offense taken -- I'm only considering the technical
reasons to want yet another string delimiter and the technical aspects
of what you get.  "Eli bait" is not because I take it personally, it's
just because I spent a ton of time thinking about such problems, and I'd
hate to see people fall into the expected traps when following
"traditional" solutions, not seeing how the @-syntax already provides a
nice solution.  (I suspected that you'd fall into them, and later in
this email you indeed do...)


> So I really do just mean that the string delimiters themselves nest --
> IE it balances them so that the string doesn't necessarily end once it
> hits an ending delimiter.  So yes, any two characters will do for the
> job.  That in itself is something that I've wanted independent of
> anything else, so for me that was a good enough reason to make this,
> and is something that I'll use it for, to avoid things like \", which
> have always irked me (whether or not it's reasonable that that should
> bother me).

Note that the scribble syntax starts with that as a basic feature.  That
is, if you replace {}s with something else like «», then inside a quoted
context @«...» any matching «»s are ignored.


> Basically, I want to have a macro that will be fully in charge of
> determining the meaning of the string, and I want to be able to use
> the same reader functions in the macro that I use in the #lang.

Same here: this is one of the uses cases I described many times for the
scribble syntax: start with a macro that uses a parser to parse the
whole thing, then refine by making it parse just one form and start
besting @-forms, and eventually get to a point when you have a new #lang
implementation.


> But to use the same read-syntax function that my language uses, I need
> a port to run it on.  To make this port, I really just need a string
> with no pre-read syntax objects inside it.  So in this case I don't
> want the top-level reader of whatever #lang I'm in to look in the
> string, I just want the macro to be able to use read-syntax on the
> full string.

Yes, and you can do all of that with just a string, which you can still
get from an @-form -- just throw a syntax error if it's not all strings.
And with just that you get the *benefit* of ignoring indentation which
makes it possible to use your syntax in a sane way.


> If the middle of the string has already been read into syntax objects,
> my reader functions would be much more complicated to write (IE I'd
> have to figure out how to deal with the port ending in the middle of a
> parenthesised expression or something, then use a pre-read syntax
> object, then jump back into reading the next section that remained a
> string while conveying whatever context I was in in the last string
> segment...).

Right -- that's what I mentioned as "throw a syntax error" above.  But
it would be a good idea to think about why it's a syntax error, which
would in most cases get you closer to something that is a composable
language.


> And the string splitting, which is as you've shown quite helpful in
> many cases, would in this case simply be something that I would have
> to undo, which as you point out would be a bit of a waste.

What I view as a waste is not just undoing the indentation elimination
-- it's the idea of a form where you want indentation to matter at the
semantic runtime level.  To clarify, my opinion is that

(foo bar
 baz)

and

 (foo bar
  baz)

should be the same.  @-expressions follow that; (traditional)
here-strings do not.  Because here-strings do not follow that, you end
up writing ugly code like

 (foo #< So I see the difference as being that in uses like scribble, the bold
> procedure isn't trying to use a reader on its arguments, and the
> at-reader needs to have split them up and turned the nested
> expressions into s-expressions already for them to have their intended
> meaning.

*Don't* confuse scribble-the-documentation-system with the syntax -- the
syntax is useful for many other cases, and designed to make sense in
other cases.  See my description (specifically section 4, which is very
relevant here), and the scribble/text and scribble/html languages.


> [...]
> ;; So basically the rash macro does exactly the same thing as #lang
> ;; rash, but is embeddable in #lang whatever!

Yes, and you can get the same with any string, and

(rash "stuff
   in a different
   language")

Re: [racket-users] udelim package -- more parens than you can shake a stick at

[William G Hatch]

On Sat, Sep 24, 2016 at 05:33:18PM -0400, Alex Knauth wrote:

The way racket already does this is with a 'paren-shape syntax property, which 
you can ignore if you want to use ｢｣ as a normal visually distinctive paren 
type *without* needing a special macro with a weird name.


I hadn't thought about the 'paren-shape property.  I should put that on.
I hadn't thought as much about these paren shapes being used to be
distinguished in other macros (eg. macro foo will do something different
if its argument is wrapped in bold brackets or in moon faces), but had
thought more about either just having them be normal parens or making
them be transformers for a fancy macro shorthand - eg. 〘+ _ 3〙might be
a shorthand lambda wrapper or something.  But at the same time, I don't
see how matching on the 'paren-shape property is any better or worse
than matching funky #%paren-shape lists.

So... yeah.  I should definitely add the 'paren-shape property, and I'll
make that change.  And I don't want all paren shapes to create a
#%paren-shape wrapper.  But I found #%braces part of Jay's talk to be
persuasive, at least in that I definitely want it on some of my parens.
So maybe some unicode paren turned on by #lang udelim should have the #%
wrapper and others not.

Thanks for your thoughts.

William

--
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: udelim package -- more parens than you can shake a stick at

[William G Hatch]

One note about the docs: when you write:

(open-input-string
 "«this is a string with nested «string delimiters.»  No \n escape 
interpreting.»")

the "\n" is already escaped by the "…" fed into open-input-string I think, so 
what udelim parses in that example is a raw newline, not the \ character followed by the n 
character.


Thanks, I clearly wasn't thinking about that very hard while writing the
docs.  Fixed.


Scribble supports "element transformers" which allow to change how an 
identifier is printed. Unfortunately, when the identifier appears in the first position 
of a form (like the #% wrappers), only the identifier itself can get styled, not the 
whole form. I added a few days ago a quick hack to my unstable scribble-enhanced library 
to add catch-alls which can re-style any identifier matching a given pattern. The hack 
[1] should also work for whole forms (untested, though), so that in scribble or 
scribble/lp2, @racketblock[(a ⟦b⟧ c)] would be properly typeset.


Thanks.  I didn't put too much thought into the typesetting so far
(apologies to Mr. Butterick), but I'll look into that more when the
library stabilizes more.

--
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] udelim package -- more parens than you can shake a stick at

[William G Hatch]

First of all, I really didn't mean any offense.  I think the at-reader
and my nestable string delimiters are trying to solve slightly different
problems, and I didn't really convey that well.  I didn't mean for it to
be "Eli bait".  Let me explain my use case a little, and maybe my
earlier mail will seem less baiting in the context I had intended,
albeit poorly communicated.


It's your use of "nestable" here that seems to me like it's making
things bogus.  If you really want it to be nested, then this is exactly
what the scribble syntax is doing -- to an extreme.  But if all you want
is to be able to nest the string *delimiters*, than any string delimiter
pair that is not using the same character will do... but more
importantly I don't see any cases where you would want *that* but not
the rest of the scribble syntax features.


So I really do just mean that the string delimiters themselves nest --
IE it balances them so that the string doesn't necessarily end once it
hits an ending delimiter.  So yes, any two characters will do for the
job.  That in itself is something that I've wanted independent of
anything else, so for me that was a good enough reason to make this, and
is something that I'll use it for, to avoid things like \", which have
always irked me (whether or not it's reasonable that that should bother
me).

As for other aspects of nesting and my other uses of these strings, the
at-reader makes perfect sense if you want to nest various expressions
inside a string that needs to remain a string at run-time, such as is
done in scribble.  But in my case that's not what I want for, say, #lang
rash, or other nebulous embedded language ideas I have floating around
my mind.  Basically, I want to have a macro that will be fully in charge
of determining the meaning of the string, and I want to be able to use
the same reader functions in the macro that I use in the #lang.  But to
use the same read-syntax function that my language uses, I need a port
to run it on.  To make this port, I really just need a string with no
pre-read syntax objects inside it.  So in this case I don't want the
top-level reader of whatever #lang I'm in to look in the string, I just
want the macro to be able to use read-syntax on the full string.  If the
middle of the string has already been read into syntax objects, my
reader functions would be much more complicated to write (IE I'd have to
figure out how to deal with the port ending in the middle of a
parenthesised expression or something, then use a pre-read syntax
object, then jump back into reading the next section that remained a
string while conveying whatever context I was in in the last string
segment...).  And the string splitting, which is as you've shown quite
helpful in many cases, would in this case simply be something that I
would have to undo, which as you point out would be a bit of a waste.  


So I see the difference as being that in uses like scribble, the bold
procedure isn't trying to use a reader on its arguments, and the
at-reader needs to have split them up and turned the nested expressions
into s-expressions already for them to have their intended meaning.
Whereas the macros I want to make want to just have a string to turn
into a port.  It could potentially be that my plans for these macros are
misguided, but I have liked the results I've gotten so far and feel like
it has promise.

Here is an example of the sort of thing I've been doing with it:

;; Here is my rash macro
(define-syntax (rash stx)
 (syntax-parse stx
   [(rash arg:str)
;; Note that since I just get one string, it is easy to turn it into a port
;; and use my read function on it.
(with-syntax ([(parg ...) (map (λ (s) (replace-context #'arg s))
   (syntax->list
(rash-read-syntax* (syntax-source #'arg)
   (stx-string->port 
#'arg])
  ;; rash-line-parse is what the #%module-begin of rash uses around 
everything.
  #'(rash-line-parse parg ...))]))
;; So basically the rash macro does exactly the same thing as #lang rash,
;; but is embeddable in #lang whatever!

Is this the best way of going about it?  I don't know.  But it's easier
than the way I was going about it before.  Something I like about this
method is that I could nest several of these macros into each other, and
each one can do the reading however it sees fit, as long as at each
level I can pass an appropriate string to the next level down.  Maybe
the languages have very different views on which characters do something
special (or specifically should not do something special), including
flag characters like @ (or any one you choose at the top level or a
higher level up in the nesting).

For example, something like this could happen:

(define some-output
 (rash/out
  «some-query $(first
(python-ish-list-comprehend
 «machine for i in machine-list where