Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

[Feature] Algos with no arguments #7

Open
JustusAdam opened this issue Nov 3, 2017 · 1 comment
Open

[Feature] Algos with no arguments #7

JustusAdam opened this issue Nov 3, 2017 · 1 comment

Comments

@JustusAdam
Copy link
Member

In clojure it makes sense to define functions with no arguments to delay an evaluation or to perform side-effects.

(defn f []
  some-effect)


(let [x (f)]
  ...)

As this makes sense for ohua too we should support algorithms without arguments too.

Example

(defalgo f []
  some-effect)

(ohua 
  (smap
    (algo [a] .. (f) ...) ; f is executed multiple times
    [...]))

ALang however makes no distinction between a value invoking a function.
A possible way to solve this is by adding a dummy ignored _ argument and inserting a unit argument at the call site.

The most important thing to do is to figure out how to ensure the inlined let _ = unit in ... bindings after applying a function like (λ _ . ...) unit are removed at the appropriate time.

Perhaps to this end it may be beneficial to distinguish the ignored binding _ explicitly rather than just making it the binding "_".

Something like

data Bnd 
    = Real Binding
    | Ignored -- `_` 
@sertel
Copy link
Contributor

sertel commented Nov 17, 2017

I may have a simpler suggestion:
Our ALang is purely functional and therefore can not understand what (f) means.
I believe that the adaptation of our Clojure frontend to ALang should handle this case.
As such, there should be a rewrite like this (f) -> (f (unit)) where unit is a built-in stateful function. No changes to ALang would then be necessary. As far as performance goes, this is again something that we can optimize via fusion or another optimization maybe in DFLang.
I would vote for not changing our ALang towards that.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Projects
None yet
Development

No branches or pull requests

2 participants