Plans for a minor release? about dora HOT 12 CLOSED

syntax highlighting for e.g. Visual Studio Code, VIM
I implemented syntax highlighting and basic indentation for Dora: vim-dora

from dora.

Not sure, haven't thought much about this since Dora for me is mostly about learning and probably also because there were just too many features missing.

Language Features I would like to see in a first release (although this might be more a wish list):

• better error messages (among other stuff report file names ;)
• implement HashMap (generics have to improve for this as well)
• some File I/O API
• implement structs+tuples
• ADT (enums) & pattern matching
• lambdas
• more powerful for loop
• modules/packages with pub/public modifier
• operators like +=, -=, *=, ...
• allow if in expressions (you already proposed that issue)
• syntax highlighting for e.g. Visual Studio Code, VIM
• some documentation for the standard library and language
• remove nil

What do you think about releases and what features would you want to include?

from dora.

@dinfuehr Thanks for your thoughts!

Personally, I prefer "release early, release often", because it helps focusing on manageable goals, iterating and revisiting things as necessary, instead of having large big-bang releases that require weeks of recovery afterwards.

My thoughts on your list:

better error messages (among other stuff report file names ;)

Agree on this. I think making sure that all errors get a file name instead just those in the parser would be a reasonable short-term goal.

implement HashMap (generics have to improved for this as well)

I think we could survive without it for the next minor release, but on the other hand it has to be implemented anyway, so why not now. This would also require that we come up with a concept for a Hash trait – a first sketch is in the PR I opened a few hours ago.

some File I/O API

I think it would make sense to restrict this to a very small, constrained scope, as I'm hoping to have some future API that is completely async (which would require something like Future<T>, which in turn requires improvements to generics).

implement structs+tuples

Absolutely! I really want to have Option and Result types, and this would be a step toward that.

ADT (enums)

Not sure this is critical; I really dislike that in most languages enums/ADTs are their own sub-language with their own, special hand-crafted syntax. I'd prefer first investigating how close we can get using modules and classes/structs for this.

pattern matching

I want this, but would avoid making this a goal, as pattern matching is very hard to implement if done right.
I have a design based on enhancing if-expressions that avoids introducing keywords like (match or switch which come with their own special syntax rules). Some of the prerequisites for this aren't here yet, so I would postpone this for now.

lambdas

I would keep them experimental as I would like to work on a syntactic overhaul, making sure that fun syntax and lambda syntax is as close as possible.

modules/packages with pub/public modifier

This is crucial in my opinion, as this is an absolute requirement to have any notion of namespacing. Also a hard requirement for a reasonable standard library where we don't drop everything into a global namespace.

operators like +=, -=, *=, ...

I would prefer not doing this at all. In the past we had languages with i++ and ++i; then we had languages showing that not having this syntax was perfectly fine, providing only i += 1. I believe that we can show that only having i = i + 1 is fine too and would reduce the amount of different ways the same code can be expressed.

My main concern is that having such operators complicates parsing and reading quite a bit, and this is complexity I would prefer spending on something else (or not at all).

allow if in expressions (you already proposed that issue)

Nice to have, but I'm on it anyway already. :-)

syntax highlighting for e.g. Visual Studio Code, VIM

I have started to investigate LSP in the last few days, I think it will be reasonably simple to get something working. It won't be nice, but it might be better than running the executable again and again. :-)

some documentation for the standard library

Agree, although I don't think it should prevent an otherwise acceptable release.

A few plans I have, which I haven't really documented or discussed yet:

• I want to implement a very simple scheme for semicolon inference.
• I want to have reasonable default implementations of equals/== and hash supplied by the runtime for non-open classes and structs.
• I want to migrate modifiers to annotations, to make our modifiers easier to extend/change and allow people to write their own annotations that live on the same footing syntax-wise.
• I want to introduce modules as a replacement for static members, not only to simplify the todos in generics into more manageable bits, but also because they are much easier to comprehend, and allow better reasoning about what stuff exists "per instance" and what stuff exists "per class" (or "per module" with the proposal, which would also nicely tie in with the free-standing functions Dora already has), and how generics apply to all of that.
• I want to overhaul our syntax regarding :: and generics to avoid the mistakes Rust and other languages have made.
• I want to have a better separation between how classes and structs are implemented (fun/let/...) and how they are accessed from the outside. E. g. allow a class's let to directly implement a traits's fun.
• I want to work on getting rid of nil, by cleaning up the entry points where they are appear, which is considerably easier than having them crop up all over the place and then trying to get them under control later. This would require structs and Option, Default and a few other things related to arrays.

I don't think they have to go into the next release with any particular priority (as we haven't even discussed them yet, so I don't even know your position on the individual items), but I wanted to warn you that you might be bombarded with new issues, designs and questions over the next weeks. :-)

In conclusion, I think nobody will have any particular expectation of polish/features/stability for probably dozens of releases going forward, so we shouldn't worry too much about it in my opinion.

