Re: [racket-users] Generate function defintions at compile time

[Philip McGrath]

On Wed, Aug 23, 2017 at 8:49 PM, Alex Harsanyi 
wrote:
>
> I think Racket is a really good language and can be directly used to write
> useful applications.  Yet new users are encouraged to start using the most
> difficult to understand feature of Racket for their simplest of projects.
>

At the risk of going off topic, I would not consider macros the most
difficult to understand feature of Racket (especially given the competition
from continuations, various concurrency and parallelism constructs,
namespaces and eval, inspectors ...). I found syntax-rules style macros a
fairly easy step from the style of reasoning about evaluation by
substitution of expressions encouraged by HtDP. And syntax-parse makes it
easy to address robustness concerns.


> > `prefix-in` is an old kludge for an old idea that, AFAIK, is no longer
> > considered as good an idea as it used to be.


I don't object to prefix-in sometimes, but I would not recommend writing
modules in the style of parser-tools/lex-sre (which re-defines things like
+) or those documented under
http://docs.racket-lang.org/web-server-internal/dispatchers.html (which
each export a function named make, even though you will almost always want
the make function from more than one such module, making them virtually
unusable without prefix-in or rename-in).

-- 
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] Generate function defintions at compile time

[Neil Van Dyke]

As someone who managed to write a 3 like Racket application without using 
macros, I think they are overrated for application development.  Macros are a 
powerful and necessary feature for designing or extending a language, but most 
people are better served by just using existing, well documented languages.


DSLs/minilanguages are, like, kinda a big deal.  And Racket has perhaps 
the best support for them.


I think it should be normal for a Racketeer to spend some time getting 
comfortable with DSLs/minilanguages, so that they can start to recognize 
when a DSL/minilanguage is a big win.


Regarding macros, syntax transformation happens to often be a great way 
to implement DSLs/minilanguages efficiently in Racket.  Shifting 
computation to compile phase is not the only use of macros, but it's 
relevant here.


I and many other people speak loosely about relative merits of different 
programming practices, but we don't actually have great metrics for most 
of that.  Lines-of-code (SLOC) metrics, for example, are most useful for 
saying things like "We refactored, with judicious use of macros and 
other accepted programming practices, and incidentally cut the million 
lines down to 200K." and "A hundred million lines of code?!  I don't 
think we can QA that in 3 months." Despite poor metrics, I'm happy to 
occasionally and generously share my own opinions, and to sniff 
dismissively at other people's opinions, in the time-honored tradition 
of programming language forums elsewhere.


--
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] Generate function defintions at compile time

[Alex Harsanyi]

On Thursday, August 24, 2017 at 8:59:26 AM UTC+8, Neil Van Dyke wrote:
> h...@oorg wrote on 08/23/2017 06:56 PM:
> 
> > Wouldn't making a DSL be overkill?
> 
> No.  In Racket, a DSL (aka minilanguage, syntax extensions, or macros) 
> can be a very small implementation effort that does exactly what one 
> wants, in a very maintainable way.

As someone who managed to write a 3 like Racket application without using 
macros, I think they are overrated for application development.  Macros are a 
powerful and necessary feature for designing or extending a language, but most 
people are better served by just using existing, well documented languages.

I think Racket is a really good language and can be directly used to write 
useful applications.  Yet new users are encouraged to start using the most 
difficult to understand feature of Racket for their simplest of projects.

> > Isn't this the sort of thing that should be handled by `prefix-in`?
> 
> `prefix-in` is an old kludge for an old idea that, AFAIK, is no longer 
> considered as good an idea as it used to be.  

Do you have any references for this statement?

I personally prefer short function names that I can prefix as needed versus 
littering my code with "author-package-foo" function calls.

Is 'prefix-in' a deprecated feature?

Best Regards,
Alex.

-- 
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] Generate function defintions at compile time

[Neil Van Dyke]

hiph...@openmailbox.org wrote on 08/23/2017 06:56 PM:


Wouldn't making a DSL be overkill?


No.  In Racket, a DSL (aka minilanguage, syntax extensions, or macros) 
can be a very small implementation effort that does exactly what one 
wants, in a very maintainable way.



Also, I don't have a choice in the matter how the API data is stored, a hash 
table is what I receive.


You're already running contrived Racket code to generate the hash syntax 
that you paste into the source file.  So you can alternatively paste 
slightly different contrived syntax, if that gives you an advantage.  
(Initially, because you happened to paste a Racket hash syntax into that 
file, you were making your life a lot harder than it needed to be.)



