Why putting "fantasy-land/" before everything in readme?

[babak-karimi-asl]

for example instead of writing :

a['fantasy-land/equals'](a) === true

why not just:

a.equals( a ) === true , or just simply a equals a .

or this:
a['fantasy-land/concat'](b)['fantasy-land/concat'](c) is equivalent to a['fantasy-land/concat'](b['fantasy-land/concat'](c)) (associativity)

to this:
a.concat(b).concat(c) === a.concat(b.concat(c)) (associativity)

these concepts are confusing enough by themselves, specially for beginners , so no need to add more complications.

[CrossEye]

You can see the discussion in #92.

A short example: if we don't specify a prefix like that, then a geospatial library with a geographic map method cannot be made Fantasyland compatible, because Fantasyland claims the ownership of the map method. But with the prefix, there's no conflict. It does make these docs hard to read, though, and I'd love to see a good fix for that.

[babak-karimi-asl]

@CrossEye thanks for responding.

this is fantasy-land's readme , so it belongs to fantasy-land.

it can be declared at the top of the readme : all of the below methods are in "fantasy-land" namespace.

[Avaq]

@babak-karimi-asl I think it's because of what Fantasy Land tries to be. Fantasy Land is: "A specification for interoperability of common algebraic structures", not "a specification of common algebraic structures". Therefore, with the focus on interoperability, the exact JavaScript structures take the front stage and legibility of the laws (which are defined in many other places) comes second.