Rhombus bi-weekly virtual meeting

[mflatt]

Let's try a regular Rhombus virtual meeting, open to anyone interested.

The next meeting is on November 14.

• When: Every other Thursday at 7:00 pm Mountain Time, which is also

  • 6:00pm Pacific Time
  • 8:00pm Central Time
  • 9:00pm Eastern Time
  • 02:00 UTC next day during northern northern winter (standard time), 00:00 UTC during summer (daylight saving)
  • 3:00am Central European Time next day (usually; beware that daylight-saving shifts may not match)
  • 10:00am next day Hong Kong Time during northern during northern winter (standard time), 9:00am summer (daylight saving)

• Where: https://utah.zoom.us/j/96590513005

• What:

  • discussion on new things to augment the discussion here

History: Meeting time was 2:00pm Mountain Time before August 4, 2022, then 6:00pm Mountain Time until July 20, 2023, then back to 2:00pm Mountain Time until January 11, 2024, then back to 6:00pm Mountain Time until April 3, 2024, then to 7:00pm Mountain Time.

[mflatt]

Plan for September 30: brief intro and then work through #122.

The idea is that digesting the details of a proposal takes time, but working through one as a group can make things more clear and aid further discussion.

[mflatt]

That's not what we did. Instead, we talked at a higher level about what a Rhombus mission statement could be, especially for the surface-syntax part. Two people took on the action item of turning the discussion into a document.

[jackfirth]

Minor scheduling announcement: Matthew and I decided to have meetings on a once-every-other-week basis rather than once a week. So after today's meeting, the next meeting will be on October 28th. I've added a calendar event anyone can invite themselves to here.

Today's agenda: I've drafted a State of Rhombus document. We can discuss it today and hopefully publish it more widely after a few rounds of comments.

[jackfirth]

Meeting summary: we talked about the State of Rhombus document and agreed that it needs a few more concrete details about the next steps, especially in regards to our plan for Rhombus libraries. More information there would make it easier for people to find sections of the Rhombus project they can contribute to or take ownership of. I plan to add this information to the document and then we'll review it again at the next meeting on October 28th.

[mflatt]

Agenda for today's meeting: we'll start with the updated State of Rhombus document, based on the previous meeting, and then start talking about pieces of Rhombus that people are interested in working on.

[jackfirth]

Action items

• @samphillips to start a GitHub discussion on example programs written in shrubbery notation.
• @mflatt to turn his list of small Rhombus tasks into a GitHub discussion.
• @sorawee to explore whether autoformatting tooling and shrubbery notation mesh well.
• @samth to write a discussion thread about strings in Rhombus.

Meeting notes

• @lojic brought up Arrow (due to a recent Slack conversation) and asked about how communication between Racket and Rhombus will work. Summary from @mflatt: we're not making new VM-level primitives so interop will work as it does between racket and other #lang implementations, rather than working like an FFI.

• @sorawee: can passing around tuples without boxing them be possible in Rhombus? @mflatt: trying to infer a bridge between multiple values and tuples is probably very hard, and it would be a lot of compiler implementation work.

• Conversation on structs and classes:

  • @mflatt: maybe struct should be called class. How will we bridge rhombus classes with racket/class? Also, should classes/structs be opaque by default?
  • @jackfirth: types fall into two categories: types that represent data (e.g. java records) vs types that represent behavior (e.g. java classes and interfaces.) Different tools for representing them makes sense. Types representing data benefit from immutability, transparency, and structural equality. Types representing behavior benefit from mutability, object identity, and opacity.
  • @samth: no mutability and inheritance make sense for a means of representing data.
  • various thoughts on Clojure-style maps-as-bags-of-data (structural) v.s. traditional racket-style structs with predicates and named fields (nominal.) @jackfirth: nominal data lends itself towards static representation, structural data towards dynamic representation. Racket's existing macro infrastructure works well with static information. VM-level infrastructure may need to be built to make dynamic representations more efficient and easier to work with.
  • @jackfirth inheritance comes in two flavors: inheritance of interface and inheritance of state. The former causes far fewer problems than the latter. Representations of data and behavior both benefit from inheriting interface, but representations of data don't benefit from inheriting state.

