gknauth
2020-12-30 14:05:25

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


kellysmith12.21
2020-12-30 15:50:52

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?


soegaard2
2020-12-30 16:01:26

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.


kellysmith12.21
2020-12-30 16:27:52

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


kellysmith12.21
2020-12-30 16:28:52

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


kellysmith12.21
2020-12-30 16:35:10

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.


soegaard2
2020-12-30 16:37:29

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


kellysmith12.21
2020-12-30 16:40:06

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


laurent.orseau
2020-12-30 17:48:50

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


kellysmith12.21
2020-12-30 17:59:27

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


laurent.orseau
2020-12-30 18:09:53

That would be a great testbed


notjack
2020-12-30 18:32:01

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


sorawee
2020-12-30 18:33:53

But that’s still variadic, right?


notjack
2020-12-30 18:34:17

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.


notjack
2020-12-30 18:35:42

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.


sorawee
2020-12-30 18:43:32

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


sorawee
2020-12-30 18:45:52

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


sorawee
2020-12-30 18:46:06

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


soegaard2
2020-12-30 18:47:22

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


notjack
2020-12-30 18:50:12

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.


notjack
2020-12-30 18:50:45

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


kellysmith12.21
2020-12-30 18:51:23

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


kellysmith12.21
2020-12-30 18:55:40

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.


kellysmith12.21
2020-12-30 19:03:34

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


laurent.orseau
2020-12-30 19:12:52

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.


kellysmith12.21
2020-12-30 19:17:28

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.


notjack
2020-12-30 22:08:03

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)


kellysmith12.21
2020-12-30 22:13:42

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…


kellysmith12.21
2020-12-31 04:08:23

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.


kellysmith12.21
2020-12-31 04:10:52

kellysmith12.21
2020-12-31 04:12:44

kellysmith12.21
2020-12-31 04:25:15

Let me know if you have any thoughts or questions.