These are chat archives for Ren-data/Ren/map

19th
Jun 2015
Gregg Irwin
@greggirwin
Jun 19 2015 19:46

Option A: 3 types, No spec-block

  • [] () = list
  • #[] = hash | hashlist (hinted list)
  • #() = map (key+value pairs)

Option B: 2 types, No spec-block or map

  • [] () = list
  • #[] #() = hash | hashlist (hinted list)

Option C: 2 types, No construction syntax, no spec-block

  • [] () = list
  • #[] #() = map (key+value pairs)

Option D: 3 types, No construction syntax

  • [] () = list
  • #[] = spec-block (name+value pairs)
  • #() = map (key+value pairs)

Notes:

  • None of these options support both current Rebol construction syntax and strict spec-blocks.
  • R2 and Red have hash!, but R3 does not. Anyone know of another language that has them (as they work in R2 and Red)?

Votes? Thoughts? Other options?

Gregg Irwin
@greggirwin
Jun 19 2015 20:06
Until now I've been firmly in the 2 Types and name-value camp, which I don't even have in the above list. Red maps and construction syntax seem too important to ignore, but they complicate things. #A is based on @WiseGenius's post. Though hash as a name will surely confuse people, and be reundant with map. hashlist may not be much better.
Gregg Irwin
@greggirwin
Jun 19 2015 20:13
I'm torn between #A and #B. The question, in my mind, is whether the value of a strict modulo 2 length check (which is all map adds) is worth calling it another type.
As @dockimbel has said in the past, pure Redbol interop is not Ren's goal (just use Redbol), but Redbol should pass through Ren unscathed.
To be clear, I added the hash* name ideas, don't blame @WiseGenius .
Gregg Irwin
@greggirwin
Jun 19 2015 20:26

Option E could be

  • #() = map
  • [] () #[] = list

But that makes map the odd man out.
Think about what "hinted list" means as well, if we use that term.