Hello guys, thanks for the response,
After brainstorming for a while, I think we can implement this without
changes in the language, and create static analysis tools for it,
What's wrong with my approach before is using the suffix "Pure" as a pure
function marker, which is unreliable because
On Mon, Jul 6, 2020 at 6:46 PM wrote:
>
> to my understanding, a pure function is a function that doesn't have a
> side effect, so we can limit pure function to:
> - unable to call non-pure function
> - unable to modify a variable that is not declared on current function
> (like a global
> the name "pure" may be debatable, but the characteristic is the same
with "constexpr" in C++, although I also don't have a strong reason why
this is important beside separation IO and non-IO
D is a lange that has true pure functions, see
https://dlang.org/spec/function.html#pure-functions
The standard math library is a natural, easy gateway; a simple preprocessor
could do it. maybe i'll prototype it.
On Tue, Jul 7, 2020 at 4:43 AM Brian Candler wrote:
> On Tuesday, 7 July 2020 01:46:48 UTC+1, Kurniagusta Dwinto wrote:
>>
>> > i would value "pure" if it were a contract for early
On Tuesday, 7 July 2020 01:46:48 UTC+1, Kurniagusta Dwinto wrote:
>
> > i would value "pure" if it were a contract for early evaluation
> does this "early evaluation" concern about IO? like loading blob data with
> ioutil.ReadFile into global variable at compile time?
>
I think by definition,
> i would value "pure" if it were a contract for early evaluation
does this "early evaluation" concern about IO? like loading blob data with
ioutil.ReadFile into global variable at compile time?
> Well, C++ is a very different language with very different goals. I
> think history shows that C++
On Mon, Jul 6, 2020 at 5:11 PM Kurniagusta Dwinto
wrote:
>
> > It's not obvious to me that "pure" is a characteristic that is important
> > enough
> > to be singled out and added to the language
>
> the name "pure" may be debatable, but the characteristic is the same with
> "constexpr" in C++,
i would value "pure" if it were a contract for early evaluation. in my post
on this from 2018 (linked above), the reasoning was so that "x :=
math.Sin(0.23)" would be a compile-time event.
On Mon, Jul 6, 2020 at 5:11 PM Kurniagusta Dwinto
wrote:
> > It's not obvious to me that "pure" is a
> It's not obvious to me that "pure" is a characteristic that is important
enough
> to be singled out and added to the language
the name "pure" may be debatable, but the characteristic is the same with
"constexpr" in C++, although I also don't have a strong reason why this is
important beside
On Mon, Jul 6, 2020 at 4:52 PM Kurniagusta Dwinto
wrote:
>
> Adding pure marker will give information to the programmer that the function
> will not do any side effect, the compiler just gives compile error when the
> programmer disagrees about the contract, like doing IO operation on pure
>
Additionally, this feature complement new generic feature,
this feature will help anyone that trying to use functional programming
pattern (like monad pattern) in their code
On Tuesday, July 7, 2020 at 6:52:31 AM UTC+7 Kurniagusta Dwinto wrote:
> Adding pure marker will give information to the
Adding pure marker will give information to the programmer that the
function will not do any side effect, the compiler just gives compile error
when the programmer disagrees about the contract, like doing IO operation
on pure function.
So in the end, this feature focuses on helping the
On Mon, Jul 6, 2020 at 3:11 PM bugpowder wrote:
>
> I'd guess the compiler could then enforce it (see if any non-pure marked
> function is called from a pure one), it could exploit it (e.g. play with
> evaluation order, cache, etc), and other such things?
The compiler can already tell whether
prior discussion:
https://groups.google.com/forum/#!searchin/Golang-Nuts/pure$20functions/golang-nuts/ZVeMxBBVpa4/slidZL9KBAAJ
On Mon, Jul 6, 2020 at 3:11 PM bugpowder wrote:
> I'd guess the compiler could then enforce it (see if any non-pure marked
> function is called from a pure one), it
I'd guess the compiler could then enforce it (see if any non-pure marked
function is called from a pure one), it could exploit it (e.g. play with
evaluation order, cache, etc), and other such things?
On Tue, Jul 7, 2020 at 1:00 AM Ian Lance Taylor wrote:
> On Mon, Jul 6, 2020 at 9:47 AM wrote:
On Mon, Jul 6, 2020 at 9:47 AM wrote:
>
> Hi, I don't know if this kind of idea is already discussed before.
>
> I have an idea of adding pure function marker/type on golang, it is just like
> "constexpr" on C++ or "const fn" on Rust, whether this function is evaluated
> at compile time if the
Hi, I don't know if this kind of idea is already discussed before.
I have an idea of adding pure function marker/type on golang, it is just
like "constexpr" on C++ or "const fn" on Rust, whether this function is
evaluated at compile time if the input is known at compile time is another
17 matches
Mail list logo