The API is only a part of the library, there is also the "client" (connecting to a Neovim 
instance) and the Racket "host" (allowing Neovim plugins in Racket). I might later 
re-export the bindings from `nvim/api` through `nvim`, I haven't decided on that yet.


This is getting into reuse ecology questions.  For now, you might just 
ask yourself whether this all needs to be in one package.  And, if 
multiple packages, just use the respective package name as the reusable 
`require` name.



Isn't this the sort of thing that should be handled by `prefix-in`?


`prefix-in` is an old kludge for an old idea that, AFAIK, is no longer 
considered as good an idea as it used to be.  I recommend trying to make 
usually-unique identifiers like I said, and save the generic terms for 
custom `#lang`.



The hash table comes from Neovim. I can either send an RPC request (using this 
library) or run `nvim --api-info` and read from Neovim's standard output.


I'm sure you have your reasons for wanting to compile-in what Neovim 
seems to want to be dynamic info.  Such as startup performance, or the 
ability to later add annotations for semantics missing in the API 
encoding that Neovim emits.


Eventually, perhaps you'll want your Racket API interface to check at 
runtime against the Neovim process what API it supports, and perhaps 
enable/disable/change bits of your Racket API interface. You might end 
up adding annotations to your DSL, or paste multiple versions of the 
Neovim APIs into that one file, and tweak your DSL's syntax transformers 
to generate more sophisticated code.


--
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] Generate function defintions at compile time

[hiphish]

Thank you all for your answers, I think I got it right this time, but I
would still appreciate feedback:
https://gitlab.com/HiPhish/neovim.rkt/blob/master/nvim/api.rkt

I think what was confusing me was that I was thinking of Racket macros
like Common Lisp macros. Instead of trying to build a list that will be
the resulting S-expression I needed to build syntax objects.

> Neil Van Dyke wrote
> If you define a kind of domain-specific language (DSL) syntax
> extension in Racket for your Neovim API, your specification might then
> look like this (with the "..." filled in): 
Wouldn't making a DSL be overkill? Also, I don't have a choice in the
matter how the API data is stored, a hash table is what I receive. I do
not get the decide what the API is myself.

> BTW, consider making the `require` name be simply `neovim` or `nvim`,
> not `neovim/api` or `nvim/api`.  Or call the package `neovim-api`. 
The API is only a part of the library, there is also the "client"
(connecting to a Neovim instance) and the Racket "host" (allowing Neovim
plugins in Racket). I might later re-export the bindings from `nvim/api`
through `nvim`, I haven't decided on that yet.

> Also BTW, consider including the string "neovim" or "nvim" in the
> names of all provided identifiers of your API package, such as
> `neovim-command` instead of `command`.
Isn't this the sort of thing that should be handled by `prefix-in`? The
Common Lisp client prefixes `nvim:`
https://github.com/adolenc/cl-neovim/#neovims-api
https://github.com/adolenc/cl-neovim/blob/master/src/package.lisp#L26



> Philip McGrath wrote
> I guess my first question would be where does the hash table in
> nvim/api/specification.rkt come from, where else is it used, and is it
> necessary for the format to be what it currently is.
The hash table comes from Neovim. I can either send an RPC request (using
this library) or run `nvim --api-info` and read from Neovim's standard
output. The result is in the MessagePack format; MessagePack is similar
to JSON, except it's binary instead of text-based.
http://msgpack.org/

I wrote my own MessagePack library, and since the MessagePack standard
does not promise that keys of dictionaries need to be strings, only an
"object" I decided to unpack keys the way they are. I also use vectors
when unpacking MessagePack arrays because vectors are closer to what
arrays are than a linked list.



> Ryan Culpepper wrote
> IIUC, you are doing argument/result checking and conversion at run
> time.
No, I want to do everything at compile time. Your second code example is
what helped me to get it working, although I still don't quite
understand what `syntax-local-introduce` does and what the `#'here`
syntax object is supposed to be (I guess just some arbitrary syntax
object that's define right "here").

I'm not concerned with runtime type checks for now, I'll eventually port
the library to Typed Racket, then I'll just add the type annotations
above the function definition.

-- 
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] How to build new formlets that allow passing default values (such as hidden)?

[Jay McCarthy]

On Wed, Aug 23, 2017 at 8:26 AM, Marc Kaufmann
 wrote:
