[racket-users] TFPIE 2022

[mora...@gmail.com]

Dear All,

Please consider submitting your classroom developments and practices to 
Trends in Functional Programming in Education 2022 (TFPIE 2022) that will 
be an in-person event in beautiful Krakow, Poland. The CFP is below and the 
website is found at: https://wiki.tfpie.science.ru.nl/TFPIE2022 .

Marco



TFPIE 2022 Call for papers
https://wiki.tfpie.science.ru.nl/TFPIE2022
(February 11th 2022, Krakow, Poland co-located with TFP 2022 and Lambda 
Days)

TFPIE 2022 welcomes submissions describing techniques used in the classroom,
tools used in and/or developed for the classroom and any creative use of
functional programming (FP) to aid education in or outside Computer Science.
Topics of interest include, but are not limited to:

  FP and beginning CS students
  FP and Computational Thinking
  FP and Artificial Intelligence
  FP in Robotics
  FP and Music
  Advanced FP for undergraduates
  FP in graduate education
  Engaging students in research using FP
  FP in Programming Languages
  FP in the high school curriculum
  FP as a stepping stone to other CS topics
  FP and Philosophy
  The pedagogy of teaching FP
  FP and e-learning: MOOCs, automated assessment etc.
  Best Lectures - more details below

In addition to papers, we are requesting best lecture presentations. What's 
your
best lecture topic in an FP related course? Do you have a fun way to 
present FP
concepts to novices or perhaps an especially interesting presentation of a
difficult topic? In either case, please consider sharing it. Best lecture 
topics
will be selected for presentation based on a short abstract describing the
lecture and its interest to TFPIE attendees. The length of the presentation
should be comparable to that of a paper. In addition, the speaker can 
provide
commentary on effectiveness or student feedback.

Submissions

Potential presenters are invited to submit an extended abstract (4-6 pages) 
or
a draft paper (up to 20 pages) in EPTCS style. The authors of accepted 
presentations
will have their preprints and their slides made available on the workshop's 
website.
Papers and abstracts can be submitted via easychair at the following link:

https://easychair.org/conferences/?conf=tfpie2022

After the workshop, presenters are invited to submit (a revised version of) 
their
article for the formal review. The PC will select the best articles for 
publication
in the Electronic Proceedings in Theoretical Computer Science (EPTCS). 
Articles
rejected for presentation and extended abstracts will not be formally 
reviewed
by the PC.

Important Dates

  Submission deadline: January 5th 2022, Anywhere on Earth.
  Notification: January 10th 2022 (Note: earlier submissions will receive 
earlier response)
  TFPIE Registration Deadline: TBA
  Workshop: February 11th 2022
  Submission for formal review: April 15th 2022, Anywhere on Earth.
  Notification of full article: June 1st 2022
  Camera ready: July 1st 2022

Program Committee

Peter Achten, Radboud University, Netherlands
Stephen Chang, University of Massachusetts Boston, USA
John Hughes, Chalmers University of Technology, Sweden
Elena Machkasova (Chair) - University of Minnesota Morris, USA
Kristina Sojakova - INRIA, Paris, France
Melinda Tóth, Eötvös Loránd University, Budapest, Hungary

Registration information

This year TFPIE takes place on the second day of the Lambda Days, 
concurrent with TFP.
Participants will need to register for the Lambda Days. Please note that 
TFP and TFPIE
have in-person attendance only. For registration fee, the deadlines, and 
the link to
register see the Lambda Days web site:
https://www.lambdadays.org/lambdadays2022

Registration and attendance are mandatory for at least one author of every 
paper
that is presented at the workshop. Presenters will have their registration 
fee waived.

Only papers that have been presented at TFPIE may be submitted to the 
post-reviewing
process. 



-- 
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.
To view this discussion on the web visit 
https://groups.google.com/d/msgid/racket-users/66a3de83-3372-4790-9e79-10b997afa488n%40googlegroups.com.

Re: [racket-users] Typesetting Redex definitions

[Mallku Ernesto Soldevila Raffa]

Thank you very much for the information provided! We have a lot to 
experiment with.
Regards,
Mallku

El martes, 26 de octubre de 2021 a las 18:40:49 UTC-3, Robby Findler 
escribió:

