5 ms·

> A proper Lisp-2, based on the features and limitations of the Erlang VM What are limitations?

jsnell 11y ago
One obvious example is that AFAIK the VM doesn't support functions with a variable number of arguments (foo/1 and foo/2 are two separate functions). This means that you can't have CL-style &rest or &key arguments.
- kazinator 11y ago
  While &key is CL-specific (and if you don't have it, you can ad-hoc it if you have variable arguments) variadic functions are pretty important, and found broadly in Lisp dialects. If you're on a VM or other target that doesn't do them natively, it's worth fighting tooth and nail to somehow get the functionality. E.g. make an inefficient variadic type that at the VM level takes a single argument---a list or vector of the arguments. Or multiple types for different combinations of fixed arg arity plus variable list.
  - wcummings 11y ago
    >E.g. make an inefficient variadic type that at the VM level takes a single argument---a list or vector of the arguments. Or multiple types for different combinations of fixed arg arity plus variable list. This would hurt interop with Erlang, which seems to be a goal of LFE.
  - cronjobber 11y ago
    > variadic functions are pretty important As you already wrote in another comment, most practical uses of variadic functions can be replaced by macros. What remains that is worth fighting the platform for?
- StreamBright 11y ago
  This is a feature to me more like a limitation. I do not like optional arguments &rest style. In Erlang you need to have explicit number of arguments and need to explicitly implement them. I really like that. Keep in mind that default values are trivial to implement when the smaller arity function calls the higher arity one with added values. Or you can call in yourself to the higher arity function and specify the parameters yourself. In my opinion this is elegant and safe way of dealing with the problem.
  - seiji 11y ago
    In Erlang you need to have explicit number of arguments and need to explicitly implement them. Or, you know, just use lists as parameters. That's the standard Erlang pattern for unknown parameters lengths (e.g. io:format("debug ~s because ~p~n", [SomeString, SomeType]))
    - kazinator 11y ago
      Firstly, this still requires a mechanism which underlies the [ ... ] notation for evaluating a sequence of any number of expressions and constructing a list. In Lisp dialects, that is done by a variadic function: (list 1 2 3 4 ...) Of course, if we don't need to indirect on this function, we could implement it as a macro (supposing further that we have variadic macros for compile time, but not variadic functions for run time). The macro would turn (list 1 2 3) into the non-variadic calls (cons 1 (cons 2 (cons 3 nil))). I imagine that's a conceptual facsimile of what Erlang's list constructor notation is doing. Erlang has variadic features in its read syntax; without a doubt its BNF is chock full of "zero or more of ..." grammar productions. The function defining mechanism lets you define a function which has any number of arguments; just that number has to be fixed for that function. So the mechanism itself enjoys variadic application. Here it is asked to define a three-arg function, here a ten-arg, ... We can simulate some aspects of variadic application with syntactic sugar, but not all. A Lisp function call which specifies five arguments can call a function which requires exactly five arguments, or a function which requires three arguments, followed by variadic ones. For instance, if we have a callback registration interface that passes five arguments, the client can supply a fixed arity function, or a variadic one. I suppose that if everything is static, that can still be worked out. The compiler sees that a variadic function with only two required args is passed as a callback that must be 5-ary, so it inserts a conversion shim: an anonymous function which takes exactly 5 parameters and applies them to the 3+rest function.
      - rvirding 11y ago
        LFE macros can have variable number of arguments. The compiler does very little in helping with this as there are in principle no inter-module dependencies. This is a requirement of the dynamic code handling which allows you to reload any module at any time without any requirements on the contents. All checking is done at run-time. This is a basic property of the Erlang system and to make something which is fully compatible you have to follow this. One way to have made LFE fully variadic in its functions would have been to have made each function only take one argument which is a list of the arguments in the call. This would have been easy to do but made it very difficult to interface LFE with the rest of the Erlang system in a clean way.
- wtbob 11y ago
  > One obvious example is that AFAIK the VM doesn't support functions with a variable number of arguments (foo/1 and foo/2 are two separate functions). This means that you can't have CL-style &rest or &key arguments. But surely one could call a function with one argument, which is a variable-length list of arguments, right?
rvirding 11y ago
Some limitations (?): are no global data; no shared data; all data is immutable; the modules are different from CL packages; functions can't have variable number of arguments[]. It does however have support for decent pattern matching and full access to all of Erlang's concurrency, fault-tolerance and scalability properties. Plus real macros as god intended. [] The macro handling can go part way to hide this.
- oubiwann 11y ago
  "Macro handling as god intended." I had to laugh :-) That reads like it's out of the Moonual ...
