Bloc of code in tiers programming language
Hi, We, Smalltalkers, use bloc of code as easily as we breathe air. I am writing an article on Smalltalk programming for a French mathematics teachers magazine. To illustrate the simplicity of Smalltalk, I would like to compare how the bloc of code 'f' and 'df' below will be implemented in Javascript and Python: f := [ :x | x cos + x ]. df := [ :x | (f value: x + 1e-8) - (f value: x) * 1e8]. Here f is a way to implement a function and df its derivate. Do some of you knows how it will be written in Javascript and Python with their own ad-hoc anonymous function? Thanks Hilaire -- Dr. Geo http://drgeo.eu
Hey, I think in python, you use Lambda Expressions. Here is how I would do it in python3: import math f = lambda x: math.cos(x) + x d_f = lambda x: (f(x + 1e-8) - f(x)) * 1e8 On Wed, May 15, 2019 at 6:33 PM Hilaire <hilaire@drgeo.eu> wrote:
Hi,
We, Smalltalkers, use bloc of code as easily as we breathe air.
I am writing an article on Smalltalk programming for a French mathematics teachers magazine.
To illustrate the simplicity of Smalltalk, I would like to compare how the bloc of code 'f' and 'df' below will be implemented in Javascript and Python:
f := [ :x | x cos + x ]. df := [ :x | (f value: x + 1e-8) - (f value: x) * 1e8].
Here f is a way to implement a function and df its derivate.
Do some of you knows how it will be written in Javascript and Python with their own ad-hoc anonymous function?
Thanks
Hilaire
-- Dr. Geo http://drgeo.eu
In javascript I believe is var f = function(x) { return Math.cos(x) + x; } var df = function(x) { return f(x + 1e-8) - f(x) * 1e8; } Best wishes, Tomaz ------ Original Message ------ From: "Atharva Khare" <khareatharva@gmail.com> To: "Any question about pharo is welcome" <pharo-users@lists.pharo.org> Sent: 15.5.2019 15:26:11 Subject: Re: [Pharo-users] Bloc of code in tiers programming language
Hey,
I think in python, you use Lambda Expressions. Here is how I would do it in python3: import math f = lambda x: math.cos(x) + x d_f = lambda x: (f(x + 1e-8) - f(x)) * 1e8
On Wed, May 15, 2019 at 6:33 PM Hilaire <hilaire@drgeo.eu> wrote:
Hi,
We, Smalltalkers, use bloc of code as easily as we breathe air.
I am writing an article on Smalltalk programming for a French mathematics teachers magazine.
To illustrate the simplicity of Smalltalk, I would like to compare how the bloc of code 'f' and 'df' below will be implemented in Javascript and Python:
f := [ :x | x cos + x ]. df := [ :x | (f value: x + 1e-8) - (f value: x) * 1e8].
Here f is a way to implement a function and df its derivate.
Do some of you knows how it will be written in Javascript and Python with their own ad-hoc anonymous function?
Thanks
Hilaire
-- Dr. Geo http://drgeo.eu
On 15. 5. 2019 15:44, Tomaž Turk wrote:
In javascript I believe is
var f = function(x) { return Math.cos(x) + x; } var df = function(x) { return f(x + 1e-8) - f(x) * 1e8; }
You should use modern JS for comparision, though, so: const f = x => Math.cos(x) + x; const df = x => (f(x + 1e-8) - f(x)) * 1e8; (fixed the operator precedence as well) Herby P.S.: I would parametrize the epsilon, as well as function, so const deriv = epsilon => f => x => (f(x + epsilon) - f(x)) * epsilon; const df = deriv(1e8)(f);
Best wishes, Tomaz
------ Original Message ------ From: "Atharva Khare" <khareatharva@gmail.com <mailto:khareatharva@gmail.com>> To: "Any question about pharo is welcome" <pharo-users@lists.pharo.org <mailto:pharo-users@lists.pharo.org>> Sent: 15.5.2019 15:26:11 Subject: Re: [Pharo-users] Bloc of code in tiers programming language
Hey,
I think in python, you use Lambda Expressions. Here is how I would do it in python3: import math f = lambda x: math.cos(x) + x d_f = lambda x: (f(x + 1e-8) - f(x)) * 1e8
On Wed, May 15, 2019 at 6:33 PM Hilaire <hilaire@drgeo.eu <mailto:hilaire@drgeo.eu>> wrote:
Hi,
We, Smalltalkers, use bloc of code as easily as we breathe air.
I am writing an article on Smalltalk programming for a French mathematics teachers magazine.
To illustrate the simplicity of Smalltalk, I would like to compare how the bloc of code 'f' and 'df' below will be implemented in Javascript and Python:
f := [ :x | x cos + x ]. df := [ :x | (f value: x + 1e-8) - (f value: x) * 1e8].
Here f is a way to implement a function and df its derivate.
Do some of you knows how it will be written in Javascript and Python with their own ad-hoc anonymous function?
Thanks
Hilaire
-- Dr. Geo http://drgeo.eu
Am 15.05.19 um 15:26 schrieb Atharva Khare:
I think in python, you use Lambda Expressions. Here is how I would do it in python3: import math f = lambda x: math.cos(x) + x d_f = lambda x: (f(x + 1e-8) - f(x)) * 1e8
Lambda expressions are indeed Python's anonymous functions, but no Python programmer would create a lambda expression only to assign it to a variable. Doing this in an article to "sell" Smalltalk might well have the opposite effect. Konrad.
Le 15/05/2019 à 20:37, Konrad Hinsen a écrit :
Lambda expressions are indeed Python's anonymous functions, but no Python programmer would create a lambda expression only to assign it to a variable. Doing this in an article to "sell" Smalltalk might well have the opposite effect.
Nor a Smalltalk programmer. Bellow the context for FYI. | sketch f df xn ptA ptB| sketch := DrGeoSketch new axesOn. xn := 2. f := [ :x | x cos + x ]. df := [ :x | (f value: x + 1e-8) - (f value: x) * 1e8]. "Derivate number" sketch plot: f from: -20 to: 20. ptA := (sketch point: xn@0) large; name: 'Drag me'. 5 timesRepeat: [ Â Â Â ptB := sketch point: [ :pt | pt point x @ (f value: pt point x)] parent: ptA. Â Â Â ptB hide. Â Â Â (sketch segment: ptA to: ptB) dotted forwardArrow . Â Â Â ptA := sketch point: [:pt | Â Â Â Â Â Â | x | Â Â Â Â Â Â x := pt point x. Â Â Â Â Â Â x - ( (f value: x) / (df value: x) )Â @ 0 ] parent: ptB. Â Â Â ptA hide. Â Â Â (sketch segment: ptB to: ptA) dotted forwardArrow]. -- Dr. Geo http://drgeo.eu
Suppose you want a pair of mutually recursive functions. They have to be able to name each other. In languages like Python and Ruby, you can have methods AND you can have named functions. In fact Python had named functions before it had objects. But in Smalltalk, you have methods, which cannot be invoked without mentioning the receiver, and you have blocks, which do NOT have a receiver of their own. So you have to write f := [:... | ... g value: ... ]. g := [:... | ... f value: ... ]. This also applies when f needs to call itself. At this point, Smalltalk beginners are so used to seeing blocks used directly as arguments that they use methods instead. On Thu, 16 May 2019 at 07:49, Hilaire <hilaire@drgeo.eu> wrote:
Le 15/05/2019 à 20:37, Konrad Hinsen a écrit :
Lambda expressions are indeed Python's anonymous functions, but no Python programmer would create a lambda expression only to assign it to a variable. Doing this in an article to "sell" Smalltalk might well have the opposite effect.
Nor a Smalltalk programmer.
Bellow the context for FYI.
| sketch f df xn ptA ptB| sketch := DrGeoSketch new axesOn. xn := 2. f := [ :x | x cos + x ]. df := [ :x | (f value: x + 1e-8) - (f value: x) * 1e8]. "Derivate number" sketch plot: f from: -20 to: 20. ptA := (sketch point: xn@0) large; name: 'Drag me'. 5 timesRepeat: [ ptB := sketch point: [ :pt | pt point x @ (f value: pt point x)] parent: ptA. ptB hide. (sketch segment: ptA to: ptB) dotted forwardArrow . ptA := sketch point: [:pt | | x | x := pt point x. x - ( (f value: x) / (df value: x) ) @ 0 ] parent: ptB. ptA hide. (sketch segment: ptB to: ptA) dotted forwardArrow].
-- Dr. Geo http://drgeo.eu
Richard, Question from someone still fairly new to Smalltalk: To implement the example you gave regarding mutually recursive functions in Lua, one must write something like this: local f, g function g () <do something> f() <do something> end function f () <do something> g() <do something> end where the initial declaration of f & g as locals defines an f such that g will see it (as a local, albeit containing nil) when g is defined. The following definition of f doesn't require this, of course. And g doesn't care what f contains -- until execution time. Both Lua and Smalltalk implement full lexical closures, so it begs the question: Do the blocks defined in your example have this same issue? What is 'g' in the block assigned to f? Is it required that 'g' be lexically defined prior to referencing it in a block closure, or does Smalltalk have a mechanism to resolve this at execution time? Thanks, -Ted -- Sent from: http://forum.world.st/Pharo-Smalltalk-Users-f1310670.html
I do wish people wouldn't say "beg the question" https://grammarist.com/rhetoric/begging-the-question-fallacy/ when they mean "invites" or "raises" the question. Sigh. Yes, Smalltalk is just like Lua here. |f g| "declare f and g as local variables" f := [... g value ...]. "f uses g's current value" g := [... f value ...]. "g uses f's current value" You cannot mix declarations and statements in Smalltalk. Local variables have to be declared before use. On Thu, 16 May 2019 at 11:31, Brainstorms <wild.ideas@gmail.com> wrote:
Richard,
Question from someone still fairly new to Smalltalk:
To implement the example you gave regarding mutually recursive functions in Lua, one must write something like this:
local f, g
function g () <do something> f() <do something> end
function f () <do something> g() <do something> end
where the initial declaration of f & g as locals defines an f such that g will see it (as a local, albeit containing nil) when g is defined. The following definition of f doesn't require this, of course. And g doesn't care what f contains -- until execution time.
Both Lua and Smalltalk implement full lexical closures, so it begs the question: Do the blocks defined in your example have this same issue? What is 'g' in the block assigned to f?
Is it required that 'g' be lexically defined prior to referencing it in a block closure, or does Smalltalk have a mechanism to resolve this at execution time?
Thanks, -Ted
-- Sent from: http://forum.world.st/Pharo-Smalltalk-Users-f1310670.html
I beg your pardon.. and thank you for being the first to draw my attention to the fact that the phrase (a common enough American colloquialism) is actually a logical fallacy. Until now, it's been strictly idiomatic to me. And thank you for your prompt reply. Am I safe to assume that blocks in Smalltalk, as with Lua, capture their locally-scoped variables (referred to in Lua as "non-local variables") for correct evaluation in other contexts, such as when blocks are passed as arguments and return values? I.e., cases where the local variables of a method have gone out of scope and no longer exist, yet are referenced within the block at some future time when evaluated. I expect so; I just haven't seen it described in this detail. -t -- Sent from: http://forum.world.st/Pharo-Smalltalk-Users-f1310670.html
On Fri, 17 May 2019 at 01:21, Brainstorms <wild.ideas@gmail.com> wrote:
I beg your pardon.. and thank you for being the first to draw my attention to the fact that the phrase (a common enough American colloquialism) is actually a logical fallacy. Until now, it's been strictly idiomatic to me.
And thank you for your prompt reply.
Am I safe to assume that blocks in Smalltalk, as with Lua, capture their locally-scoped variables (referred to in Lua as "non-local variables") for correct evaluation in other contexts, such as when blocks are passed as arguments and return values? I.e., cases where the local variables of a method have gone out of scope and no longer exist, yet are referenced within the block at some future time when evaluated. I expect so; I just haven't seen it described in this detail.
You mean like this... In System Browser... Object subclass: #A instanceVariableNames: '' classVariableNames: '' package: 'AA' A >> block |a| ^ [ a := (a ifNil: [ 0 ]) + 1 ] In Playground... b := A new block inspect. { b value. b value. b value . b } "==> an Array( 1 2 3 [ a := (a ifNil: [ 0 ]) + 1 ] )" cheers -ben
You got it. Thanks, Ben! After success with Lua, now I'm thinking about how to get Pharo inserted into the culture here... Ben Coman wrote
You mean like this...
In System Browser... Object subclass: #A instanceVariableNames: '' classVariableNames: '' package: 'AA'
A >> block |a| ^ [ a := (a ifNil: [ 0 ]) + 1 ]
In Playground... b := A new block inspect. { b value. b value. b value . b } "==> an Array( 1 2 3 [ a := (a ifNil: [ 0 ]) + 1 ] )"
cheers -ben
-- Sent from: http://forum.world.st/Pharo-Smalltalk-Users-f1310670.html
Hi, Is nice to see this similitude between Lua and Pharo. We have been using both in the Grafoscopio[1] project, because Lua is Pandoc's default choice for embedded scripting language, and is pretty fast on the Abstract Syntax Tree filters. [1] https://mutabit.com/grafoscopio/index.en.html For me Lua and Pharo are kind on opposite sides of the programming spectrum/experience but is nice to see this conceptual connections. Hopefully we, at the local hackerspace, will be able to explore the Lua+Pharo bridge more and showcase them here. Cheers, Offray On 16/05/19 1:18 p. m., Brainstorms wrote:
You got it. Thanks, Ben!
After success with Lua, now I'm thinking about how to get Pharo inserted into the culture here...
Ben Coman wrote
You mean like this...
In System Browser... Object subclass: #A instanceVariableNames: '' classVariableNames: '' package: 'AA'
A >> block |a| ^ [ a := (a ifNil: [ 0 ]) + 1 ]
In Playground... b := A new block inspect. { b value. b value. b value . b } "==> an Array( 1 2 3 [ a := (a ifNil: [ 0 ]) + 1 ] )"
cheers -ben
-- Sent from: http://forum.world.st/Pharo-Smalltalk-Users-f1310670.html
Hi Offray, You probably know that you can develop Lua using OOP techniques, so they're not so opposite for me, at least. There is a significant difference as far as their OOP styles, however: Lua OOP is prototype-based, not class-based. But you can fashion class(like) objects in Lua and program as though classes existed -- albeit with some quirks taken into account (beyond the obvious message-vs-function call difference). The important thing is that you can enjoy the benefits of using OO design patterns with Lua. Lua has dynamic typing, every data type is first-class, it has a nil value, inheritance (via metatables), closures, coroutines, limited reflection (which you could possibly enhance through its C interface), and a nice C API for gluing other code/languages together. Much of its functionality is obtained through included external libraries (most of which are written in C). What I hope to see is a nice FFI for Pharo that allows connection to Lua code. With that, I can glue Pharo to anything... We've been using it to automate LabVIEW applications. I want to automate LabVIEW with Pharo as well. -t Offray Vladimir Luna Cárdenas-2 wrote
Is nice to see this similitude between Lua and Pharo. We have been using both in the Grafoscopio[1] project, because Lua is Pandoc's default choice for embedded scripting language, and is pretty fast on the Abstract Syntax Tree filters.
[1] https://mutabit.com/grafoscopio/index.en.html
For me Lua and Pharo are kind on opposite sides of the programming spectrum/experience but is nice to see this conceptual connections. Hopefully we, at the local hackerspace, will be able to explore the Lua+Pharo bridge more and showcase them here.
Cheers,
Offray
-- Sent from: http://forum.world.st/Pharo-Smalltalk-Users-f1310670.html
Hi t, Yes, I know that Lua support OOP, with several implementations and using metatables. I have not looked in detail. But the idea of shared similarities while being at opposite extremes of the programming spectrum/experience is more related with both sharing minimalist concepts applied everywhere (objects and messages for Pharo, tables and functions for Lua), but one provided a full IDE/GUI and being tied with a programming paradigm, which makes it great for agile prototyping, while the other offers just the bare minimum and you arm your puzzle from there regarding tools, paradigms, which makes it great for embedding. Cheers, Offray On 17/05/19 3:29 p. m., Brainstorms wrote:
Hi Offray,
You probably know that you can develop Lua using OOP techniques, so they're not so opposite for me, at least. There is a significant difference as far as their OOP styles, however: Lua OOP is prototype-based, not class-based.
But you can fashion class(like) objects in Lua and program as though classes existed -- albeit with some quirks taken into account (beyond the obvious message-vs-function call difference). The important thing is that you can enjoy the benefits of using OO design patterns with Lua.
Lua has dynamic typing, every data type is first-class, it has a nil value, inheritance (via metatables), closures, coroutines, limited reflection (which you could possibly enhance through its C interface), and a nice C API for gluing other code/languages together. Much of its functionality is obtained through included external libraries (most of which are written in C).
What I hope to see is a nice FFI for Pharo that allows connection to Lua code. With that, I can glue Pharo to anything... We've been using it to automate LabVIEW applications. I want to automate LabVIEW with Pharo as well.
-t
Offray Vladimir Luna Cárdenas-2 wrote
Is nice to see this similitude between Lua and Pharo. We have been using both in the Grafoscopio[1] project, because Lua is Pandoc's default choice for embedded scripting language, and is pretty fast on the Abstract Syntax Tree filters.
[1] https://mutabit.com/grafoscopio/index.en.html
For me Lua and Pharo are kind on opposite sides of the programming spectrum/experience but is nice to see this conceptual connections. Hopefully we, at the local hackerspace, will be able to explore the Lua+Pharo bridge more and showcase them here.
Cheers,
Offray
-- Sent from: http://forum.world.st/Pharo-Smalltalk-Users-f1310670.html
Hi Offray, Yes, I definitely agree with you that Lua does not have the nice development environment of Pharo (what other language does?), and is very bare-bones, as it was originally intended for embedded applications. I've gone through nearly all of the online version of the Pharo MOOC now, and the ease of building a web app with Pharo+Seaside is /amazing/. (That's reason enough to adopt Pharo!) I'm now looking at Spec and how to work with that to make GUI apps. I can't do web apps in Lua, nor is there a GUI in Lua. For that matter, with Lua there is no interaction with the OS, no sockets, and very minimal file system interaction (that's actually built into Lua -- it doesn't even know what a directory is). All of these capabilities can be had in Lua, but they must be provided by external libraries -- even the ability to interact via a terminal command line is typically done via a small C app that wraps a Lua "state". Lua is tiny. Tiny, but powerful. So I see that as an advantage, and a compliment to Pharo. Seaside may be an external library to Pharo, but much of "the rest" is built-in, and comes with a nice OS/IDE to wrap it all up and keep things together. Did not Smalltalk-80 invent the concept of a container, which is becoming all the rage in IT today? Yet another first for ST..? So I guess that's my beginner impression of Pharo: a great environment that lives in a container. (I'm learning how to implement containers and implement /in/ containers now, too.) How easy is it to cross that boundary and interact with the rest of the world? Maybe another way Lua and Pharo are dissimilar? Example: I automate hardware... Can I use Pharo to interact with instrumentation over USB? -Ted Offray Vladimir Luna Cárdenas-2 wrote
Hi t,
Yes, I know that Lua support OOP, with several implementations and using metatables. I have not looked in detail. But the idea of shared similarities while being at opposite extremes of the programming spectrum/experience is more related with both sharing minimalist concepts applied everywhere (objects and messages for Pharo, tables and functions for Lua), but one provided a full IDE/GUI and being tied with a programming paradigm, which makes it great for agile prototyping, while the other offers just the bare minimum and you arm your puzzle from there regarding tools, paradigms, which makes it great for embedding.
Cheers,
Offray
-- Sent from: http://forum.world.st/Pharo-Smalltalk-Users-f1310670.html
Hi Ted, On 17/05/19 6:38 p. m., Brainstorms wrote:
Hi Offray,
Yes, I definitely agree with you that Lua does not have the nice development environment of Pharo (what other language does?), and is very bare-bones, as it was originally intended for embedded applications.
Yep, Pharo and other Smalltalk based IDEs are unbeatable as programming experiences. What they have changed in my, is my look for other similar experiences. In fact was going from an interactive first computing experience that I explored things like Squeak, Etoys, Bots Inc, IPython/Jupyter and Pharo. Trying to get something similar in Lua has point me towards Zero Brane Studio (ZBS), which is (like Pharo) a Lua IDE made on Lua itself.
I've gone through nearly all of the online version of the Pharo MOOC now, and the ease of building a web app with Pharo+Seaside is /amazing/. (That's reason enough to adopt Pharo!) I'm now looking at Spec and how to work with that to make GUI apps. I can't do web apps in Lua, nor is there a GUI in Lua.
Spec and making GUI was the way I started my exploration with Pharo. Particularly using the Spec-GT bridge to create interactive notebooks in Grafoscopio. In my case, works better when you have a "real world" example to learn/solve in your programming environment. ZBS is made on Lua using Wx Widgets for Lua, but as you point after, it is an extra library. On the web front I saw some Seaside and Aida Web, but now I'm more into and even more minimalist approach using Teapot. Even I have a pretty alpha stuff combining Teapot with Material Design Light and Fossil at: https://mutabit.com/repos.fossil/brea/
For that matter, with Lua there is no interaction with the OS, no sockets, and very minimal file system interaction (that's actually built into Lua -- it doesn't even know what a directory is). All of these capabilities can be had in Lua, but they must be provided by external libraries -- even the ability to interact via a terminal command line is typically done via a small C app that wraps a Lua "state". Lua is tiny. Tiny, but powerful.
Yes I like this pretty minimal setup for Lua. In fact I found it (again) while working on reproducible research and publishing, as the extension language for Pandoc and LaTeX (via LuaTeX).
So I see that as an advantage, and a compliment to Pharo. Seaside may be an external library to Pharo, but much of "the rest" is built-in, and comes with a nice OS/IDE to wrap it all up and keep things together. Did not Smalltalk-80 invent the concept of a container, which is becoming all the rage in IT today? Yet another first for ST..?
I remember some talk in Twitter with the Docker people about how Smalltalk was an inspiration of the containers idea, but I can't locate it again.
So I guess that's my beginner impression of Pharo: a great environment that lives in a container. (I'm learning how to implement containers and implement /in/ containers now, too.) How easy is it to cross that boundary and interact with the rest of the world? Maybe another way Lua and Pharo are dissimilar?
In my case, I interact with the external world via formats and DOMs using parsers for JSON, HTML, CVS and so on and some times callings to the OS. No obstacles there. Pharo is a pretty well suited environment to interact with the external world on data visualization/processing issues for reproducible research and publishing, while it helps me in keep incidental complexity away, being a pretty self contained environment.
Example: I automate hardware... Can I use Pharo to interact with instrumentation over USB?
Yes. There is a Pharo things project and Phratch (Arduido + Pharo + Scratch) which use Pharo to interact with hardware. Cheers, Offray
Blocks in current Smalltalk system are just like lambdas in Scheme. Pharo even has continuations (see the Continuation class). On Fri, 17 May 2019 at 05:21, Brainstorms <wild.ideas@gmail.com> wrote:
I beg your pardon.. and thank you for being the first to draw my attention to the fact that the phrase (a common enough American colloquialism) is actually a logical fallacy. Until now, it's been strictly idiomatic to me.
And thank you for your prompt reply.
Am I safe to assume that blocks in Smalltalk, as with Lua, capture their locally-scoped variables (referred to in Lua as "non-local variables") for correct evaluation in other contexts, such as when blocks are passed as arguments and return values? I.e., cases where the local variables of a method have gone out of scope and no longer exist, yet are referenced within the block at some future time when evaluated. I expect so; I just haven't seen it described in this detail.
-t
-- Sent from: http://forum.world.st/Pharo-Smalltalk-Users-f1310670.html
Richard O'Keefe wrote
Blocks in current Smalltalk system are just like lambdas in Scheme. Pharo even has continuations (see the Continuation class).
I was going to ask about coroutines and continuations, but I thought maybe bringing these subjects up in another thread would be more appropriate. (This forum is also new to me. More so than Smalltalk & Pharo.) Is the "Continuation class" part of the MOOC series? Or a class held at the ESUG conference? I don't recall running across anything referring to the subject. -t -- Sent from: http://forum.world.st/Pharo-Smalltalk-Users-f1310670.html
I did not mean "course of instruction on the topic of continuations", I meant "that class whose name is Continuation in the Smalltalk image." In a Playground, type Continuation and then Control-B. On Fri, 17 May 2019 at 14:03, Brainstorms <wild.ideas@gmail.com> wrote:
Richard O'Keefe wrote
Blocks in current Smalltalk system are just like lambdas in Scheme. Pharo even has continuations (see the Continuation class).
I was going to ask about coroutines and continuations, but I thought maybe bringing these subjects up in another thread would be more appropriate. (This forum is also new to me. More so than Smalltalk & Pharo.)
Is the "Continuation class" part of the MOOC series? Or a class held at the ESUG conference? I don't recall running across anything referring to the subject.
-t
-- Sent from: http://forum.world.st/Pharo-Smalltalk-Users-f1310670.html
Richard O'Keefe wrote
I did not mean "course of instruction on the topic of continuations", I meant "that class whose name is Continuation in the Smalltalk image." In a Playground, type Continuation and then Control-B.
Of course... My inexperience again, coupled with hopes for a course of instruction with examples. However, the browser and source code are sufficient, and I do need to read more ST code. Having read your answers to others' questions, I'm impressed with the depth of your knowledge and your eloquence (and patience) in explaining the concepts and techniques. The level of detail, examples, and notes on usage are what I've been looking for. -t -- Sent from: http://forum.world.st/Pharo-Smalltalk-Users-f1310670.html
On a similar line - Iâve often noticed that an interesting block pattern in Smalltalk which is overlooked in other languages is how we handle errors through them. We often donât throw exceptions but instead pass a useful block (and often 2) for what to do instead. at:ifAbsent: comes to mind or at:ifPreset:ifAbsent: leading you to do interesting things yourself like parseSource:onErrorRecoverWith: (or whatever). I think this makes an interesting point about our block flexibility. Tim Sent from my iPhone Sent from my iPhone
On 15 May 2019, at 19:37, Konrad Hinsen <konrad.hinsen@fastmail.net> wrote:
Am 15.05.19 um 15:26 schrieb Atharva Khare:
I think in python, you use Lambda Expressions. Here is how I would do it in python3: import math f = lambda x: math.cos(x) + x d_f = lambda x: (f(x + 1e-8) - f(x)) * 1e8
Lambda expressions are indeed Python's anonymous functions, but no Python programmer would create a lambda expression only to assign it to a variable. Doing this in an article to "sell" Smalltalk might well have the opposite effect.
Konrad.
On Wed, May 15, 2019 at 5:21 PM Tim Mackinnon <tim@testit.works> wrote:
On a similar line - Iâve often noticed that an interesting block pattern in Smalltalk which is overlooked in other languages is how we handle errors through them.
We often donât throw exceptions but instead pass a useful block (and often 2) for what to do instead.
at:ifAbsent: comes to mind or at:ifPreset:ifAbsent: leading you to do interesting things yourself like parseSource:onErrorRecoverWith: (or whatever).
I think this makes an interesting point about our block flexibility.
Although it is not exactly the same, the async style of programming JavaScript uses similar approaches by passing "callback functions" as arguments to certain functions. e.g. fopen('/path/to/file', successFunction, errorHandler). As said, it is not exactly the same thing, and 100% callback programs can be a hell to work with, but the idiom of passing "lambdas" around is similar. Regards, Esteban A. Maringolo
Hi, Blocks are very useful when you need to evaluate code from an outside source. For example a BPM Process that have gateways with different conditions. To the Smalltalk system conditions come as Strings and convert them to Smalltalk objects is very easy: self evaluate: '[:process | process amount > 1500]'. "condition inside a gateway of a process" And we have the block to evaluate and get the Boolean (to see what transition follow after the gateway). In other languages you have to process the condition String and do some kind of interpretation but is much more limited than a block. Of course there is a security issue here but very easy to overcome with an AST. If the conditions is: 'Smalltalk become: nil'. In my case all message can be sent to the block argument only and some other simple rules. regards, bruno -- Sent from: http://forum.world.st/Pharo-Smalltalk-Users-f1310670.html
One point worth making is that Python lambdas are artificially restricted: the body of a Python lambda may only be a single expression, not a sequence of statements. This restriction is for ideological reasons (the BDFL does not *want* you to do that) not for technical reasons. Lisp and Algol 68 were doing lambda expressions in the 60s. As well as function (x, y) { ... }, modern Javascript has (x, y) => ... with subtly different semantics. On Thu, 16 May 2019 at 01:03, Hilaire <hilaire@drgeo.eu> wrote:
Hi,
We, Smalltalkers, use bloc of code as easily as we breathe air.
I am writing an article on Smalltalk programming for a French mathematics teachers magazine.
To illustrate the simplicity of Smalltalk, I would like to compare how the bloc of code 'f' and 'df' below will be implemented in Javascript and Python:
f := [ :x | x cos + x ]. df := [ :x | (f value: x + 1e-8) - (f value: x) * 1e8].
Here f is a way to implement a function and df its derivate.
Do some of you knows how it will be written in Javascript and Python with their own ad-hoc anonymous function?
Thanks
Hilaire
-- Dr. Geo http://drgeo.eu
Hi, It is an important restriction on Python. So Javasctip has several way of doing lambda, correct? Thanks Hilaire Le 15/05/2019 à 16:19, Richard O'Keefe a écrit :
One point worth making is that Python lambdas are artificially restricted: the body of a Python lambda may only be a single expression, not a sequence of statements. This restriction is for ideological reasons (the BDFL does not *want* you to do that) not for technical reasons. Lisp and Algol 68 were doing lambda expressions in the 60s.
As well as function (x, y) { ... }, modern Javascript has (x, y) => .... with subtly different semantics.
-- Dr. Geo http://drgeo.eu
Here's a nice description about JS: https://www.vinta.com.br/blog/2015/javascript-lambda-and-arrow-functions/ Best wishes, Tomaz ------ Original Message ------ From: "Hilaire" <hilaire@drgeo.eu> To: pharo-users@lists.pharo.org Sent: 15.5.2019 18:54:58 Subject: Re: [Pharo-users] Bloc of code in tiers programming language
Hi,
It is an important restriction on Python. So Javasctip has several way of doing lambda, correct?
Thanks
Hilaire
Le 15/05/2019 à 16:19, Richard O'Keefe a écrit :
One point worth making is that Python lambdas are artificially restricted: the body of a Python lambda may only be a single expression, not a sequence of statements. This restriction is for ideological reasons (the BDFL does not *want* you to do that) not for technical reasons. Lisp and Algol 68 were doing lambda expressions in the 60s.
As well as function (x, y) { ... }, modern Javascript has (x, y) => .... with subtly different semantics.
-- Dr. Geo http://drgeo.eu
participants (12)
-
Atharva Khare -
Ben Coman -
Brainstorms -
BrunoBB -
Esteban Maringolo -
Herby VojÄÃk -
Hilaire -
Konrad Hinsen -
Offray Vladimir Luna Cárdenas -
Richard O'Keefe -
Tim Mackinnon -
Tomaž Turk