600 reputation
48
bio website felix-lang.org
location
age
visits member for 4 years, 1 month
seen Jun 6 '12 at 10:53

Developer of the open source Felix programming toolkit.


Sep
24
awarded  Autobiographer
Sep
11
awarded  Necromancer
Mar
1
awarded  Necromancer
Nov
26
awarded  Yearling
May
12
comment Correct For Loop Design
C's for loop does not universally handle all cases with a fixed comparison in the predicate. If you use < you cannot stop a loop which reaches the maximum value of the control variable type (for some types). If you use <= you cannot skip the body of the loop for zero cases. There is therefore no formulation for an arbitrary integral type which works correctly for 0 upto and including maximum value of the type. You need to understand my problem: I am generating code (not hand writing it) for unknown type with unknown bounds.
Apr
25
awarded  Critic
Jan
30
comment How to verify/prove orthogonality of a programming language?
+1 for the idea of splitting out the sugar
Jan
30
comment How to verify/prove orthogonality of a programming language?
@joan: I'm not a Haskell programmer so it's a bit hard to say, but the presence in Haskell of "extremely high level functionality" is indicative of strong orthogonality: you simply can't have a coherent implementation of Monads or Arrows unless the rest of the language has substantial "orthogonality"
Jan
30
comment How to verify/prove orthogonality of a programming language?
@joan: well, lisp doesn't have any features so it satisfies the requirement in vaccuuo :)
Jan
13
answered Interesting or unique types in programming languages?
Jan
13
comment Interesting or unique types in programming languages?
Channels aren't unique. Many languages have them. Felix had them 10 years before Google existed :) Ocaml had them 10 years before Felix existed.
Jan
13
comment Choosing the type of Index Variables
@Let_Me_Be: Because it makes the boundary conditions easier to test. For example on a count down to zero, a less-than test before executing the loop body cannot work with an unsigned value. Similarly a count up to the maximum doesn't work. Of course in that case a signed integer won't work either (because it can't represent such a large value).
Jan
13
comment Advantage/disadvantage of parameters / return types declaration in languages with type inference
As above, but with a different twist: machine readability. For example to make it easier to document a library with a tool.
Jan
9
comment Why is it good not to rely on changing state?
Mixed functional and imperative programming is what almost every language in existence does. Haskell may have provided a way to isolate the stateful parts, but that doesn't make it a proper mix: Charity is more like how it should be (IMHO).
Jan
8
answered Why is it good not to rely on changing state?
Jan
8
comment Why is it good not to rely on changing state?
Unfortunately the reality is that most FP languages, despite in theory providing the best concurrency, actually provide the worst. Partly because they rely on garbage collection which is not easy to parallelise, but also because basic optimisations like tail recursion optimisation go back to mutable state anyhow, and so fight against concurrency in practice.
Jan
8
comment Basis of definitions
FYI: I actually tried to generate this digraph at one stage, by analysing the default definitions. Maybe I should try that again. After all your Eq definition above is unsafe (just leave out both functions and you get an infinite loop). For even simple classes like partial orders it's much harder to "see" what's required.
Jan
8
comment Basis of definitions
Interesting! FYI, Felix is allowing both independent axioms for semantics, as well as default definitions (which are also semantic specifications). It isn't quite clear how to use this information though, apart from dependency analysis. But your Q2 is a fascinating idea! Basically a type class is a category, and you're suggesting writing isomorphisms between them.
Jan
7
comment Is Haskell's type system an obstacle to understanding functional programming?
It's not Java's type system that is the problem, its the object oriented rubbish that forces you to try to convolute a fairly obvious and correct solution into a framework which provably cannot provide one. The typing simply enforces the fraudulent design concept.
Jan
7
comment Is Haskell's type system an obstacle to understanding functional programming?
@Larry Coleman: +1 for describing precisely my own experience with types systems: first C++, then Ocaml, and now my own language Felix. Yes, I still refactor by chasing down compiler errors.