@sigue #RabbitSeason ? #DuckSeason ? Noo, #DylanLang season.

@UweHalfHand

Possibly this is not at all relevant to your situation but I thought I'd mention the way this is handled in #DylanLang (specifically in Open Dylan) since Dylan is similar to Scheme in many ways. Whether or not you could do similar in the Wile compiler probably depends a lot on implementation details.

"element" is the generic function used for collection accesses. For example, element(s, 0) === s[0]. "element" is defined essentially as

1. call element-range-check(...);
2. call element-no-bounds-check(...);

and Open Dylan provides a macro without-bounds-checks (https://github.com/dylan-lang/opendylan/blob/6ea23c96eec5ea6f0b501624c6c768fb5db4a2c8/sources/dylan/collection-macros.dylan#L31) that rebinds "element" to "element-no-bounds-check".

https://github.com/dylan-lang/opendylan/blob/6ea23c96eec5ea6f0b501624c6c768fb5db4a2c8/sources/dylan/string.dylan#L83

@sigue @nytpu

> #DylanLang has separate functions for map, map-as, and do.

That is certainly a justifiable different design approach (than #CommonLisp's).

@vnikolov @nytpu

We don't always learn every construct in a language by staring at the spec. Frequently (thankfully) it's clear from the argument list, e.g. (map result-type function first-sequence &rest more-sequences) how the function works.

The problem here is that (map nil ...) is completely unintuitive. It's even non-obvious when you see it used in CL code.

This is why #DylanLang has separate functions for map, map-as, and do.

https://opendylan.org/books/drm/Collection_Operations#HEADING-102-512

@tiang

@mdhughes

Your post prodded me to finally read the Rhombus macro paper. (Well, I skipped a lot of the gory details and concentrated on the intro and the comparisons.)

My take, as a #DylanLang lover, is that I don't see a huge advantage in all the flexibility Rhombus provides over what Dylan already has. I tend to use macros sparingly though, in Dylan but even in Common Lisp.

But it seems like a cool advance in the state of the art for non-s-expression macro technology. (Not an expert though.)

@jackdaniel

@glitzersachen

Personally, I switched to #DylanLang. Although its "locators" library was probably somewhat modeled on Common Lisp pathnames, i'd say it's much better designed.

I've heard some Common Lispers claim they just avoid pathnames completely, but I'm not sure what they do instead.

What's the high-level problem you're trying to solve that has led to this nightmare? Maybe you can avoid it completely?

@screwtape

This will sound like sacrilege for #CommonLisp but in #DylanLang I no longer use plain symbols as a poor-man's enum. Instead I do this:

define constant $rock = #"rock";
define constant $paper = #"paper";
define constant $scissors = #"scissors";

define constant <tool> = one-of($rock, $paper, $scissors);

and then type things as <tool> where appropriate. Et voilà, I can no longer misspell symbol names without getting a compiler warning. More importantly, neither can clients of my library.

EDIT: fix Dylan bugs, add last sentence.

@amoroso

All the things he talks about macros doing can be done in infix syntax too. #DylanLang for example, since circa 2000. But I will say that _writing_ macros is a lot easier in prefix syntax than infix syntax.

(I have this queued up to read, but have not read it yet: https://dl.acm.org/doi/10.1145/3622818)

I think that ultimately syntax is a very personal choice. I'm fine with Lisp syntax, but I honestly find Dylan and Python easier to read, precisely _because of_ the variability and no need for lots of parens.

@abcdw hmm, interesting that Jeremy Siek claims to have invented gradual typing in 2006 given that #DylanLang had it in the 1990s. Maybe he invented the term "gradual typing" though.

@abcdw I'd say if you don't really care about parsing tech, just skip that part of whatever book you choose.

I'm going through https://craftinginterpreters.com (free, online) and am quite enjoying it. It builds an ad-hoc parser and you could easily swap in an s-expression parser.

It first builds an AST-based interpreter in Java (I used #DylanLang instead) and then builds a byte code interpreter in C for the same language.

This book is really refreshing compared to other compiler books I've used. It's very hands-on; much less theoretical.

@ringtailringo

There's definitely an aspect of "don't worry, be happy" to dynamic error handling. In my experience a large % of errors are unrecoverable anyway (aside from via user interaction) so one or two strategically placed condition handlers (e.g. in the main loop) are usually enough.

And obviously document public APIs with any explicitly signaled errors.

There are some standard CL functions, like parse-integer, that return an error value (e.g., nil) much like in Go, except you're not required to check it. I think there's a decent argument for forcing the caller to deal with the error there, but you'd never convince the CL community to require it. (It's one of the ways the #DylanLang ethos differs from #CommonLisp... https://github.com/dylan-lang/opendylan/blob/master/sources/common-dylan/format.dylan#L355)