recursion (and usually in tail position) is usually used in functional / immutable context

thanks

Look at the data type. If the data type is recursive (I.e. it refers to itself) then it is natural to write a recursive function.

The simplest recursive data type is the singly linked list. So that’s why so much time is spent explaining how to write functions that deal with lists.

would anyone object if I created a #Racket2 channel?

Friday, 19 July at 12pm–3pm there will be an impromptu Racket meetup at the cafe at the British Library ‘The Last Word’ see https://goo.gl/maps/M62e4b9JK7c1oaA69

No agenda. All welcome. Spread the word!

I’ll be drinking tea, eating cake(I hope), and will be easily identified as a the man with racket logo on his laptop. Updates on #uk channel

reading libraries at https://docs.racket-lang.org/mrlib/index.html there is no visual representation of the APIs, it will be best of done so we don’t need to test everything

@kokou.afidegnon Yeah screenshots would have been nice.

@sorawee Can I reply to your comment about “keywords are currently not extensible by clients” and auxiliary-macro-contexts here instead of on the issue for making a pattern-matching RFC?

@spdegabrielle I think that’s a great idea

#racket2 :arrow_heading_down:

I agree - thanks for creating the channel!

wait, racket2? what is it

This may ask more questions than it answers, but: https://groups.google.com/d/msg/racket-users/3aIPOGbGgmc/A4HHSbdxAwAJ

is tldr native infix notation?

no

not as such at least

TL;DR is that @mflatt made a suggestion at RacketCon to change the syntax for racket2 with the goal of making it more palatable for… lets say non-()-nerds

he keeps stressing that this was a suggestion and there should be a discussion and a process that might lead to new syntax

some people have made pretty good contributions already in my opinion

to be honest, @mflatt’s talk included quite a few other things one could do, the syntax one was the controversial one :wink:

but () is kinda one of the selling points in lisp, no?

data-like syntax gives easy way to make extensions in the form of syntax macros

@sanchom there is a issue ‘Make an RFC for Matthew’s 3 syntactic principles’ at https://github.com/racket/racket2-rfcs/issues/3

Save me from re-watching..what were the other things? (I think I was blinded by the syntax thing)

Java has macros in the form of annotation processors, and yet your average Joe doesn’t even know about it, since it’s pain to use

and it’s not like they didn’t try to make it nice and all, but the thing is, language syntax design doesn’t really open up itself for such thing

Things like compiling to web-assembly, supporting ARM64

aren’t the slides online?

I didnt think of that

brb

then normally turn up at https://con.racket-lang.org/#schedule but they are not there yet

I’ve made a #racket2 channel

I’ve suggested using the scribble at-exp syntax for algebra-style function notation: function(arg, ...)

how is @something better than (something

might be just me, but at-syntax is.. hard on the eyes (though very handy in template context like html)

unambiguous mapping from fn(…) to (fn …) ?

I’m not worried about losing Racket1 syntax as it is clear that isn’t going away.

As long as there is a unambiguous 2-way mapping between racket1 and racket2 I’m thinking macros might be built in Racket1 then compiled into Racket2? (or is that an insane idea)

should we move this discussion to #racket2 ?

tbh no, I don’t think I’m in position to argue one way or another at this point in time for I’m relatively inexperienced, and this is very vague topic yet

perhaps when something more concrete emerges

Neither am I :grinning:

And inexperienced perspectives are valuable - everyone starts out inexperienced, but it’s hard to remember it that was like.

Does anyone know of a good rainbow blocks mode for emacs that plays nicely with Racket?

I wanted to try one out, but several that I looked into do not appear to be working.

Yes!

Lets say I have a macro m, and it allows the keywords #:a, #:b, and #:c. However, I want it to be extensible if someone defines an m-expander, they can expand to some combination of those keywords.

As the implementor of m I can define the calling-convention for m-expanders to return a list of syntax objects, which I will splice into m. (define-m-expander extension [(_ stuff ...) #'(#:a a #:b b #:c c)]) And then use the extension inside m (m (extension stuff ...)) ; =expands-into> ; (m #:a a #:b b #:c c) And the same thing applies to match-expanders, if m was a match-expander and extension is defined as an m-expander only valid within m.

However, allowing unquoted keywords as normal patterns does not help this, and in my opinion it makes this less-useful because of the ambiguity. Imagine m also had a by-position argument x. (m x #:a a #:b b #:c c) or (m #:b b #:a a x #:c c) Now if m is a match expander unquoted keywords can be normal patterns, then x being #:a, #:b, or #:c makes it ambiguous. (m #:b b #:a a #:c #:c c) However if match patterns need a quote in front of a keyword in order to match a keyword value, then that takes away the ambiguity (m #:b b #:a a '#:c #:c c) Now it’s clear that the x argument is '#:c, and in the match-expander, the match will only succeed if the x field is the value '#:c

I think we are talking about orthogonal issues (but I understand your points above)

What I don’t like is that with keywords, clients can’t extend the macro with more keywords. They can indeed extend the macro with expanders as you illustrate above, but then things are not uniform.

E.g., it doesn’t make sense to write

(define-syntax-parse-expander #:hello ....)

(define-simple-macro (foo)
  #:with ...
  #:hello ...
  ...)

Instead, we would need to write

(define-syntax-parse-expander hello ....)

(define-simple-macro (foo)
  #:with ...
  {hello …}
  ...)

And what I’m saying is that, why don’t we make things uniform in the first place. E.g.,

(define-syntax-parse-expander hello ....)

(define-simple-macro (foo)
  {with ...}
  {hello …}
  ...)

Amusing quote from https://m00natic.github.io/lisp/manual-jit.html#fn.13

... from Common Lisp's perspective but Racket seems to have even more elaborate macro phase system. Part of the reason is Racket, being a Scheme descendant, has single namespace for functions and variables (Lisp-1). And all those crazy academics!

@krismicinski are you talking about something like this? https://www.emacswiki.org/emacs/RainbowDelimiters