> The only way to do that currently is to use the compound rewriters (they 
> rewrite anything with parens) and the atomic rewriters (they rewrite 
> anything without parens). The interface that redex provides is pretty 
> low-level and I'd like to find time to improve it, but in the meantime 
> there are some libraries on the package server that build higher-level ways 
> to do this. 
>
> There's an example of with-compound-rewriter here: 
> https://docs.racket-lang.org/redex/reference.html#%28form._%28%28lib._redex%2Fpict..rkt%29._with-compound-rewriter%29%29
>  
> and redex doesn't care if the thing it is rewriting is defined as a 
> judgment form or as the syntax of a term; it'll apply the rewriter in 
> either case.
>
> As for what Redex generates, it isn't generating latex, it is generating 
> picts (which basically boils down to postscript-style drawing commands when 
> you think about them from the perspective of interoperating with other 
> tools -- one nice thing to do is to use scribble (which generates latex) as 
> it has handling to make them look nice in the rendered output, although 
> getting the right fonts set up can sometimes be tricky).
>
> hth,
> Robby
>
>
> On Tue, Oct 26, 2021 at 1:55 PM Mallku Ernesto Soldevila Raffa <
> mallku...@gmail.com> wrote:
>
>> Hi community!,
>> a colleague of mine is trying to typeset a grammar from a model in Redex,
>> using redex/pict. So far, he has obtained a nice-looking typesetting of
>> the productions, but with the inconvenience that they are not abstract. In
>> particular, there are parentheses around every list of symbols,
>> as in Redex. Since it seems that redex/pict does not generate the latex 
>> code
>> (or does it?), we are not able to get rid of those concrete-syntax 
>> details. Is 
>> there any known/simple way of doing it?
>>
>> Thanks in advance!,
>> Mallku
>>
>> -- 
>> 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...@googlegroups.com.
>> To view this discussion on the web visit 
>> https://groups.google.com/d/msgid/racket-users/3c6330fe-a048-4561-98bf-495c9b92e06an%40googlegroups.com
>>  
>> 
>> .
>>
>

-- 
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.
To view this discussion on the web visit 
https://groups.google.com/d/msgid/racket-users/f405ba3e-559d-43f5-9df6-2b061c9277d0n%40googlegroups.com.

Re: [racket-users] Typesetting Redex definitions

[Robby Findler]

The only way to do that currently is to use the compound rewriters (they
rewrite anything with parens) and the atomic rewriters (they rewrite
anything without parens). The interface that redex provides is pretty
low-level and I'd like to find time to improve it, but in the meantime
there are some libraries on the package server that build higher-level ways
to do this.

There's an example of with-compound-rewriter here:
https://docs.racket-lang.org/redex/reference.html#%28form._%28%28lib._redex%2Fpict..rkt%29._with-compound-rewriter%29%29
and redex doesn't care if the thing it is rewriting is defined as a
judgment form or as the syntax of a term; it'll apply the rewriter in
either case.

As for what Redex generates, it isn't generating latex, it is generating
picts (which basically boils down to postscript-style drawing commands when
you think about them from the perspective of interoperating with other
tools -- one nice thing to do is to use scribble (which generates latex) as
it has handling to make them look nice in the rendered output, although
getting the right fonts set up can sometimes be tricky).

hth,
Robby


On Tue, Oct 26, 2021 at 1:55 PM Mallku Ernesto Soldevila Raffa <
mallkuerne...@gmail.com> wrote:

> Hi community!,
> a colleague of mine is trying to typeset a grammar from a model in Redex,
> using redex/pict. So far, he has obtained a nice-looking typesetting of
> the productions, but with the inconvenience that they are not abstract. In
> particular, there are parentheses around every list of symbols,
> as in Redex. Since it seems that redex/pict does not generate the latex
> code
> (or does it?), we are not able to get rid of those concrete-syntax
> details. Is
> there any known/simple way of doing it?
>
> Thanks in advance!,
> Mallku
>
> --
> 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.
> To view this discussion on the web visit
> https://groups.google.com/d/msgid/racket-users/3c6330fe-a048-4561-98bf-495c9b92e06an%40googlegroups.com
> 
> .
>

-- 
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.
To view this discussion on the web visit 
https://groups.google.com/d/msgid/racket-users/CAL3TdOOUxqO8c1DrdBkuCXwU7U5W35ZjMBr3PFzpxfpdfbY4Xw%40mail.gmail.com.

[racket-users] Typesetting Redex definitions

[Mallku Ernesto Soldevila Raffa]

Hi community!,
a colleague of mine is trying to typeset a grammar from a model in Redex,
using redex/pict. So far, he has obtained a nice-looking typesetting of
the productions, but with the inconvenience that they are not abstract. In
particular, there are parentheses around every list of symbols,
as in Redex. Since it seems that redex/pict does not generate the latex code
(or does it?), we are not able to get rid of those concrete-syntax details. 
Is 
there any known/simple way of doing it?

