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

Example of lpf/dynamic does not work #6

Closed
jproy opened this issue Apr 28, 2014 · 5 comments
Closed

Example of lpf/dynamic does not work #6

jproy opened this issue Apr 28, 2014 · 5 comments

Comments

@jproy
Copy link

jproy commented Apr 28, 2014

The example with control and sawtooth in the doc of lpf/dynamic does not work.

@jbclements
Copy link
Owner

I've fixed the docs. However, the larger problem is that the "application pun" that happens in networks is just terrible--it always confuses me, and I came up with it. I think everything will read much much better if I replace

[out (foo bar baz)]

with

[out <- foo bar baz]

The difference is that the "call" to foo isn't actually a call, and foo isn't a procedure. Changing this should make it much clearer. Also, it will hopefully address the horrible hack that's currently in place where things like

[out (/ x 5)]

work, but for a really nasty reason.

@jbclements
Copy link
Owner

No! Better idea! Dispense with the whole notion of signals as separate from functions. This means that initialization of signals has to become a call to a maker, but I think that'll actually read pretty nicely.

@jbclements
Copy link
Owner

Arrrrrrr! No, the initialization doesn't quite work. Grr... Still thinking.

@jproy
Copy link
Author

jproy commented May 9, 2014

Reading "Signals & Systems" books, I thought that signals were functions time -> pressure and that systems were things that transformed signals… The doc will be important for people like me who have not this kind of culture :-)
Macros are cool up to the point where too many things are hidden or just don’t "follow the rules" (e.g. function application). Sure you will converge to the best point of view.
Thanks for your nice work and your time,

-jpr

Le 9 mai 2014 à 19:05, John Clements notifications@github.com a écrit :

No! Better idea! Dispense with the whole notion of signals as separate from functions. This means that initialization of signals has to become a call to a maker, but I think that'll actually read pretty nicely.


Reply to this email directly or view it on GitHub.

@jbclements
Copy link
Owner

Okay, I think I have a happy medium now. Should be fixed in 3280ea3

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

No branches or pull requests

2 participants