FAQ

[Clojure] notes on Mathematica pattern transformation & Clojure predicate dispatch

Kovas boguta
Feb 21, 2012 at 2:56 am
Mathematica implements a version of open and order-independent
dispatch, so I wanted to add some points to the discussion.

The design of Mathematica's pattern matching is tightly coupled to the
language's computational model, as well as with all other aspects of
the system. So a lot of it would get lost in translation to Clojure,
and not give you as much mileage as it does in Mathematica. So I'm
mostly gonna focus on some pitfalls rather than the upside.

The biggest problem for the developer is understanding the state of
the rules system, especially during interactive development.

Mathematica tries it's best to insert new function definitions in the
"right" order, trying to figure out if pattern X if a subcase of
pattern Y, etc. Of course, there are ambiguous cases, particular since
the pattern language is rich. You solve this problem by either making
your pattern more specific, changing the order in which definitions
are loaded, or attaching the definition another symbol that has higher
precedence.

So debugging the pattern ordering is something you end up needing to
know how to do.

But this exposes a bigger problem: when doing interactive development,
you will end up with old definitions sticking around. You are
debugging one case of your function, and change the pattern a little.
The old pattern is still there, potentially shadowing the new one. So
anytime you see unexpected output while debugging, you need to wonder
about the state of the definitions and if you should reinitialize
them.

You can also get a function that works at the repl, but its broken in
source. The way this happens is, you enter definitions in arbitrary
order at the repl, but they are in a different order in source. So in
cases where order matters, this can get you too.

I've pretty much had every possible situation happen.

In Mathematica, it's possible to manually specific the order of the
definitions, but it's too cumbersome to use in source code.