Thanks in advance!,
Mallku

-- 
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.
To view this discussion on the web visit 
https://groups.google.com/d/msgid/racket-users/3c6330fe-a048-4561-98bf-495c9b92e06an%40googlegroups.com.

Re: [racket-users] [ANN] Splitflap: generating valid Atom and RSS feeds

[Jon Zeppieri]

On Tue, Oct 26, 2021 at 2:18 PM 'Joel Dueck' via Racket Users
 wrote:
>
>
>
> On Tuesday, October 26, 2021 at 12:30:59 PM UTC-5 Sage Gerard wrote:
>>
>> Yes, but I'm talking about code we were asked to give feedback on. I focus 
>> on `tz/c` because it is documented as a flat contract that checks for "an 
>> identifier from the IANA tz database", but it does not parse the timezone 
>> name to check correctness.
>>
>> My feedback says no validation occurs for the timezone name in a parameter 
>> for Splitflap. Joel indicated that parameter will go away below, and I'm 
>> glad to know of the tzinfo package. But if a limitation in gregor's 
>> contracts would oblige you to use tzinfo for validation, then I'd want to 
>> know that so that I can assess how much of gregor I really need. It still 
>> seems like the timezone data is the hard part, so use a timezone dependency 
>> instead of a dependency that misleads the user into incomplete validation
>
> It does seem odd that tz/c uses string? instead of tzid-exists? I’m wondering 
> if that could be changed without breaking a lot of stuff. If not, then it 
> *might* be worth keeping my own feed-timezone parameter that allows only 
> (integer-in -64800 64800). On the other hand, it is also true that if an 
> invalid time zone is supplied anywhere along the way to building the feed 
> data, an exception is going to occur before the feed is generated, which is 
> what I care about for the most part.

I agree, and I'm the one who wrote `tz/c` the way it is. Go figure. As
you pointed out, the issue with changing it now is backwards
compatibility. Anyhow, I'm definitely open to suggestions.

>
> In general I appreciate feedback like Sage’s from people who think a lot more 
> carefully than I do about dependencies. I like knowing that if someone has 
> differing time zones for different items within a feed, or cares about 
> gap/overlap resolution, etc, I can let them use gregor to handle it. It's not 
> something I ever encountered in building CMSs or publishing podcasts, but 
> also you never know what a feed will be used for. I will probably experiment 
> with reducing the dependency down to tzinfo/tzdata and using Racket’s native 
> date structs.

[Disclaimer: since I am the author of `gregor`, you should definitely
take into account that I'm biased -- though, maybe not as much as
you'd expect. I'm aware of a bunch of design mistakes I made in
gregor.]

To the extent that validation is a concern, gregor is (despite the
`tz/c` issue) much better, on the whole, than racket/base's `date` and
`date*` structs, which will happily let you construct things like "the
31st of February." And yes, this needs to be balanced against the cost
of taking on an additional dependency.

- Jon

-- 
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.
To view this discussion on the web visit 
https://groups.google.com/d/msgid/racket-users/CAKfDxxyF3_tdb7%2BxOtnR%2BhtbS1LNznChzUAVOG1W7mctiK%3Dakg%40mail.gmail.com.

Re: [racket-users] [ANN] Splitflap: generating valid Atom and RSS feeds

['Joel Dueck' via Racket Users]

On Tuesday, October 26, 2021 at 12:30:59 PM UTC-5 Sage Gerard wrote:

> Yes, but I'm talking about code we were asked to give feedback on. I focus 
> on `tz/c` because it is documented as a flat contract that checks for "an 
> identifier from the IANA tz database ", 
> but it does not parse the timezone name to check correctness.
>
> My feedback says no validation occurs for the timezone name in a parameter 
> for Splitflap. Joel indicated that parameter will go away below, and I'm 
> glad to know of the tzinfo package. But if a limitation in gregor's 
> contracts would oblige you to use tzinfo for validation, then I'd want to 
> know that so that I can assess how much of gregor I really need. It still 
> seems like the timezone data is the hard part, so use a timezone dependency 
> instead of a dependency that misleads the user into incomplete validation
>
It does seem odd that tz/c uses string? instead of tzid-exists? I’m 
wondering if that could be changed without breaking a lot of stuff. If not, 
then it *might* be worth keeping my own feed-timezone parameter that allows 
only (integer-in -64800 64800). On the other hand, it is also true that if 
an invalid time zone is supplied anywhere along the way to building the 
feed data, an exception is going to occur before the feed is generated, 
which is what I care about for the most part.

