[refactor] Is this the functor/applicative/monadic life?
This is a big change. For chapter 5, I ripped out all line/column
tracking and most error handling from the parser; it's now a plain
ol' Lisp parser, and if it's not close to CL 22.1.1, it's a hell of
a lot closer than it used to be.
In doing so, I reduced the size of the parser by about 40 lines.
TrackingReader takes every function in a Reader and puts that
debugging information *back*. It turns out that all that information
was prelude and postlude to the act of parsing; by wrapping each
function in a decorator I was able to restore all that information,
and I only had to get it right exactly *once*.
In functional programming terms, this lifts:
IO -> (atom | list)
to:
IO with tracking -> Node (atom | list) with tracking
It's a totally free win without having to do much extra work.
Now, this check-in isn't perfect. The tracking reader is still
tossing on some things, and because I don't have a robust type
system (it is Coffeescript, after all), I'm having to do the
decorating and wrapping by hand. But I'm definitely on my way
to understanding the issues, and having a grasp on functors and
monoids.
2015-08-20 15:50:52 +00:00
|
|
|
{cons, nil} = require "cons-lists/lists"
|
|
|
|
|
exports.samples = [
|
|
|
|
|
['nil', nil]
|
|
|
|
|
['0', 0]
|
|
|
|
|
['1', 1]
|
|
|
|
|
['500', 500]
|
|
|
|
|
['0xdeadbeef', 3735928559]
|
|
|
|
|
['"Foo"', 'Foo']
|
|
|
|
|
['(1)', cons(1)]
|
|
|
|
|
['(1 2)', cons(1, (cons 2))]
|
|
|
|
|
['(1 2 )', cons(1, (cons 2))]
|
|
|
|
|
['( 1 2 )', cons(1, (cons 2))]
|
2015-08-26 05:01:21 +00:00
|
|
|
['(1 (2 3) 4)', cons(1, cons(cons(2, cons(3)), cons(4)))]
|
[refactor] Is this the functor/applicative/monadic life?
This is a big change. For chapter 5, I ripped out all line/column
tracking and most error handling from the parser; it's now a plain
ol' Lisp parser, and if it's not close to CL 22.1.1, it's a hell of
a lot closer than it used to be.
In doing so, I reduced the size of the parser by about 40 lines.
TrackingReader takes every function in a Reader and puts that
debugging information *back*. It turns out that all that information
was prelude and postlude to the act of parsing; by wrapping each
function in a decorator I was able to restore all that information,
and I only had to get it right exactly *once*.
In functional programming terms, this lifts:
IO -> (atom | list)
to:
IO with tracking -> Node (atom | list) with tracking
It's a totally free win without having to do much extra work.
Now, this check-in isn't perfect. The tracking reader is still
tossing on some things, and because I don't have a robust type
system (it is Coffeescript, after all), I'm having to do the
decorating and wrapping by hand. But I'm definitely on my way
to understanding the issues, and having a grasp on functors and
monoids.
2015-08-20 15:50:52 +00:00
|
|
|
['( 1 2 )', cons(1, (cons 2))]
|
|
|
|
|
['("a" "b")', cons("a", (cons "b"))]
|
|
|
|
|
['("a" . "b")', cons("a", "b")]
|
|
|
|
|
['[]', []]
|
|
|
|
|
['{}', {}]
|
2015-08-26 05:01:21 +00:00
|
|
|
['{"a" [1 2 3] "b" {"c" "d"} "c" ("a" "b" . "c")}', {"a": [1,2,3], "b":{"c": "d"}, "c": cons("a", cons("b", "c"))}]
|
[refactor] Is this the functor/applicative/monadic life?
This is a big change. For chapter 5, I ripped out all line/column
tracking and most error handling from the parser; it's now a plain
ol' Lisp parser, and if it's not close to CL 22.1.1, it's a hell of
a lot closer than it used to be.
In doing so, I reduced the size of the parser by about 40 lines.
TrackingReader takes every function in a Reader and puts that
debugging information *back*. It turns out that all that information
was prelude and postlude to the act of parsing; by wrapping each
function in a decorator I was able to restore all that information,
and I only had to get it right exactly *once*.
In functional programming terms, this lifts:
IO -> (atom | list)
to:
IO with tracking -> Node (atom | list) with tracking
It's a totally free win without having to do much extra work.
Now, this check-in isn't perfect. The tracking reader is still
tossing on some things, and because I don't have a robust type
system (it is Coffeescript, after all), I'm having to do the
decorating and wrapping by hand. But I'm definitely on my way
to understanding the issues, and having a grasp on functors and
monoids.
2015-08-20 15:50:52 +00:00
|
|
|
['[1 2 3]', [1, 2, 3]]
|
2015-08-26 05:01:21 +00:00
|
|
|
['[1 2 [3 4] 5]', [1, 2, [3, 4], 5]]
|
[refactor] Is this the functor/applicative/monadic life?
This is a big change. For chapter 5, I ripped out all line/column
tracking and most error handling from the parser; it's now a plain
ol' Lisp parser, and if it's not close to CL 22.1.1, it's a hell of
a lot closer than it used to be.
In doing so, I reduced the size of the parser by about 40 lines.
TrackingReader takes every function in a Reader and puts that
debugging information *back*. It turns out that all that information
was prelude and postlude to the act of parsing; by wrapping each
function in a decorator I was able to restore all that information,
and I only had to get it right exactly *once*.
In functional programming terms, this lifts:
IO -> (atom | list)
to:
IO with tracking -> Node (atom | list) with tracking
It's a totally free win without having to do much extra work.
Now, this check-in isn't perfect. The tracking reader is still
tossing on some things, and because I don't have a robust type
system (it is Coffeescript, after all), I'm having to do the
decorating and wrapping by hand. But I'm definitely on my way
to understanding the issues, and having a grasp on functors and
monoids.
2015-08-20 15:50:52 +00:00
|
|
|
# ['(1 2 3', 'error']
|
|
|
|
|
['{"foo" "bar"}', {foo: "bar"}]
|
|
|
|
|
]
|
|
|
|
|
|