rvirding 11y ago
Some limitations (?): are no global data; no shared data; all data is immutable; the modules are different from CL packages; functions can't have variable number of arguments[]. It does however have support for decent pattern matching and full access to all of Erlang's concurrency, fault-tolerance and scalability properties. Plus real macros as god intended. [] The macro handling can go part way to hide this.

One obvious example is that AFAIK the VM doesn't support functions with a variable number of arguments (foo/1 and foo/2 are two separate functions). This means that you can't have CL-style &rest or &key arguments.

kazinator 11y ago
While &key is CL-specific (and if you don't have it, you can ad-hoc it if you have variable arguments) variadic functions are pretty important, and found broadly in Lisp dialects. If you're on a VM or other target that doesn't do them natively, it's worth fighting tooth and nail to somehow get the functionality. E.g. make an inefficient variadic type that at the VM level takes a single argument---a list or vector of the arguments. Or multiple types for different combinations of fixed arg arity plus variable list.
- wcummings 11y ago
  >E.g. make an inefficient variadic type that at the VM level takes a single argument---a list or vector of the arguments. Or multiple types for different combinations of fixed arg arity plus variable list. This would hurt interop with Erlang, which seems to be a goal of LFE.
- cronjobber 11y ago
  > variadic functions are pretty important As you already wrote in another comment, most practical uses of variadic functions can be replaced by macros. What remains that is worth fighting the platform for?
StreamBright 11y ago
This is a feature to me more like a limitation. I do not like optional arguments &rest style. In Erlang you need to have explicit number of arguments and need to explicitly implement them. I really like that. Keep in mind that default values are trivial to implement when the smaller arity function calls the higher arity one with added values. Or you can call in yourself to the higher arity function and specify the parameters yourself. In my opinion this is elegant and safe way of dealing with the problem.
- seiji 11y ago
  In Erlang you need to have explicit number of arguments and need to explicitly implement them. Or, you know, just use lists as parameters. That's the standard Erlang pattern for unknown parameters lengths (e.g. io:format("debug ~s because ~p~n", [SomeString, SomeType]))
  - kazinator 11y ago
    Firstly, this still requires a mechanism which underlies the [ ... ] notation for evaluating a sequence of any number of expressions and constructing a list. In Lisp dialects, that is done by a variadic function: (list 1 2 3 4 ...) Of course, if we don't need to indirect on this function, we could implement it as a macro (supposing further that we have variadic macros for compile time, but not variadic functions for run time). The macro would turn (list 1 2 3) into the non-variadic calls (cons 1 (cons 2 (cons 3 nil))). I imagine that's a conceptual facsimile of what Erlang's list constructor notation is doing. Erlang has variadic features in its read syntax; without a doubt its BNF is chock full of "zero or more of ..." grammar productions. The function defining mechanism lets you define a function which has any number of arguments; just that number has to be fixed for that function. So the mechanism itself enjoys variadic application. Here it is asked to define a three-arg function, here a ten-arg, ... We can simulate some aspects of variadic application with syntactic sugar, but not all. A Lisp function call which specifies five arguments can call a function which requires exactly five arguments, or a function which requires three arguments, followed by variadic ones. For instance, if we have a callback registration interface that passes five arguments, the client can supply a fixed arity function, or a variadic one. I suppose that if everything is static, that can still be worked out. The compiler sees that a variadic function with only two required args is passed as a callback that must be 5-ary, so it inserts a conversion shim: an anonymous function which takes exactly 5 parameters and applies them to the 3+rest function.
    - rvirding 11y ago
      LFE macros can have variable number of arguments. The compiler does very little in helping with this as there are in principle no inter-module dependencies. This is a requirement of the dynamic code handling which allows you to reload any module at any time without any requirements on the contents. All checking is done at run-time. This is a basic property of the Erlang system and to make something which is fully compatible you have to follow this. One way to have made LFE fully variadic in its functions would have been to have made each function only take one argument which is a list of the arguments in the call. This would have been easy to do but made it very difficult to interface LFE with the rest of the Erlang system in a clean way.
wtbob 11y ago
> One obvious example is that AFAIK the VM doesn't support functions with a variable number of arguments (foo/1 and foo/2 are two separate functions). This means that you can't have CL-style &rest or &key arguments. But surely one could call a function with one argument, which is a variable-length list of arguments, right?

rvirding 11y ago

Some limitations (?): are no global data; no shared data; all data is immutable; the modules are different from CL packages; functions can't have variable number of arguments[]. It does however have support for decent pattern matching and full access to all of Erlang's concurrency, fault-tolerance and scalability properties. Plus real macros as god intended. [] The macro handling can go part way to hide this.

oubiwann 11y ago
"Macro handling as god intended." I had to laugh :-) That reads like it's out of the Moonual ...

rvirding 11y ago