• Conversation on strings:

  • @samth: modern languages (swift and rust for example) make different choices with strings, such as utf8 encoding, immutability, deprioritizing indexed access. Racket does the opposite for all of those. Can rhombus do better? Can rhombus have a different string representation, or could the VM change to admit multiple string representations?
  • @mflatt: this is very relevant for indentation-sensitive languages, particularly those where things need to horizontally align with the content on preceding lines.
  • This also matters a lot for autoformatting.
  • See also the canonical forms for Unicode strings: https://unicode.org/reports/tr15/.
  • @jackfirth: the Unicode folks also wrote a spec with recommendations for handling Unicode in programming language identifiers, see https://www.unicode.org/reports/tr31/.
  • Notes on emoji string length: https://hsivonen.fi/string-length/.
  • @jackfirth: can we explore constraining the surface syntax to only express leading indentation with a constant multiple of some number of spaces? So no horizontal alignment with content on the above line. @mflatt: yes, though there are some interaction points in shrubbery notation. @sorawee: it's possible for autoformatting to handle this algorithmically, including during renaming changes. @AlexKnauth: this impacts column counting in error messages and editors, and it's affected by fonts (monospace vs duospace.)
  • Jon Zeppier (@97jaz, I think): what is the space of options we're looking at here? Strings as a list of code points, code units, or grapheme clusters? Are there other options?
  • @samth: do we want one single string type that supports many operations? What about ropes, string builders, etc.? Do we need a string interface? Or should we have multiple distinct string data structures and require conversion between them?

[mflatt]

Agenda for today's meeting:

• moving Rhombus officially out of "brainstorming" and into "iterative design"
• looking at and discussion example programs written with the current prototype
• strings

[mflatt]

Next meeting

December 2 (three weeks instead of two), because November 25 is Thanksgiving in the U.S.

Action items

• @AlexKnauth will post about a surface-syntax proposal

Notes

• moving Rhombus officially out of "brainstorming" and into "iterative design"

  We discussed whether to create a new repo or rename the current one. Possibly, when you rename a repo, GitHub forwards the old name to the new name, so we wouldn't break links. The new name might be "rhombus-prototype". Whether renamed and reorganized or created as a new repo, the evolving prototype would reside there instead of an external repo like mflatt/shrubbery-rhombus-0.

  But the idea that we're moving out of brainstorming, including that we'll tentatively adopt a syntax, seemed to surprise some people. So, we tabled the move for now.

• looking at and discussion on example programs written with the current prototype

  We looked at @samdphillips's examples, which are very nice. There was a little discussion on details, such as whether leading-operator indentation works ok and whether there's a better name for -:. The annotation system is working ok, but @samdphillips already misses ->.

• strings

  We recapped issues and possible solutions, including the design points of keeping strings as sequences of Unicode code points versus sequences of grapheme clusters. Overall, we seem all agree that experiments are necessary, and @97jaz has been building useful pieces toward those experiments and either conclusion.

[rfindler]

There was also a discussion on whether or not formatting needs information at the macro level or not, with @sorawee making a compelling case vis a vis . vs + and an example involving a set.

[sorawee]

Nevermind about set. That was me being silly. A better example is function application vs macro, or array indexing vs macro, etc. You probably should write:

parameterize [abc: 1]:
  body

