That's interesting, but excluding the "reducing to combinatorial forms" thing, which only seems to be an implementation detail, can't this all be done in Scheme or another Lisp dialect? "no distinction between data and function" goes hand in hand with https://secure.wikimedia.org/wikipedia/en/wiki/Homoiconicity
So at least Fexl has the virtue of being more compact in those cases. :) Also, in Fexl, whenever you see a name, it always refers to a function, unlike in Lisp, where names like "defun" and "lambda" and "prog" are meta-logical syntactic devices and cannot be defined as functions in their own right. And anything like "setq" or "setf" is strictly out of the question in Fexl.
You could of course implement lazy techniques in Lisp, even going so far as to write a Fexl interpreter if you like. I just wanted to see what happened if procedural, mutable, and meta-logical constructs were completely eliminated as possibilities in a language.
Definitely without the types, yes. However, monads are completely do-able in Fexl. I can write Fexl code that looks procedural and "side-effect-y", using the monadic technique so that you never actually see the state variable that's being chained through the functions. Monads are more a style of code than a feature of the language per se.
Personally I'm quite happy without the baggage of type declarations. As long as I build up functions systematically, I have very few problems with run-type type violations. Sure every once in a while I forget a semicolon or whatever and my function gets "out of synch" like a T-1 line gone out of phase. But it's usually pretty easy to see what went wrong.
Yeah, I know how monads work, what I mean was that according to the examples you don't seem to enforce purity(nothing like the IO monad).
And I've never found types to be a burden in Haskell, the type inference works great so that you can usually omit them if you can't be bothered, but I still include them most of the time because they help you reason about your code and see patterns.
Right, I don't enforce purity, but I do allow it. Ultimately there's a "string_put" function which (1) produces an actual side effect and (2) evaluates to the identity function. You can wrap monadic (monastic?) purity around that if you like.
Also, strict typing is pretty much impossible in Fexl, since I'm using combinators. You can't really assign a meaningful type to things like S, C, I, Y, etc. So yes, Fexl is very "loosey-goosey" that way. I also didn't want to bother with some ponderous PhD project like a "type inference engine" written into my ANSI-C interpreter. I figure if you want to do high level things like that, write those tools in Fexl itself (i.e. use meta-programming techniques).
Comments
That's interesting, but excluding the "reducing to combinatorial forms" thing, which only seems to be an implementation detail, can't this all be done in Scheme or another Lisp dialect? "no distinction between data and function" goes hand in hand with https://secure.wikimedia.org/wikipedia/en/wiki/Homoiconicity
You can certainly do this sort of thing in Lisp, using forms like:
In Fexl you would see instead: So at least Fexl has the virtue of being more compact in those cases. :) Also, in Fexl, whenever you see a name, it always refers to a function, unlike in Lisp, where names like "defun" and "lambda" and "prog" are meta-logical syntactic devices and cannot be defined as functions in their own right. And anything like "setq" or "setf" is strictly out of the question in Fexl.You could of course implement lazy techniques in Lisp, even going so far as to write a Fexl interpreter if you like. I just wanted to see what happened if procedural, mutable, and meta-logical constructs were completely eliminated as possibilities in a language.
So, Haskell without types and monads basically? ;)
Definitely without the types, yes. However, monads are completely do-able in Fexl. I can write Fexl code that looks procedural and "side-effect-y", using the monadic technique so that you never actually see the state variable that's being chained through the functions. Monads are more a style of code than a feature of the language per se.
Personally I'm quite happy without the baggage of type declarations. As long as I build up functions systematically, I have very few problems with run-type type violations. Sure every once in a while I forget a semicolon or whatever and my function gets "out of synch" like a T-1 line gone out of phase. But it's usually pretty easy to see what went wrong.
Yeah, I know how monads work, what I mean was that according to the examples you don't seem to enforce purity(nothing like the IO monad).
And I've never found types to be a burden in Haskell, the type inference works great so that you can usually omit them if you can't be bothered, but I still include them most of the time because they help you reason about your code and see patterns.
Right, I don't enforce purity, but I do allow it. Ultimately there's a "string_put" function which (1) produces an actual side effect and (2) evaluates to the identity function. You can wrap monadic (monastic?) purity around that if you like.
Also, strict typing is pretty much impossible in Fexl, since I'm using combinators. You can't really assign a meaningful type to things like S, C, I, Y, etc. So yes, Fexl is very "loosey-goosey" that way. I also didn't want to bother with some ponderous PhD project like a "type inference engine" written into my ANSI-C interpreter. I figure if you want to do high level things like that, write those tools in Fexl itself (i.e. use meta-programming techniques).