3 ms·

Is Fexl open-source, or even available for download? It looks pretty neat.

by Imbue 16y ago

fexl 16y ago
Funny, I was just thinking about that very thing when I noticed your post. Problem is, I'm a little "ashamed" to release the code right now because I'm in the middle of some major revisions: 1. Use DeBruin notation for referring to bound lambda values positionally, instead of my current approach of actually using the lambda symbol in an associative list. (Don't laugh, it works.) 2. Change the C implementation so it just uses an array of longs for the whole working space, with integer offsets, instead of node structs with pointers. At that point the whole implementation will be "nothin' but int", and avoid malloc altogether. 3. Change both the Perl and C implementations so that I supply external function definitions as function pointers. Right now when a high-order function is reduced to a normal form (lambda form), I actually look at the name of the external function being called and do a big if-else on that. (Don't laugh, it works.) This will no longer be an option when I go with DeBruin notation. Besides, the function pointer approach will be a lot more solid, serious, and extensible. Thanks for expressing an interest. When I'm a little more proud of my code and have something available for download, I'll announce it on HN.
- Imbue 16y ago
  This is probably a stupid question. If you have Fexl written in Perl now, what are the chances of just throwing a sand-boxed interpreter online for people to play with? I'm thinking just a form with an input field and a submit button which runs the script and displays any printed values.
  - fexl 16y ago
    It's a brilliant question, and it's now on my TODO list. I'll aim to get this done by the end of August. You're right about the sandboxing too -- the Fexl interpreter runs with two limits: the maximum number of cycles, and the maximum amount of memory. If it reaches either of those limits, it halts. So it should be perfectly safe to run it on the public web.
    - Imbue 16y ago
      Great! I'll be looking forward to it. I kind of have a thing for small languages.
    - fexl 16y ago
      Update: It might not be ready by the end of August. I just returned from a week-long trip, and I'm now busy rewriting the whole Fexl interpreter in terms of pure combinatorics (see http://fexl.com/#combinatorics http://fexl.com/#combinatorics ). The interpreter understands only the two fundamental combinators S and C. Although it is possible to define high-order combinators in the interpreter using function pointers, I am limiting myself to S and C to minimize the code size and illustrate the principle that all computable functions can be defined as applications of only S and C. So, for example, even the Y combinator itself is defined in terms of S and C as: \I = (S C C) \Q = (S (S (C S) C) (C (S I I))) \Y = (S Q Q) I'm now doing some bootstrapping, eliminating code formerly written in Perl. I'm writing the Fexl parser in Fexl, and manually converting it to S and C. I can then eliminate the parser written in Perl.
    - fexl 16y ago
      Update: It might not be ready by the end of August. I just returned from a week-long trip, and I'm now busy rewriting the whole Fexl interpreter in terms of pure combinatorics (see http://fexl.com/#combinatorics http://fexl.com/#combinatorics ). The interpreter understands only the two fundamental combinators S and C. Although it is possible to define high-order combinators in the interpreter using function pointers, I am limiting myself to S and C to minimize the code size and illustrate the principle that all computable functions can be defined as applications of only S and C. For example, even the Y combinator itself is defined in terms of S and C as: \I = (S C C) \Q = (S (S (C S) C) (C (S I I))) \Y = (S Q Q) I'm now doing some bootstrapping, eliminating code formerly written in Perl. I'm writing the Fexl parser in Fexl, and manually converting it to S and C. I can then eliminate the parser written in Perl. Manually abstracting Fexl code into S and C is not as hard as it may seem. I can take a piece of Fexl code and, using a very simple and mechanical method, systematically transform it into S and C. The Fexl parser itself employs this same method automatically using these functions: # Basic parse tree forms (sym name) and (app fun arg). \sym = (\name \sym\app sym name) \app = (\fun\arg \sym\app app fun arg) # Lambda abstraction of a parameter from a form. Note # that a symbol name in Fexl source code cannot start with # "=". We use this fact to introduce symbols with fixed # definitions, e.g. "=C", "=S", and "=I". \lam = (\param\form form (\name string:eq param name (sym "=I") (app (sym "=C") (sym name))) (\fun\arg app (app (sym "=S") (lam param fun)) (lam param arg)) ) # We then resolve externally defined symbols with the # resolve function. The context parameter is an arbitrary # function which maps symbol names to functional values. \resolve = (\context\form form context (\fun\arg (resolve context fun) (resolve context arg)) )
fexl 16y ago
If you're interested in dabbling a bit, here's the grammar I'm using: Here is the basic Fexl language, which can express all computable functions. expr = \atom expr expr = factor expr = factor expr factor = atom factor = (expr) The full language includes two additional notations for convenience. expr = \atom=factor expr = (\atom expr) factor expr = factor; expr = factor (expr)

Is Fexl open-source, or even available for download? It looks pretty neat.

by Imbue 16y ago

Is Fexl open-source, or even available for download? It looks pretty neat.

fexl 16y ago

Funny, I was just thinking about that very thing when I noticed your post. Problem is, I'm a little "ashamed" to release the code right now because I'm in the middle of some major revisions: 1. Use DeBruin notation for referring to bound lambda values positionally, instead of my current approach of actually using the lambda symbol in an associative list. (Don't laugh, it works.) 2. Change the C implementation so it just uses an array of longs for the whole working space, with integer offsets, instead of node structs with pointers. At that point the whole implementation will be "nothin' but int", and avoid malloc altogether. 3. Change both the Perl and C implementations so that I supply external function definitions as function pointers. Right now when a high-order function is reduced to a normal form (lambda form), I actually look at the name of the external function being called and do a big if-else on that. (Don't laugh, it works.) This will no longer be an option when I go with DeBruin notation. Besides, the function pointer approach will be a lot more solid, serious, and extensible. Thanks for expressing an interest. When I'm a little more proud of my code and have something available for download, I'll announce it on HN.

Imbue 16y ago
This is probably a stupid question. If you have Fexl written in Perl now, what are the chances of just throwing a sand-boxed interpreter online for people to play with? I'm thinking just a form with an input field and a submit button which runs the script and displays any printed values.
- fexl 16y ago
  It's a brilliant question, and it's now on my TODO list. I'll aim to get this done by the end of August. You're right about the sandboxing too -- the Fexl interpreter runs with two limits: the maximum number of cycles, and the maximum amount of memory. If it reaches either of those limits, it halts. So it should be perfectly safe to run it on the public web.
  - Imbue 16y ago
    Great! I'll be looking forward to it. I kind of have a thing for small languages.
  - fexl 16y ago
    Update: It might not be ready by the end of August. I just returned from a week-long trip, and I'm now busy rewriting the whole Fexl interpreter in terms of pure combinatorics (see http://fexl.com/#combinatorics http://fexl.com/#combinatorics ). The interpreter understands only the two fundamental combinators S and C. Although it is possible to define high-order combinators in the interpreter using function pointers, I am limiting myself to S and C to minimize the code size and illustrate the principle that all computable functions can be defined as applications of only S and C. So, for example, even the Y combinator itself is defined in terms of S and C as: \I = (S C C) \Q = (S (S (C S) C) (C (S I I))) \Y = (S Q Q) I'm now doing some bootstrapping, eliminating code formerly written in Perl. I'm writing the Fexl parser in Fexl, and manually converting it to S and C. I can then eliminate the parser written in Perl.
  - fexl 16y ago
    Update: It might not be ready by the end of August. I just returned from a week-long trip, and I'm now busy rewriting the whole Fexl interpreter in terms of pure combinatorics (see http://fexl.com/#combinatorics http://fexl.com/#combinatorics ). The interpreter understands only the two fundamental combinators S and C. Although it is possible to define high-order combinators in the interpreter using function pointers, I am limiting myself to S and C to minimize the code size and illustrate the principle that all computable functions can be defined as applications of only S and C. For example, even the Y combinator itself is defined in terms of S and C as: \I = (S C C) \Q = (S (S (C S) C) (C (S I I))) \Y = (S Q Q) I'm now doing some bootstrapping, eliminating code formerly written in Perl. I'm writing the Fexl parser in Fexl, and manually converting it to S and C. I can then eliminate the parser written in Perl. Manually abstracting Fexl code into S and C is not as hard as it may seem. I can take a piece of Fexl code and, using a very simple and mechanical method, systematically transform it into S and C. The Fexl parser itself employs this same method automatically using these functions: # Basic parse tree forms (sym name) and (app fun arg). \sym = (\name \sym\app sym name) \app = (\fun\arg \sym\app app fun arg) # Lambda abstraction of a parameter from a form. Note # that a symbol name in Fexl source code cannot start with # "=". We use this fact to introduce symbols with fixed # definitions, e.g. "=C", "=S", and "=I". \lam = (\param\form form (\name string:eq param name (sym "=I") (app (sym "=C") (sym name))) (\fun\arg app (app (sym "=S") (lam param fun)) (lam param arg)) ) # We then resolve externally defined symbols with the # resolve function. The context parameter is an arbitrary # function which maps symbol names to functional values. \resolve = (\context\form form context (\fun\arg (resolve context fun) (resolve context arg)) )

fexl 16y ago

If you're interested in dabbling a bit, here's the grammar I'm using: Here is the basic Fexl language, which can express all computable functions. expr = \atom expr expr = factor expr = factor expr factor = atom factor = (expr) The full language includes two additional notations for convenience. expr = \atom=factor expr = (\atom expr) factor expr = factor; expr = factor (expr)