In Clojure, the situation is simpler, and that helps. The pattern
language (or versions that we've seen of it) is simpler, and
destructuring is not part of its mission. (Changes to destructuring
are a common source of this shadowing issue.) There is also the
core.logic engine to do more deduction about the patterns themselves.

Still, I still see the two problems of 1. debugging the ordering, and
then 2. dealing with the state of the definitions during debugging and
interactive development.

On 1, the best thing is if you look at the source and immediately
understand what the ordering will be. So when you are writing code,
you just have this simple mental model, and spotting mistakes is easy.
For example, if the system does no "intelligent" ordering for you, its
obvious what the order at runtime will be, and you don't have to fight
anything to get things into the desired order.

On 2, this is more tooling support, in rough order of importance
-- which case is called for input X, and why
-- debugging a specific case independent of all others (suppress the
other cases)
-- various operations for comparing and testing patterns
-- ide support for displaying / editing the ordering of definitions

I've spent a ton of time debugging this stuff; its really important to
have a quick way to find out why something happened in these open
matching systems, and then have a convient way to patch the behavior.
Its just not as easy as changing a cond case in a single place in
source.

The great thing about pattern matching in Mathematica is that it is so
deeply integrated with all kinds of other primitives, from string
manipulation, data manipulation, math stuff, the equivalent of Map,
the equivalent of macros. So my question is can clojure-style pattern
matching and predicate dispatch be equally as powerful and pervasive,
but it it's own way.

One thought I had is about the relationship with program querying.
With predicate dispatch, you'll have greater runtime control over your
program, can swap things in and out at a finer granularity. And with
this idea of program querying that Rich talked about, you might find
all sorts of behaviors in your program that you might want to do
something about. Seems sort of complementary.

Maybe there is something there at that intersection, that can be a
greater extension of logic-based programming beyond only extending the
multimethod concept. So instead of replacing defn or defmulti, there
could be an entirely different use case, and it would be obvious which
one to use when.

--
You received this message because you are subscribed to the Google
Groups "Clojure" group.
To post to this group, send email to clojure@googlegroups.com
Note that posts from new members are moderated - please be patient with your first post.
To unsubscribe from this group, send email to
clojure+unsubscribe@googlegroups.com
For more options, visit this group at
http://groups.google.com/group/clojure?hl=en
reply

Search Discussions

10 responses

  • David Nolen at Feb 21, 2012 at 5:17 am
    Lots to think about :)

    I definitely agree there needs to be a simple way to "query" a predicate
    dispatch system in order for it to work well in larger programs. But I
    haven't thought about it much more then that yet.

    David
    On Mon, Feb 20, 2012 at 9:56 PM, kovas boguta wrote:

    Mathematica implements a version of open and order-independent
    dispatch, so I wanted to add some points to the discussion.

    The design of Mathematica's pattern matching is tightly coupled to the
    language's computational model, as well as with all other aspects of
    the system. So a lot of it would get lost in translation to Clojure,
    and not give you as much mileage as it does in Mathematica. So I'm
    mostly gonna focus on some pitfalls rather than the upside.

    The biggest problem for the developer is understanding the state of
    the rules system, especially during interactive development.

    Mathematica tries it's best to insert new function definitions in the
    "right" order, trying to figure out if pattern X if a subcase of
    pattern Y, etc. Of course, there are ambiguous cases, particular since
    the pattern language is rich. You solve this problem by either making
    your pattern more specific, changing the order in which definitions
    are loaded, or attaching the definition another symbol that has higher
    precedence.

    So debugging the pattern ordering is something you end up needing to
    know how to do.

    But this exposes a bigger problem: when doing interactive development,
    you will end up with old definitions sticking around. You are
    debugging one case of your function, and change the pattern a little.
    The old pattern is still there, potentially shadowing the new one. So
    anytime you see unexpected output while debugging, you need to wonder
    about the state of the definitions and if you should reinitialize
    them.

    You can also get a function that works at the repl, but its broken in
    source. The way this happens is, you enter definitions in arbitrary
    order at the repl, but they are in a different order in source. So in
    cases where order matters, this can get you too.

    I've pretty much had every possible situation happen.

    In Mathematica, it's possible to manually specific the order of the
    definitions, but it's too cumbersome to use in source code.

    In Clojure, the situation is simpler, and that helps. The pattern
    language (or versions that we've seen of it) is simpler, and
    destructuring is not part of its mission. (Changes to destructuring
    are a common source of this shadowing issue.) There is also the
    core.logic engine to do more deduction about the patterns themselves.

    Still, I still see the two problems of 1. debugging the ordering, and
    then 2. dealing with the state of the definitions during debugging and
    interactive development.

    On 1, the best thing is if you look at the source and immediately
    understand what the ordering will be. So when you are writing code,
    you just have this simple mental model, and spotting mistakes is easy.
    For example, if the system does no "intelligent" ordering for you, its
    obvious what the order at runtime will be, and you don't have to fight
    anything to get things into the desired order.

    On 2, this is more tooling support, in rough order of importance
    -- which case is called for input X, and why
    -- debugging a specific case independent of all others (suppress the
    other cases)
    -- various operations for comparing and testing patterns
    -- ide support for displaying / editing the ordering of definitions

    I've spent a ton of time debugging this stuff; its really important to
    have a quick way to find out why something happened in these open
    matching systems, and then have a convient way to patch the behavior.
    Its just not as easy as changing a cond case in a single place in
    source.

    The great thing about pattern matching in Mathematica is that it is so
    deeply integrated with all kinds of other primitives, from string
    manipulation, data manipulation, math stuff, the equivalent of Map,
    the equivalent of macros. So my question is can clojure-style pattern
    matching and predicate dispatch be equally as powerful and pervasive,
    but it it's own way.

    One thought I had is about the relationship with program querying.
    With predicate dispatch, you'll have greater runtime control over your
    program, can swap things in and out at a finer granularity. And with
    this idea of program querying that Rich talked about, you might find
    all sorts of behaviors in your program that you might want to do
    something about. Seems sort of complementary.

    Maybe there is something there at that intersection, that can be a
    greater extension of logic-based programming beyond only extending the
    multimethod concept. So instead of replacing defn or defmulti, there
    could be an entirely different use case, and it would be obvious which
    one to use when.

    --
    You received this message because you are subscribed to the Google
    Groups "Clojure" group.
    To post to this group, send email to clojure@googlegroups.com
    Note that posts from new members are moderated - please be patient with
    your first post.
    To unsubscribe from this group, send email to
    clojure+unsubscribe@googlegroups.com
    For more options, visit this group at
    http://groups.google.com/group/clojure?hl=en
    --
    You received this message because you are subscribed to the Google
    Groups "Clojure" group.
    To post to this group, send email to clojure@googlegroups.com
    Note that posts from new members are moderated - please be patient with your first post.
    To unsubscribe from this group, send email to
    clojure+unsubscribe@googlegroups.com
    For more options, visit this group at
    http://groups.google.com/group/clojure?hl=en
  • Kovas boguta at Feb 21, 2012 at 5:20 am
    I also have a small syntax idea.

    One principle that would be nice, and that Mathematica lacks, is
    parity between anonymous predicate dispatch constructs, and those
    attached to vars.

    So while one way is to look at predicate dispatch as an extension of
    multimethods, another way is to look at it as an extension of maps.

    so instead of writing

    (hash-map lhs1 rhs1 lhs2 rhs2 ...)

    you would have

    (rules lhs1 rhs1 lhs2 rhs2 ...)

    but in this case, the lhs and rhs would describe a computation, rather
    than just looking up literal values from literal values. Then you can
    use this anonymously, or def it to a var.

    The benefits are 1) you can re-use conj as the way to add new rules,
    or do all the typical sequence manipulation on it, and 2) it is
    natural to have alternatives like ordered-rules or other types of rule
    "collections" that determine the reordering behavior when new rules
    are conj'ed on, similar how there are multiple versions of sets and
    maps. It is also natural to have the equivalent version of a pattern
    set, so you can ask about membership in this sequence of patterns.

    So it could be possible to start from this construct, and then figure
    out the convenience macros later.
    On Mon, Feb 20, 2012 at 9:56 PM, kovas boguta wrote:
    Mathematica implements a version of open and order-independent
    dispatch, so I wanted to add some points to the discussion.

    The design of Mathematica's pattern matching is tightly coupled to the
    language's computational model, as well as with all other aspects of
    the system. So a lot of it would get lost in translation to Clojure,
    and not give you as much mileage as it does in Mathematica.  So I'm
    mostly gonna focus on some pitfalls rather than the upside.

    The biggest problem for the developer is understanding the state of
    the rules system, especially during interactive development.

    Mathematica tries it's best to insert new function definitions in the
    "right" order, trying to figure out if pattern X if a subcase of
    pattern Y, etc. Of course, there are ambiguous cases, particular since
    the pattern language is rich. You solve this problem by either making
    your pattern more specific, changing the order in which definitions
    are loaded, or attaching the definition another symbol that has higher
    precedence.

    So debugging the pattern ordering is something you end up needing to
    know how to do.

    But this exposes a bigger problem: when doing interactive development,
    you will end up with old definitions sticking around. You are
    debugging one case of your function, and change the pattern a little.
    The old pattern is still there, potentially shadowing the new one. So
    anytime you see unexpected output while debugging, you need to wonder
    about the state of the definitions and if you should reinitialize
    them.

    You can also get a function that works at the repl, but its broken in
    source. The way this happens is, you enter definitions in arbitrary
    order at the repl, but they are in a different order in source. So in
    cases where order matters, this can get you too.

    I've pretty much had every possible situation happen.

    In Mathematica, it's possible to manually specific the order of the
    definitions, but it's too cumbersome to use in source code.

    In Clojure, the situation is simpler, and that helps. The pattern
    language (or versions that we've seen of it) is simpler, and
    destructuring is not part of its mission. (Changes to destructuring
    are a common source of this shadowing issue.) There is also the
    core.logic engine to do more deduction about the patterns themselves.

    Still, I still see the two problems of 1. debugging the ordering, and
    then 2. dealing with the state of the definitions during debugging and
    interactive development.

    On 1, the best thing is if you look at the source and immediately
    understand what the ordering will be. So when you are writing code,
    you just have this simple mental model, and spotting mistakes is easy.
    For example, if the system does no "intelligent" ordering for you, its
    obvious what the order at runtime will be, and you don't have to fight
    anything to get things into the desired order.

    On 2, this is more tooling support, in rough order of importance
    -- which case is called for input X, and why
    -- debugging a specific case independent of all others (suppress the
    other cases)
    -- various operations for comparing and testing patterns
    -- ide support for displaying / editing the ordering of definitions

    I've spent a ton of time debugging this stuff; its really important to
    have a quick way to find out why something happened in these open
    matching systems, and then have a convient way to patch the behavior.
    Its just not as easy as changing a cond case in a single place in
    source.

    The great thing about pattern matching in Mathematica is that it is so
    deeply integrated with all kinds of other primitives, from string
    manipulation, data manipulation, math stuff, the equivalent of Map,
    the equivalent of macros.  So my question is can clojure-style pattern
    matching and predicate dispatch be equally as powerful and pervasive,
    but it it's own way.

    One thought I had is about the relationship with program querying.
    With predicate dispatch, you'll have greater runtime control over your
    program, can swap things in and out at a finer granularity. And with
    this idea of program querying that Rich talked about, you might find
    all sorts of behaviors in your program that you might want to do
    something about. Seems sort of complementary.

    Maybe there is something there at that intersection, that can be a
    greater extension of logic-based programming beyond only extending the
    multimethod concept. So instead of replacing defn or defmulti, there
    could be an entirely different use case, and it would be obvious which
    one to use when.
    --
    You received this message because you are subscribed to the Google
    Groups "Clojure" group.
    To post to this group, send email to clojure@googlegroups.com
    Note that posts from new members are moderated - please be patient with your first post.
    To unsubscribe from this group, send email to
    clojure+unsubscribe@googlegroups.com
    For more options, visit this group at
    http://groups.google.com/group/clojure?hl=en
  • David Nolen at Feb 21, 2012 at 4:43 pm

    On Tue, Feb 21, 2012 at 12:20 AM, kovas boguta wrote:

    I also have a small syntax idea.

    One principle that would be nice, and that Mathematica lacks, is
    parity between anonymous predicate dispatch constructs, and those
    attached to vars.

    So while one way is to look at predicate dispatch as an extension of
    multimethods, another way is to look at it as an extension of maps.

    so instead of writing

    (hash-map lhs1 rhs1 lhs2 rhs2 ...)

    you would have

    (rules lhs1 rhs1 lhs2 rhs2 ...)
    In the direction I'd like to explore the "rules" / "implications" would be
    a la carte. In fact in order for predicate dispatch to deliver more than
    what Chambers / Chen accomplished pretty much requires it.

    David

    --
    You received this message because you are subscribed to the Google
    Groups "Clojure" group.
    To post to this group, send email to clojure@googlegroups.com
    Note that posts from new members are moderated - please be patient with your first post.
    To unsubscribe from this group, send email to
    clojure+unsubscribe@googlegroups.com
    For more options, visit this group at
    http://groups.google.com/group/clojure?hl=en
  • Jason Jackson at Feb 23, 2012 at 1:09 pm
    "But this exposes a bigger problem: when doing interactive
    development,
    you will end up with old definitions sticking around. You are
    debugging one case of your function, and change the pattern a little.
    "

    Personally, I suffer from interactive development problems even with
    merely using def/defn. This is especially true if you're eval'ing
    snippets, and not the entire file C-cC-k.

    You could solve these problems by creating a new editor specifically
    for clojure interactive development which is aware of when you're
    updating code vs inserting new code vs deleting code, and change the
    interactive session accordingly. I'm sure there's a lot more you could
    add to such an editor.

    (or maybe emacs mode is sufficient dunno).
    On Feb 20, 9:56 pm, kovas boguta wrote:
    Mathematica implements a version of open and order-independent
    dispatch, so I wanted to add some points to the discussion.

    The design of Mathematica's pattern matching is tightly coupled to the
    language's computational model, as well as with all other aspects of
    the system. So a lot of it would get lost in translation to Clojure,
    and not give you as much mileage as it does in Mathematica.  So I'm
    mostly gonna focus on some pitfalls rather than the upside.

    The biggest problem for the developer is understanding the state of
    the rules system, especially during interactive development.

    Mathematica tries it's best to insert new function definitions in the
    "right" order, trying to figure out if pattern X if a subcase of
    pattern Y, etc. Of course, there are ambiguous cases, particular since
    the pattern language is rich. You solve this problem by either making
    your pattern more specific, changing the order in which definitions
    are loaded, or attaching the definition another symbol that has higher
    precedence.

    So debugging the pattern ordering is something you end up needing to
    know how to do.

    But this exposes a bigger problem: when doing interactive development,
    you will end up with old definitions sticking around. You are
    debugging one case of your function, and change the pattern a little.
    The old pattern is still there, potentially shadowing the new one. So
    anytime you see unexpected output while debugging, you need to wonder
    about the state of the definitions and if you should reinitialize
    them.

    You can also get a function that works at the repl, but its broken in
    source. The way this happens is, you enter definitions in arbitrary
    order at the repl, but they are in a different order in source. So in
    cases where order matters, this can get you too.

    I've pretty much had every possible situation happen.

    In Mathematica, it's possible to manually specific the order of the
    definitions, but it's too cumbersome to use in source code.

    In Clojure, the situation is simpler, and that helps. The pattern
    language (or versions that we've seen of it) is simpler, and
    destructuring is not part of its mission. (Changes to destructuring
    are a common source of this shadowing issue.) There is also the
    core.logic engine to do more deduction about the patterns themselves.

    Still, I still see the two problems of 1. debugging the ordering, and
    then 2. dealing with the state of the definitions during debugging and
    interactive development.

    On 1, the best thing is if you look at the source and immediately
    understand what the ordering will be. So when you are writing code,
    you just have this simple mental model, and spotting mistakes is easy.
    For example, if the system does no "intelligent" ordering for you, its
    obvious what the order at runtime will be, and you don't have to fight
    anything to get things into the desired order.

    On 2, this is more tooling support, in rough order of importance
    -- which case is called for input X, and why
    -- debugging a specific case independent of all others (suppress the
    other cases)
    -- various operations for comparing and testing patterns
    -- ide support for displaying / editing the ordering of definitions

    I've spent a ton of time debugging this stuff; its really important to
    have a quick way to find out why something happened in these open
    matching systems, and then have a convient way to patch the behavior.
    Its just not as easy as changing a cond case in a single place in
    source.

    The great thing about pattern matching in Mathematica is that it is so
    deeply integrated with all kinds of other primitives, from string
    manipulation, data manipulation, math stuff, the equivalent of Map,
    the equivalent of macros.  So my question is can clojure-style pattern
    matching and predicate dispatch be equally as powerful and pervasive,
    but it it's own way.

    One thought I had is about the relationship with program querying.
    With predicate dispatch, you'll have greater runtime control over your
    program, can swap things in and out at a finer granularity. And with
    this idea of program querying that Rich talked about, you might find
    all sorts of behaviors in your program that you might want to do
    something about. Seems sort of complementary.

    Maybe there is something there at that intersection, that can be a
    greater extension of logic-based programming beyond only extending the
    multimethod concept. So instead of replacing defn or defmulti, there
    could be an entirely different use case, and it would be obvious which
    one to use when.
    --
    You received this message because you are subscribed to the Google
    Groups "Clojure" group.
    To post to this group, send email to clojure@googlegroups.com
    Note that posts from new members are moderated - please be patient with your first post.
    To unsubscribe from this group, send email to
    clojure+unsubscribe@googlegroups.com
    For more options, visit this group at
    http://groups.google.com/group/clojure?hl=en
  • Kovas boguta at Feb 23, 2012 at 7:41 pm
    In general the way repl's handle state is pretty busted.

    Ever create a piece of data and then later wonder, how the heck did I make this?

    On Wed, Feb 22, 2012 at 11:29 PM, Jason Jackson wrote:
    "But this exposes a bigger problem: when doing interactive
    development,
    you will end up with old definitions sticking around. You are
    debugging one case of your function, and change the pattern a little.
    "

    Personally, I suffer from interactive development problems even with
    merely using def/defn. This is especially true if you're eval'ing
    snippets, and not the entire file C-cC-k.

    You could solve these problems by creating a new editor specifically
    for clojure interactive development which is aware of when you're
    updating code vs inserting new code vs deleting code, and change the
    interactive session accordingly. I'm sure there's a lot more you could
    add to such an editor.

    (or maybe emacs mode is sufficient dunno).
    On Feb 20, 9:56 pm, kovas boguta wrote:
    Mathematica implements a version of open and order-independent
    dispatch, so I wanted to add some points to the discussion.

    The design of Mathematica's pattern matching is tightly coupled to the
    language's computational model, as well as with all other aspects of
    the system. So a lot of it would get lost in translation to Clojure,
    and not give you as much mileage as it does in Mathematica.  So I'm
    mostly gonna focus on some pitfalls rather than the upside.

    The biggest problem for the developer is understanding the state of
    the rules system, especially during interactive development.

    Mathematica tries it's best to insert new function definitions in the
    "right" order, trying to figure out if pattern X if a subcase of
    pattern Y, etc. Of course, there are ambiguous cases, particular since
    the pattern language is rich. You solve this problem by either making
    your pattern more specific, changing the order in which definitions
    are loaded, or attaching the definition another symbol that has higher
    precedence.

    So debugging the pattern ordering is something you end up needing to
    know how to do.

    But this exposes a bigger problem: when doing interactive development,
    you will end up with old definitions sticking around. You are
    debugging one case of your function, and change the pattern a little.
    The old pattern is still there, potentially shadowing the new one. So
    anytime you see unexpected output while debugging, you need to wonder
    about the state of the definitions and if you should reinitialize
    them.

    You can also get a function that works at the repl, but its broken in
    source. The way this happens is, you enter definitions in arbitrary
    order at the repl, but they are in a different order in source. So in
    cases where order matters, this can get you too.

    I've pretty much had every possible situation happen.

    In Mathematica, it's possible to manually specific the order of the
    definitions, but it's too cumbersome to use in source code.

    In Clojure, the situation is simpler, and that helps. The pattern
    language (or versions that we've seen of it) is simpler, and
    destructuring is not part of its mission. (Changes to destructuring
    are a common source of this shadowing issue.) There is also the
    core.logic engine to do more deduction about the patterns themselves.

    Still, I still see the two problems of 1. debugging the ordering, and
    then 2. dealing with the state of the definitions during debugging and
    interactive development.

    On 1, the best thing is if you look at the source and immediately
    understand what the ordering will be. So when you are writing code,
    you just have this simple mental model, and spotting mistakes is easy.
    For example, if the system does no "intelligent" ordering for you, its
    obvious what the order at runtime will be, and you don't have to fight
    anything to get things into the desired order.

    On 2, this is more tooling support, in rough order of importance
    -- which case is called for input X, and why
    -- debugging a specific case independent of all others (suppress the
    other cases)
    -- various operations for comparing and testing patterns
    -- ide support for displaying / editing the ordering of definitions

    I've spent a ton of time debugging this stuff; its really important to
    have a quick way to find out why something happened in these open
    matching systems, and then have a convient way to patch the behavior.
    Its just not as easy as changing a cond case in a single place in
    source.

    The great thing about pattern matching in Mathematica is that it is so
    deeply integrated with all kinds of other primitives, from string
    manipulation, data manipulation, math stuff, the equivalent of Map,
    the equivalent of macros.  So my question is can clojure-style pattern
    matching and predicate dispatch be equally as powerful and pervasive,
    but it it's own way.

    One thought I had is about the relationship with program querying.
    With predicate dispatch, you'll have greater runtime control over your
    program, can swap things in and out at a finer granularity. And with
    this idea of program querying that Rich talked about, you might find
    all sorts of behaviors in your program that you might want to do
    something about. Seems sort of complementary.

    Maybe there is something there at that intersection, that can be a
    greater extension of logic-based programming beyond only extending the
    multimethod concept. So instead of replacing defn or defmulti, there
    could be an entirely different use case, and it would be obvious which
    one to use when.
    --
    You received this message because you are subscribed to the Google
    Groups "Clojure" group.
    To post to this group, send email to clojure@googlegroups.com
    Note that posts from new members are moderated - please be patient with your first post.
    To unsubscribe from this group, send email to
    clojure+unsubscribe@googlegroups.com
    For more options, visit this group at
    http://groups.google.com/group/clojure?hl=en
    --
    You received this message because you are subscribed to the Google
    Groups "Clojure" group.
    To post to this group, send email to clojure@googlegroups.com
    Note that posts from new members are moderated - please be patient with your first post.
    To unsubscribe from this group, send email to
    clojure+unsubscribe@googlegroups.com
    For more options, visit this group at
    http://groups.google.com/group/clojure?hl=en
  • Cedric Greevey at Feb 23, 2012 at 8:26 pm

    On Thu, Feb 23, 2012 at 2:41 PM, kovas boguta wrote:
    In general the way repl's handle state is pretty busted.

    Ever create a piece of data and then later wonder, how the heck did I make this?
    One simple thing would be if the repl logged sessions to
    sequentially-numbered files.

    You'd be able to do a lot with just grep and a text editor to retrace
    your steps, and even to distill repl experiments down into .clj source
    files.

    --
    You received this message because you are subscribed to the Google
    Groups "Clojure" group.
    To post to this group, send email to clojure@googlegroups.com
    Note that posts from new members are moderated - please be patient with your first post.
    To unsubscribe from this group, send email to
    clojure+unsubscribe@googlegroups.com
    For more options, visit this group at
    http://groups.google.com/group/clojure?hl=en
  • Linus Ericsson at Feb 23, 2012 at 8:29 pm
    2012/2/23 Cedric Greevey <cgreevey@gmail.com>
    On Thu, Feb 23, 2012 at 2:41 PM, kovas boguta wrote:
    In general the way repl's handle state is pretty busted.

    Ever create a piece of data and then later wonder, how the heck did I
    make this?

    One simple thing would be if the repl logged sessions to
    sequentially-numbered files.

    You'd be able to do a lot with just grep and a text editor to retrace
    your steps, and even to distill repl experiments down into .clj source
    files.

    A great idea. I would also love that the source + unixtime was attached to
    meta when the function was interactively inserted, since that usually isn't
    that big overhead + great for checking it out later on...

    /Linus ...getting a bit excited.

    --
    You received this message because you are subscribed to the Google
    Groups "Clojure" group.
    To post to this group, send email to clojure@googlegroups.com
    Note that posts from new members are moderated - please be patient with your first post.
    To unsubscribe from this group, send email to
    clojure+unsubscribe@googlegroups.com
    For more options, visit this group at
    http://groups.google.com/group/clojure?hl=en
  • Kovas boguta at Feb 23, 2012 at 8:45 pm
    You could also have 1 file for inputs, and 1 file for outputs.

    One of the most useless things about repl's is when you go back to the
    saved sessions, the input and output are mixed together in an
    indistinguishable mess.


    On Thu, Feb 23, 2012 at 3:28 PM, Linus Ericsson
    wrote:

    2012/2/23 Cedric Greevey <cgreevey@gmail.com>
    On Thu, Feb 23, 2012 at 2:41 PM, kovas boguta <kovas.boguta@gmail.com>
    wrote:
    In general the way repl's handle state is pretty busted.

    Ever create a piece of data and then later wonder, how the heck did I
    make this?
    One simple thing would be if the repl logged sessions to
    sequentially-numbered files.

    You'd be able to do a lot with just grep and a text editor to retrace
    your steps, and even to distill repl experiments down into .clj source
    files.
    A great idea. I would also love that the source + unixtime was attached to
    meta when the function was interactively inserted, since that usually isn't
    that big overhead + great for checking it out later on...

    /Linus ...getting a bit excited.

    --
    You received this message because you are subscribed to the Google
    Groups "Clojure" group.
    To post to this group, send email to clojure@googlegroups.com
    Note that posts from new members are moderated - please be patient with your
    first post.
    To unsubscribe from this group, send email to
    clojure+unsubscribe@googlegroups.com
    For more options, visit this group at
    http://groups.google.com/group/clojure?hl=en
    --
    You received this message because you are subscribed to the Google
    Groups "Clojure" group.
    To post to this group, send email to clojure@googlegroups.com
    Note that posts from new members are moderated - please be patient with your first post.
    To unsubscribe from this group, send email to
    clojure+unsubscribe@googlegroups.com
    For more options, visit this group at
    http://groups.google.com/group/clojure?hl=en
  • Kovas boguta at Feb 23, 2012 at 8:49 pm
    Is it possible to have something like this as a lein plugin?
    On Thu, Feb 23, 2012 at 3:45 PM, kovas boguta wrote:
    You could also have 1 file for inputs, and 1 file for outputs.

    One of the most useless things about repl's is when you go back to the
    saved sessions, the input and output are mixed together in an
    indistinguishable mess.


    On Thu, Feb 23, 2012 at 3:28 PM, Linus Ericsson
    wrote:

    2012/2/23 Cedric Greevey <cgreevey@gmail.com>
    On Thu, Feb 23, 2012 at 2:41 PM, kovas boguta <kovas.boguta@gmail.com>
    wrote:
    In general the way repl's handle state is pretty busted.

    Ever create a piece of data and then later wonder, how the heck did I
    make this?
    One simple thing would be if the repl logged sessions to
    sequentially-numbered files.

    You'd be able to do a lot with just grep and a text editor to retrace
    your steps, and even to distill repl experiments down into .clj source
    files.
    A great idea. I would also love that the source + unixtime was attached to
    meta when the function was interactively inserted, since that usually isn't
    that big overhead + great for checking it out later on...

    /Linus ...getting a bit excited.

    --
    You received this message because you are subscribed to the Google
    Groups "Clojure" group.
    To post to this group, send email to clojure@googlegroups.com
    Note that posts from new members are moderated - please be patient with your
    first post.
    To unsubscribe from this group, send email to
    clojure+unsubscribe@googlegroups.com
    For more options, visit this group at
    http://groups.google.com/group/clojure?hl=en
    --
    You received this message because you are subscribed to the Google
    Groups "Clojure" group.
    To post to this group, send email to clojure@googlegroups.com
    Note that posts from new members are moderated - please be patient with your first post.
    To unsubscribe from this group, send email to
    clojure+unsubscribe@googlegroups.com
    For more options, visit this group at
    http://groups.google.com/group/clojure?hl=en
  • Phil Hagelberg at Feb 23, 2012 at 9:51 pm

    kovas boguta writes:

    Is it possible to have something like this as a lein plugin?
    Sure, you could write an alternate repl that did this fairly easily,
    though doing it in Swank would be more work.

    Your best bet would be to build it on reply:

    https://github.com/trptcolin/reply

    -Phil

    --
    You received this message because you are subscribed to the Google
    Groups "Clojure" group.
    To post to this group, send email to clojure@googlegroups.com
    Note that posts from new members are moderated - please be patient with your first post.
    To unsubscribe from this group, send email to
    clojure+unsubscribe@googlegroups.com
    For more options, visit this group at
    http://groups.google.com/group/clojure?hl=en

Related Discussions