< Back to IRCAM Forum

To eval or not to eval?

OpenMusic
#1

Hello OM developpers,

I very often use to write lambda expressions directly into the objects inlets, as a ‘value’ (since in principle lisp uses to make not difference between symbolic expressions and data) and one could expect that a lambda expr should be passed as it is and to be evaluated internally (let say magically, or lispally ;), but even when using a syntax such as #’(lambda (data) …), OM objects seem to have no method to manage such a lambda (which is nevertheless a real and beautiful lambda) and one may use the object [eval] to make it work (as a lambsa).
So that why not considering that OM objects inlets may internally eval lambdas by default (as a generic method for instance) ? This may make unnecessary the absurd eval (which converts a lambda into a lambda), the patch lighter, and write the patch faster (as in emacs-slime-sbcl or so), isn’t it ?
:))

#2

Hi Fred.

May I ask you WHEN this was possible in OM ? I can’t seem to remember this as possible.

Best
K

#3

Hahaha as I remember it had never been possible ! But I always think that it may be possible and very convenient to enter litteral lamba function as an input, with something like a method for all OM objects for symbolic expressions…
Bests.

#4

Hi Fred,
Can you elaborate please?

Best
K

#5

Not sure it’s a good idea for all, the error message when evaluating (3) is wrong since the symbolic expression in the input of mapcar object IS a lambda (even if not ‘compiled’ by some eval object) so that it may work :wink:

Capture d’écran du 2022-11-28 15-35-29
Capture d’écran du 2022-11-28 15-35-29552×564 23.2 KB

#6

Hi,

Maybe something I don’t get here. But both “expressions” work for me:

Screenshot_2022-11-28_15-48-40
Screenshot_2022-11-28_15-48-40663×553 23.7 KB

Best
K

#7

Hi Karim :slight_smile:

yes here it is, but the one without the use of ‘eval’ box is missing in your example. Please have a look at where is coming from the left input of the mapcar (3) in my example #trickyquestion ?

#8

Dear Fred,

I mostly like riddles, but unfortunately i don’t have much time for them lately. If you don’t send me a patch i can never never guess in no way what’s incoming in your mapcar since you have a red abstraction.

Now if you expect the lambda expression to be evaluated WITHOUT eval, well i guess you can still pray on that to happen. :slight_smile:

Best
K

#9

Dear Karim,

Sorry for such a strange question.
Here is the same idea where the mapcar box says that its left argument is not a function when it is a function even if it’s a list in respect to lisp.

Capture d’écran du 2022-11-29 13-59-40

Since I often define lambdas as inputs, such a feature may make the patches more easy to read than using ‘Lisp code’ boxes which require to be open to have a look to the lambda definitions…
Do you know the OM lisp file to define OM boxes methods according to their input types ? I’d like to have a try :wink:
Bests,
fred

#10

well fred,

Now i understand your concern: You want to use an ombox as a function.
Well it is a little bit tricky. You can start looking at this file:

/code/kernel/ommodele/ombasicobjects/boxes/patchboxes.lisp

You have then to find a way to indentify the box as a lambda expression and NOT as a list of elts.

However i recommend simply using eval if you don’t want yourself to get into troubles… :slight_smile:
Best
K