with a space between parameterize and [, but when it's array indexing, you probably should not have any space.

abc[123]

[mflatt]

We are meeting today!

Agenda:

• data structures
• moving Rhombus officially out of "brainstorming" and into "iterative design"
• what have we learned from writing more Rhombus programs?

[mflatt]

Some discussion points for tomorrow's meeting, December 16:

• equality operations and interaction with collections
• fancy-app

Given the upcoming holidays, out meeting after this one will be January 6 (instead of December 30).

[mflatt]

Here's a summary of today's discussion, hopefully not too biased by my perspective:

We generally agreed on adding equal-always? and making it the default equality operator for Rhombus (as ==). Although we have trouble pointing to specific Racket code that, say, avoids bugs by using equal-always? where equal? would not have worked (maybe I'm the only one worried about that), there's a compelling rationale for why equal-always? is a good default. See #16 for more. The story is nice enough that we're willing to take on a fourth primitive equality operator in Racket, and the implementation is pretty far along at racket/racket#4076. Assuming we go this way, though, it would not be added to Racket until after v8.4.

The interaction of equality operators and collections seems less clear, at the moment. While == will make a good default, some uses of collections will need a different equality+hashing operator. The equality operator can be implemented by wrapping every key in an object that implements equals in a selected way, but the expense and hassle of the extra objects is worrying. Maybe the choice of equality operator doesn't belong as part of the collection interface, and it's just a question of what constructor is used to create a collection (where maybe the constructor is parameterized over its equality function). Then again, for operations like union that work on multiple collections, maybe some notion of compatible equality is needed.

For fancy-app — that is, using _ in place of an expression within a sufficiently simple expression to create an anonymous function — there was general agreement that it's worth supporting. More experiments are needed to see how deeply it needs to be embedded in the expansion protocol to work nicely with general operators. (While we discussed precedence a little, but I think that was a detour caused by me not understanding how _ works. The most helpful example for me was _ * 2 + 1, which does not mean fun (x): x * 2 + 1 as I expected, but means (fun (x): x * 2) + 1; the "smallest enclosing expression" rule avoids various problems.)

Finally, we discussed how to discuss a new surface-syntax proposal. Wraith #202 is on the agenda for the next meeting on January 6.

[plane]

The most helpful example for me was _ * 2 + 1, which does not mean fun (x): x * 2 + 1 as I expected, but means (fun (x): x * 2) + 1; the "smallest enclosing expression" rule avoids various problems.

The current PR (mflatt/shrubbery-rhombus-0#4) seems to have the former behavior:

val f: _ * 2 + 1
f(10)               // => 21
(_ * 2 + 1)(10)     // => 21

The latter behavior seems like it could surprise everyone else, too. How would you write fun (x): x * 2 + 1 using fancy-app in that case?

[Metaxal]

The most helpful example for me was _ * 2 + 1, which does not mean fun (x): x * 2 + 1 as I expected,

That's what I was expecting too.

but means (fun (x): x * 2) + 1; the "smallest enclosing expression" rule avoids various problems.)

While I can imagine there are a number of gotchas otherwise, that one behaviour seems to greatly limit the utility of fancy app, as it does not seem possible to use it to obtain (fun (x): x * 2 + 1), which is in itself surprising.

One possibility is to specify the enclosing context explicitly, e.g., { _ * 2 + 1} (or whatever other brackets make sense), but that's becoming closer to using fun altogether. Alternatively, (fun: _ * 2 + 1) (note the lack of parentheses) which avoids naming arguments.

(Then again, I don't use fancy app in general, and I expect to stick with s-exp syntax in the foreseeable future anyway.)

[samdphillips]

Continuing this discussion at #203

[cwebber]

For January 6th, I'm interested in attending... I kicked up some dust recently about surface syntax decisions and there was expression of interest on today's call about discussing this at the next meeting.

I also offered to help turn the wraith writeup into a proper proposal before the meeting, though I think I'd appreciate some help with that (which @AlexKnauth said they probably could do though it was not their primary focus at the moment).

[cwebber]

PR added here. (It might benefit from some extra integration with the rest of the repo, currently just leaves Wraith in its own subdirectory rather than changing the toplevel README or whatever.)

[mflatt]

Agenda for the January 6 meeting this week:

• Wraith (see also Add Wraith syntax proposal #202)

[cwebber]

Looking forward to it, and I've prepared a short walkthrough of the ideaspace to open us up if that's okay.

[mflatt]

Our next meeting is this Thursday, January 20.

As a starting point for discussion, let's take up the question of iteration/comprehension syntax (along the lines of for and for/fold) and how it interacts with tranducer syntax (see also https://docs.racket-lang.org/rebellion/Transducers.html).

[mflatt]

Notes on today's meeting:

For for, we started with #209 and also looked briefly at what Scala does. Putting iteration clauses in the body seems to work well, and it still supports nested iteration well, so we expect to keep that. Some ideas toward the next experiment:

• Change "folder" to "reducer" with the goal of unifying for and transduce. That is, a tranducer pipeline should consume the same kinds of sequences as for, and they should end in the same kind of reducers. We expect this unification to work out with performance results similar to for in Racket level, where higher-order uses of sequences are possible while first-order uses are recognized (in a way that is reasonably easy for programmers to reason about) and optimized.

• Move the reducer part of for to the end of the for body block, because that's where values to be reduced are produced. In the current implementation, it was at the top (just?) because Racket for variants use that order.

• Try putting for/fold-like accumulators into the body of for, too. That should make room for options along the lines of the loop package.

• Try allowing macros to expand to iteration forms, instead of requiring that ~each and similar are present in the source for form.

We considered alternative names for for, since putting iterations in the body means that it doesn't have quite the traditional for shape. After some discussion, we concluded that for is probably still best, because the benefits of the connection to traditional for outweigh the drawbacks of using the same word for something that has a somewhat different shape and use.

We also talked about the status of equal-always? in Racket, which will provide the default equality operation for Rhombus. The one piece still to be worked out is how to allow specializations of equal-always? and how those specializations relate to prop;equal+hash; we didn't make any particular decisions, leaving it to Alex to explore. It would be nice to shed the secondary hash-code function from the prop:equal+hash protocol, even at the Racket level, but maybe later. (BC relies on it, currently.) Meanwhile, there really should be a good hash-combiner function/object for use by implementations of prop:equal+hash.

[countvajhula]

If I understand "specialization of equal-always" correctly @mflatt, then this is exactly what my proposal earlier was about (for reference). I haven't had a chance to return to it, but to summarize in this context, the idea is that instead of relying on users to do:

(= (floor a) (floor b))

or

(= (->string a) (->string b))

we instead bake the mapping function into a higher level equality interface ==:

(== #:key floor a b)
(== #:key ->string a b)

This == becomes pervasive in all equality-related notions throughout the language, e.g. hashes, sequence interfaces that leverage equality (e.g. index-of, remove, replace, ...), always expose a #:key optional argument. For instance,

(define students (make-hash #:key string-upcase))
(hash-set! students "alice" (student "Alice A" "CS"))
(hash-set! students "Alice" (student "Alice B" "Biology"))

And the second Alice overwrites the first since this hash is case insensitive.

I don't think there would be any performance related issues here because every case where we use a key function is a case where we would use one anyway. prop:hash issues also don't come in (which I think you pointed out, Matthew) because the ultimate hash used is simply the one defined in equal-always after applying the mapping function. The question is just whether we choose to incorporate the notion of a key function into the equality interface presented by the language or leave it to users to do it in an ad hoc way.

I see advantages to baking it into the equality interface which I mentioned earlier, viz. a single interface usable in all cases by virtue of mapping functions being able to express any notion / specialization of equality. It would also have the effect of eliminating the need for a large number of predicates, such as string-ci=?, and the need for users to define custom binary equality lambdas for use with interfaces like member. Another big benefit is that the same key notion can be used in other elementary relations too including <, <=, >=, and >, yielding an intuitive and pervasive interface (e.g. this sort interface), while also, I suspect, resulting in big savings in the size of the language, by virtue of covering a lot of cases currently covered in ad hoc ways such as string-ci=?.

To be clear, there isn't a single mapping function being talked about here but simply a key optional argument that the user can supply, which can be any unary function. We already do this all the time in using the equality relation in any programming language -- the suggestion here is that this is not a coincidence, but rather reflects something about the nature of equality (i.e. the ability to specialize it via functions being part of the idea of equality itself).

If my attendance at an upcoming meeting would be useful then I can aim to attend, let me know 👍

[countvajhula]

@mflatt I'd love to join an upcoming meeting to discuss the interface to elementary relations such as =, < and > in the language -- specifically the possibility of making them generic, and supporting an optional key argument across the board as a way to simplify the interface. Would this Thursday's meeting be the best one to join, or another one at a later date?

[mflatt]

Unless this reply is too late (sorry I missed the question earlier!), let's make it today.

[mflatt]

Our next meeting is today, Thursday, February 3.

Initial agenda:

• comparison operations and a possible key argument (if @countvajhula is able to attend)
• experience writing Rhombus macros, so far, and discussion on how it could be easier/better

[countvajhula]

Another thing is, the key argument is not so much a way to simplify the relation as it is a lightweight way to define it. So when we say (sort < #:key length (list "abc" "a" "pqrs")), we are providing a definition of what we would like less than to mean in this case. In the case of equality, it so happens that the key argument is not just convenient but can in fact express any definition of equivalence we might want. In the case of order, it can express many definitions of ordering, but perhaps not all.

Given this, one perspective could be that we do not need to guarantee completeness via the APIs themselves -- only convenience. It just so happens that with equality these coincide. But with order, instead of supporting both a key as well as a comparator, we could instead leverage the fact that order relations could be extended in the same way as equality, e.g. via some form of generic interface. So then, even if key cannot ensure complete coverage of definitions, you could always define a custom data type (as you perhaps should, if the case is so complex) which specifies the definition of the order via comparators, just like gen:equal+hash. And in this case, we only expose key in the API, while the comparator is specifiable via the generic interface. This would keep APIs lean and also encourage good data modeling (i.e. creating data structures instead of using just lists or anonymous tuples).

[jackfirth]

Thinking of the key argument as a lightweight convenience makes total sense to me. In that vein, I think it works best with extensions of equality and sorting where you're dealing with more than two objects. For the regular binary infix operators like == and <=, I don't think a key argument makes much sense since it's not really any more convenient than just writing f(x) == f(y) or x.f() == y.f(). But for stuff like xs.sort(~key f) it really helps.

[benknoble]

From the Racket side, though, I prefer (= #:key f x y) over (= (f x) (f y)); the difference is more dramatic with multiple arguments:

(<= #:key f w x y z)
(<= (f w) (f x) (f y) (f z))
(apply <= (map f (list w x y z))) ;; to avoid typing out (f ?) each time

[jackfirth]

Right, for racket's variadic comparison functions a key function argument seems useful. Rhombus will use infix operators though.

[countvajhula]

Personally, while I don't mind a syntax like a =.f b [disclaimer: I'm not familiar with Rhombus idioms!], I can also see the argument that the value provided for the binary case is not great enough to warrant introducing an extra language feature here. At the same time, if the key argument is supported everywhere else, then excluding it here could also be seen as the decision being made (rather than including it), in which case, we would have to ask, is the value gained by excluding it enough to warrant the exclusion? It may be too early to have a strong opinion here.

[mflatt]

We meet today, February 17.

The topic is: experience writing Rhombus macros, so far, and discussion on how it could be easier/better.

[mflatt]

Notes from two weeks ago:

• there should be syntax classes for comon patterns
• the current $ escape seems noisy; changing the syntax-class annotation from $: to :: helps, but only some
• the current way to distinguish already-parsed-right infix-operator macros seems clumsy
• can we get rid of ...... by having ... produce a sequence instead of a raw list?
• can the macro stepper be more adaptable to shrubbery notation?
• it seems like there is some connection to string interpolation

[mflatt]

We'll meet today, March 3. There's a not a specific agenda this time, but we can discuss the current status and plans.

[spdegabrielle]

https://gist.github.com/countvajhula/bf4041e4ae5e2feb7ad4b9631e2cf734
tabled by @countvajhula (sorry I don't have minutes I just didn't want to lose the link)

[mflatt]

We can start tomorrow's meeting (March 17) with ideas and discussion on #213.

The U.S. has switched to Daylight Saving time since the last meeting, so please check the mapping of 2:00 PM MDT to your time zone.

[mflatt]

Meeting notes

On aspects of #213:

• the use of '«...»' isn't great, and it's a little uncomfortable that it's not really the same as «» after : or |, but the uses are consistent in the sense of resolving grouping ambiguity
• some of us think sets and maps will turn out to be common enough in Rhombus that using {} for those will be worthwhile
• syntax forms in Racket avoid various issues by being sensitive to bindings; although we're not enthusiastic about the idea of reintroducing pattern variables as opposed to literals, maybe there's a middle ground that makes good use of binding for escape levels
• next experiment: try brinding back quoting depths and see if that makes macro-defining macros better

Planned topics for upcoming meetings:

• March 31: class and method dispatch
• April 14: equality (required reading: https://gist.github.com/countvajhula/bf4041e4ae5e2feb7ad4b9631e2cf734 https://github.com/countvajhula/rhombus-prototype/blob/master/rrfi/equality.rst).

[countvajhula]

For equality, this is the updated link (reading for April 14): https://github.com/countvajhula/rhombus-prototype/blob/master/rrfi/equality.rst

[mflatt]

Agenda for the August 31 meeting:

We are currently in the "Phase 2: Iterative Design" step of the Rhombus Plan. What will it take to get to the "Phase 3: Conversion" step?

[mflatt]

We identified four specific areas to investigate or work on further before the current phase should be considered complete:

• collection classes, including the choice of interfaces and implementations that are available from #lang rhombus versus further imports

• whether and how to support more adaptations of existing datatypes without wrapping

• the interaction of annotations, contracts, and types --- including whether annotations should be able to influence indirect use sites, such as a function call whose argument has an annotation

• exceptions, including how to make more information about an exception available through fields instead of the message text

Based primarily on specific plans for collection classes, we expect these tasks to take the next few months. We may be ready to consider declaring movement to the next phase by the start of next year.

[mflatt]

In the September 14 meeting, we'll discuss types.

[sorawee]

I will miss it, unfortunately (it's my 3am, and I have work in the morning)

Will @capfredf join the meeting?

[capfredf]

Thanks for the reminder. @sorawee . I should be able to join.

[jackfirth]

The list design in #351 is ready for review and a good topic for the next meeting.

[mflatt]

Ok, let's make that the agenda for the September 28 meeting.

[jackfirth]

A work meeting came up, and I can only make it to the first half of the Rhombus meeting. Hopefully that's enough time to get at least some consensus on the basic plan and the immediate next step of #371.

[samth]

At the meeting we discussed many things, but two in particular:

1. How to support migration while not breaking current Rhombus users (eg @mflatt's class)
2. What other systems seem like good precedent. Below is a list of some of the ones discussed:

• Guava (@jackfirth's major inspiration): https://github.com/google/guava/wiki
• Scala: https://docs.scala-lang.org/overviews/collections-2.13/overview.html
• Java: https://docs.oracle.com/en/java/javase/20/docs/api/java.base/java/util/doc-files/coll-overview.html
• Kotlin: https://kotlinlang.org/docs/collections-overview.html
• OCaml Batteries: https://ocaml-batteries-team.github.io/batteries-included/hdoc2/
• OCaml Core: https://ocaml.org/p/core_kernel/latest/doc/index.html

[mflatt]

No meeting November 23, which would be our normally scheduled next meeting, due to the U.S. holiday. I suggest that we delay only by one week and meet on November 30. That does shift our meeting schedule, though, so let me know if that creates trouble.

[mflatt]

For the November 30 meeting, we'll start with a report from Alec on the RRB tree implementation.

[samdphillips]

Notes from today's (2023/12/14) meeting:

I talked about some observations from doing some Advent of Code puzzles with Rhombus recently:

• List.sort is missing the ~key keyword option that is in Racket sort.
• Dealing with literal Chars is painful, either use the shrubbery escape syntax #{#\newline} or use string reference "\n"[0]. No one has a good solution. The group on the call all prefer having a Char data type to just using strings of length 1.
• The unfortunate formatting of this shrubbery (which can be made nicer wrapping the match with parens)

  test
    || match val
  | aaa: bbb
  | ccc: ddd
  

• Setting up a kind of "static" method in a class namespace where the return
  annotation doesn't work.

  class Foo():
    export bar
    fun bar() :: Foo:
      Foo()
  

  This can be made to work by defining the function after the class and exporting the name from the class namespace (which is documented in the class overview

  class Foo():
    export make
  fun make() :: Foo:
    Foo()
  

• Using Shrubbery at notation to make here-docs

  defn.macro 'example_input($(name :: Identifier), [$s, ...])':
    'def $name: String.append($s, ...)'
  
  example_input(the_input){
  aaa
  bbb
  ccc
  }
  

• Ported a minimal amalgam of Parsec/MegaParsack/microparsec to Rhombus for dealing with Advent of Code puzzle inputs. https://github.com/samdphillips/aoc-2023/blob/main/util/parsec.rhm

@mflatt needed to leave early and @AlexKnauth joined late so in the second half of the meeting we talked about using the at notation to make format strings.

• Initial function @samdphillips is using

  fun fmt(vs :: List):
    def ss:
      for List:
        each v: vs
        to_string(v)
    String.append(& ss)
  
  @fmt{Add one and two makes @(1 + 2)}
  

• Alex thought we could create a "formatting" space with bindings for common formats.

  @fmt{Here are some numbers @a([1,2, math.pi])}
  @fmt{Pi is @r(~precision: 2, math.pi)}
  

[usaoc]

class.together can be used to allow early reference to the class name, but I think defining the function outside the class is indeed a better option, because conceptually the fun doesn’t “belong” to the class. (Also I personally like to use namespace extension as opposed to explicit export.)

[samdphillips]

Thanks for the tip. Namespace extension seems to be working better for my particular use right now.

[AlexKnauth]

I was thinking about the Rhombus equivalents to Racket's ~a, ~s, and ~v format specifiers.

If text mode is like ~a, and expr mode is like ~v, then what would ~s correspond to? I'm thinking it might correspond to coercing a value into a syntax object with '$x', and then formatting that syntax object with text mode. But I don't know whether enough people will want that to justify making a special format specifier for it. Using a pattern like @a('$x') isn't that much harder than using @s(x), and ideally, most people who want this would just make x a syntax object to begin with, and if they do that then just using @a(x) directly will do what they want.

[mflatt]

We'll take a break for holidays, so the next meeting is January 11. Also, we'll switch back to 6:00pm Mountain Time (instead of 2:00pm), so that it's a reasonable time of day for @usaoc.

[mflatt]

The topic for this week's meeting is #455.

As a reminder, the meeting is scheduled at 6:00pm Mountain Time, which is 4 hours later in the day than recent meetings.

[mflatt]

The conclusions from this meeting was that we'll merge #455. Next step include creating a PR for Racket to add racket/treelist there and experimenting with mutable-treelist/MutableList.

[mflatt]

Notes on the February 22 meeting

Some general Rhombus things that need more work or discussion:

• Try again to find a better syntax for symbols.
• Reconsider what let means, and in particular not have a def binding after let be visible in the enclosing body before the let.

Thoughts on the pict library:

• Probably should remove the experiment of allowing a pict as a width or height argument to rectangle.
• Add beside and stack (or above?) as methods to Pict. Those kinds of combiners can be both functions and methods.
• Maybe lines and paths generally should have more direct support, instead of only having them in pict form. The pict/radial library could then use it instead of having it's own Radial objects.
• The pict/radial library should not export names that conflict with the pict libary. The circle function isn't so useful can can be removed (but circle_radial is ok), while polygon can be regular_polygon.
• There should be an annotation corresponding to allowed arguments for t and for slide, for example, and the documentation should use those annotations.

[rfindler]

Also, it would be nice to support people who want to experiment with various functions that work at the level of coordinates, without having to drop down to either racket/draw or something like dc, as Alex enjoyed being able to do. For some situations, it is nice to have both coordinates and the friction-free environment of picts together somehow.

[mflatt]

Plan for the March 21 meeting: Cooper will present his background work and initial design for a regexp sublanguage.

[mflatt]

Notes from the April 4 meeting:

Besides discussing recent changes and pull requests to make sure we agree, we tried to make a list of things that we'd like to finish or clean up before moving the next Rhombus stage:

• improve class support for immutable private fields — Sorawee will work on this.
• ranges and step-by — Wing Hei will work on this.
• clean up List methods — Matthew plans to sync List method with racket/treelist operations, and also add MutableList.
• enumerations and symbols — Binding enumeraions has the advantage that it catches spelling mistakes, but the disadvantage that you have to use longer names to avoid conflicts. We speculated on grouping directions like #'left and #'bottom into larger enumerations (so the enumeration can have a short name) and having annotations that identify subsets.
• fancy app — It's still not clear how to extend to binary operators, though, without breaking precedence parsing.

For enumerations, the idea from the meeting did not work out well when I tried it. PR #497 is what I found to work well in practice, which is to have long names for use in contexts where it's worthwhile for checking, but to generally use symbols for brevity.

[mflatt]

Agenda for the June 13 meeting: moving to the next phase and deciding on the process for picking the language name.

[spdegabrielle]

How did the meeting go?

What was decided? I'm interested in the porting of code and documentation? (and the name process obviously 🤣)

Congratulations to all involved Phase 2 - it was a biggie! It is wonderful to see such progress.

best regards

Stephen

---

partial copy of plan.md Phase 3:

Phase 3: Integration (months or years)

GOAL AND OUTPUT: Complete language, libraries, and documentation, including a name for the language.

PROCESS: This phase starts the attempt to port and adjust appropriate existing code and documentation (e.g., in the Racket main distribution) to make sure it works and to continue sorting out any mismatches between the new language and #lang racket at an even larger scale.

A language name—as opposed to a temporary project name—must be picked at this point. By delaying the choice of name until we know what the language is, we avoid confusion and misinformation due to historical properties of Rhombus-in-development that end up not being true about the completed language.
[...]

[mflatt]

We had a short meeting that was just about how to get started on names. See #510, and add suggestions!

[mflatt]

At the July 25 meeting, we started a wiki page to coordinate integration tasks. See also #521.

[mflatt]

Plan for the August 8 meeting: Cooper will report back on how the rx sublanguage has turned out — with prepared slides, because this brief presentation is a step for his Bachelor's thesis.

[mflatt]

The September 19 meeting, like the one before, was just short updates and discussion on various Rhombus (and Racket) things that we're working on.

We decided to skip the next regularly scheduled meeting on October 3, since that's just a couple of days before RacketCon. The next meeting will be October 17.

[mflatt]

Skipping October 31, too, since that's Halloween. The next meeting is November 14 — still 7:00pm Mountain Time, but that's Mountain Standard Time, because Daylight Saving ends between now and then.

Edit: November 14, not 13.