In general I appreciate feedback like Sage’s from people who think a lot 
more carefully than I do about dependencies. I like knowing that if someone 
has differing time zones for different items within a feed, or cares about 
gap/overlap resolution, etc, I can let them use gregor to handle it. It's 
not something I ever encountered in building CMSs or publishing podcasts, 
but also you never know what a feed will be used for. I will probably 
experiment with reducing the dependency down to tzinfo/tzdata and using 
Racket’s native date structs.


-- 
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.
To view this discussion on the web visit 
https://groups.google.com/d/msgid/racket-users/ea7090cc-1ebf-40a3-a7e6-0634d038602en%40googlegroups.com.

Re: [racket-users] [ANN] Splitflap: generating valid Atom and RSS feeds

[Philip McGrath]

On Tue, Oct 26, 2021 at 1:30 PM Sage Gerard  wrote:

> > Jon: I'm guessing you haven't actually tried this
> > Phillip: I guess the check doesn't happen as part of `tz/c`, but I can
> tell you that this program
>
> Yes, but I'm talking about code we were asked to give feedback on. I focus
> on `tz/c` because it is documented as a flat contract that checks for "an
> identifier from the IANA tz database ",
> but it does not parse the timezone name to check correctness.
>
I agree that I would have expected `tz/c` to consult the IANA database.

> My feedback says no validation occurs for the timezone name in a parameter
> for Splitflap. Joel indicated that parameter will go away below, and I'm
> glad to know of the tzinfo package.
>
Ah, the undocumented `feed-timezone` parameter is not what I had in mind:
I've been considering functions like `feed-item` and `episode`, which take
their created and updated timestamps as `moment?`s—I think any Racket
function that needs to operate on timestamps with timezones ought to
operate on `moment?`s (or perhaps `moment-provider?`s). Gregor does ensure
that `moment?`s are valid.

-Philip

-- 
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.
To view this discussion on the web visit 
https://groups.google.com/d/msgid/racket-users/0100017cbdcf4c28-12d5c1df-f829-4ca2-af95-ec768b5309da-00%40email.amazonses.com.

Re: [racket-users] [ANN] Splitflap: generating valid Atom and RSS feeds

[Sage Gerard]