> Hi again,
>
> I am now trying to deal with formlets in a more principled fashion and thus
> trying to implement, as Philip suggested, to use `send/formlet` and
> `embed-formlet`. After a lot of tinkering, I still haven't figured out how
> to actually process the formlet (without having to pass it around) with
> embed-formlet. Here is the current example:
>
> (define (debrief request)
>   (define test-formlet
> (formlet
>   (div "Name:" ,{input-string . => . name})
>   (list name)))
>   (define (response-generator embed/url)
> (html-wrapper
>   `((h1 "Testing Formlets")
> (form ([action ,(embed/url testing)]
>[method "POST"])
>   (p "Here is the displayed formlet")
>   ;,@(formlet-display test-formlet) ;; THIS WORKS
>   ,(embed-formlet embed/url test-formlet)
>   (input ([type "submit"]))
>   
>
> The above works without `embed-formlet` with the following definition of
> `testing`:
>
>   (define (testing request)
> (define result (formlet-process test-formlet request))
> (html-wrapper
>   `((h1 "Result")
> (div
>   ,(first result)
>   (send/suspend/dispatch response-generator))
>
> But it does not work (or I can't figure out how it works) with
> embed-formlet. How do I process the formlet, with the requirement that I do
> not want to refer explicitly to `test-formlet`?

That is not possible. A formlet defines two things: the rendering and
the processing, so it doesn't make sense to process without the
processing definition.

> Or is this not possible - in
> which case, what does `embed-formlet` do that `formlet-processing` doesn't?
> Any working example with embed-formlet is appreciate, even if it is not the
> same as mine.

When you use embed-formlet, the formlet is displayed and when you
submit, then the formlet's processing runs and returns to the
call-site of send/suspend/dispatch. So you don't separate them.
embed-formlet  is really simple:

(define (embed-formlet embed/url f)
  `(form ([action ,(embed/url
(lambda (r)
  (formlet-process f r)))])
 ,@(formlet-display f)))

> Thanks,
> Marc
>
>
> On Thu, Mar 16, 2017 at 2:11 PM, Marc Kaufmann 
> wrote:
>>
>> Thanks Philip. I checked out the links, but I fear that it's over my head,
>> and that I would almost surely screw it up. For now I'll keep passing the
>> parameters.
>>
>> Cheers,
>> Marc
>>
>> On Tuesday, March 14, 2017 at 3:22:39 PM UTC-4, Philip McGrath wrote:
>> > If you want it to be part of the continuation without having to pass it
>> > around as an argument, check out web cells
>> > (http://docs.racket-lang.org/web-server/stateless.html?q=web-server%2Flang%2Fwe#%28mod-path._web-server%2Flang%2Fweb-cells%29)
>> > or web parameters
>> > (http://docs.racket-lang.org/web-server/stateless.html?q=web-server%2Flang%2Fwe#%28mod-path._web-server%2Flang%2Fweb-param%29).
>> >
>> >
>> >
>> > -Philip
>> >
>> >
>> >
>> > On Tue, Mar 14, 2017 at 1:48 PM, Marc Kaufmann 
>> > wrote:
>> >
>> >
>> >
>> > Thanks for the detailed answer Philip! Some of it is definitely over my
>> > head. The reason I don't pass around the id is that I use the html field
>> > exactly to track the id and wanted to avoid having to pass around the
>> > argument left and right - and the only ways to pass it on are via forms or
>> > by sticking it into the requested URL or by using continuations. I will 
>> > give
>> > the continuation-style solution a shot though, it's probably cleaner to 
>> > pass
>> > the id around as an argument.
>> >
>> > Cheers,
>> > Marc
>> >
>> >
>> >
>> >
>> >
>> > On Tue, Mar 14, 2017 at 1:34 PM, Philip McGrath
>> >  wrote:
>> >
>> > In this case it will work despite being a hack, because you know that
>> > your id argument affects only the display stage, not the processing stage:
>> > however, you can't know in general that this will work for dynamically
>> > generated formlets, and personally I would therefore be reluctant to rely 
>> > on
>> > this, both because it is fragile in terms of changes to your implementation
>> > of matrix-formlet that you might make later.
>> >
>> >
>> > If you are using native continuations (i.e. not the stateless #lang
>> > web-server), you can use send/formlet or embed-formlet to deal with this
>> > correctly and easily. (At a lower level, you could also do something
>> > like(define-values (xexpr-forest bindings->result i)
>> >   ((matrix-formlet "3") 0))
>> > to access the low-level rendering, processing function, and next
>> > allowable input integer directly.)
>> >
>> >
>> > It is a little more tricky in #lang web-server, because your formlet and
>> > it's generated processing function are plain functions, and thus not
>> > serializable (see this old thread for discussion:
>> > 

Re: [racket-users] European Racketeers and conferences

[Matthew Eric Bassett]

So there's at least 7 of us around UK/Germany/France/Netherlands that
are active on the mailing list.  What would we need at a European
Rackeeteers Meeting to ensure that *at least* all 7 of us would travel
to it ?

@Matthias - it'd be fantastic if we could arrange something in London or
Oxford.  I'm just getting back from Salone this week and wasn't planning
on making to ICFP, but I'll see if I can help organize something.  Can
you sure your itinerary ?


On 08/23/2017 11:13 AM, 'Paulo Matos' via Racket Users wrote:
> 
> 
> On 22/08/17 16:20, Daniel Brunner wrote:
>> Hey Matthew,
>>
>> I live in Germany and use Racket for teaching students, teaching our
>> apprentices (dual education system in Germany) and use it "in
>> production" for some tasks.
>>
> 
> In Germany as well - Nuernberg to be precise. I learned Racket back in
> version 53 - that was something around 1999. On and off for a few years
> and now I am using in commercially in my own company.
> 
> Happy to join a European Racket gathering.
> 
> Paulo Matos
> 
>> Best wishes,
>> Daniel
>>
>> Am 22.08.2017 um 15:15 schrieb Matthew Eric Bassett:
>>> Hi all,
>>>
>>> Gutted I can't make it to RacketCon this year.  Really glad to see it
>>> growing.
>>>
>>> Question for y'all - how many Racketeers are active on this side of the
>>> Atlantic?  Enough for a specific get-together over here?  Or are there
>>> already appropriate venues for that that I'm unaware of (I am already
>>> familiar with the European lisp symposium)
>>>
>>> Best,
>>>
>>>
>>
> 


-- 
Matthew Eric Bassett | http://mebassett.info

-- 
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.


signature.asc
Description: OpenPGP digital signature

Re: [racket-users] How to build new formlets that allow passing default values (such as hidden)?

[Marc Kaufmann]

Hi again,

I am now trying to deal with formlets in a more principled fashion and thus
trying to implement, as Philip suggested, to use `send/formlet` and
`embed-formlet`. After a lot of tinkering, I still haven't figured out how
to actually process the formlet (without having to pass it around) with
embed-formlet. Here is the current example:

(define (debrief request)
  (define test-formlet
(formlet
  (div "Name:" ,{input-string . => . name})
  (list name)))
  (define (response-generator embed/url)
(html-wrapper
  `((h1 "Testing Formlets")
(form ([action ,(embed/url testing)]
   [method "POST"])
  (p "Here is the displayed formlet")
  ;,@(formlet-display test-formlet) ;; THIS WORKS
  ,(embed-formlet embed/url test-formlet)
  (input ([type "submit"]))
  

The above works without `embed-formlet` with the following definition of
`testing`:

  (define (testing request)
(define result (formlet-process test-formlet request))
(html-wrapper
  `((h1 "Result")
(div
  ,(first result)
  (send/suspend/dispatch response-generator))

But it does not work (or I can't figure out how it works) with
embed-formlet. How do I process the formlet, with the requirement that I do
not want to refer explicitly to `test-formlet`? Or is this not possible -
in which case, what does `embed-formlet` do that `formlet-processing`
doesn't? Any working example with embed-formlet is appreciate, even if it
is not the same as mine.

Thanks,
Marc


On Thu, Mar 16, 2017 at 2:11 PM, Marc Kaufmann 
wrote:

> Thanks Philip. I checked out the links, but I fear that it's over my head,
> and that I would almost surely screw it up. For now I'll keep passing the
> parameters.
>
> Cheers,
> Marc
>
> On Tuesday, March 14, 2017 at 3:22:39 PM UTC-4, Philip McGrath wrote:
> > If you want it to be part of the continuation without having to pass it
> around as an argument, check out web cells (http://docs.racket-lang.org/
> web-server/stateless.html?q=web-server%2Flang%2Fwe#%28mod-
> path._web-server%2Flang%2Fweb-cells%29) or web parameters (
> http://docs.racket-lang.org/web-server/stateless.html?q=
> web-server%2Flang%2Fwe#%28mod-path._web-server%2Flang%2Fweb-param%29).
> >
> >
> >
> > -Philip
> >
> >
> >
> > On Tue, Mar 14, 2017 at 1:48 PM, Marc Kaufmann 
> wrote:
> >
> >
> >
> > Thanks for the detailed answer Philip! Some of it is definitely over my
> head. The reason I don't pass around the id is that I use the html field
> exactly to track the id and wanted to avoid having to pass around the
> argument left and right - and the only ways to pass it on are via forms or
> by sticking it into the requested URL or by using continuations. I will
> give the continuation-style solution a shot though, it's probably cleaner
> to pass the id around as an argument.
> >
> > Cheers,
> > Marc
> >
> >
> >
> >
> >
> > On Tue, Mar 14, 2017 at 1:34 PM, Philip McGrath <
> phi...@philipmcgrath.com> wrote:
> >
> > In this case it will work despite being a hack, because you know that
> your id argument affects only the display stage, not the processing stage:
> however, you can't know in general that this will work for dynamically
> generated formlets, and personally I would therefore be reluctant to rely
> on this, both because it is fragile in terms of changes to your
> implementation of matrix-formlet that you might make later.
> >
> >
> > If you are using native continuations (i.e. not the stateless #lang
> web-server), you can use send/formlet or embed-formlet to deal with this
> correctly and easily. (At a lower level, you could also do something
> like(define-values (xexpr-forest bindings->result i)
> >   ((matrix-formlet "3") 0))
> > to access the low-level rendering, processing function, and next
> allowable input integer directly.)
> >
> >
> > It is a little more tricky in #lang web-server, because your formlet and
> it's generated processing function are plain functions, and thus not
> serializable (see this old thread for discussion: https://groups.
> google.com/d/topic/racket-users/lMYWjodgpmo/discussion). The easy
> work-around is to keep the arguments you need to reproduce your formlet
> around as part of the closure, e.g. by rewriting your matrix-submission
> like this:(define (matrix-submission req id)
> >   (define-values (number-of-ones user-id)
> >   (formlet-process (matrix-formlet id) req))
> >   ...)
> > The alternative is to either recompile the formlet library using #lang
> web-server/base or to implement your formlet at a low level using
> serial-lambda and not use any of the library tools.
> >
> >
> > In this specific case, though, if you are using this hidden input field
> just to remember the user id from one request to the next (i.e. you
> wouldn't ever change it on the client side with JavaScript or something),
> the best solution is not to put it in the form 

Re: [racket-users] European Racketeers and conferences

['Paulo Matos' via Racket Users]

On 22/08/17 16:20, Daniel Brunner wrote:
> Hey Matthew,
> 
> I live in Germany and use Racket for teaching students, teaching our
> apprentices (dual education system in Germany) and use it "in
> production" for some tasks.
>

In Germany as well - Nuernberg to be precise. I learned Racket back in
version 53 - that was something around 1999. On and off for a few years
and now I am using in commercially in my own company.

Happy to join a European Racket gathering.

Paulo Matos

> Best wishes,
> Daniel
> 
> Am 22.08.2017 um 15:15 schrieb Matthew Eric Bassett:
>> Hi all,
>>
>> Gutted I can't make it to RacketCon this year.  Really glad to see it
>> growing.
>>
>> Question for y'all - how many Racketeers are active on this side of the
>> Atlantic?  Enough for a specific get-together over here?  Or are there
>> already appropriate venues for that that I'm unaware of (I am already
>> familiar with the European lisp symposium)
>>
>> Best,
>>
>>
> 

-- 
Paulo Matos

-- 
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

[Daniel Brunner]

Am 22.08.2017 um 20:00 schrieb Alexander Shopov:
> Hmm, what about the Netherlands? Anyone willing to meet?
> @Daniel Brunner: Are you in Wetzlar?

Near Wetzlar, it's about 45 minutes by car.

> Anyone else around hereabouts?
> Kind regards:
> al_shopov
Best wishes, Daniel

-- 
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

[Konrad Hinsen]

On 22/08/2017 20:00, Alexander Shopov wrote:


Hmm, what about the Netherlands? Anyone willing to meet?
@Daniel Brunner: Are you in Wetzlar?
Anyone else around hereabouts?


I am in Paris.

Konrad.

--
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.