funkia / list

🐆 An immutable list with unmatched performance and a comprehensive functional API.
MIT License
1.65k stars 51 forks source link

support sanctuary-show #57

Open davidchambers opened 6 years ago

davidchambers commented 6 years ago
> var {list} = require ('list')
> var show = require ('sanctuary-show')

Current behaviour:

> show (list ('foo', 'bar', 'baz'))
'{"bits": 3, "length": 3, "offset": 0, "prefix": [0], "root": undefined, "suffix": ["foo", "bar", "baz"]}'

Suggested behaviour:

> show (list ('foo', 'bar', 'baz'))
'list ("foo", "bar", "baz")'

This would require defining a @@show method which applies show to each of the list's elements.

paldepind commented 6 years ago

Since this is specific for Sanctuary, what do you think about including it in sanctuary-list(*)?

(*) Which I have not forgotten about 😅

davidchambers commented 6 years ago

I like to imagine a future in which the Fantasy Land community at large adopts @@show. There's nothing Sanctuary-specific about the specification.

Edit: Updated link to point to correct project.

paldepind commented 6 years ago

I don't see anything about @@show in the link? What is the difference between toString and @@show? If List implemented a toString method could it's @@show method simply be List.prototype["@@show"] = List.prototype.toString?

davidchambers commented 6 years ago

I don't see anything about @@show in the link?

Oops! I linked to the wrong project. I meant to link to sanctuary-show.

If List implemented a toString method could it's @@show method simply be List.prototype["@@show"] = List.prototype.toString?

If List#toString uses show to generate the string representations of its elements, then absolutely!

paldepind commented 6 years ago

@davidchambers

If I understand correctly @@show should be implemented as:

List.prototype["@@show"] = function(l) {
  return "list(" + L.join(", ", L.map(show, l)) + ")";
}

However, that depends on the show function from sanctuary-show. I hope List will become a foundational library and therefore I'd like to avoid adding dependencies to it.

I understand that converting values to strings is used extensively in Sanctuary to do error reporting. But outside of that, I don't see many use cases for converting a list into an evaluateable string. Debugging and REPLs could be potential use cases but JavaScript has debuggers and REPLs that don't rely on converting values to strings.

Taking that into consideration, wouldn't it be more reasonable to add @@show in sanctuary-list?

davidchambers commented 6 years ago

I hope List will become a foundational library and therefore I'd like to avoid adding dependencies to it.

I hope that show will become foundational and that all ADTs will support it. ;)

Taking that into consideration, wouldn't it be more reasonable to add @@show in sanctuary-list?

It's certainly reasonable. It seems that Sanctuary is opinionated to the point that we need a sanctuary- package for everything (except Future a b).