So I'd say that we could try to

• get error reporting of filenames across the finish line
• get something working in terms of structs (we could probably live without language support for tuples for now)
• get some kind of module system working
• investigate semicolon inference
• investigate a better separation between class/struct members and how they are accessed

and then have a look again whether we feel our priorities have changed, whether we find that something crucial is missing, or whether we could cut a release.

from dora.

Nice! Will definitely try this next week!

from dora.

Oh, we probably should also have a foreach or for .. in ... loop.

from dora.

I'd prefer having only a very low-level while for now, and later thinking about adding some do/for/... which looks like a for of imperative languages, but supports general applicative/monadic operations. (do in Haskell, computation expressions in F#, for in Scala, ...).

from dora.

I've ticked a few boxes above, I think we are getting closer to a state where builds (or releases) could actually make sense. Lambdas seem to be the last missing bigger language feature from that list, although obviously many of those already checked features still require quite a lot more work.

We could use GH actions to create the build once in a while and then with asdf there would be a simple way to download & install the most recent build.

from dora.

Great!

I think after lambdas, there are huge chunks of standard library (especially in collections) that be written, but I don't think this should be a blocker.

Likewise, I'd like to discuss some of the defaults (making @pub default, and making integer literals default to Int64), but I don't think these would be a blocker either.

Do you still have plans regarding the point "operators like +=, -=, *=, ..."? Otherwise that could be crossed off too (leaving them out).

from dora.

Yeah, unfortunately lambdas are needed for a lot of stuff in the stdlib... We should definitely treat lambdas as a blocker for that release.

Making integer literals by default Int64 makes a lot of sense for Dora, although this might become less relevant when we get some/better type inference. But who knows when we will get there, so I quite like that idea. Not sure about making @pub default though, but let's discuss this later separately.

Btw it would be cool to have ranges in Dora. Right now it's quite cumbersome to implement a simple loop like for x in 0..10 {} in Dora. I hope Dora is already expressive enough to implement this and imho this would improve DX a lot. Maybe you are interested to work on that.

Another thing I wanted to do was to get rid of inheritance (only after we have lambdas though). We might want to remove this before we make a release as well.

So far I was too lazy for implementing +=, etc. I still think it makes sense to add those operators but it just wasn't high priority enough for me so far and is definitely not a blocker.

from dora.

We should definitely treat lambdas as a blocker for that release.

Agreed, my comment above was confusing: What I meant to say is that lambdas are a blocker, but extending the std lib to use lambdas everywhere probably isn't.

Making integer literals by default Int64 makes a lot of sense for Dora, although this might become less relevant when we get some/better type inference.

I also think that it will become less relevant after we are done with the "fiddly" std library code that tends to be written in the beginning.

To be honest, I like the strictness of the current system quite a bit, even though there are ways to make number literals "more convenient":

Every time I have seen people try to make numbers "smarter", the amount of complexity and bugs that followed was immense.

Even the creators of Java think that their numeric widening rules were a mistake, and looking at other languages I can't come up with a single example where I'd say that proportion of convenience to language complexity was worth it.

Not sure about making @pub default though, but let's discuss this later separately.

Ok!

Another thing I wanted to do was to get rid of inheritance (only after we have lambdas though). We might want to remove this before we make a release as well.

Ah I thought this was gone already? In which places does inheritance still exist?

So far I was too lazy for implementing +=, etc. I still think it makes sense to add those operators but it just wasn't high priority enough for me so far and is definitely not a blocker.

I'd prefer leaving them out: having multiple syntaxes for achieving the same thing isn't worth it imho, especially when the saving is two characters.

Also, we currently have 7 operator precedence levels with 24 operators spread between them, I'd rather reduce this (e. g. by dropping <<, >> and >>>) than adding more to it.

from dora.

I think inheritance is still used in some benchmarks but also a lot within boots.

Just to be clear: with type inference for integer literals I do not mean automatic type-conversions. I would like that we don't need to use a suffix each and every time an integer literal of a non-default type is used. Even in trivial code like return Some[Int64](0L) we need to specify the type twice and once again in the function declaration (although with recent changes this should already work as Some(0) as well). But each literal would still have exactly one type and that wouldn't be auto-casted to some other type.

from dora.

Btw it would be cool to have ranges in Dora. Right now it's quite cumbersome to implement a simple loop like for x in 0..10 {} in Dora. I hope Dora is already expressive enough to implement this and imho this would improve DX a lot. Maybe you are interested to work on that.

I'd try and avoid putting ranges into the language. I have seen so much broken code over the years involving ranges, because they aren't as trivial as they look like.

I'd rather have some kine of Range type, it's easier to deal with bugs this way and let's us avoid the whole "syntax for end-inclusive ranges vs. syntax for end-exclusive ranges" battle (see Rust).

from dora.