Re: Rationale of behavior when invoking composite data type as 0-arity function
Ok so I think taking a step back, I think their is some complecting going
on here. I don't see how you see "that invoking a map without arguments
evaluates it" as a generalization. I believe Rich's intention behind map's,
set's, and vector's being callable is that they naturally behave as
primitive (mathematically) functions, which map a key space to an output
space. So first, there aren't any natural meanings for calling a map with
zero arguments. (If anything, I think it should return nil. Because
sometimes we would call functions using apply like (apply f [a b c]), and
sometimes that list is empty, like (apply {} []). This is just like how (+)
evaluates to 0. But I digress...).
What you are generally talking about is controlling code evaluation. You
are specifically storing code within the values (and potentially keys) of
the map. Really, this code is just lists, aka data. It is really important
to keep the phases of evaluation separate, otherwise this makes macro
writing very confusing (and coding in general). What you are suggesting
complects calling a map (keys to values), with evaling a map (recursively
eval any non quoted lists). These are separate actions/ideas. When we do
want to operate in different phases, then we really do want to call eval
explicitly as this is a "dramatic" action. Eval takes literal data and
pipes them through unless they are lists, where it treats the first arg as
a function/special-form, and the output can be very different from the
input. In contrast, often transformations on maps result in other maps. My
take here is, again, this should be explicit. In your intended behavior
example (({}) :b), it is calling eval behind the scenes. This is very
hidden and leads to very different performance implications. My take is you
are suggesting reducing code size but not actually addressing duplication,
and in the process making special behaviors less intuitive. (One other
thing is what you suggest doesn't blend nicely with -> as you'd still have
to call .invoke at the end instead of just calling eval.)
-
To support your cause, however, I think there are many tools to help you
with code manipulation and code analysis during runtime.
If you want your code to work as is but have code analysis phases, you can
use macros to insert code analyzing phases without impacting the evaluation
and runtime implications of the code itself.
For example:
(def code-size (atom 0))
(defmacro count-code [some-code]
(reset! code-size (count (str some-code)))
some-code)
(count-code {:a :b}) ;; => {:a :b}
@code-size ;; => 7
>From there, you can write code analysis walkers as functions (not macros)
and use them at runtime with explicit quoted forms at the repl, or insert
them into your macros for analyzing "production" code.
On Wednesday, November 24, 2021 at 2:52:43 PM UTC-5 dieter.v...@gmail.com
wrote:
> Hello Brent,
>
> The use case I had in mind was to keep a map readable during development.
> Take a simple map: {:type QTDIR :path (hash "a string")}. It's easier to
> play with this data if evaluation of certain symbols and functions is
> delayed.
>
> Thanks you both for your answer,
> kind regards,
> Dieter
>
>
>
>
> On Mon, Nov 22, 2021 at 3:39 AM Brent Millare wrote:
>
>> I'm curious why you are saving hashmaps that have clojure code within it
>> with the intention of evaluating this code as embedded in the hashmap? What
>> is the use case? Are you trying to delay evaluation? Regardless, eval
>> always incurs a cost and should generally be avoided if you can use
>> "runtime" techniques instead. Is the embedded code trusted?
>>
>> Best,
>> Brent
>>
>> On Sunday, November 21, 2021 at 9:22:47 AM UTC-5 dieter.v...@gmail.com
>> wrote:
>>
>>> Hello,
>>>
>>> It seems to be a design decision that 0-arity invoke of a composite data
>>> type gives an ArityException: the composite data type does not implement
>>> the IFn when no arguments are given.
>>> Is there a certain design decision behind this behavior? (or a certain
>>> use-case)
>>>
>>>
>>> repl> ;composite data type evaluates to itself
>>> repl> {:a 1 :b (hash "word")}
>>> {:a 1 :b -304538205}
>>> repl> '{:a 1 :b (hash "word")}
>>> {:a 1 :b (hash "word")}
>>> repl> (def mydata '{:a 1 :b (hash "word")})
>>> repl> mydata
>>> {:a 1 :b (hash "word")}
>>> repl> ;composite data type implements IFn for its keys
>>> repl> (mydata :b)
>>> (hash "word")
>>> repl> ; there is no '0-arity' implementation of IFn for composite data
>>> type
>>> repl> ({})
>>> ... (ArityException)...
>>> repl> (mydata)
>>> ... (ArityException)...
>>> repl> ; instead i have to type eval
>>> repl> ((eval mymap) :b)
>>> -304538205
>>>
>>> I know its only 4 letters and a space extra, but software composition is
>>> supposed to avoid code duplication and perhaps the idea makes sense that
>>> invoking a map without arguments evaluates it... Hence the question about
>>> the choice made for the current behavior.
>>>
>>> A possi
2nd Call for Contributions: BOB 2022 [March 11, Deadline Dec 6]
Please send us some Clojure! BOB Conference 2022 "What happens when we use what's best for a change?" https://bobkonf.de/2022/cfc.html Berlin, Mar 11 Call for Contributions Deadline: December 6, 2021 You are actively engaged in advanced software engineering methods, solve ambitious problem with software and are open to cutting-edge innovation? Attend this conference, meet people that share your goals, and get to know the best software tools and technologies available today. We strive to offer a day full of new experiences and impressions that you can use to immediately improve your daily life as a software developer. If you share our vision and want to contribute, submit a proposal for a talk or tutorial! NOTE: The conference fee will be waived for presenters. Travel expenses will not be covered (for exceptions see "Speaker Grants"). Online or Onsite We expect we'll be able to hold BOB 2022 in Berlin. If that is not possible, we'll make BOB a successful online event, like BOB 2021. Should BOB happen online, we will likely ask for pre-recorded talks to make room for questions and social interactions during the actual conference day. (Of course, we'll provide assistance making those recordings.) Tutorials will likely happen as a live-session. Shepherding --- The program committee offers shepherding to all speakers. Shepherding provides speakers assistance with preparing their sessions. Specifically: - advice on structure and presentation - review of talk slides - assistance with recording - review of recording, if applicable Speaker Grants -- BOB has Speaker Grants available to support speakers from groups under-represented in technology. We specifically seek women speakers, speakers of color, and speakers who are not able to attend the conference for financial reasons. Topics -- We are looking for talks about best-of-breed software technology, e.g.: - functional programming - persistent data structures and databases - event-based modelling and architecture - "fancy types" (dependent types, gradual typing, linear types, ...) - formal methods for correctness and robustness - abstractions for concurrency and parallelism - metaprogramming - probabilistic programming - math and programming - controlled side effects - program synthesis - next-generation IDEs - effective abstractions for data analytics - … everything really that isn’t mainstream, but you think should be. Presenters should provide the audience with information that is practically useful for software developers. Challenges -- Furthermore, we seek contributions on successful approaches for solving hard problems, for example: - bias in machine-learning systems - digital transformation in difficult settings - accessibiltity - systems with critical reliability requirements - ecologically sustainable software development We're especially interested in experience reports. Other topics are also relevant, e.g.: - introductory talks on technical background - overviews of a given field - demos and how-tos Requirements We accept proposals for presentations of 45 minutes (40 minutes talk + 5 minutes questions), as well as 90 minute tutorials for beginners. The language of presentation should be either English or German. Your proposal should include (in your presentation language of choice): - An abstract of max. 1500 characters. - A short bio/cv - Contact information (including at least email address) - A list of 3-5 concrete ideas of how your work can be applied in a developer's daily life - additional material (websites, blogs, slides, videos of past presentations, …) - Don't be confused: The system calls a submission event. Organisation - Direct questions to contact at bobkonf dot de - Proposal deadline: December 6, 2021 - Notification: December 17, 2021 - Program: December 22, 2021 Submit here: https://bobcfc.active-group.de/en/bob2022/cfp Program Committee - (more information here: https://bobkonf.de/2022/programmkomitee.html) - Matthias Fischmann, Wire - Matthias Neubauer, SICK AG - Nicole Rauch, Softwareentwicklung und Entwicklungscoaching - Michael Sperber, Active Group - Stefan Wehr, Hochschule Offenburg Scientific Advisory Board - Annette Bieniusa, TU Kaiserslautern - Torsten Grust, Uni Tübingen - Peter Thiemann, Uni Freiburg -- You received this message because you are subscribed to the Google Groups "Clojure" group. To post to this group, send email to clojure@googlegroups.com Note that posts from new members are moderated - please be patient with your first post. To unsubscribe from this group, send email to clojure+unsubscr...@googlegroups.co
