Re: Dylan 2016: Evolving Dylan

I wanted to give some quick responses to help with this as good I can.

Naming the revision "Dylan 2016" sounds good to me.

On 04/15/2014 02:00 PM, Bruce Mitchener wrote:

> My current thoughts on things that I'd like to see proposed and implemented:
> 
>   * Immutable strings: Strings become an immutable object. Do we need
>     some sort of string builder API to support existing use cases? How
>     often do we actually modify strings inside of Open Dylan?

Agree 100%.

>   * Unicode: A single string type with UTF8 encoding internally. A byte
>     vector is used instead for binary data and encoders handle
>     converting between the UTF8 string and the byte vector. Immutable
>     strings can help simplify this work.

My approach would be:

- Use unicode for everything internally
  (Dylan doesn't need to worry about other charsets this way)
- use UCS-4 for <character> and in <string>
  (makes for simple and efficient string manipulation)
  (size cost isn't bad enough to be serious trouble)
- use UTF-8 as the default for I/O
  (and allow others to be specified, unicode or not)

>   * Atomic operations. We should specify atomic operations similar to
>     C++11 and C11. Atomic operations should either be available on
>     anything of the right type or on bindings that have an "atomic"
>     adjective, such as slots and "define atomic variable".

I agree. Only problem I can see is portability, so the set of operations
offered by Dylan itself should probably be limited to "common" ones.

>   * Greater immutability for local bindings. We should have a form that
>     complements "let x = y" to specify that the binding can't be
>     modified. One suggestion is "constant x = y".

I like this. Rust has "let" and "let mut", but with dylan it makes
more sense to say "constant" or "let constant" in my eyes.

>   * More immutable types or better implementations of immutable types.
>     We can learn a lot from Clojure and other languages to provide
>     better implementations of core types that are immutable.

Not sure what can be done here.
Immutable strings require immutable vectors though,
so thats the least that should be done here.

>   * Improvements to the numeric tower. This needs some serious thought.
>     Lacking an easy to use 64 bit integer type is pretty painful.

Agree 100%. We should have "fixed size" integer types, including
unsigned ones. System programming all but requires them.

>   * Improvements to the type system. There are ideas that can be
>     borrowed from the work that Hannes did. There is also a thesis by
>     James Knight (http://googoogaga.github.io/james-thesis.pdf) on
>     adding parameterized types to Goo that may be worth examining.

Not my turf.

>   * An improvement to numeric literals. Some languages permit numeric
>     literals along the lines of 1_000_000 or 1'000'000. This is a nice
>     readability improvement.

Not sure. Especially as a European. Not opposed though.