3,877 reputation
21648
bio website connjur.uchc.edu
location Connecticut, USA
age 27
visits member for 2 years, 9 months
seen Jul 23 at 13:44

I work in a scientific computing group on the CONNJUR project, providing open-source software for NMR (Nuclear Magnetic Resonance) spectroscopy.

Check out some of my work on github:

  • NMRPyStar: an API for accessing archived NMR data files in the NMR-Star format used by the BMRB.

  • Miscue-js: validation of JSON files to deal with obnoxious and tricky interoperability issues such as number overflows and duplicate keys

Some technologies that I've used and like:

  • Python
  • git
  • Javascript
  • Haskell
  • Java
  • MySQL

Jun
30
comment extensible effects in purescript
@Simon maybe you could clarify the OP? I'm still not sure what exactly it's asking, and I'd be happy to remove or edit my answer if you wouldn't mind improving the OP.
Jun
10
comment Is there an imperative language with a Haskell-like type system?
1) what is perfect about it? compared to e.g. agda? 2) history of type classes; 3) type inference & subtyping, also here; 4) effects systems -- i.e. do effects have to be explicit? in the type? etc.
May
29
comment What is a real-world use case of using a Chomsky Type-I (context-sensitive) grammar
@HonzaBrabec you're right -- I implicitly assumed that arbitrary tag names are allowed. I should have explicitly stated that assumption. Thank you for pointing that out!
May
21
comment What is the responsibility or benefit of a Tokenizer?
What if your tokens can't be described with a regular grammar? Also, a huge difference between a "lexer" and a "parser" is the latter's stack, allowing it to for example, correctly parse arbitrarily-deep nested parentheses -- ((()())(((())))).
May
21
comment What is the responsibility or benefit of a Tokenizer?
-1. This is a fallacious appeal to common sense, and raises more questions than it answers. Why is that the first step? Why does it need to be separated from the rest of parsing? What's so important about tokens? What if your language doesn't have have "words" in the same sense as C? What if your "tokens" can't be parsed with a regular grammar, but require context-free or context-sensitive? How can you think about what the document means if you've tokenized it, but not assembled it into a parse tree?
May
21
comment What is the responsibility or benefit of a Tokenizer?
@Doval I was not asking for the definition of "unrelated", but why you think that tokenizing and hierarchical parsing are unrelated. Because both in theory (of languages) and in practice, they are related: splitting them introduces problems that are not present when they're combined. (Of course it's possible to minimize and work-around these problems with careful design, but that's not the same as just not having them in the first place.)
May
19
comment What is the responsibility or benefit of a Tokenizer?
@Doval re: cost. Your statement easier to make changes without affecting unrelated parts is actually an interesting one. Why do you think they're unrelated? In practice, this assumption is not universally true (i.e. you can not split an arbitrary language into "tokens" and "not tokens" -- example of Java's lexical grammar failing).
May
19
comment What is the responsibility or benefit of a Tokenizer?
@delnan you're reading too much in my answer that's not there. The subtle implication that I'm pooping on everybody who uses/supports/write about separate tokenization is pure strawman. Plus, you're just making stuff up about the importance of tokenization; tokens aren't interesting, tokenization isn't a big deal. Just one of several ways to get a parse tree.
May
19
comment What is the responsibility or benefit of a Tokenizer?
@Doval you're making a circular argument -- you're essentially saying that we need separate tokenizers and hierarchical parsers, because tokenizing and hierarchical parsing are different. But why are they different? More importantly, what is the cost of differentiating them?
May
19
comment What is the responsibility or benefit of a Tokenizer?
@MichaelShaw tokenizers (and token grammars) typically limit the complexity (approximately Chomsky type 3) of the tokens, allowing the increase in performance.
May
16
comment What is the responsibility or benefit of a Tokenizer?
This misconception seems to be at the core of this answer: The benefit is that this simplifies the grammar and parser. That complexity doesn't just disappear: it goes somewhere else (in this case, to the token grammar and tokenizer). So now you have two things, each of which does ~1/2 the job of a parser. About the same amount of work. Where's the benefit?
May
10
comment How do I simplify a compiler/interpreter?
@delnan rereading your comment, it seems we're in violent agreement. I'm not claiming that it should be done, nor that it's hugely beneficial, nor that it's always great, but rather pointing out that it can be done and why one might choose to do so. Importantly, I doubt there's a one-size-fits-all choice -- I expect the cost/value of such an approach is heavily context-sensitive.
May
10
comment How do I simplify a compiler/interpreter?
@delnan I disagree on all points. I think the root of our disagreement is different implicit assumptions about the language and how the parser will be used. Needless to say, without understanding each other's assumptions, this conversation is 100% pointless.
May
9
comment How do I simplify a compiler/interpreter?
@delnan there's several benefits: 1) separation of concerns -- can change concrete and abstract syntaxes independently; 2) simpler parser; 3) can regenerate the original input; 4) parse tree corresponds directly to input (it seems we disagree on the importance of this for debugging). Of course there are costs as well.
May
9
comment How do I simplify a compiler/interpreter?
Is the question exclusively about parsing? I'm asking because none of the responses mention anything about all the other things besides parsing that compilers and interpreters do.
May
9
comment How do I simplify a compiler/interpreter?
Nice points. To make it even simpler, I'd even go so far as to suggest producing a concrete syntax tree (CST) instead of an AST -- then the parse tree will exactly match the input, even including things like unnecessary parentheses. Easier to debug. Not at all sure how well this approach fits into YACC though.
Apr
30
comment Why is studying an lisp interpreter in lisp so important?
2nd paragraph doesn't make sense: homoiconicity != simple syntax; simple syntax makes it easy to write a Lisp parser in any language (see this). 3rd paragraph is vague, needs example(s).
Apr
25
comment Pattern matching in Clojure vs Scala
@gnat c2.com/cgi/wiki?QuotingNotThinking
Apr
25
comment Pattern matching in Clojure vs Scala
@kurofune it looks like most of us, myself included, agree that it was a well-written question.
Apr
25
comment Pattern matching in Clojure vs Scala
In defense of this question: it's objective, well-written, and clear. Why does it matter that the OP read a blog before posting this question? That doesn't change the quality of the question.