3,892 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

Jul
3
comment Is there a real advantage to dynamic languages?
Unjustified assumptions: 1) "[...] you can achieve the same effect in just about any statically-typed language, syntactic convenience aside [...]" -- assuming that 'syntactic convenience' is not a concern of language designers and users; 2) "[...] a good statically-typed language [...]" -- assuming that a good statically-typed language exists, and that everybody is perfectly free to use it; 3) "[...] type inference allows you to write code that's just as concise [...]".
Jul
3
comment Is there a real advantage to dynamic languages?
You forgot to attribute your source for the first paragraph -- existentialtype.wordpress.com/2011/03/19/…
Jul
2
awarded  Curious
Jun
30
comment extensible effects in purescript
@Simon gotcha -- just edited too!
Jun
30
revised extensible effects in purescript
added 671 characters in body
Jun
30
comment extensible effects in purescript
@Simon ah, I think I just got it. I initially didn't get what you meant by "label" ... I'll edit the answer when I get a chance.
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
30
answered extensible effects in purescript
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
30
accepted How are comments expressed in programming language grammars?
May
29
revised What is a real-world use case of using a Chomsky Type-I (context-sensitive) grammar
rolled back to a previous revision
May
29
awarded  Necromancer
May
29
revised What is a real-world use case of using a Chomsky Type-I (context-sensitive) grammar
added 42 characters in body
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
29
revised What is a real-world use case of using a Chomsky Type-I (context-sensitive) grammar
deleted 220 characters in body
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.