> The timezone database lookup logic is in the `tzinfo` package 
> (https://docs.racket-lang.org/tzinfo/index.html)

Thanks.

> Jon: I'm guessing you haven't actually tried this
> Phillip: I guess the check doesn't happen as part of `tz/c`, but I can tell 
> you that this program

Yes, but I'm talking about code we were asked to give feedback on. I focus on 
`tz/c` because it is documented as a flat contract that checks for "an 
identifier from the IANA [tz database](https://www.iana.org/time-zones)", but 
it does not parse the timezone name to check correctness.

My feedback says no validation occurs for the timezone name in a parameter for 
Splitflap. Joel indicated that parameter will go away below, and I'm glad to 
know of the tzinfo package. But if a limitation in gregor's contracts would 
oblige you to use tzinfo for validation, then I'd want to know that so that I 
can assess how much of gregor I really need. It still seems like the timezone 
data is the hard part, so use a timezone dependency instead of a dependency 
that misleads the user into incomplete validation.

On 10/26/21 12:39 PM, 'Joel Dueck' via Racket Users wrote:

> On Tuesday, October 26, 2021 at 11:01:38 AM UTC-5 Sage Gerard wrote:
>
>> -  Assuming I have the right repository link, gregor's tz/c contract is only 
>> (or/c string? (integer-in -64800 64800)) [1]. I can set the feed-timezone 
>> parameter in Splitflap to an arbitrary string and the guard won't stop me.
>
> Yep — I left feed-timezone out of the docs because I plan to remove it. 
> Unless I'm missing something? in the end I think it's redundant to tzinfo's 
> current-timezone parameter.
> --
> 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.
> To view this discussion on the web visit 
> [https://groups.google.com/d/msgid/racket-users/d202c537-0173-42fd-b75f-082275c57426n%40googlegroups.com](https://groups.google.com/d/msgid/racket-users/d202c537-0173-42fd-b75f-082275c57426n%40googlegroups.com?utm_medium=email_source=footer).

-- 
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.
To view this discussion on the web visit 
https://groups.google.com/d/msgid/racket-users/f879496a-04c6-e5dd-2501-928a4eff7fb2%40sagegerard.com.

Re: [racket-users] [ANN] Splitflap: generating valid Atom and RSS feeds

['Joel Dueck' via Racket Users]

On Tuesday, October 26, 2021 at 11:01:38 AM UTC-5 Sage Gerard wrote:

>
>- Assuming I have the right repository link, gregor's tz/c contract is 
>only (or/c string? (integer-in -64800 64800)) [1]. I can set the 
>feed-timezone parameter in Splitflap to an arbitrary string and the guard 
>won't stop me.
>
> Yep — I left feed-timezone out of the docs because I plan to remove it. 
Unless I'm missing something? in the end I think it's redundant to tzinfo's 
current-timezone parameter. 

-- 
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.
To view this discussion on the web visit 
https://groups.google.com/d/msgid/racket-users/d202c537-0173-42fd-b75f-082275c57426n%40googlegroups.com.

Re: [racket-users] [ANN] Splitflap: generating valid Atom and RSS feeds

[Jon Zeppieri]

On Tue, Oct 26, 2021 at 12:01 PM Sage Gerard  wrote:
>
> I can understand wanting gregor for timezone offsets when constructing 
> moments, but...
>
> Assuming I have the right repository link, gregor's tz/c contract is only 
> (or/c string? (integer-in -64800 64800)) [1]. I can set the feed-timezone 
> parameter in Splitflap to an arbitrary string and the guard won't stop me.

I'm guessing you haven't actually tried this:

```
> (moment 2000 #:tz "arbitrary string")
. . Library/Racket/8.0/pkgs/tzinfo/tzinfo/private/tzfile-parser.rkt:21:0:
Cannot find zoneinfo file for [arbitrary string]
```

> The IANA's timezone database changed this month, and gregor's last commit was 
> 2 years ago.

Gregor's repo doesn't contain the IANA tzdb and prefers to rely on the
system's zoneinfo files. Every contemporary Unix (including MacOS)
ships with this data and updates it with OS updates. Windows is a
different story (though I know that in recent years, parts of the
Windows ecosystem works with IANA zones, so maybe those files exist
somewhere?).  You're right that the tzdata package has old data. It
would probably make sense for someone who runs Windows to maintain it.
It comes with a script that can update the package for a new version
of the tzdb. I'll do that right now, in fact. Thanks for reminding me.

- Jon

-- 
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.
To view this discussion on the web visit 
https://groups.google.com/d/msgid/racket-users/CAKfDxxzEQBkv1z2T_T4KDhayoPQbeCe%3D%3Dai8YJJKnAZ4z_dUKA%40mail.gmail.com.

Re: [racket-users] [ANN] Splitflap: generating valid Atom and RSS feeds

[Philip McGrath]

On Tue, Oct 26, 2021 at 12:01 PM Sage Gerard  wrote:

>
>- The IANA's timezone database changed this month, and gregor's last
>commit was 2 years ago.
>
> My comment was not meant to say that timezone math is easy to replace, or
> even that gregor isn't a fit. It's to say  that I'm not seeing correct
> answers without a name lookup in front of tz/c, and the latest data from
> the IANA.
>
The timezone database lookup logic is in the `tzinfo` package (
https://docs.racket-lang.org/tzinfo/index.html), last updated two *months*
ago: https://github.com/97jaz/tzinfo Further, on Unix and Mac, it simply
consults the OS-provided IANA timezone database. (It does look like the
`tzdata` package that ships the database for Windows or other cases when
you don't rely on the OS could use a pull request, though:
https://github.com/97jaz/tzdata)

On Tue, Oct 26, 2021 at 12:01 PM Sage Gerard  wrote:

>
>- Assuming I have the right repository link, gregor's tz/c contract is
>only (or/c string? (integer-in -64800 64800)) [1]. I can set the
>feed-timezone parameter in Splitflap to an arbitrary string and the guard
>won't stop me.
>
> I guess the check doesn't happen as part of `tz/c`, but I can tell you
that this program:

#lang racket
(require gregor)
(now/moment #:tz "Nowhere/Middle")

raises an exception saying, "Cannot find zoneinfo file for
[Nowhere/Middle]".

-Philip

-- 
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.
To view this discussion on the web visit 
https://groups.google.com/d/msgid/racket-users/0100017cbd702ddf-9c09541b-7c04-42d5-99be-00e7162b4dc6-00%40email.amazonses.com.

Re: [racket-users] [ANN] Splitflap: generating valid Atom and RSS feeds

[Sage Gerard]

I can understand wanting gregor for timezone offsets when constructing moments, 
but...

-  Assuming I have the right repository link, gregor's tz/c contract is only 
(or/c string? (integer-in -64800 64800)) [1]. I can set the feed-timezone 
parameter in Splitflap to an arbitrary string and the guard won't stop me.
- The IANA's timezone database changed this month, and gregor's last commit was 
2 years ago.

My comment was not meant to say that timezone math is easy to replace, or even 
that gregor isn't a fit. It's to say that I'm not seeing correct answers 
without a name lookup in front of tz/c, and the latest data from the IANA.

But if you were going to do all that in the first place, then I'm not sure what 
I'd use gregor for outside of relative arithmetic.

[1]: 
https://github.com/97jaz/gregor/blob/91d71c6082fec4197aaf9ade57aceb148116c11c/gregor-lib/gregor/private/moment.rkt#L91

On 10/26/21 11:25 AM, David Storrs wrote:

> On Mon, Oct 25, 2021 at 10:25 PM 'Joel Dueck' via Racket Users 
>  wrote:
>
>> - Removing dependencies: yes, I see the appeal. I’m really not eager to 
>> reimplement all the timezone handling and temporal comparison stuff in 
>> gregor, though.
>>
>> Joel
>
> Having done a fair bit of datetime programming, my suggestion on the best way 
> to handle it is to not handle it. Let some purpose-built library such as 
> gregor do it instead of trying to roll your own, because datetime math is a 
> nightmare.
>
>> On Monday, October 25, 2021 at 6:36:30 PM UTC-5 Sage Gerard wrote:
>>
>>> Thank you for this!!
>>>
>>> Feedback
>>>
>>> - I like your podcast-specific entries
>>> - The validation logic is refreshing to see
>>> - Re: boolean arguments, I'd stick to keyword arguments and ask for any/c, 
>>> not boolean?, in contracts. That way forms like (and ... (member ...)) 
>>> won't bug users about a non-threatening contract violation, and it's 
>>> trivial to cast the value yourself.
>>> - Unsure what licenses are compatible with Blue Oak. If you want more 
>>> licensing options re: IANA media type to extension mappings, here are some.
>>>
>>> - MIT: https://github.com/mime-types/mime-types-data
>>> - Apache 2.0 (From the horse's mouth): 
>>> https://svn.apache.org/repos/asf/httpd/httpd/trunk/docs/conf/mime.types
>>>
>>> - CC-BY-SA: Scrape MDN's table using the console on 
>>> https://developer.mozilla.org/en-US/docs/Web/HTTP/Basics_of_HTTP/MIME_types/Common_types
>>>
>>> - I normally don't use functions like splitflap-version because I can't 
>>> assume that a package will define one. I'd use a program that returns a 
>>> version of a given package.
>>> - Why is language-codes a procedure?
>>> - You have a lot of local contract boundaries, so values may get checked 
>>> more than necessary.
>>> - Prefer example.com so you don't have to leak your URLs or make up email 
>>> addresses that actually go to an inbox.
>>> - txexpr, gregor, and web-server dependencies don't look terribly difficult 
>>> to remove
>>
>> --
>> 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.
>> To view this discussion on the web visit 
>> [https://groups.google.com/d/msgid/racket-users/cb2927c7-3d21-41c3-89c7-d6b73a9e53f9n%40googlegroups.com](https://groups.google.com/d/msgid/racket-users/cb2927c7-3d21-41c3-89c7-d6b73a9e53f9n%40googlegroups.com?utm_medium=email_source=footer).
>
> --
> 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.
> To view this discussion on the web visit 
> [https://groups.google.com/d/msgid/racket-users/CAE8gKoc93-d6gUXYEhA_L-bM%3DzqWBbu9UG2TtvX-nqTHaKA_jA%40mail.gmail.com](https://groups.google.com/d/msgid/racket-users/CAE8gKoc93-d6gUXYEhA_L-bM%3DzqWBbu9UG2TtvX-nqTHaKA_jA%40mail.gmail.com?utm_medium=email_source=footer).

-- 
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.
To view this discussion on the web visit 
https://groups.google.com/d/msgid/racket-users/25acca19-5970-1131-c63f-305abd4964e9%40sagegerard.com.

Re: [racket-users] [ANN] Splitflap: generating valid Atom and RSS feeds

[David Storrs]

On Mon, Oct 25, 2021 at 10:25 PM 'Joel Dueck' via Racket Users <
racket-users@googlegroups.com> wrote:

>
>
>- Removing dependencies: yes, I see the appeal. I’m really not eager
>to reimplement all the timezone handling and temporal comparison stuff in
>gregor, though.
>
> Joel
>

Having done a fair bit of datetime programming, my suggestion on the best
way to handle it is to not handle it.  Let some purpose-built library such
as gregor do it  instead of trying to roll your own, because datetime math
is a nightmare.


> On Monday, October 25, 2021 at 6:36:30 PM UTC-5 Sage Gerard wrote:
>
>> Thank you for this!!
>>
>> Feedback
>>
>>- I like your podcast-specific entries
>>- The validation logic is refreshing to see
>>- Re: boolean arguments, I'd stick to keyword arguments and ask for
>>any/c, not boolean?, in contracts. That way forms like (and ... (member
>>...)) won't bug users about a non-threatening contract violation, and it's
>>trivial to cast the value yourself.
>>- Unsure what licenses are compatible with Blue Oak. If you want more
>>licensing options re: IANA media type to extension mappings, here are 
>> some.
>>- MIT: https://github.com/mime-types/mime-types-data
>>   - Apache 2.0 (From the horse's mouth):
>>   https://svn.apache.org/repos/asf/httpd/httpd/trunk/docs/conf/mime.types
>>   - CC-BY-SA: Scrape MDN's table using the console on
>>   
>> https://developer.mozilla.org/en-US/docs/Web/HTTP/Basics_of_HTTP/MIME_types/Common_types
>>- I normally don't use functions like splitflap-version because I
>>can't assume that a package will define one. I'd use a program that 
>> returns
>>a version of a given package.
>>- Why is language-codes a procedure?
>>- You have a lot of local contract boundaries, so values may get
>>checked more than necessary.
>>- Prefer example.com so you don't have to leak your URLs or make up
>>email addresses that actually go to an inbox.
>>- txexpr, gregor, and web-server dependencies don't look terribly
>>difficult to remove
>>
>> --
> 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.
> To view this discussion on the web visit
> https://groups.google.com/d/msgid/racket-users/cb2927c7-3d21-41c3-89c7-d6b73a9e53f9n%40googlegroups.com
> 
> .
>

-- 
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.
To view this discussion on the web visit 
https://groups.google.com/d/msgid/racket-users/CAE8gKoc93-d6gUXYEhA_L-bM%3DzqWBbu9UG2TtvX-nqTHaKA_jA%40mail.gmail.com.

Re: [racket-users] [ANN] Splitflap: generating valid Atom and RSS feeds

['Joel Dueck' via Racket Users]

On Tuesday, October 26, 2021 at 6:51:56 AM UTC-5 Philip McGrath wrote:

> I'm not totally clear about all of the different sets of requirements 
> (RSS, Atom, and, de facto, Apple), but I thought there were more language 
> codes permitted than ISO 639-1 (e.g. 
> https://www.rssboard.org/rss-language-codes points to ISO 639-2, and 
> https://validator.w3.org/feed/docs/rfc4287.html#rfc.section.4.2.7.4 for 
> Atom points to RFC 3066. These standards also allow for the assignment of 
> new codes (and, at least for ISO 639-3, deprecation). I hope the right set 
> of codes might be in the one of the CLDR packages (also used by Gregor): if 
> so, I'd recommend getting it from there.
>

We could probably open it up to more codes for generic feeds, for sure. 
Podcast feeds are limited to ISO 639-1 by Apple. Also, system language 
detection would probably always be limited to ISO 639-1 for the foreseeable 
future, unless I find out that my existing method might encounter (and 
mis-handle) codes from other lists in some circumstances.
 

> On a different topic, for the XML stuff, is there a requirement that 
> embedded HTML be represented with the CDATA lexical syntax? 
>

I’m using CDATA for the traditional reason: it allowed me to punt on 
validating the internal content. If I didn’t use CDATA, I’d probably want 
to start handling strings and tagged xexprs differently. Strings would go 
in as `` and an exception should probably be raised if 
it can be determined (how?) that the string is actually a string of HTML. 
Tagged X-exprs would go in as `` with escaped HTML as 
you suggest. Or perhaps only tagged x-expressions should be allowed. Or 
perhaps strings should be coerced to a txexpr (by, e.g. putting them inside 
a 'div).
 

> everyone manipulating these feeds in Racket 
>

Although I make this possible, the design intent is that once you put stuff 
into a food-like struct, that’s the last step before generating the final 
feed (thus keeping all the guarantees of validation intact). I would hope 
that *content* in particular would not need more manipulation between the 
creation of a feed-item struct and the final output.
 

> (Tangentially, AIUI the convention is to use `#f` for the start and stop 
> fields when creating cdata and p-i structures in code, though apparently the 
> docs for `source` 
> 
>  
> say something about symbols.)
>

Indeed, since the structures returned by xexpr->xml use 'racket for those 
fields, I though mine ought to match.
 

> rather than using an ad-hoc encoding scheme for the entities Apple has odd 
> rules about, you can just replace them with symbols or `valid-char?`s and 
> let the library take care of everything. Well, my example code for that has 
> grown complete enough that I'll just make a PR shortly :)
>

Sounds good! Just bear in mind that Apple is not only picky about the 
characters it wants replaced but also about what you replace them with. 
E.g.  and not  for the copyright symbol. 

-- 
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.
To view this discussion on the web visit 
https://groups.google.com/d/msgid/racket-users/5b83ad5f-3be1-4bd7-a876-0184dafadbddn%40googlegroups.com.

Re: [racket-users] [ANN] Splitflap: generating valid Atom and RSS feeds

[Philip McGrath]

Excited to try this! Generating Atom and RSS feeds is on the to-do list for
one of my current projects.

On Mon, Oct 25, 2021 at 10:25 PM 'Joel Dueck' wrote:

>
>- MIME types: Yes, I should use/add a more complete extension→type
>mapping, though I probably will continue not to validate MIME types against
>the IANA list. (My somewhat erroneous note in the docs notwithstanding, it
>turns out having a non-IANA MIME type or a valid but mismatched type in an
>enclosure doesn’t actually cause feed validation errors.)
>
>
Since you have a dependency on `web-server-lib`, instead of shipping your
own "mime.types", you can write:

(define-runtime-path mime.types
  '(lib "web-server/default-web-root/mime.types"))

to use the one it ships. It seems generally useful enough that maybe it
should be split into a package like "web-server-mime-types-lib". I've been
meaning for years to improve the file, and the general
`make-path->mime-types` functionality, with some upstream database, perhaps
the fairly comprehensive one at https://github.com/jshttp/mime-db (which
pools data from Apache, Nginx, and IANA, and is used by e.g. Github Pages).


>
>- language-codes: yes this should be a value, not a procedure. Will
>change it.
>
> `system-language` should use `delay/sync` to be safe for concurrent access.

I'm not totally clear about all of the different sets of requirements (RSS,
Atom, and, de facto, Apple), but I thought there were more language codes
permitted than ISO 639-1 (e.g. https://www.rssboard.org/rss-language-codes
points to ISO 639-2, and
https://validator.w3.org/feed/docs/rfc4287.html#rfc.section.4.2.7.4 for
Atom points to RFC 3066. These standards also allow for the assignment of
new codes (and, at least for ISO 639-3, deprecation). I hope the right set
of codes might be in the one of the CLDR packages (also used by Gregor): if
so, I'd recommend getting it from there.


>
>- Removing dependencies: yes, I see the appeal. I’m really not eager
>to reimplement all the timezone handling and temporal comparison stuff in
>gregor, though.
>
> Please keep depending on Gregor! I think it's one of the treasures of the
Racket library, and we should all just use it, as even the documentation
for `racket/date` suggests
,
rather than create any more, as Greenspun might put it, "ad hoc,
informally-specified, bug-ridden, slow implementation[s] of half of" Gregor.

On a different topic, for the XML stuff, is there a requirement that
embedded HTML be represented with the CDATA lexical syntax? Under normal
XML rules, this xexpr:

`(content
  ,(cdata #f #f ""))

should be semantically equivalent to this one:

'(content "Hi & < >")

which would generate the XML concrete syntax:

divpHi  
/p/div

This has the advantage of avoiding prohibition on `]]>` within CDATA
concrete syntax, and it lets everyone manipulating these feeds in Racket
avoid the need to add and remove "" from the string
inside the CDATA struct. (Tangentially, AIUI the convention is to use `#f`
for the start and stop fields when creating cdata and p-i structures in
code, though apparently the docs for `source`

say something about symbols.)

Regardless, rather than using an ad-hoc encoding scheme for the entities
Apple has odd rules about, you can just replace them with symbols or
`valid-char?`s and let the library take care of everything. Well, my
example code for that has grown complete enough that I'll just make a PR
shortly :)

-Philip

-- 
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.
To view this discussion on the web visit 
https://groups.google.com/d/msgid/racket-users/0100017cbc714ad9-99e03c7f-69ae-43c1-92d4-58536cab5278-00%40email.amazonses.com.