
@laurent.orseau It’s Ok, I don’t read my own messages carefully enough either.

Racket’s procedures can be quite flexible in their arity: I’ve seen procedures that requires a certain multiple of arguments (e.g. <https://docs.racket-lang.org/reference/hashtables.html?q=hash#%28def.%28%28quote.~23~25kernel%29._hash%29%29|the hash procedure>). Are there any opinions on such procedures? Would it be worthwhile for my lang to provide special support for such procedures?

Variadic functions are in most languages. I know some people like to test a language by answering: Can a user implement implement print
?
The C programming language didn’t have variadic functions from the beginning; the result wasn’t pretty when they finally were added.

I’m not fond of some uses of variadic functions (e.g. print
) but others I think are perfectly fine (e.g. +
).

In the case of functions like hash
, I tend to think that a macro would be a better solution.

Presently, my lang’s lambda
can handle rest arguments, and I think that’s sufficient. I don’t intend to provide a case-lambda
, because I think it’s confusing.

If you have rest arguments, then you already have better variadic functions than C!

My lang is, essentially, a dialect of #lang racket
, so it inherits all of the nice parts (but hopefully none of the not-so-nice parts!)

If you have some design issues in mind, don’t forget to open issues for Rhombus: https://github.com/racket/rhombus-brainstorming/issues\|https://github.com/racket/rhombus-brainstorming/issues

Will do. I may also be ~stealing~ borrowing some ideas from the Rhombus discussions :smile:

That would be a great testbed

You could do this: (hash
(entry 'a 1)
(entry 'b 2)
(entry 'c 3))

But that’s still variadic, right?

Definitely report on your experiences and experiments in those issues! An ounce of running code contains more valuable knowledge than a pound of discussion about hypotheticals.

Yes, but not alternating. No need to write special precondition checks to verify the list is even, cooperates more with type checkers, and requires less effort from implementors.

entry
is really… a lot of typing. Might not be convenient for users?

Macro would help with that. Maybe (hash ['a 1] ['b 2] ['c 3])

and this would correspond to dictionary/object syntax in other languages.

Not more than, say … (let ()
(define a 1)
(define b 2))
:wink:

I think an undervalued fix to things being a lot of typing is to get better support for autocompletion. I have better UX on my phone for typing longer text than I do in DrRacket. For one thing, the autocompletion is fast and on by default.

and I never react to that by thinking “oh the better fix is to come up with terser sentences”

I’ve already made several improvements and I’m pleased with the progress, but there are many, more difficult parts yet to tackle.

Even with the drcomplete
extension, autocomplete in DrRacket is not great. It seems to get confused about what I’m doing and will make unhelpful completions.

Regarding procedures like hash
, I’m replacing them with match expanders, specifically because I’m emphasizing pattern matching. (The syntax I chose for hash tables does poke at the question of commas, but I’ve left them out.)

The amount of typing is not the issue for me, its the misuse of the visual space. Long words often don’t improve readability, because they introduce a lot of useless duplicate information and they lose a lot of valuable space that could be used to display other information.

Instead of entry
, I’d probably prefer an anonymous pair, like Haskell’s (a, b)
, then again, I also like the specificity of a pair just for dictionary entries… I’ve noticed that there’s a tricky balance between using specific data types and generic (possibly nameless) ones.

galaxy brain: [a, b]
as sugar for (list a b)
, (a, b)
as sugar for (pair a b)
, and a: b
as sugar for (entry a b)

I’d argue that that sort of sugar makes sense in a language with a set of privileged core data types, but no macros, like Python or Lua. But in Racket, having special sugar for a handful of data types feels odd. I suppose it’d make sense if the sugar was used for very generic data…

I’ve mostly finished the require/provide interface, so I thought I’d show a little side-by-side comparison of a Racket snippet with the equivalent version in my lang.



Let me know if you have any thoughts or questions.