On Monday, 24 June 2019 at 13:47:06 UTC, Araq wrote:
>
>
> **Disclaimer**: I invented Nim.
>
> The AST is "close to" the parse-tree but that's not a problem, the usual things that a macro system is capable of can all be done (async, serialization, lazy evaluation, control flow abstractions, currying, DSLs), and reasonably easy too.
>
> It's certainly ugly in some ways but that is not because it is "close to" the parse-tree (hey, it works for Lisp too!) but because it was a research project that escaped the lab. Almost no effort was spent on API design. But we're getting there.

Is there anything you would have done differently if you started over?

On Monday, 24 June 2019 at 17:16:04 UTC, jmh530 wrote:
> Is there anything you would have done differently if you started over?


Sure, but only details. We got most things right.

But let's assume we got it wrong and there is a superior IR that also the macro system should have access to. Then we would need a translation layer from the old AST to the new IR and back so that older code keeps working. But that's well trotted ground, see GCC's various different IRs (GENERIC, GIMPLE and RTL).

On Saturday, 22 June 2019 at 09:03:42 UTC, Ola Fosheim Grøstad wrote:
> What are the essential features?  Or, which ones are less essential, e.g. I don't really see the need for hex strings, but maybe they are very useful to others.

GC (at run time), clasess and typeinfo, everything else is good for embedded. BetterC is not a good subset, it's more a PR feature.

On Thursday, 27 June 2019 at 15:42:27 UTC, Kagamin wrote:
> GC (at run time), clasess and typeinfo, everything else is good for embedded. BetterC is not a good subset, it's more a PR feature.

Ok, but the question is more: what features are essential?

And, which features are rarely used and can be replaced by a library solution?

On Thursday, 27 June 2019 at 17:15:27 UTC, Ola Fosheim Grøstad wrote:
> On Thursday, 27 June 2019 at 15:42:27 UTC, Kagamin wrote:
>> GC (at run time), clasess and typeinfo, everything else is good for embedded. BetterC is not a good subset, it's more a PR feature.
>
> Ok, but the question is more: what features are essential?
>
> And, which features are rarely used and can be replaced by a library solution?

This is less a question of a features essential-ness and more a question of how much compiler integration is needed to implemented it in an efficient and convenient (convenient for the user) manner.

For example bounds-checking and slices can be done as a library easily, but it's so much more convenient if they are part of the language.

A type-system also needs to be integrated closely with the compiler because it defines which code may be rejected early thereby improving iteration times on faulty code.

On Friday, 28 June 2019 at 08:29:20 UTC, Stefan Koch wrote:
> This is less a question of a features essential-ness and more a question of how much compiler integration is needed to implemented it in an efficient and convenient (convenient for the user) manner.

Well, it was posed as a question of what is essential.  Clearly some features are more used than others and some are difficult to replace with a library solution.

> For example bounds-checking and slices can be done as a library easily, but it's so much more convenient if they are part of the language.

But is it more convenient?  In terms of generic programming you often deal with array-like APIs rather than arrays and slices might need to support other indexing mappings in parallel code so that each core hits disjunct sets of cache lines etc.

What you need is the basic operators and a convenient syntax, it should not matter if the implementation is in a library.

> A type-system also needs to be integrated closely with the compiler because it defines which code may be rejected early thereby improving iteration times on faulty code.

Not sure what is meant by "iteration times", but yes, the type system unification process is an essential part of the compiler.

So which features have to be dealt with explicitly in the type system as a non-library type?